Last Call Review of draft-ietf-netconf-yang-push-22
review-ietf-netconf-yang-push-22-rtgdir-lc-ceccarelli-2019-05-04-00

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