Updated Rules for Processing Stateful PCE Request Parameters Flags
draft-ietf-pce-stateful-flags-01
Yes
(Deborah Brungard)
No Objection
Roman Danyliw
Warren Kumari
Éric Vyncke
(Adam Roach)
(Alexey Melnikov)
(Barry Leiba)
(Magnus Westerlund)
(Martin Vigoureux)
(Mirja Kühlewind)
(Suresh Krishnan)
Note: This ballot was opened for revision 00 and is now closed.
Roman Danyliw
No Objection
Warren Kumari
No Objection
Éric Vyncke
No Objection
Deborah Brungard Former IESG member
Yes
Yes
(for -00)
Unknown
Adam Roach Former IESG member
No Objection
No Objection
(for -00)
Not sent
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -00)
Not sent
Alissa Cooper Former IESG member
No Objection
No Objection
(2020-01-21 for -00)
Not sent
Section 6: s/MAY log the fact./MAY log that fact./
Alvaro Retana Former IESG member
(was Discuss)
No Objection
No Objection
(2020-01-23)
Sent for earlier
[Thanks for addressing my DISCUSS.]
Barry Leiba Former IESG member
No Objection
No Objection
(for -00)
Not sent
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2020-01-21 for -00)
Sent
Thanks for this clear and well-written document! I just have a couple of editorial comments that probably don't even need a response. Section 4 There will remain an issue with compatibility between implementations of RFC 8231 that might set any of the unassigned flags, and current (such as [RFC8281]) and future (such as [I-D.ietf-pce-lsp-control-request]) specifications. That problem cannot be fixed in old implementations by any amount of documentation, and can only be handled for future specifications by obsoleting the Flags field and using a new technique. Fortunately, however, most implementations will have been constructed to set unused flags to zero which is consistent with the behavior described in this document. I had a little bit of trouble reading this, as I keep expecting the first sentence to be saying that there is a legitimately-allocated flag value that is set with intent to change behavior, but it doesn't really say anything specifically about a flag value getting allocated (or used). W.r.t. obsoleting Flags vs. relying on "most implementations" to be consistent with this document's recommendations, is it worth being more clear about the conclusion that this document is drawing, namely that the risk of bad interactions is sufficiently small that there is no desire to incur the cost of obsoleting/replacing the Flags field?
Magnus Westerlund Former IESG member
No Objection
No Objection
(for -00)
Not sent
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -00)
Not sent
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -00)
Not sent
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -00)
Not sent