Subject: [Netconf] WGLC on netconf-event-notifications-13

From: Kent Watsen <[email-masked]>
Date: Thu, 4 Oct 2018 22:10:51 +0000

This message starts a Last Call on draft-ietf-netconf-netconf-event-notifications-13 (a.k.a. "netconf-notif"):

  https://tools.ietf.org/html/draft-ietf-netconf-netconf-event-notifications-13

This, along with the restconf-notif Last Call, started in a separate 
message, marks the last of the last calls on the yang push suite of
drafts. As explained before, given the size and number of documents,
the chairs decided to break the reviews up into pieces so as to get
focus on each in turn.  We chose to go top-down, starting with 
yang-push and ending with the "notif" drafts.  We plan to submit 
the drafts for publication when they are ready as a collective.  
The goal is to do all this prior to IETF 103.

While it's always nice to receive messages of support, at this time, 
the question isn't so much if the working group supports the work 
than if the document is ready to progress.  The chairs need to see
reviews that indicate thorough end-to-end reading of the text.  Of
course, if there are any objections, these should be brought forward
now as well.

The current version (-13) of this draft was published on Oct 4th 
(today).  The datatracker page for the draft is here:

  https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-notifications.

Thanks,
Kent (and Mahesh)

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 5 Oct 2018 12:17:19 +0000

Hello,

I have reviewed the draft and I think it is ready to progress forward.

Some comments minor:

Generally I find the draft a bit too long and too detailed. Much of this 
can be derived from the yang language, subscribed-notifications and 
yang-push.
Still I  can accept it; it is OK.

Ch 3)

s/is been received/has been received/
Last paragraph) true, but to me this seems trivial. If you don't support 
something, don't advertise it. Still this does not harm anyone.

CH 5)

s/if the NETCONF session involved with the "establish-subscription" 
terminates,/ if the NETCONF session that carried the 
"establish-subscription" terminates/
s/RPC MUST be sent using same the NETCONF session/RPC MUST be sent using 
the same NETCONF session/

regards Balazs

On 10/5/2018 12:10 AM, Kent Watsen wrote:
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: [email-masked]

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 5 Oct 2018 14:13:06 +0000

Thanks Balazs.   Requested tweaks in Ch3 & Ch5 made.

Eric

> From Balázs Lengyel, October 5, 2018 8:17 AM
> 
> Hello,
> 
> Generally I find the draft a bit too long and too detailed. Much of this can be
> derived from the yang language, subscribed-notifications and yang-push.
> terminates,/ if the NETCONF session that carried the "establish-subscription"
> terminates/ s/RPC MUST be sent using same the NETCONF session/RPC MUST
> be sent using the same NETCONF session/
> 
> regards Balazs
> 
> > This message starts a Last Call on draft-ietf-netconf-netconf-event-
> notifications-13 (a.k.a. "netconf-notif"):
> >
> >
> > yang-push and ending with the "notif" drafts.  We plan to submit the
> > drafts for publication when they are ready as a collective.
> > the question isn't so much if the working group supports the work than
> > if the document is ready to progress.  The chairs need to see reviews
> > that indicate thorough end-to-end reading of the text.  Of course, if
> > there are any objections, these should be brought forward now as well.
> >

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 9 Oct 2018 18:56:35 +0000

Hi,

I believe the document is ready to progress. I agree with the comments from Balazs on Sections 3 and 5, except that I think keeping the past paragraph in section 3 is worthwhile since it's a clarification.
All my comments are nits:
- Section 4 last sentence, s/in that draft/in that document/
- Figure 8 s/with Hint/with hint/
- A.3 Closing ) not needed?
- A.3.1 s/might be sent if over NETCONF if/might be sent over NETCONF if/

Regards,
Reshad.

On 2018-10-05, 10:13 AM, "Netconf on behalf of Eric Voit (evoit)" <[email-masked] on behalf of [email-masked]> wrote:

    Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 9 Oct 2018 20:01:41 +0000

Hi Reshad,

Thanks.  Thoughts in-line...

> -----Original Message-----
> From: Reshad Rahman (rrahman)
> Sent: Tuesday, October 9, 2018 2:57 PM
> To: Eric Voit (evoit) <[email-masked]>; Balázs Lengyel
> <[email-masked]>; Kent Watsen <[email-masked]>;
> [email-masked]
> Subject: Re: [Netconf] WGLC on netconf-event-notifications-13
> 
> Hi,
> 
> I believe the document is ready to progress. I agree with the comments from
> Balazs on Sections 3 and 5, except that I think keeping the past paragraph in
> section 3 is worthwhile since it's a clarification.

updated

