Re: [Netconf] My review of draft-ietf-netconf-netconf-event-notifications

[Mahesh Jethanandani <[e-mail]>]

Hi Eric,

> On Feb 15, 2018, at 5:31 PM, Eric Voit (evoit) <[e-mail]> wrote:
> 
> Hi Mahesh,
> 
> Thanks for going through his, some thoughts....
> 
>> -----Original Message-----
>> From: Netconf [mailto:[e-mail]] On Behalf Of Mahesh
>> Jethanandani
>> Sent: Thursday, February 15, 2018 6:57 PM
>> To: [e-mail]
>> Subject: [Netconf] My review of draft-ietf-netconf-netconf-event-notifications
>> 
>> I have read -07 version of the above draft, and I believe the document needs
>> work.
>> 
>> Abstract:
>> 
>> One does not put normative references in the abstract section. You have to
>> spell them out (without any cross references), and put a RFC editor note some
>> where to indicate that the references need to be updated to the RFC number,
>> whenever that is assigned.
> 
> Ok.  This should be straight-forward.  I will post a new revision including this.
> 
>> Since you repeat what is included in the abstract in the introduction section
>> also, you can shorten the abstract to say that it provides NETCONF bindings for
>> subscribed notifications and yang-push - period.
> 
> Ok
> 
>> Section 3:
>> 
>> Can you please follow the template in RFC 6241, Appendix D for defining a new
>> capability.
> 
> What I think you are saying that a new ":subscribe" capability should be used to indicate support for subscriptions over NETCONF.  I had been hoping that advertising support subscribed-notifications.yang (plus the existing RFC5277 interleave) would be sufficient to indicate support.  Am I reading it right in that you not believe this is sufficient? 

You are redefining the :interleave capability as defined in RFC5277, and I agree with Martin that clarification about the changes you are making to the capability need to be made. It would be helpful for folks to compare the capability if (re)defined in the same format that it is described today.

Also, if the new capability is different from the capability currently defined in RFC 5277, then I wonder how does a client distinguish between the new and the old capability the server support.

> 
>> Also see examples in the same document for what all things need to
>> be captured as part of defining a new capability, e.g. Positive Response,
>> Negative Response, Example, SHOULD, MUST, and MAY conditions.
> 
> If I have your ask above correct, I will follow the examples which exist in RFC 4741, Section 8.
> 
>> Section 5.1 and 5.2 and the entire Section 7 will then move under the
>> Overview section of the template from Appendix D of RFC 6241.
> 
> If I have your ask above correct, you want to insert the framework of RFC 6241 Appendix D into where Section 3 is now.  This would make it:
> 
> 	3.1.  capability-name - Subscription
> 
> 	3.1.1.  Overview
> 
> 	(Move Section 4.1, 5.2, & 7 here)
> 
> 	3.1.3.  Capability Identifier
> 
> 	Something like:
> 	"urn:ietf:params:netconf:capability:subscription:1.0"
> 
> If I have it right, this would not be hard to do.
> 
>> Section 8 Security Considerations
>> 
>> Should this follow the template in rfc6087bis, at least for the part about
>> NETCONF protocol and the security it provides.
> 
> The security sections of subscribed-notifications (5.3) and yang-push (7.0) are aimed at the types of vulnerabilities discussed in Section  3.7.1 or RFC6087bis.  As these vulnerabilities are not really NETCONF specific, it didn't seem necessary to place/repeat them in the NETCONF draft.  In any of the docs, do you specific gaps which should be articulated?
> 
>> Please update reference to rfc6536bis instead of RFC6536.
> 
> Ok.
> 
>> Missing IANA considerations section.
>> 
>> Needs to capture the new capability in the NETCONF capability registry of
>> IANA.
> 
> If I got the ask right above, I will add.

Ok. If there is no update to the registry of the existing capability, then this section may not be needed.

Cheers.

> 
>> Appendix
>> 
>> Most of the examples in the appendix are for subscribed-notifications or yang-
>> push. Why are these examples not in those documents?
> 
> The intent has been to have transport specific examples in each of the transport specific drafts.  I.e., it would be confusing to have NETCONF examples in YANG Push cluttering up the base specification for a reader who is interested in HTTP, UDP, or COMI transports.
> 
>> Which brings up the question. If the examples are moved to their own
>> documents, you would be left with the new :interleave capability. Do you
>> really need a separate draft just for that?
> 
> Per above, if we insert the template from RFC 6241 appendix D into Section 3 of this document, then there still is much meat here.  I don't see an alternative home for NETCONF binding specific info such as error codes, mandatory datastores / streams.
> 
> Eric
> 
>> Thanks.
>> 
>> Mahesh Jethanandani
>> [e-mail]
>> 
>> _______________________________________________
>> Netconf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
[e-mail]