Subject: Re: Last Call: <draft-ietf-i2rs-pub-sub-requirements-05.txt> (Requirements for Subscription to YANG Datastores) to Proposed Standard

From: tom p. <[email-masked]>
Date: Wed, 27 Apr 2016 17:55:20 +0100

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-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
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-masked] mailing lists by 2016-04-29. Exceptionally, comments may
be
> sent to [email-masked] 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.
>
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 27 Apr 2016 18:15:35 +0000

Hi Tom,

> From: tom p., April 27, 2016 12:55 PM
> 
> which I think unhelpful.  There is no such term as  'NETCONF datastore'; rather
> there is 'datastore' defined (in RFC6241) as
> 
> protocol ( which is not just a transport), it can be used with RESTCONF and could
> in future be used with other application protocols.
> 
> 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).