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

[Daniele Ceccarelli <[e-mail]>]

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

Nits:

*       Abstract: suggest to change “continuous, customized” with “continuous and customized”.
*       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.”
*       “Traditional approaches to providing”, shouldn’t this be “to provide” or “of providing”?
*       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.”)
*       [I-D.draft-ietf-netconf-subscribed-notifications] usually a more friendly reference is used, e.g. [SUB-NOT]

BR

Daniele