Capabilities Advertisement with BGP-4
draft-ietf-idr-rfc3392bis-05
Yes
(David Ward)
(Jari Arkko)
No Objection
(Chris Newman)
(Cullen Jennings)
(Dan Romascanu)
(Jon Peterson)
(Lisa Dusseault)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Tim Polk)
Note: This ballot was opened for revision 05 and is now closed.
David Ward Former IESG member
Yes
Yes
()
Unknown
Jari Arkko Former IESG member
Yes
Yes
()
Unknown
Chris Newman Former IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
(2009-01-08)
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
No Objection
No Objection
(2009-01-07)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2009-01-07)
Unknown
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 IESG member
(was No Record, Discuss)
No Objection
No Objection
(2009-01-06)
Unknown
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.