> - Figure 8 s/with Hint/with hint/

updated

> - A.3 Closing ) not needed?

removed

> - A.3.1 s/might be sent if over NETCONF if/might be sent over NETCONF if/

Updated.

Thanks again!
Eric

> Regards,
> Reshad.
> 
> On 2018-10-05, 10:13 AM, "Netconf on behalf of Eric Voit (evoit)" <netconf-
> [email-masked] on behalf of [email-masked]> wrote:
>

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 10 Oct 2018 02:07:06 +0000

Hi,

I have reviewed this document, and think it's OK to move forward.

Only one thing, I am a little lost in the following paragraph.
"  Each error identity will be inserted as the "error-app-tag" using
   JSON encoding following the form <modulename>:<identityname>.  An
   example of such as valid encoding would be "ietf-subscribed-
   notifications:no-such-subscription". "

I do not know why "JSON encoding" is mentioned here.
<modulename>:<identityname> is not JSON like.

Regards,
Tianran

> From: Netconf [mailto:[email-masked]] On Behalf Of Kent Watsen
> Sent: Friday, October 05, 2018 6:11 AM
> To: [email-masked]
> Subject: [Netconf] WGLC on netconf-event-notifications-13
> 
> This message starts a Last Call on
> draft-ietf-netconf-netconf-event-notifications-13 (a.k.a.
> "netconf-notif"):
> 
> 
> This, along with the restconf-notif Last Call, started in a separate message,
> marks the last of the last calls on the yang push suite of drafts. As explained
> before, given the size and number of documents, the chairs decided to break
> the reviews up into pieces so as to get focus on each in turn.  We chose to
> go top-down, starting with yang-push and ending with the "notif" drafts.  We
> plan to submit the drafts for publication when they are ready as a collective.
> While it's always nice to receive messages of support, at this time, the
> question isn't so much if the working group supports the work than if the
> document is ready to progress.  The chairs need to see reviews that indicate
> thorough end-to-end reading of the text.  Of course, if there are any
> objections, these should be brought forward now as well.
> 
> The current version (-13) of this draft was published on Oct 4th (today).
> The datatracker page for the draft is here:
> 
>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 10 Oct 2018 11:14:55 +0200 (CEST)

Hi,

I think this document is ready for publication.  Some minor comments
below.  And note a bug in SN as well.

o  section 4

  OLD:

   The "encode-xml" feature of
   [I-D.draft-ietf-netconf-subscribed-notifications] is mandatory to
   support.

  NEW:

   The "encode-xml" feature of
   [I-D.draft-ietf-netconf-subscribed-notifications] MUST be
   supported.

o  section 7

  Also, it seems this text starts a itemized list, but it probably
  should not be a list:

   o  In case of error responses to an "establish-subscription" or

o  section A.2.2

  Bad xmlns:

  OLD:

       <error-info
          xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
          <modify-subscription-datastore-error-info>
            <period-hint>
                3000
            </period-hint>
          </modify-subscription-datastore-error-info>
       </error-info>

  NEW:
        <error-info>
          <modify-subscription-datastore-error-info
            xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
            <period-hint>
                3000
            </period-hint>
          </modify-subscription-datastore-error-info>
       </error-info>

o  A.3.1

  The example has:

    <transport xmlns:nsn=
    "urn:ietf:params:xml:ns:yang:ietf-netconf-subscribed-notifications">
      nsn:netconf
    <transport>

 There is no transport "netconf" defined in SN, so this is broken.

 But this illustrates a problem with SN; the "transport" leaf is
 mandatory if the feature "configured" is supported.  The problem is
 that just b/c a server supports the "configured" feature, it doesn't
 mean that there is an identity defined for all transports; e.g.,
 there is no identity defined for NETCONF.  So the leaf "transport"
 should probably not be mandatory.

o  A.4

  Namespace and XPath errors:

  OLD:

    <stream-xpath-filter xmlns="urn:ietf:params:xml:ns:yang:ietf-vrrp">
      /vrrp-protocol-error-event[protocol-error-reason="checksum-error"]
    </stream-xpath-filter>

  NEW:

    <stream-xpath-filter vrrp:xmlns="urn:ietf:params:xml:ns:yang:ietf-vrrp">
      /vrrp:vrrp-protocol-error-event[
         vrrp:protocol-error-reason="vrrp:checksum-error"]
    </stream-xpath-filter>

o  Spelling of XPath

  s/xpath filter/XPath filter/  (a couple of places)

  OLD:

   This section provides examples which illustrate both xpath and

  NEW:

   This section provides examples which illustrate both XPath and

  OLD:

   Establishing a subscription error reason via XPATH

  NEW:

   Establishing a subscription error reason via XPath

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 10 Oct 2018 14:11:10 +0000

