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 <[email protected]> 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
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
