Subject: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Tue, 03 May 2016 01:52:42 -0700

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?

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 4 May 2016 23:24:51 +0000

Hi Benoit,

Comments in-line...

> 1. As mentioned on the NETMOD mailing list by Tom Petch, don't redefine the
> YANG datastore term:

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

Updated. 

> Versioning of what? Yang push protocol, subscription, transport session, state of
> of subscription, something else?

Updated.

Fixed
 
> Note: there are multiple instances of filter -> Filter

Fixed
 
>    being evaluated has changed since the last Update.

Fixed

> 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-masked]
> https://www.ietf.org/mailman/listinfo/i2rs

---

From: Benoit Claise <[email-masked]>
Date: Sun, 8 May 2016 09:50:15 +0200

Hi Eric,

See in line.
> The new updated v07 includes a reference to the RFC6241 definition of datastore.
Thanks. Minor editorial point.

     A datastore is defined in [RFC6241] and is not redefined here.

The second part of the sentence is unnecessary IMO.

>> of subscription, something else?
You have not addressed my point
Your new sentence is:

        Versioning MUST be supported so that the capabilities and behaviors
        expected of specific technology implementations can be exposed.

Regards, Benoit

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 9 May 2016 19:51:38 +0000

From: Benoit Claise, May 08, 2016 3:50 AM

The second part of the sentence is unnecessary IMO.
<EV> now says:
    A datastore is defined in [RFC6241].

Updated.

   expected of specific technology implementations can be exposed.
Versioning of what? Yang push protocol, subscription, transport session, state of of subscription, something else?

<EV> now says:
Versioning of any subscription protocols MUST be supported so that the capabilities and behaviors expected of specific technology implementations can be exposed.

Eric

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Mon, 9 May 2016 16:21:07 -0400

Eric,

Perfect. Thank you.

Regards, Benoit
>
> *From:*Benoit Claise, May 08, 2016 3:50 AM
>
> Versioning of what? Yang push protocol, subscription, transport 
> session, state of of subscription, something else?
>
> <EV> now says:
> Versioning of any subscription protocols MUST be supported so that the 
> capabilities and behaviors expected of specific technology 
> implementations can be exposed.
>
> Eric
>
>
> Regards, Benoit
>
> .