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

[Jari Arkko <[e-mail]>]

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

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