Skip to main content

Capabilities Advertisement with BGP-4
RFC 5492

Yes

(David Ward)
(Jari Arkko)

No Objection

(Chris Newman)
(Cullen Jennings)
(Dan Romascanu)
(Jon Peterson)
(Lisa Dusseault)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)

Note: This ballot was opened for revision 05 and is now closed.

(David Ward; former steering group member) Yes

Yes ()

                            

(Jari Arkko; former steering group member) Yes

Yes ()

                            

(Chris Newman; former steering group member) No Objection

No Objection ()

                            

(Cullen Jennings; former steering group member) No Objection

No Objection ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection (2009-01-08)

                            

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Lisa Dusseault; former steering group member) No Objection

No Objection ()

                            

(Mark Townsley; former steering group member) No Objection

No Objection ()

                            

(Pasi Eronen; former steering group member) No Objection

No Objection (2009-01-07)
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

No Objection ()

                            

(Ross Callon; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection (2009-01-07)
  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

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