Subject: [netconf] Comments on draft-ietf-netconf-netconf-event-notifications-16

From: Rohit R Ranade <[email-masked]>
Date: Wed, 13 Feb 2019 04:23:28 +0000

Hi All,

Editorial:

1.       "resynch-subscription" is used in 4 places with an additional 'h' after sync. It is "resync-subscription" in draft-ietf-netconf-yang-push-22

2.       Section 7  bullet 3, "this MAY but does not have to be included", can be replaced with just "optional" ?

3.       Section 7, bullet 4,  "section 2.4.6" link looks to be broken.

4.       Section 5 refers to many RPCs, but there is no reference to the documents which define these RPCs.

5.       Since there are many RPC names used, there are too many hyperlinks pointing to their sources in the document. Whether we can have a separate section which provides the list of RPCs used in this draft and their source document. The increase in hyperlinks leads to distraction while reading.

Technical:

1.       Section 3 "reply with the [RFC6241] error "operation-not-supported"". I think this should be an "<rpc-error> element is returned with an <error-tag> value of "operation-not-supported". Similar occurrence in another place in same section.

2.       Is the intention that RFC5277 be implemented and then this draft be supported on top of it ? I see that there are 7 references to RFC5277 , including definitions of <notification> and its encoding mechanism. Whether we can add a statement regarding this point ?

With Regards,
Rohit R

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 13 Feb 2019 14:58:48 +0000

Hi Rohit,

Thanks for looking through and commenting.  I am posting v17 which includes the conclusion of the error-tag discussion from several weeks ago, as well as some tweaks based on your comments below.

From: Rohit R Ranade, February 12, 2019 11:23 PM

Hi All,

Editorial:

<eric> fixed

2.       Section 7  bullet 3, "this MAY but does not have to be included", can be replaced with just "optional" ?
<eric> Either should work.  We might as well leave the current text.

3.       Section 7, bullet 4,  "section 2.4.6" link looks to be broken.
<eric> Why does this seem to be broken?  The list of identities is in draft-ietf-netconf-subscribed-notifications section 2.4.6.

4.       Section 5 refers to many RPCs, but there is no reference to the documents which define these RPCs.
<eric>  It seems excessive to me, as this entire document refers to [I-D.draft-ietf-netconf-subscribed-notifications] and [I-D.ietf-netconf-yang-push].  But to make it clear where the RPCs come from, I moved the following sentence from the beginning of Section 7 to the beginning of Section 5.
Management of dynamic subscriptions occurs via RPCs as defined in [I-D.ietf-netconf-yang-push] and [I-D.draft-ietf-netconf-subscribed-notifications].

5.       Since there are many RPC names used, there are too many hyperlinks pointing to their sources in the document. Whether we can have a separate section which provides the list of RPCs used in this draft and their source document. The increase in hyperlinks leads to distraction while reading.
<eric> The links should be simplified once they collapse to RFC references.  At this point it would be great if the document is not be re-opened for new sections.

Technical:

1.       Section 3 "reply with the [RFC6241] error "operation-not-supported"". I think this should be an "<rpc-error> element is returned with an <error-tag> value of "operation-not-supported". Similar occurrence in another place in same section.
<eric> I tweaked the text to:  A solution MUST reply with the [RFC6241] "rpc-error" element containing the "error-tag" value of "operation-not-supported" if...

2.       Is the intention that RFC5277 be implemented and then this draft be supported on top of it ? I see that there are 7 references to RFC5277 , including definitions of <notification> and its encoding mechanism. Whether we can add a statement regarding this point ?
<eric>  A section on this relationship is contained in Section 1.4 of draft-ietf-netconf-subscribed-notifications

Thanks,
Eric

With Regards,
Rohit R