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

["Eric Voit (evoit)" <[e-mail]>]

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:

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