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" <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.
>
>