Skip to main content

Enhanced Route Refresh Capability for BGP-4
RFC 7313

Yes

(Alia Atlas)

No Objection

(Alissa Cooper)
(Benoît Claise)
(Jari Arkko)
(Martin Stiemerling)
(Pete Resnick)
(Spencer Dawkins)
(Ted Lemon)

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

(Adrian Farrel; former steering group member) (was Discuss) Yes

Yes (2014-06-09 for -09)
Thanks for fixing my Discuss

(Alia Atlas; former steering group member) (was Discuss, Yes) Yes

Yes ()

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (for -09)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (2014-06-06 for -08)
I just have a couple of minor, non-blocking comments that I'd like you to please consider:

-- Section 1 --

   It is sometimes necessary to perform routing consistency validations
   such as checking for possible missing withdraws between BGP speakers

"Withdraw" is not a noun; the noun should be either "withdrawal" or "withdrawn route".  Both are consistent with usage in RFC 4271.

-- Section 4 --

   A BGP speaker that supports the message subtypes for the ROUTE-
   REFRESH message and the related procedures SHOULD advertise the
   "Enhanced Route Refresh Capability".

Why "SHOULD"?  Under what conditions might such a BGP speaker not advertise it?  I think what you really mean here doesn't need 2119 key words at all: change "SHOULD advertise" to "advertises".

(Benoît Claise; former steering group member) No Objection

No Objection ()

                            

(Brian Haberman; former steering group member) No Objection

No Objection (2014-06-09 for -08)
I support Adrian's DISCUSS points.

(Jari Arkko; former steering group member) No Objection

No Objection (for -09)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (2014-06-11)
Oh boy, passive voice.

(no this doesn't need to be fixed)

(Kathleen Moriarty; former steering group member) (was Discuss) No Objection

No Objection (2014-06-12)
Thanks for addressing my previous discuss to add in a reference to the
appropriate Security Considerations section of an existing RFC that covers the
list of known security considerations and addressing previous comments.

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -09)

                            

(Pete Resnick; former steering group member) No Objection

No Objection ()

                            

(Richard Barnes; former steering group member) No Objection

No Objection (2014-06-11)
The risk noted in Stephen's DISCUSS is worth considering.  I suspect the answer lies in how a BGP speaker handles a dropped session.  Everything is fine if either it discards any incomplete refresh or it discards all BGP state associated with the session.  In the former case, this document would need to specify the behavior; in the latter, assuming the behavior is documented elsewhere, a citation and note would be helpful.

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -09)

                            

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2014-06-10)
- section 4: I don't get why you need to say that stuff "MAY
be logged" - is that really needed? Are there real
conventions for what to not log with BGP? If so, I could
understand these statements, but absent such, I don't see
you need 'em. Equally, there's no problem saying that, it
just jumped out as an odd thing to say.

(Ted Lemon; former steering group member) No Objection

No Objection ()