> From: Tianran Zhou, October 9, 2018 10:07 PM
> 
> Hi,
> 

Thanks for the comment Tianran.   In that paragraph we are saying that a way of encoding is needed to uniquely identify a specific identity within the module.  As you point out, It is true that there are not quotes around the "<modulename>" and  "<identityname>".  So you are right that it is not exactly JSON like (although there is some similarity).   

To remove the confusion, I just eliminated the text "using JSON encoding".  Is that sufficient for you?

Eric

> > https://tools.ietf.org/html/draft-ietf-netconf-netconf-event-notificat
> > io
> > ns-13
> >
> > yang-push and ending with the "notif" drafts.  We plan to submit the drafts
> for publication when they are ready as a collective.
> > https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-event-noti
> > fi
> > cations.
> >
> >
> > Thanks,
> > Kent (and Mahesh)
> >
> >
> >

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 10 Oct 2018 16:44:33 +0000

Thanks very much Martin.   Changes made as described in-line.

> From: Martin Bjorklund, October 10, 2018 5:15 AM
> 
> Hi,
> 
> I think this document is ready for publication.  Some minor comments below.
> And note a bug in SN as well.
> 
> 
> o  section 4
> 
>   OLD:
> 

Updated

>    o  In case of error responses to an "establish-subscription" or

Updated

>           </modify-subscription-datastore-error-info>

Updated

Updated.
 
>  But this illustrates a problem with SN; the "transport" leaf is  mandatory if the
> feature "configured" is supported.  The problem is  that just b/c a server
> supports the "configured" feature, it doesn't  mean that there is an identity
> defined for all transports; e.g.,  there is no identity defined for NETCONF.  So
> the leaf "transport"

Made optional within the SN grouping "subscription-policy", and tweaked the definition as follows:

    leaf transport {
      if-feature "configured";
      type transport;
      description
        "For a configured subscription, this leaf specifies the 
        transport used to deliver messages destined to all receivers 
        of that subscription.";
    }

Also in SN, refined the definition of:

  +--rw subscriptions
     +--rw subscription* [id]
        +--rw transport             

To:

        refine "transport" {
          description
            "For a configured subscription, this leaf specifies the 
            transport used to deliver messages destined to all  
            receivers of that subscription.  This object is mandatory
            for subscriptions in the configuration datastore."
        }

>          vrrp:protocol-error-reason="vrrp:checksum-error"]

Update made

>   s/xpath filter/XPath filter/  (a couple of places)

Found one.  Fixed.
 
>    This section provides examples which illustrate both XPath and

fixed

>    Establishing a subscription error reason via XPath

Fixed.

Eric

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 11 Oct 2018 01:09:08 +0000

> From: Eric Voit (evoit) [mailto:[email-masked]]
> Sent: Wednesday, October 10, 2018 10:11 PM
> To: Tianran Zhou <[email-masked]>; Kent Watsen
> <[email-masked]>; [email-masked]
> Subject: RE: WGLC on netconf-event-notifications-13
> 
> Thanks for the comment Tianran.   In that paragraph we are saying that a way
> of encoding is needed to uniquely identify a specific identity within the
> module. 

That's what I understood.

 As you point out, It is true that there are not quotes around the
> "<modulename>" and  "<identityname>".  So you are right that it is not
> exactly JSON like (although there is some similarity).
> 

Yes, thanks.

Tianran

> > > drafts
> > > course, if there are any objections, these should be brought forward now
> as well.
> > >

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 Oct 2018 09:25:39 +0200 (CEST)

Hi,

Thanks for fixing these issues.  Two comments, trimming:

> > From: Martin Bjorklund, October 10, 2018 5:15 AM

[...]

> > mandatory if the feature "configured" is supported.  The problem
> > is that just b/c a server supports the "configured" feature, it
> > doesn't mean that there is an identity defined for all transports;
> > e.g., there is no identity defined for NETCONF.  So the leaf
> > "transport" should probably not be mandatory.
> 

Is the intention that this leaf is not present in the operational
state for dynamic subscriptions?  If so, I think this should be
explicitly stated.

[...]

> >   s/xpath filter/XPath filter/  (a couple of places)

In A.2.2:

   seen, the modifications being attempted are the application of a new
   xpath filter as well as the setting of a new periodic time interval.

In A.4:

   For more examples of xpath filters, see [XPATH].

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Oct 2018 09:40:33 +0200

> >         transport used to deliver messages destined to all receivers 

The fix does not seem to address the question nor do I understand how
a configured unspecified transport will work.
 
