Skip to main content

Last Call Review of draft-ietf-idr-bgp-enhanced-route-refresh-06
review-ietf-idr-bgp-enhanced-route-refresh-06-genart-lc-yee-2014-06-05-00

Request Review of draft-ietf-idr-bgp-enhanced-route-refresh
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-06-03
Requested 2014-05-22
Authors Keyur Patel , Enke Chen , Balaji Venkatachalapathy
I-D last updated 2014-06-05
Completed reviews Genart Last Call review of -06 by Peter E. Yee (diff)
Genart Last Call review of -06 by Peter E. Yee (diff)
Secdir Last Call review of -06 by Dacheng Zhang (diff)
Assignment Reviewer Peter E. Yee
State Completed
Request Last Call review on draft-ietf-idr-bgp-enhanced-route-refresh by General Area Review Team (Gen-ART) Assigned
Reviewed revision 06 (document currently at 10)
Result Ready w/nits
Completed 2014-06-05
review-ietf-idr-bgp-enhanced-route-refresh-06-genart-lc-yee-2014-06-05-00
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Please resolve these comments along with any other Last Call comments you
may receive.

Document: draft-ietf-idr-bgp-enhanced-route-refresh-06
Reviewer: Peter Yee
Review Date: June-04-2014
IETF LC End Date: June-03-2014
IESG Telechat date: June-12-2014

This review is a couple of days late owing to my being unavailable during
most of the review period.

Summary: This draft is basically ready for publication as a Standards Track
RFC, but has some nits that should be fixed before publication. [Ready with
nits.]

No major complaints with this draft -- just a few consistency nits and a
couple of questions.

Questions:

Page 3, Section 3.2: the set of available values is enumerated.  Is the
encoding format of these values understood from other context?  Older BGP
specifications seem to give guidance such as "unsigned integer" at a
minimum.

Page 3, Section 3.2, table of values: the value is a "should" in RFC 2918.
That RFC indicated that it was to be ignored by recipients.  Now that values
will actually matter, is there any concern about senders that don't abide by
the "should" clause in RFC 2918?

Page 4, 1st full paragraph, 3rd sentence: the behavior for receipt of a BoRR
is described.  What happens if an EoRR is somehow received prior to receipt
of a BoRR?  Is it just ignored?  Or should an error notification be
returned?

Nits:

Page 3, Section 4, 4th paragraph, 2nd sentence: change "comprise of both,
the" to "comprise both the".

Page 4, 1st partial paragraph: change "ADJ-RIB-Out" to "Adj-RIB-Out" for
consistency.

Page 4, 1st full paragraph, 3rd sentence: change "anytime" to "any time".

Page 4, 3rd paragraph, 2nd sentence: use upper/lower case consistently for
the term 'EoR'.  RFC 4724 does not give specific guidance, but the spelled
out form would tend to indicate that 'EoR' is preferred.

Page 5, Section 6, table: value 255 is shown reserved.  This clashes with
the text in Section 3.2 which indicates all values outside of 0 - 2 are
reserved.

Page 5, last paragraph, 2nd sentence: change "need" to "needs".

Page 7, authors' addresses: drop "95124" from both addresses.