Benoit Claise has entered the following ballot position for draft-ietf-i2rs-pub-sub-requirements-06: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ ---------------------------------------------------------------------- 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. 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 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? ---------------------------------------------------------------------- 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 - Editorial: A Subscription MAY include filters as defined s/filters/Filters Note: there are multiple instances of filter -> Filter - 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. - 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? _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
