Tom,
The below is all fine with me. I will clear when the updated draft
is posted.Regards, Brian On 7/22/14 6:01 PM, Tom Henderson wrote: > On 07/22/2014 02:08 PM, Brian Haberman wrote: >> Hi Tom, >> >> On 7/22/14 2:51 PM, Tom Henderson wrote: >>> Brian, >>> >>> You left the following DISCUSS comments on draft-ietf-hip-rfc5201-bis >>> which I would like to address below: >>> >>>> I have no objection to the publication of this document, but I do >>>> have two small points to discuss in section 5.2.3. >>>> >>>> 1. The R1_COUNTER parameter was labeled as optional in RFC 5201, but >>>> made mandatory in this revision. However, the text says it SHOULD be >>>> included in R1. If it is not included in R1 (violates the SHOULD), >>>> where will it be included given it is mandatory? >>> >>> Support for it is mandatory (if the Responder sends it, the Initiator >>> must echo it back), but the inclusion by the responder is optional. >>> >>> To try to clarify this, I edited it (for version -15) to read: >>> >>> Support for the R1_COUNTER parameter is mandatory although >>> its inclusion in the R1 packet is optional. It SHOULD be >>> included in the R1 ... >>> >> >> The above is fine. If this parameter is sent by the Responder, what >> packets could it be sent in (i.e., violate the SHOULD) and still be >> useful? >> >> The above question is just something for you to think about. I will not >> hold a discuss on it. > > R1_COUNTER can be sent in the R1 and I2 packets (Sections 5.3.2 and > 5.3.3) but is not found in any of the other packets. > >> >>>> >>>> 2. The Type value of R1_COUNTER was 128 in 5201 and is now 129. Is >>>> that correct? >>> >>> Yes, by making its support mandatory, it is now deemed a "critical" >>> parameter and the LSB of the type value must be 1. This necessitated >>> the change from 128 to 129. >>> >> >> Is there a need to discuss any backwards compatibility issues with this >> change? >> > > I don't know whether any need exists. If a legacy implementation > provides 128, it also likely provides HIP version 1, in which case an > ICMP packet with Parameter Problem should be generated (section 5.4.2). > If HIP version 2 is indicated but this parameter is encoded with 128, > it will probably be covered by an implementation with the INVALID_SYNTAX > notification (Section 5.2.19). > > - Tom
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
