[Gen-art] Gen-ART LC review of draft-ietf-idr-bgp-enhanced-route-refresh-06

"Peter Yee" <peter@akayla.com> Thu, 05 June 2014 18:38 UTC

From: Peter Yee <peter@akayla.com>
To: draft-ietf-idr-bgp-enhanced-route-refresh.all@tools.ietf.org
Date: Thu, 05 Jun 2014 11:38:02 -0700
Message-ID: <00e101cf80ed$4a0e9d70$de2bd850$@akayla.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Ac+A6uuiaVlJWZTWRceARV1M5CoFfw==
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/gen-art/ridVA3M_tKCF-tsmeMiYW2GSExY
Cc: gen-art@ietf.org, ietf@ietf.org
Subject: [Gen-art] Gen-ART LC review of draft-ietf-idr-bgp-enhanced-route-refresh-06
Precedence: list

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.

[Gen-art] Gen-ART LC review of draft-ietf-idr-bgp… Peter Yee
Re: [Gen-art] Gen-ART LC review of draft-ietf-idr… Keyur Patel (keyupate)
Re: [Gen-art] Gen-ART LC review of draft-ietf-idr… Jari Arkko