Enhanced Route Refresh Capability for BGP-4
RFC 7313
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
(Adrian Farrel; former steering group member) (was Discuss) Yes
Thanks for fixing my Discuss
(Alia Atlas; former steering group member) (was Discuss, Yes) Yes
(Alissa Cooper; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
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
(Brian Haberman; former steering group member) No Objection
I support Adrian's DISCUSS points.
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
Oh boy, passive voice. (no this doesn't need to be fixed)
(Kathleen Moriarty; former steering group member) (was Discuss) No Objection
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
(Pete Resnick; former steering group member) No Objection
(Richard Barnes; former steering group member) No Objection
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
(Stephen Farrell; former steering group member) (was Discuss) No Objection
- 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