Skip to main content

Subscription to YANG Notifications
draft-ietf-netconf-subscribed-notifications-26

Yes

(Ignas Bagdonas)

No Objection

(Adam Roach)
(Barry Leiba)
(Deborah Brungard)
(Martin Vigoureux)
(Suresh Krishnan)

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

Roman Danyliw
(was Discuss) No Objection
Comment (2019-05-06 for -25) Sent for earlier
Thank you for resolving my DISCUSS.
Warren Kumari
No Objection
Comment (2019-04-30 for -24) Not sent
I support Benjamin and Roman's DISCUSSes.

Also, thanks to Benjamin and others for such detailed reviews, they saved my much typing :-)
Éric Vyncke
No Objection
Comment (2019-04-30 for -24) Sent
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.

Comments
--------

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 2.4.2.1, 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

Nits
----

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
Ignas Bagdonas Former IESG member
Yes
Yes (for -23) Unknown

                            
Adam Roach Former IESG member
No Objection
No Objection (for -25) Not sent

                            
Alexey Melnikov Former IESG member
(was Discuss) No Objection
No Objection (2019-05-02 for -25) Not sent
I missed comment from the document shepherd about YANG validation, so I am clearing my DISCUSS.
Alissa Cooper Former IESG member
No Objection
No Objection (2019-05-01 for -25) Sent
= 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.
Alvaro Retana Former IESG member
No Objection
No Objection (2019-05-01 for -25) Not sent
I support Roman's DISCUSS.
Barry Leiba Former IESG member
No Objection
No Objection (for -25) Not sent

                            
Benjamin Kaduk Former IESG member
(was Discuss, No Record, Discuss) No Objection
No Objection (2019-05-06 for -25) Sent for earlier
Thank you for resolving my Discuss points!
Deborah Brungard Former IESG member
No Objection
No Objection (for -23) Not sent

                            
Magnus Westerlund Former IESG member
(was Discuss) No Objection
No Objection (2019-05-10) Sent
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.
Martin Vigoureux Former IESG member
No Objection
No Objection (for -25) Not sent

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2019-04-29 for -23) Sent
 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
      subscriptions.”

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.
Suresh Krishnan Former IESG member
No Objection
No Objection (for -25) Not sent