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(_at_)ietf(_dot_)org>
To: "IETF-Announce" <ietf-announce(_at_)ietf(_dot_)org>
Cc: <i2rs(_at_)ietf(_dot_)org>;
<draft-ietf-i2rs-pub-sub-requirements(_at_)ietf(_dot_)org>;
<i2rs-chairs(_at_)ietf(_dot_)org>; <shares(_at_)ndzh(_dot_)com>;
<akatlas(_at_)gmail(_dot_)com>
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(_at_)ietf(_dot_)org mailing lists by 2016-04-29. Exceptionally,
comments may
be
sent to iesg(_at_)ietf(_dot_)org 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.