> state for dynamic subscriptions?  If so, I think this should be

I hope there are no special semantics wrt. <operational>.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 11 Oct 2018 13:54:48 +0000

Hi Martin,

> From: Martin Bjorklund, October 11, 2018 3:26 AM
> 
> Hi,
> 
> Is the intention that this leaf is not present in the operational state for dynamic
> subscriptions?  If so, I think this should be explicitly stated.

That was the intent with the subsequent part of the earlier email.   To improve things, I have added the sentence: 
  "The object should not be present for dynamic subscriptions"
to the text.   Now the leaf:

  +--rw subscriptions
     +--rw subscription* [id]
        +--rw transport             

Is defined as:

        refine "transport" {
          description
            "For a configured subscription, this leaf specifies the 
            transport used to deliver messages destined to all  
            receivers of that subscription.  This object is mandatory
            for subscriptions in the configuration datastore.  The 
            object should not be present for dynamic subscriptions."
        }

>    For more examples of xpath filters, see [XPATH].

Fixed this one too.

Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 11 Oct 2018 16:13:15 +0000

Hi Juergen,

> From: Juergen Schoenwaelder, October 11, 2018 3:41 AM
> 
> The fix does not seem to address the question nor do I understand how a
> configured unspecified transport will work.

An unspecified configured transport cannot work without leaf transport populated.  That is why there is a refinement to the definition for the Data Node which appends to the description above: "This object is mandatory  for subscriptions in the configuration datastore."
 
> I hope there are no special semantics wrt. <operational>.

A dynamic subscription does not need to populate "transport".  There is nothing in the model which would stop an implementation from populating this leaf should it choose to do so.

Thanks,
Eric

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Oct 2018 18:32:54 +0200

> An unspecified configured transport cannot work without leaf transport populated.  That is why there is a refinement to the definition for the Data Node which appends to the description above: "Thi…

The original statement was "there is no identity defined for NETCONF".
So is there a defined transport identity for NETCONF or not?

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 11 Oct 2018 16:41:39 +0000

> From: Juergen Schoenwaelder, October 11, 2018 12:33 PM
> 
> > > > > > But this illustrates a problem with SN; the "transport" leaf
> > > > > > is mandatory if the feature "configured" is supported.  The
> > > > > > problem is that just b/c a server supports the "configured"
> > > > > > feature, it doesn't mean that there is an identity defined for
> > > > > > all transports; e.g., there is no identity defined for
> > > > > > NETCONF.  So the leaf "transport" should probably not be mandatory.
> > > > >
> > > The fix does not seem to address the question nor do I understand
> > > how a configured unspecified transport will work.
> >
> > An unspecified configured transport cannot work without leaf transport
> populated.  That is why there is a refinement to the definition for the Data
> Node which appends to the description above: "This object is mandatory  for
> subscriptions in the configuration datastore."
> >
> 

There is not.   

This identity was extracted from a previous version of SN to a new model in NETCONF-Notif earlier in the year.  When we subsequently removed configured subscription support from the NETCONF-Notif draft, we removed the identity.

Eric

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Oct 2018 21:12:08 +0200

> This identity was extracted from a previous version of SN to a new model in NETCONF-Notif earlier in the year.  When we subsequently removed configured subscription support from the NETCONF-Notif d…

So should there be one? Or how do things work with NETCONF? (Seems we
go in circles here instead of addressing the question...)

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 11 Oct 2018 19:51:23 +0000

> > > > > > > > But this illustrates a problem with SN; the "transport"
> > > > > > > > leaf is mandatory if the feature "configured" is
> > > > > > > > supported.  The problem is that just b/c a server supports the
> "configured"
> > > > > > > > feature, it doesn't mean that there is an identity defined
> > > > > > > > for all transports; e.g., there is no identity defined for
> > > > > The fix does not seem to address the question nor do I
> > > > > understand how a configured unspecified transport will work.
> > > >
> > > populated.  That is why there is a refinement to the definition for
> > > the Data Node which appends to the description above: "This object
> > > is mandatory  for subscriptions in the configuration datastore."
> > > >
> > >
> > This identity was extracted from a previous version of SN to a new model in
> NETCONF-Notif earlier in the year.  When we subsequently removed
> configured subscription support from the NETCONF-Notif draft, we removed
> the identity.
> >
> 
> So should there be one? Or how do things work with NETCONF? (Seems we go
> in circles here instead of addressing the question...)

There should not be a NETCONF identity until there is configured subscription support for NETCONF.  

Previous reviewers have been very vigilant in ensuring each transport identity not appear until supported by a transport document.   This is why the NETCONF transport identity was extracted from SN earlier this year.

Eric