Re: [Hipsec] I-D Action: draft-ietf-hip-rfc5203-bis-03.txt

[Ari Keranen <[e-mail]>]

Hi Julien,

On 1/17/14 5:50 AM, Julien Laganier wrote:
> Hi Ari,
>
> On Thu, Jan 16, 2014 at 8:20 AM, Ari Keranen <[e-mail]> wrote:
>> Hi Julien,
>>
>> Thanks, that looks good to me. Although reading the draft again, I was
>> wondering is it missing some text regarding the "Insufficient resources"
>> error?
>
> Hmm... a registration failing because of "insufficient resources" is
> quite explicit; it conveys enough information for a  requester to know
> that there are no resources to create a registration at a given
> registrar. Presumably a requester would try to register at a different
> registrar if it knows one...
>
> What else would the requester need to know?

I mean that it looks a bit strange that there's only an error code 
defined but no text at all when to use it (even if the name of the code 
kinda gives it away). I would recommend to add a sentence or two about 
when/how to use it.

I spotted one (copy-paste) error in the draft, section 3.3:

    If the registrar knows the Host Identities (HIs) of all the hosts
    that are allowed to use the relaying service, it SHOULD reject
    registrations from unknown hosts.  However, since it may be
    unfeasible to pre-configure the relay with all the HIs, the relay
    SHOULD also support HIP certificates [I-D.ietf-hip-rfc6253-bis] to
    allow for certificate based authentication.

This should no longer be "relaying service" and "relay" (2 instances 
here) but in general the service for which one is registering for.

In the figures, at the end of the section, I was wondering why S3 is not 
announced by the registrar? Also the text is a bit unclear; almost as if 
RQ would try to register for S1 and S2 even if the figure shows only S1.

In section "4.5. REG_FAILED", it says "Failure types other than zero (0) 
and one (1) have not been defined." This is obviously not true anymore. 
Perhaps here would be a good place for some text on the insufficient 
resources error code.

And by the way, I guess you can have more than one REG_FAILEDs if there 
was more than one failure type? The text seems to now imply only single 
REG_FAILED.

Section 6 says:

    Registrars act on a voluntary basis and are willing to accept being a
    responder and then to create HIP associations with a number of
    previously unknown hosts.

Now with the HI/cert authentication this has actually improved (you only 
potentially do things with previously unknown hosts).

Otherwise I think the draft is in good shape and could move forward.


Cheers,
Ari