----- Original Message ----- From: "tom p." <[email protected]> To: <[email protected]> Cc: <[email protected]>; <[email protected]>; <[email protected]>; <[email protected]> Sent: Wednesday, April 27, 2016 5: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. > > (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" <[email protected]> > To: "IETF-Announce" <[email protected]> > Cc: <[email protected]>; <[email protected]>; > <[email protected]>; <[email protected]>; <[email protected]> > 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 > > [email protected] mailing lists by 2016-04-29. Exceptionally, comments may > be > > sent to [email protected] 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. > > > > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
