Hi Tom, Thank for the review. Please see inline below the proposed resolution for your WGLC comments.
--julien > On 05/05/2015 2:02 AM, Tom Henderson wrote: >> On 04/17/2015 03:47 AM, Gonzalo Camarillo wrote: >>> Hi, >>> >>> I would like to start a WGLC on the following draft. This WGLC will end >>> on May 4th: >>> >>> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5204-bis/ >>> >>> Please, send your comments to this list. >>> >>> Thanks, >>> >>> Gonzalo >>> >>> _______________________________________________ >>> Hipsec mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/hipsec >>> >> >> Here are a few questions/comments on this draft. >> >> Technical >> --------- >> Section 4.3.3 (including VIA_RVS) seems to conflict with 4.2.3 (VIA_RVS >> parameter definition). Section 4.3.3 states that VIA_RVS is mandatory >> if the I1 arrived via a RVS, but 4.2.3 says that the responder MAY >> choose to send it for debugging purposes. I have made it mandatory everywhere. >> Another point regarding Section 4.2.3: it states that the responder may >> include "a subset of the IP addresses of its RVSs in some of the >> packets." What use cases are there for including more than a single RVS >> address (the one that was used)? Would more than one RVS ever need to >> be traversed between initiator and responder? I don't think the draft >> supports such security relationships, so perhaps it would be best to >> explicitly say it is out of scope. I've added a disclaimer than including more than one RVS IP address is out of scope. The paragraph in 4.2.4 now reads: After the responder receives a relayed I1 packet, it can begin to send HIP packets addressed to the initiator's IP address, without further assistance from an RVS. For debugging purposes, it MUST append a newly created VIA_RVS parameter at the end of the R1 packet that contains the IP address of the RVS that relayed the I1 packet. Including more than one IP address in the VIA_RVS parameter is outside the scope of this specification. The main goal of using the VIA_RVS parameter is to allow operators to diagnose possible issues encountered while establishing a HIP association via an RVS. >> Editorial >> ---------- >> Section 6 (IANA) needs to be updated to request the new action items of >> IANA, not the ones previously asked when 5204 was published. >> Accordingly, IANA is not assigning new Parameter Types but instead this >> draft should request that IANA update the reference for these three >> types from 5204 to this document. The same holds for the Registration >> Type value. done. IANA sec. now reads: This document updates the IANA Registry for HIP Parameters Types by replacing references to [RFC5204] by references to this document. _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
