Capabilities Advertisement with BGP-4
Note: This ballot was opened for revision 05 and is now closed.
(Jari Arkko) Yes
(David Ward) Yes
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Lisa Dusseault) No Objection
(Pasi Eronen) 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.
(Russ Housley) No Objection
Comment (2009-01-07 for -)
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?
(Cullen Jennings) No Objection
(Chris Newman) No Objection
(Jon Peterson) No Objection
(Tim Polk) (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.