Subscription to YANG Notifications

Note: This ballot was opened for revision 23 and is now closed.

(Ignas Bagdonas) Yes

(Deborah Brungard) No Objection

(Alissa Cooper) No Objection

Comment (2019-05-01 for -25)
= Section 1.3 =

"Also note that transport specific transport drafts based on this
   specification MUST detail the life cycle of dynamic subscriptions, as
   well as the lifecycle of configured subscriptions (if supported)."

I think this would be clearer if it said "transport-specific documents."

= Section 2.5 =

Please expand VRF on first use.

Roman Danyliw (was Discuss) No Objection

Comment (2019-05-06 for -25)
No email
send info
Thank you for resolving my DISCUSS.

Benjamin Kaduk (was Discuss, No Record, Discuss) No Objection

Comment (2019-05-06 for -25)
No email
send info
Thank you for resolving my Discuss points!

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2019-04-30 for -24)
No email
send info
I support Benjamin and Roman's DISCUSSes.

Also, thanks to Benjamin and others for such detailed reviews, they saved my much typing :-)

(Mirja Kühlewind) No Objection

Comment (2019-04-29 for -23)
 1) Sec 2.3:
   “Where TCP is used, a publisher which supports the "dscp" feature
   SHOULD ensure that a subscription's notification messages are
   returned within a single TCP transport session where all traffic
   shares the subscription's "dscp" leaf value.“
This should probably be generalised to “If a connection-oriented protocol is used, …”, however, I’m not sure I understand the sentence correctly. It is no problem to have multiple TCP session using the same DSCP value, however, what should be avoided is using different DCSP values within the same TCP connection. Can you please clarify what this sentence is supposed to say?

 2) Also sec 2.3:
“For the "weighting" parameter, when concurrently dequeuing
   notification messages from multiple subscriptions to a receiver, the
   publisher MUST allocate bandwidth to each subscription proportionally
   to the weights assigned to those subscriptions.”
I’m also wondering about this sentence. Should this really be a MUST? I can assume that there could also be cases where there is a local policy to prioritise some notification. And do you really mean bandwidth (which would mean taking the message size into account), or would it make sense to leave the details to the exact implementation of the publisher and maybe talk just about “resources” instead? 

 3) Sec 1.3 says
“ the loss of the transport session will
      result in the immediate termination of any associated dynamic

However, there is the following text in section 2.4.5:
“The "kill-subscription" operation permits an operator to end a
   dynamic subscription which is not associated with the transport
   session used for the RPC.”
If the subscription is anyway immediately terminated when the transport session is lost, why is the kill-subscription operation still needed?

 4) Sec 2.5: Please expand VRF.

 5) Figure 8: I would recommend to call the second “evaluate” event “re-evaluate” instead.

(Barry Leiba) No Objection

(Alexey Melnikov) (was Discuss) No Objection

Comment (2019-05-02 for -25)
No email
send info
I missed comment from the document shepherd about YANG validation, so I am clearing my DISCUSS.

Alvaro Retana No Objection

Comment (2019-05-01 for -25)
No email
send info
I support Roman's DISCUSS.

(Adam Roach) No Objection

Martin Vigoureux No Objection

Éric Vyncke No Objection

Comment (2019-04-30 for -24)
I appreciate the goal of this document to specify another telemetry streaming than gRPC. As the I-D has been reviewed by YANG-doctors, I did not look in the YANG module.


C1) section 1.3, should the published check authorization before accepting an subscription? There is some text in section 3.1 is about authorization but I would prefer to have this authorization stated as early as possible

C2) end of section 1.3, "transport drafts" shouldn't rather be "transport specifications" ?

C3) end of section 1.3, upon termination decided by the publisher, is there a need for any explanation message sent to the subscriber?

C4) is there any reason why the YANG module validation but the datatracker fails? Outdated/invalid PYANG ?

C5) section 2.2 "all event records on an event stream are to be sent", should there be a mention of publisher being out of ressource ?

C6) section 2.4.1 "insufficient CPU or bandwidth available" but there may be other reasons (e.g. memory), what about using "insufficient CPU, bandwidth unavailable or other lack of ressource"

C7) for my curiosity, in section, how deep could realistically be a replay buffer? Minutes?

C8) the term 'transport' is used quite often in the document but it seems to refer to NETCONF and not so much to my understanding of 'transport' in an IETF document (which is TCP, UDP, SCTP, ...). Is it obvious to the readers? If so, then I do not mind. Else, it may be useful to clarify in section 1.2


N1) is there any reason why not all Cisco authors are not grouped together? (even if another one has changed affiliation)

N2) abstract s/information/data/ also applicable in other sections IMHO

N3) section 1.3, expand RPC even if obvious

N4) section 2.3, expand QoS even if obvious

(Magnus Westerlund) (was Discuss) No Objection

Comment (2019-05-10)
Thanks for addressing the discuss and issues. I understand that there is significant work in defining a solution that actually is capable of expressing the receiver's need and provides the publisher with reasonable to process rules and avoids the randomness in what happens in an overload situation. I hope the community will consider how they deal with this issue going forward.