Re: [Hipsec] WGLC: draft-ietf-hip-rfc5204-bis

[Julien Laganier <[e-mail]>]

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
>>> [e-mail]
>>> 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.