Enhanced Route Refresh Capability for BGP-4
draft-ietf-idr-bgp-enhanced-route-refresh-10

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

(Alia Atlas) (was Discuss, Yes) Yes

(Adrian Farrel) (was Discuss) Yes

Comment (2014-06-09 for -09)
No email
send info
Thanks for fixing my Discuss

(Jari Arkko) No Objection

(Richard Barnes) No Objection

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

(Benoît Claise) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) (was Discuss) No Objection

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

(Brian Haberman) No Objection

Comment (2014-06-09 for -08)
No email
send info
I support Adrian's DISCUSS points.

(Joel Jaeggli) No Objection

Comment (2014-06-11)
No email
send info
Oh boy, passive voice.

(no this doesn't need to be fixed)

Barry Leiba No Objection

Comment (2014-06-06 for -08)
No email
send info
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".

(Ted Lemon) No Objection

(Kathleen Moriarty) (was Discuss) No Objection

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

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection