Hi Tom, > From: tom p., April 27, 2016 12:55 PM > > This I-D gives a fresh definition of 'datastore' in s.3 > > A YANG datastore is a conceptual datastore that contains hierarchical > data defined in YANG data models. It is what is referred in existing > RFCs as "NETCONF datastore". However, as the same datastore is no > longer tied to NETCONF as a specific transport, the term "YANG > datastore" is deemed more appropriate. > > which I think unhelpful. There is no such term as 'NETCONF datastore'; rather > there is 'datastore' defined (in RFC6241) as > > o datastore: A conceptual place to store and access information. A > datastore might be implemented, for example, using files, a > database, flash memory locations, or combinations thereof. > > and widely used now in OAM RFC and I-D. It can be used with the NETCONF > protocol ( which is not just a transport), it can be used with RESTCONF and could > in future be used with other application protocols. > > YANG 1.0 (RFC6020) could have, should have, imported that definition in > s.3 (as other RFC and I-D do); rather it uses the phrase 'NETCONF datastore' > which makes it clear where the definition comes from but that does not tie it to > a particular protocol nor does it qualify its meaning. In the context of YANG, it is > the unit of constraint checking. > > Although NETCONF and YANG have grown up in tandem, NETCONF could be > used with another DDL but with the same concept of datastore just as the > concept of datastore can be used with another prototocol, such as RESTCONF. > > So if this I-D wants to use 'datastore' as defined in RFC6241, then it should > import and use it; if it wants another concept, then it should mint a fresh term > and define that. From reading the I-D, I suspect that the latter is the case, that > the concept is nothing to do with 'datastore' (as currently defined in the IETF) > and is just configuration and state data on a device modelled with YANG as a > DDL. Nice catch, I agree with your analysis above. As an FYI references to 'NETCONF datastore' came from within RFCs 6020, 6022, and RFC 6536. A re-reading shows that NETCONF 'datastore' would be closer to the originally defined meaning. I see no reason why draft-ietf-i2rs-pub-sub-requirements cannot import the definition of datastore from RFC 6241. This would impact nothing in the draft except replacing the term definition of "YANG datastore" you reference above with the text: " The term datastore is defined in [RFC6241] and is not redefined here". Would that be a sufficient fix? Eric > (In passing, one of the work items that the netmod WG circles around, and will I > am sure one day take on and complete, is the removal of NETCONF from the > documentation of YANG so that YANG is a standalone DDL - but still importing > the concept of datastore). > Tom Petch > > ----- Original Message ----- > From: "The IESG" <iesg-secretary@xxxxxxxx> > To: "IETF-Announce" <ietf-announce@xxxxxxxx> > Cc: <i2rs@xxxxxxxx>; <draft-ietf-i2rs-pub-sub-requirements@xxxxxxxx>; > <i2rs-chairs@xxxxxxxx>; <shares@xxxxxxxx>; <akatlas@xxxxxxxxx> > Sent: Friday, April 15, 2016 6:58 PM > Subject: Last Call: <draft-ietf-i2rs-pub-sub-requirements-05.txt> > (Requirements for Subscription to YANG Datastores) to Proposed Standard > > > > > > The IESG has received a request from the Interface to the Routing > System > > WG (i2rs) to consider the following document: > > - 'Requirements for Subscription to YANG Datastores' > > <draft-ietf-i2rs-pub-sub-requirements-05.txt> as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@xxxxxxxx mailing lists by 2016-04-29. Exceptionally, comments may > be > > sent to iesg@xxxxxxxx instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > This document provides requirements for a service that allows > client > > applications to subscribe to updates of a YANG datastore. Based on > > criteria negotiated as part of a subscription, updates will be > pushed > > to targeted recipients. Such a capability eliminates the need for > > periodic polling of YANG datastores by applications and fills a > > functional gap in existing YANG transports (i.e. Netconf and > > Restconf). Such a service can be summarized as a "pub/sub" service > > for YANG datastore updates. Beyond a set of basic requirements for > > the service, various refinements are addressed. These refinements > > include: periodicity of object updates, filtering out of objects > > underneath a requested a subtree, and delivery QoS guarantees. > > > > > > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ > > > > IESG discussion can be tracked via > > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ba > llot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > >