Capabilities Advertisement with BGP-4
RFC 5492

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

Comment (2009-01-07)
No email
send info
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 -)
No email
send info
  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

Comment (2009-01-06)
No email
send info
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.

(Dan Romascanu) No Objection

(Mark Townsley) No Objection