Re: Gen-ART LC review of draft-ietf-idr-bgp-enhanced-route-refresh-06

["Keyur Patel (keyupate)" <[e-mail]>]

Hi Peter,

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

More comments inlined. #Keyur

On 6/5/14 11:38 AM, "Peter Yee" <[e-mail]> wrote:

>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.

#Keyur: Yes.

>
>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?

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

>
>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?

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

Best Regards,
Keyur

>
>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.
>
>