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

From: Tom Henderson <[email-masked]>
Date: Tue, 2 Jun 2015 12:45:20 -0700 (PDT)

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/

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)?

p.4  s/unfeasible/infeasible

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.

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

---

From: Julien Laganier <[email-masked]>
Date: Wed, 10 Jun 2015 17:31:26 -0700

Hi Tom,

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

--julien

> p.3  s/registration type implicated/registration type requested/

done.

> 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.

> 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.

>    [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