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.
<<attachment: smime.p7s>>