Hi Benoit,

Comments in-line...

> Benoit Claise has entered the following ballot position for
> draft-ietf-i2rs-pub-sub-requirements-06: Discuss
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Three DISCUSS points, which could be easily resolved IMO.
> 
> 1. As mentioned on the NETMOD mailing list by Tom Petch, don't redefine the
> YANG datastore term:
> > I see that the definition of 'datastores' has cropped up in this AD
> > Review, as in the e-mail below.
> >
> > Meanwhile, draft-ietf-i2rs-pub-sub-requirements-05.txt is in IETF Last
> > Call and redefines, or recreates, the term for us
> >
> >     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.
> >
> > I think that the concept of datastore has been troublesome to those
> > coming to YANG lately, such as openconfig and I2RS, and that this will
> > just muddy the waters more, especially as it is tucked away in an
> > Informational document.  If I2RS want to define such terminology, then
> > it should be in the I2RS Architecture or some such; but IMHO they
> should
> > not be defining YANG datastores at all.

The new updated v07 includes a reference to the RFC6241 definition of datastore.
 
> 2. Maybe I read too much into this (at the time of specifying the operational
> state in NETMOD) ...
> 
>    A Subscription Service MUST be able support a Subtree Filter so that
>    subscribed updates under a target node might publish only operational
>    data, only configuration data, or both.
> 
> Proposal: s/Subtree Filter/Filter

Updated. 

> 3. In the security considerations section
> 
>    Versioning MUST be supported.
> 
> Versioning of what? Yang push protocol, subscription, transport session, 
> state of
> of subscription, something else?

Updated.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> - Editorial
>    Based on
>    current I2RS requirements, NETCONF should the initially supported
>    transport based on the need for connection-oriented/unicast
>    communication.
> 
> s/should/should be

Fixed
 
> - Editorial:
>    A Subscription MAY include filters as defined
> 
> s/filters/Filters
> 
> Note: there are multiple instances of filter -> Filter

Fixed
 
> - AND is not a RFC2119 keyword
>    For "on-change" notifications, passing
>    through the Filter requires that a subscribed object is now different
>    that from the previous Push, AND at least one of the YANG objects
>    being evaluated has changed since the last Update.

Fixed

> -
> I always wonder what a MAY requirement means? Example:
> 
>    A Subscriber MAY check with a Subscription Service to validate the
>    existence and monitored subtrees of a Subscription.
> 
> Or:
>    A Subscription Service MAY send Updates over Best Effort and Reliable
>    transports.
> 
> What if  https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/
> doesn't address this requirement (I haven't checked), are we good or not?

Yes.   A MAY provides guidance, but is not required.

Eric

> 
> _______________________________________________
> i2rs mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs

_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to