Skip to main content

Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol
RFC 7470

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 steering group member) Yes

Yes ()

                            

(Barry Leiba; former steering group member) Yes

Yes ()

                            

(Spencer Dawkins; former steering group member) Yes

Yes ()

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (2015-01-05)
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

No Objection (2015-01-06)
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

No Objection ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection ()

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2015-01-06)
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

No Objection ()

                            

(Pete Resnick; former steering group member) No Objection

No Objection ()

                            

(Richard Barnes; former steering group member) No Objection

No Objection ()

                            

(Stephen Farrell; former steering group member) No Objection

No Objection ()

                            

(Ted Lemon; former steering group member) No Objection

No Objection ()

                            

(Adrian Farrel; former steering group member) Recuse

Recuse ()