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

Hi Qin,

Thanks very much for your review.  Some thoughts in-line...

> From: Qin Wu, October 10, 2018 9:45 PM
> 
> Hi:
> I have read the latest version of netconf event notification and believe it is
> ready for publication, here is a few comments:
> 1. Section 5
> The first sentence in paragraph 1 discuss how to encode notification messages
> over NETCONF protocol, but it is not clear how to encode notification
> messages transported over RESTCONF protocol? additional text to clarify?

RESTCONF requirements would seem a cleaner fit for draft-ietf-netconf-restconf-notif, which is also currently under WGLC.

> For second paragraph, I think we should emphasize all notifications and RPC
> are carried in the same session, how about the following proprosed text:
> "
> For dynamic subscriptions, all notification messages MUST be sent in a same
> NETCONF transport session used by the "establish-subscription" RPC.
> "

I agree with your desire to clarify and simplify.  And proposed text above does appearing two paragraphs below in Section 6.

However the kill-subscription RPC likely will not come from the same NETCONF transport session.  So we cannot fully generalize/simplify.  Let me know if there is some other approach you would like, or whether this is ok.

> 2. Section 7, paragraph 2 and paragraph 2, the 1st bullet:
> Why JSON encoding is underlined? Why is limited to XML encoding?

Per another thread, mention of JSON in this draft is removed.  I don't think that we have a full set of IETF standards which document JSON + NETCONF.  

> 3.Section 7 paragraph 2, the 1st bullet:
>       "In case of error responses to an "establish-subscription" or
>       "modify-subscription" request there is the option of including an
>       "error-info" node."
> 
> Where "error-info" node is included? <rpc-error> element?

Good catch.  The text "each error identity..." really is part of the previous bullet.  I will move the text up to make that obvious.  That makes the "error-info" bullet an obvious part of the previous list.

> "  The yang-data included within "error-info" SHOULD NOT include the
>       optional leaf "error-reason", as such a leaf would be redundant
>       with information that is already placed within the
>       "error-app-tag".
> "
> 
> 
> where yang-data included in "error-info" defined? I only see something similar
> defined in RFC8040 for error-info.

I have updated the document to show that the yang-data structures come from: ietf-subscribed-notifications and ietf-yang-push.

Thanks again,

Eric

> -Qin
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf