Re: [RTG-DIR] RtgDir review: draft-ietf-netconf-subscribed-notifications

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

Hi Ravi,

Thanks very much for the review.  It is appreciated.  Thoughts in-line...

From: Ravi Singh <[e-mail]>
Sent: Sunday, April 14, 2019 8:40 PM
To: Routing ADs <[e-mail]>
Cc: Routing Directorate <[e-mail]>; [e-mail]; [e-mail]
Subject: RtgDir review: draft-ietf-netconf-subscribed-notifications

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-netconf-subscribed-notifications
Reviewer: Ravi Singh
Review Date: 04/12/2019
IETF LC End Date: date-if-known
Intended Status: Standards Track

Summary:
This document is basically ready for publication, but has nits that should be considered prior to publication.

Comments:
I've reviewed the draft.
It is very exhaustive and generally well written.
I consider it ready for publication, after the following "nits" have been addressed.


1.       1.3:
"Support for configured subscriptions is optional, with its availability advertised via a  YANG feature."
The "how" aspect should be alluded to here, even though subsequent sections address this in detail?
This will make for better readability.
<eric> As capability advertisement is a basic infrastructure capability of YANG itself, I suspect that putting these details here would be fairly obvious to developers and operators familiar to YANG.  Note: as a design objective, we have been attempting to keep the documents smaller by not articulating accepted/core capabilities of the base YANG suite of drafts.

2.       "For connectionless or stateless transports like
      HTTP, a lack of receipt acknowledgment of a sequential set of
      notification messages and/or keep-alives can be used to trigger a
      termination of a dynamic subscription."
How long to wait? Any inputs the draft would like to provide or leave to an implementation?

<eric> This draft has specific transport drafts which are going through IESG reviews in parallel to this one.  Specific to your question on connectionless transport, draft-ietf-netconf-restconf-notif-13 Section 3.1 provides guidance for RESTCONF/HTTP connectionless configuration and operation.  E.g. TLS heartbeat [RFC6520] is recommended.

3.       Section 2.4.2:
Would be useful to explain "when replay stops", if "replay" was requested.
Is this done by mandating that "stop-time" must be provided if replay was requested?
Subsequent sections address this, however would be useful to allude to in this section…
<eric> It could be due to reaching a stop time, or when the replay buffer is now empty, and the current time has been reached.  Do you want me to add a sentence which describes the purpose as: “This allows a targeted history of event records to be extracted.”


4.       Section 2.4.3:
Please elaborate on the presence of the following in the schema:
             +---w stop-time?
                     yang:date-and-time

<eric>   This is one leaf of many under the modify subscription RPC.   This leaf means that a subscription is being modified to end at a targeted stop time.   While it could be possible to write a meaning for every leaf within the tree, we decided that doing this for every leaf would have made the document very large.  There is a description of what stop-time does in the previous section.


5.        Section 2.4.5: not clear when this would actually get used, IOW…what would cause there to be such a situation where the kill-sbuscription notifcation would need to be used. When will a subscription not be associated with a transport session?

<eric> A kill-subscription RPC is intended for a network operator.  The operator needs to be able to have the ability to terminate an active subscription.   This is different from delete-subscription, where the intended use is for the requestor of a subscription to be able to end it.

6.       2.4.6:
a.       why have errors w.r.t. "weighting", and "dependency" not been included?
<eric> Much like the analogous HTTP2 capabilities to which the can be mapped, failures in configuring these properly don’t have exposed error conditions.  For example, if you point to a subscription dependency which doesn’t exist, the dependency is silently discarded.


b.       Numered points 1/2/3 are better communicated via a table to avoid the duplicated text.
Brevity makes for better reading.

<eric>  In general I agree with you.  And I initially attempted a table.  However the leaf names were so long, it gave very little space for the other text within the table, so I defaulted back to what is there now.

7.       Sections 2.5.2 - 2.5.7: these are a bit of a drag to read through, in an already large document. Readability for these sections would be greatly improved if the notifications that get sent out were listed pictorially or in a tabular fashion by enhancing the simple FSMs listed in section 2.5.1.

<eric> I do agree there is a lot of text here.   Based on the WG feedback, things get very explicit in this section over time.   Perhaps another format could work here as you suggest. I am hoping that this alternative formatting isn’t needed to insert into the document at this point

8.       Section 5.4:
"This can be accomplish by establishing" -> "This can be accomplished by establishing"
<eric>  Good catch.  It is correct in my XML right now, so I suspect some other reviewer also pointed this out to me.

Thanks again!
Eric


Regards
Ravi