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

[Julien Laganier <[e-mail]>]

Hi Tom,

Thank you for the WGLC review. Please see inline the proposed
resolution of your WGLC comments.

--julien

On Tue, Jun 2, 2015 at 12:45 PM, Tom Henderson <[e-mail]> wrote:
> I discovered recently that my email this year to the HIPSEC list has not been making it to the list, and I haven't been able to resolve the issue, so I will start to send from a different address.
>
> Below, please find some comments on the RFC5203-bis draft that I sent on May 11.
>
> - Tom
>
> On 04/24/2015 03:09 AM, Gonzalo Camarillo wrote:
>> Hi,
>>
>> I would like to start a WGLC on the following draft. This WGLC will end
>> on May 11th:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis/
>>
>> Please, send your comments to this list.
>
> Gonzalo and Julien, I had a fresh read of this document and it looks
> ready, aside from the following small comments.
>
> - Tom
>
> p.3  s/registration type implicated/registration type requested/

done.

> p.4  "A host that is capable and willing to act as a registrar SHOULD
>    include a REG_INFO parameter in the R1 packets it sends during all
>    base exchanges."  Shouldn't this be constrained to include REG_INFO
> only to those hosts to which it wants to offer services (i.e. it may not
> offer such services to all peers that it talks to)?

Makes sense. I have adjusted the text to read:

        A host that is capable and willing to act as a registrar
vis-a-vis a specific
        requester SHOULD include a REG_INFO parameter in the R1 packets it
        sends during all base exchanges with that requester.

> p.4  s/unfeasible/infeasible

done.

> p.9  what is the purpose of including minimum and maximum lifetime in
> the REG_INFO, when it can be seemingly disregarded by the registrar?
>
>    The requester MUST be prepared to receive any registration lifetime,
>    including ones beyond the minimum and maximum lifetime indicated in
>    the REG_INFO parameter.  It MUST NOT expect that the returned
>    lifetime will be the requested one, even when the requested lifetime
>    falls within the announced minimum and maximum.
>
> wouldn't it be easier to just have the requester just submit its
> request, and accept whatever the registrar gives it (which it has to do
> anyway)?  Else, please clarify what a requester should do with the
> min/max provided by the REG_INFO.

The min/max lifetime in the the REG_INFO are offered by the registrar
to the requester as guidance w.r.t. to the interval of lifetimes that
are currently acceptable to the registrar.

The provision that the requester be prepared to deal with a
registration lifetime that is not within the previously advertized
interval makes the protocol robust against a change of the acceptable
interval between its advertisement in REG_INFO and the registration
being requested and granted in REG_REQ/RESP exchange.

I've added to the REG_INFO parameter description the following
paragraph to clarify what the requester should do with these values.

     The registrar indicates the minimum and maximum registration lifetime
     that it is willing to offer to a requester. A requester SHOULD NOT
     request registration with lifetime greater than the maximum registration
     lifetime or smaller than the minimum registration lifetime.

> p.11 In the IANA section, I think that you want to instead request that
> IANA replace references to RFC 5203 to with references to this document,
> and to allocate two new Registration Failure Type codes for these new ones:
>
>    [TBD-IANA]      Insufficient resources
>    [TBD-IANA]      Invalid certificate

done:

  This document updates the IANA Registry for HIP Parameters Types by
   replacing references to [RFC5203] by references to this document.

   This document also updates the registry for registration failure
   types by making the following failure type definitions and
   reservations:

   Failure Type    Reason
   ------------    --------------------------------------------
   [TBD-IANA]      Insufficient resources
   [TBD-IANA]      Invalid certificate