Enhanced Route Refresh Capability for BGP-4
draft-ietf-idr-bgp-enhanced-route-refresh-10
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 IESG member
(was Discuss)
Yes
Yes
(2014-06-09 for -09)
Unknown
Thanks for fixing my Discuss
Alia Atlas Former IESG member
(was Discuss, Yes)
Yes
Yes
()
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -09)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2014-06-06 for -08)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(2014-06-09 for -08)
Unknown
I support Adrian's DISCUSS points.
Jari Arkko Former IESG member
No Objection
No Objection
(for -09)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2014-06-11)
Unknown
Oh boy, passive voice. (no this doesn't need to be fixed)
Kathleen Moriarty Former IESG member
(was Discuss)
No Objection
No Objection
(2014-06-12)
Unknown
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 IESG member
No Objection
No Objection
(for -09)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
()
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(2014-06-11)
Unknown
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 IESG member
No Objection
No Objection
(for -09)
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2014-06-10)
Unknown
- 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 IESG member
No Objection
No Objection
()
Unknown