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

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 15 Feb 2018 15:56:57 -0800

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.

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.

Section 3:

Can you please follow the template in RFC 6241, Appendix D for defining a new capability. 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.

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.

Section 8 Security Considerations

Should this follow the template in rfc6087bis, at least for the part about NETCONF protocol and the security it provides. 

Please update reference to rfc6536bis instead of RFC6536.

Missing IANA considerations section.

Needs to capture the new capability in the NETCONF capability registry of IANA.

Appendix

Most of the examples in the appendix are for subscribed-notifications or yang-push. Why are these examples not in those documents? 

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?

Thanks.

Mahesh Jethanandani
[email-masked]

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 16 Feb 2018 01:31:52 +0000

Hi Mahesh,

Thanks for going through his, some thoughts....

> -----Original Message-----
> From: Netconf [mailto:[email-masked]] On Behalf Of Mahesh
> Jethanandani
> Sent: Thursday, February 15, 2018 6:57 PM
> To: [email-masked]
> Subject: [Netconf] My review of draft-ietf-netconf-netconf-event-notifications
> 
> 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? 

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

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

> Needs to capture the new capability in the NETCONF capability registry of

If I got the ask right above, I will add.

> 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
> [email-masked]
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 19 Feb 2018 12:49:48 +0100 (CET)

"Eric Voit (evoit)" <[email-masked]> wrote:
> > 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.

[...]

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

I don't think a new capability for "subscribe" is necessary;
I agree that advertising support for ietf-subscribed-notifications is
enough.

However, I don't think that you can use the :interleave capability in
the way you do in this draft.  The :interleave capability defined in
RFC 5277 details how "create-subscription" is handled.  I think what
you really want to say is that when a subscription has been started
with "establish-subscriptio", a server MUST be to handle any rpc
operation (including another establish-subscription).  I.e., you don't
want interleaving to be an optional capability at all.

So, I think that this section needs to be rewritten to explain this
behavior.  It should also define how replies/notifications are
interleaved -- i.e., specify that they MUST be sent one after the
other; the XML cannot be mixed.   It should also explain that a client
that creates a subscription and then sends an <rpc> must be prepared
to receive any number of notifications before the <rpc-reply>.

/martin

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 19 Feb 2018 21:36:59 -0800

Hi Eric,

> On Feb 15, 2018, at 5:31 PM, Eric Voit (evoit) <[email-masked]> wrote:
> 
> Hi Mahesh,
> 

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.

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

Mahesh Jethanandani
[email-masked]

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 21 Feb 2018 23:38:49 +0000

Hi Martin,
Hi Mahesh,

The interleave capability of RFC 5277 Section 6 reads cleanly for me.  I don't see anything which need be deprecated as a result of conflicts with the WG's current subscription drafts.  To me the question comes down to: in which drafts should different aspects of interleave functionality be defined.

As the ability to interleave multiple RPC operations and notification contents is something which is transport independent, most interleaving text needs to be in draft-ietf-netconf-subscribed-notifications.  The good news is that we do currently have text in Section 2.4.2 which says: "It MUST be possible to support multiple establish subscription RPC requests made within the same transport session."   But to be really clear, I will add another sentence which says: "A solution MUST support the interleaving of RPC requests made on independent subscriptions."   Beyond that, I will also add the following sentence to section 2.6: " A single transport session MUST support the interleaving of notification messages and RPCs from independent subscriptions".  And to cover Martin's other point: "Subscribed events MUST NOT be sent until after the corresponding RPC response or state-change notification has been sent to a receiver". 

With that as a pre-requisite, let's look at what remains for protocol dependent interleaving rules as contained in draft-ietf-netconf-netconf-event-notifications.  

Martin's point is that RFC-5277 :interleave provides rule for create-subscription. So what is needed above the protocol independent interleave described above is the intersection with RFC-5277.  To cover that, basically I will included text describing "RFC-5277 create-subscription compatibility".  This will add the following sentences:
(1) A solution must reply with the RFC6241 error 'operation-not-supported' if a 'create-subscription' RPC is received on a NETCONF session where at least one subscription is currently active.
(2) It is a prohibited to send updates or state change notifications for a configured subscription on a NETCONF session where the create-subscription RPC has successfully created a subscription.  
(3) A 'create-subscription' RPC MUST be rejected if a subscription is already active across that NETCONF transport session.
This text should cover what may, and what may not be interleaved.

Beyond that, I can tweak the draft-ietf-netconf-netconf-event-notifications Interleave section to say "Advertisement of both the :interleave capability and "urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications" within a NETCONF capability exchange MUST indicate that a NETCONF publisher is able to receive, process, and respond to NETCONF requests and [I-D.draft-ietf-netconf-subscribed-notifications] subscription operations."

Let me know if this doesn't cover it for you.
Eric

> From: Martin Bjorklund, February 19, 2018 6:50 AM
> 
> > > Can you please follow the template in RFC 6241, Appendix D for
> > > defining a new capability.
> >
> > 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
> I don't think a new capability for "subscribe" is necessary; I agree that
> advertising support for ietf-subscribed-notifications is enough.
> 
> However, I don't think that you can use the :interleave capability in the way
> you do in this draft.  The :interleave capability defined in RFC 5277 details how
> "create-subscription" is handled.  I think what you really want to say is that
> when a subscription has been started with "establish-subscriptio", a server
> MUST be to handle any rpc operation (including another establish-
> subscription).  I.e., you don't want interleaving to be an optional capability at
> all.
> 
> So, I think that this section needs to be rewritten to explain this behavior.  It
> should also define how replies/notifications are interleaved -- i.e., specify that
> they MUST be sent one after the
> that creates a subscription and then sends an <rpc> must be prepared to
> receive any number of notifications before the <rpc-reply>.
> 
> 
> /martin