Re: [Netconf] Last Call on yang-push-17

Hi all,

after a thorough review of yang-push-17 I think it is in good shape and 
ready to progress.

A few comments below (more of the nit'esque kind):

In 2. Update Record

It seems to me that "update record" and "update" are used synonymously 
in this document? If so, please add something like the following to the 
definition of update record- NEW:
"In this document, update records are often simply referred to as 
"updates"."

In 3.1. Subscription Model

OLD:
"YANG-push subscriptions are defined using a data model that is itself 
defined in YANG."

I assume there is a good reason for not just phrasing it like - NEW:
"YANG-push subscriptions are defined using a YANG data model."

In 3.1. Dampening period

OLD:
"The dampening period goes into effect every time an update record 
completes assembly."

For clarity (and probably implementation guidance) maybe highlight - NEW:
"The dampening period goes into effect every time an update record 
completes assembly. As long as a dampening period is in effect, the 
Update Trigger functions the same way as with periodic subscriptions, 
using the dampening period as the periodic interval."

In 3.2.

OLD:
"However, there are no guarantees that subsequent requests which 
consider these hints will be accepted."

NEW:
"However, there are no guarantees that subsequent requests, which 
consider these hints, will be accepted."

In 3.3.

OLD:
"In case of a configured subscription, the subscription MAY be suspended."

NEW:
"In case of a configured subscription, the subscription MAY be suspended 
by the publisher."

In 3.3. conceptual process

"access control rules" are rather surprisingly introduced here and then 
never mentioned again.

In 3.3. conceptual process

Same thing with "patch record" the term is only used in the context of 
the conceptual process and never again. Why is this not an update 
record? The relationship to RFC8072 is elaborated on in 3.5.2., but is 
surprising to be found here already.

In 3.3.

OLD:
"A publisher SHOULD reject a request for a subscription if it is 
unlikely that the publisher will be able fulfill the terms of that 
subscription request."

NEW:
"A publisher SHOULD reject a request for a subscription, if it is 
unlikely that the publisher will be able fulfill the terms of that 
subscription request."

In 3.5.1.

OLD:
"In a periodic subscription, the data included as part of an update 
corresponds to data that could have been read using a retrieval operation."

See above. Is there a difference between update and update record? If 
so, highlight it, please - Optional NEW:
"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."

(there are multiple occurrences)

In 3.5.2.

OLD:
"Therefore encoding rules for data in on-change updates will generally 
follow YANG-patch operation as specified in [RFC8072]."

NEW:
"Therefore, encoding rules for data in on-change updates will generally 
follow YANG-patch operation as specified in [RFC8072]."

In 3.5.2.

OLD:
"However a patch must be able to do more than just describe the delta 
from the previous state to the current state. As per Section 3.3, it 
must also be able to identify if transient changes have occurred on an 
object during a dampening period."

NEW:
"However, a patch must be able to do more than just describe the delta 
from the previous state to the current state. As per Section 3.3, it 
must also be able to identify, if transient changes have occurred on an 
object during a dampening period."

In 3.6.

xpath, Xpath and XPath are found in this section. More consistency 
cannot hurt.

In 3.7.

OLD:
"First it will be used as the initial "push-update" if there is a need 
to synchronize the receiver at the start of a new subscription."

NEW:
"First, it will be used as the initial "push-update", if there is a need 
to synchronize the receiver at the start of a new subscription."

In 4.3.2.

OLD:
"Where it is, the relevant "subscription-id" MUST be encoded as the 
first element within each "push-update" or "push-change-update"."

NEW:
"If present, "subscription-id" MUST be encoded as the first element 
within each "push-update" or "push-change-update"."

In 4.4.1.

OLD:
"The specific parameters to be returned in as part of the RPC error 
response depend on the specific transport that is used to manage the 
subscription."

NEW:
"The specific parameters to be returned as part of the RPC error 
response depend on the specific transport that is used to manage the 
subscription."

In 4.4.2.

The non-normative may is intentional here, correct? Also, rpc is also 
low caps here again - more consistency cannot hurt?
"This rpc error response may contain hints encapsulated within the 
yang-data structure "modify-subscription-error-datastore".

In 4.4.4.

OLD:
"This RPC is only applicable only for on-change subscriptions previously 
established using an "establish-subscription" RPC."

NEW:
"This RPC is only applicable for on-change subscriptions previously 
established using an "establish-subscription" RPC."

In 4.4.5.

Is this intended to be a guidance section? It seems to me that the use 
of RFC6470 might be a good enough basis to warrant a SHOULD somewhere?

Viele Grüße,

Henk

On 08/14/2018 07:28 PM, Kent Watsen wrote:
> This message starts a Last Call on draft-ietf-netconf-yang-push-17:
> 
>    https://tools.ietf.org/html/draft-ietf-netconf-yang-push-17
> 
> 
> This marks the beginning of the last calls on the yang push suite of drafts.
> Given the size and number of documents, the chairs decided to break the
> reviews up into pieces so as to get focus on each in turn.  We are choosing
> to go top-down, starting with yang-push and ending with the "notif" drafts.
> We plan to submit the drafts for publication when they are ready as a
> collective.  The goal is to do all this prior to IETF 103.
> 
> We understand that, in reviewing yang-push, there is a need to consider the
> subscribed-notifications draft.  We will not be surprised if, in the course
> of things, both drafts are updated, even though the review is primarily on
> the yang-push draft.
> 
> While it's always nice to receive messages of support, at this time, the
> question isn't so much if the working group supports the work, than if
> the document is ready to progress.  The chairs need to see reviews that
> indicate thorough end-to-end reading of the text.  Of course, if there
> are any objections, these should be brought forward now as well.
> 
> The current version (-17) of this draft was published on July 1st, just
> before the IETF 102 meeting.  The datatracker page for the draft is here:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push.
> 
> 
> Thanks,
> Kent (and Mahesh)
> 
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> 