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.
smime.p7s
Description: S/MIME cryptographic signature