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

From: "Peter Yee" <[email-masked]>
Date: Thu, 5 Jun 2014 11:38:02 -0700

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.

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Fri, 6 Jun 2014 19:54:40 +0000

Hi Peter,

Thank you for the draft review. I have fixed the nits in the draft.

More comments inlined. #Keyur

>specifications seem to give guidance such as "unsigned integer" at a

#Keyur: Yes.

>the "should" clause in RFC 2918?

#Keyur: Yes. This functionality is controlled using BGP capabilities.

>of a BoRR?  Is it just ignored?  Or should an error notification be

#Keyur: It would be a no-op operation. 07 version of draft covers it.

Best Regards,
Keyur

---

From: Jari Arkko <[email-masked]>
Date: Tue, 10 Jun 2014 10:14:42 +0300

Peter, Keyur,

First: thank you Peter for your review.

I am looking at the changes from the reviewed draft to the most recent one:

    http://tools.ietf.org/rfcdiff?url1=draft-ietf-idr-bgp-enhanced-route-refresh-06.txt&url2=draft-ietf-idr-bgp-enhanced-route-refresh-09.txt

and I think they cover Peter’s third item (receiving an EoRR before receiving a BoRR).  The second item, is I think, clear without any changes. On the first item, I think the situation is also clear when looking at both Sections 3.2 and 6.

Thanks, all,

Jari