Re: [Hipsec] A new I-D: HIP Registration Extension

I read this document again, and in general it looks good to me.

The language could be improved, now it is a little bit too
"abstract" or fluffy to my taste.  Changing some of the terminology
and especially the definitions of terms would make it easier to
read.  Also considering advice from draft-iab-model-XX.txt might
help.  But content-wise, once a proper security considerations
section is added, I think the document starts to be ready
for a WG LC, though most probably we have to wait for the base spec
to first advance to WG LC.

Major detail:

Did we discuss using exponential seconds instead of seconds for
the lifetimes?  I don't remember any more.  In general, I'm in
favour of fixed point exponential times instead of integer
times...

The parameter type values need to be checked against base-03.

Can a reply include both REG_RESPONSE and REG_FAILED params
if some of the registrations succeeded and some failed?

Minor details:

Sec 3, bullet 3:

>    3.  At this point, the registrar tries to authenticate the requester
>        based on currently available information.  The details of this
>        authentication procedure are not specified in this document.  If

It would be good to be more specific in the second statement, and
refer directly to the base spec.  Also make the difference between
authentication (as a part of the base exchange) vs. authorisation
(which is a matter local to the registrar).

Sec 3, second list, bullet 1:

>        exchanges or later announces its capabilities by sending the

It might be good to discuss briefly when REG_INFO might be sent in
an UPDATE; i.e., when the registrar changes its configuration.
It would also be good to note that there may be a long time between
R1 with REG_INFO and UPDATE with REG_REQUEST...

Sec 3, second list, bullet 3:

Please clarify the authenticate vs. authorise language.  I think
the first sentence uses authenticate while it should use authorise.

Sec 3, 2nd para after second list:

>   Both the requester and
>   registrar can cancel the created registration before its expiration.

I don't understand what that is trying to say.  I guess this is
part of the language being too abstract or fluffy...  Or otherwise
I just need more coffee....

Sec 4.2:

>    REG_REQUEST parameter is in an UPDATE packet, the registrar SHOULD
>    NOT modify the registrations of registration types which are not
>    listed in the parameter.  Moreover, the requester SHOULD NOT include

IMHO these "SHOULD NOT"s should be "MUST NOT"s....  In the former
case, violating the rule would lead to inconsistent state (enough for
a MUST), in the latter case apply the "be strict in what you sent
(and liberal in what you expect) principle".

>    the parameter unless the registrar's I1 packet or an earlier 
> received

s/an earlier/latest/

>    signature.  The requester SHOULD support inclusion of multiple
>    instances of the REG_REQUEST parameter in its I2 packets.

What happens if it does not?

Sec 4.3:

>    The registrar SHOULD include the REG_RESPONSE parameter in its R2 or
>    UPDATE packet only if a registration has successfully completed.

I don't understand why we have here a "SHOULD"??  What is the rationale?
Doesn't the registrar just include it if and only if the rgistration
has been succesfully completed?

Sec 4.4:

>    The registrar SHOULD include the REG_FAILED parameter in its R2 or
>    UPDATE packet if registering with registration types listed has not
>    completed successfully and a requester is asked to try again with
>    additional credentials.

I don't understand the rationale for the SHOULD here either.

Sec 5:

>    REG_RESPONSE parameters.  Therefore, registration type definitions
>    MAY define dependencies for HIP parameters that are not defined in

... specifications that define different registration types and
corresponding services MAY define ...

--Pekka

_______________________________________________
Hipsec mailing list
Hipsec@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/hipsec