Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol
RFC 7470
Yes
No Objection
Recuse
Note: This ballot was opened for revision 01 and is now closed.
(Alia Atlas; former steering group member) Yes
(Barry Leiba; former steering group member) Yes
(Spencer Dawkins; former steering group member) Yes
(Alissa Cooper; former steering group member) No Objection
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 steering group member) No Objection
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 steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
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 steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Richard Barnes; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
(Ted Lemon; former steering group member) No Objection
(Adrian Farrel; former steering group member) Recuse