Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol
draft-ietf-pce-rfc7150bis-01
Yes
(Alia Atlas)
(Barry Leiba)
(Spencer Dawkins)
No Objection
(Brian Haberman)
(Jari Arkko)
(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)
(Stephen Farrell)
(Ted Lemon)
Recuse
(Adrian Farrel)
Note: This ballot was opened for revision 01 and is now closed.
Alia Atlas Former IESG member
Yes
Yes
()
Unknown
Barry Leiba Former IESG member
Yes
Yes
()
Unknown
Spencer Dawkins Former IESG member
Yes
Yes
()
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(2015-01-05)
Unknown
It's a little hard to gather the context here just from reading the document and the shepherd write-up, so apologies if this is an obvious question: is there a plan in place to get the object-class value 32 registered? If not, what is to prevent the same scenario from arising again once 32 is unassigned, other than general knowledge among WG participants that 32 is in use but has not been registered?
Benoît Claise Former IESG member
No Objection
No Objection
(2015-01-06)
Unknown
As explained in the write-up: "A diff allows to quickly spot the new text." A new section called "Differences from RFC 7150", with your text below, and a table of content to highlight this section is a very good practice IMO. This document obsoletes RFC 7150 making two changes to that document: - Clarification that the TLV is available for use in any PCEP object (existing or future) that supports TLVs. - The allocation of a different code point for the VENDOR-INFORMATION object. This change became necessary because of an inadvertant clash with codepoints used in another Internet-Draft that had been deployed without IANA allocation. The PCE working group has conducted a survey of implementations and deployments of RFC 7150 and considers that this change is safe and does not harm early implementers of RFC 7150.
Brian Haberman Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2015-01-06)
Unknown
Thanks for your work on this draft. I see the concern listed in the security considerations section for possible abuse on the size of PCEP messages and this addition helping with more opportunities for bloat. The security considerations section points to authentication and integrity to protect against this, but normally that would be coding practices (limits to size/length of fields, etc.). I noticed the SecDir review had a similar observation. Is there a reason that can't be done? Are there are limits for the defined object type that can help? https://www.ietf.org/mail-archive/web/secdir/current/msg05331.html Thanks, Kathleen
Martin Stiemerling Former IESG member
No Objection
No Objection
()
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
()
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
()
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
()
Unknown
Ted Lemon Former IESG member
No Objection
No Objection
()
Unknown
Adrian Farrel Former IESG member
Recuse
Recuse
()
Unknown