Re: [RTG-DIR] [netconf] RtgDir review: draft-ietf-netconf-yang-push-22

["Alexander Clemm" <[e-mail]>]

Hello Daniele,

 

Thank you for your review!  Responses inline, <ALEX>.  Updates will be reflected in -24, to be published shortly.  

 

Kind regards

--- Alex

 

From: netconf <[e-mail]> On Behalf Of Daniele Ceccarelli
Sent: Tuesday, April 30, 2019 12:24 PM
To: <[e-mail]> ([e-mail]) <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: [netconf] RtgDir review: draft-ietf-netconf-yang-push-22

 

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> ​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-yang-push-22
Reviewer: Daniele ceccarelli 
Review Date: 2019-04-30
IETF LC End Date: 
Intended Status: Standards Track

Summary: 

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

Comments:

*	The draft is well structured and covers a lot of different aspects of the proposed method. I only have some concerns on readability and quality of English. A review from a mother tongue would improve it significantly. (maybe the RFC editor should be enough).

Major Issues:

*	No major issues found

Minor Issues:

*	Number of authors on the front page: shouldn’t it be 5 max?

<ALEX> Several of the authors have graciously agreed to step down and be listed as contributors. </ALEX>

*	Section 3: “This solution supports dynamic as well as configured subscriptions to updates of datastore node”. What does dynamic and configured mean? It’s probably defined in other documents? 

<ALEX> Yes, these are defined in the Subscribed Notifications draft which YANG-Push builds on, as explained in the Introduction.  </ALEX>

*	Section 3.2. “However, there are no guarantees that subsequent requests which consider these hints will be accepted.” What happens then? Undefined number of retries?

<ALEX> It is up to the client application.  When making a subsequent request, it should presumably “lower” its demands.  The idea of the hint is to provide an idea which request would result in a load that is still acceptable, a “poor man’s negotiation” if you will that will reduce the number of retries that might otherwise result.  </ALEX>

*	3.5.1.  Periodic Subscriptions:”In a periodic subscription, the data included as part of an update record corresponds to data that could have been read using a retrieval operation.”. Is it not possible to have periodic subscriptions with just the delta between the previous update and the last one? Everything needs to be sent at any time? 

<ALEX> In that case, you would request an on-change subscription.  In case of a high rate of changes, the dampening period will in effect result in periodic updates of changes only. </ALEX>  

Nits:

*	Abstract: suggest to change “continuous, customized” with “continuous and customized”.

<ALEX> see next bullet item </ALEX>

*	Maybe it’s better to change the first sentence entirely. How about: “  This document describes a mechanism that allows subscriber applications requesting a continuous and customized stream of updates from a YANG datastore.”

<ALEX> This sounds fine to me. Perhaps we have edited the sentence too much in the past.  I am making the change, but replacing “requesting” with “to request”, to read “This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore.” </ALEX>

*	“Traditional approaches to providing”, shouldn’t this be “to provide” or “of providing”?

<ALEX> OK, change made </ALEX>

*	Polling incurs significant latency. This latency prohibits many application types. – Also this sentence doesn’t look very correct. Actually the entire section can be improved from a language perspective. (e.g. “yet for which applications need to be quickly notified whenever a change does occur with minimal delay.”)

<ALEX> Prefer to keep as-is at this point.  Would leave copy edits to RFC-editor.  </ALEX>

*	[I-D.draft-ietf-netconf-subscribed-notifications] usually a more friendly reference is used, e.g. [SUB-NOT]

<ALEX> Keeping this as-is, as this will be replaced by the corresponding RFC reference anyhow.  </ALEX>

BR

Daniele