Capabilities Advertisement with BGP-4
RFC 5492
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
(David Ward; former steering group member) Yes
(Jari Arkko; former steering group member) Yes
(Chris Newman; former steering group member) No Objection
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Pasi Eronen; former steering group member) No Objection
Minor nit (which could be fixed during RFC Editor processing): The "IETF Consensus" policy has been renamed to "IETF Review" in RFC 5226, so Section 6 should be updated accordingly.
(Ron Bonica; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
Elwyn Davies performed a Gen-ART Review, and he pointed out that there does not appear to be an IANA registry for OPEN message (optional) parameter types. Should one be established?
(Tim Polk; former steering group member) (was No Record, Discuss) No Objection
I believe a second paragraph should be added to the introduction. The current text reads: The base BGP-4 specification [RFC4271] requires that when a BGP speaker receives an OPEN message with one or more unrecognized Optional Parameters, the speaker must terminate the BGP peering. This complicates the introduction of new capabilities in BGP. On first reading, I assumed this specification modified the processing rules for unrecognized Optional Parameters. Perhaps another paragraph to explain the strategy would be useful. Perhaps something along the following lines would be useful: This specification defines an Optional Parameter and processing rules that allows BGP speakers to communicate capabilities in an OPEN message. BGP speakers that both support this specification can maintain the peering even when presented with unrecognized capabilities, so long as all capabilities required to support the peering are supported.