Skip to main content

Dynamic Subscription to YANG Events and Datastores over RESTCONF
draft-ietf-netconf-restconf-notif-15

Yes

(Ignas Bagdonas)

No Objection

Éric Vyncke
(Alexey Melnikov)
(Alvaro Retana)
(Deborah Brungard)
(Martin Vigoureux)
(Suresh Krishnan)

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

Roman Danyliw
(was Discuss) No Objection
Comment (2019-06-10 for -14) Sent for earlier
Thank you for addressing my DISCUSS and COMMENTs.
Éric Vyncke
No Objection
Ignas Bagdonas Former IESG member
Yes
Yes (for -13) Unknown

                            
Adam Roach Former IESG member
(was Discuss) No Objection
No Objection (2019-07-26) Sent
Thanks for addressing my discuss points!
Alexey Melnikov Former IESG member
No Objection
No Objection (for -13) Not sent

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2019-05-14 for -13) Sent
= Section 9 =

	"Access control must be set so that only someone
      with proper access permissions, and perhaps even HTTP session has
      the ability to access this resource."
    
There is a grammar error in this sentence -- "perhaps even HTTP session" doesn't follow from the antecedent.
Alvaro Retana Former IESG member
No Objection
No Objection (for -13) Not sent

                            
Barry Leiba Former IESG member
No Objection
No Objection (2019-05-15 for -13) Not sent
I support Adam’s DISCUSS point on Section 3.3.
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2019-06-13) Sent for earlier
Thank you for addressing my Discuss points!
Deborah Brungard Former IESG member
No Objection
No Objection (for -13) Not sent

                            
Magnus Westerlund Former IESG member
No Objection
No Objection (2019-05-16 for -13) Sent
Section 4:

Based on the QoS discussion for draft-ietf-netconf-subscribed-notifications weight is not really a a priority in the terms people think of it. It only provides a weight for bandwidth allocation. 

   o  take any existing subscription "priority", as specified by the
      "weighting" leaf node in
      [I-D.draft-ietf-netconf-subscribed-notifications], and copy it
      into the HTTP2 stream weight, [RFC7540] section 5.3, and

I would recommend that the use of "priority" is reformualted here to reflect that aspect. 


   o  take any existing subscription "dependency", as specified by the
      "dependency" leaf node in
      [I-D.draft-ietf-netconf-subscribed-notifications], and use the
      HTTP2 stream for the parent subscription as the HTTP2 stream
      dependency, [RFC7540] section 5.3.1, of the dependent
      subscription.

What is not obivous to me is that just because that a subscription exists at the publisher that it is going over the same HTTP/2 connection and thus there might be nothing for the dependency to point at that is relevant for the mechanism described in RFC 7540. I didn't even find a recommendation that the receiver (subscriber) should actually re-use the HTTP/2 connection for all communication with the same publisher.
Martin Vigoureux Former IESG member
No Objection
No Objection (for -13) Not sent

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2019-05-13 for -13) Sent
One question (and this is probably just because of my lack of detailed knowledge about RESTCONF):

Sec 4 says: "To meet subscription quality of service promises, the publisher MUST
   take any existing subscription "dscp" and apply it to the DSCP
   marking in the IP header."
What does "existing subscription "dscp"" mean here?

Related update: please also consider the comment from the TSV-ART review about the example DSCP value (Thanks Wes!). I actually would also appreciate to add a comment that this is an internal value that depends on the network configuration (in order to avoid that people just randomly copy this example value and suddenly always use 10)!
Suresh Krishnan Former IESG member
No Objection
No Objection (for -13) Not sent