Document: Host Identity Protocol (HIP) Registration Extension
Draft:  draft-ietf-hip-registration-02
Reviewer: Chisholm, Sharon 
Review Date: Wednesday 2/14/2007 1:00 PM CST
IETF LC Date: 1/29/2007


Summary: This document is ready for publication, but has the following
nits that should be resolved.

Comments
---------

1. In section 2, replace "Please note that terminology shared with other
documents is defined elsewhere [RFC4423]." with "Please note that
additional terminology is defined in [RFC4423]."

2. In section 2, requester is defined to be "a HIP node registering with
a HIP registrar to request registration for a service.", but wouldn't
you register for a service, not for a registration for a service?

3. In section 3, first paragraph it says 'Other documents will define
parameters and how they shall be used.", which is pretty vague. Suggest
replacing with "Subsequent documents will define these parameters and
how they shall be used." This is still value but changes other to
subsequent implying the documents will be based on this stuff and adds a
'these' in front of parameters to link it back to what was discussed in
the previous sentence.

4. In section 3.2, I2 and R2 are used without being first introduced. I
understand these are used in HIP and shown in a figure in section 3.3 a
page or two later, but they should really be better introduced.

5. In section 3.3, third paragraph says "The precise means of
establishing and verifying credentials are beyond the scope of this
document and are expected to be defined in other documents.", where
'other documents' again seems vague.

6. In section 4.2, 4.3, 4.4 and 4.5, it says things like
	Reg Type        Service
    --------        -------
    0-200           Reserved by IANA
    201-255         Reserved by IANA for private use
I suspect this is saying that 0-200 are reserved for IETF usage and
registered via IANA and that 201-255 are available for
vendor/implementation use as also registered by IANA. This isn't clear
from the text.

7. In section 4.3, second real paragraph says "The requester MUST NOT
include more than one REG_REQUEST parameter in its I2 or UPDATE packets,
while the registrar MUST be able to process one or more REG_REQUEST
parameters in received I2 or UPDATE packets." This doesn't make sense to
me. Do you mean that the registrar must support it or do you mean it
should reject with appropriate error if it received more then one
REG_REQUEST parameter?

8. In section 4.4, second real paragraph says "The registrar MUST NOT
include more than one REG_RESPONSE parameter in its R2 or UPDATE
packets, while the requester MUST be able to process one or more
REG_RESPONSE parameters in received R2 or UPDATE packets." which again
doesn't make sense to me.

9. In section 4.3 and 4.4, it says "HIP_SIGNATURE protects the parameter
within the R2 and UPDATE packets." without any explanation or reference.

10. In section 4.5, second last paragraph replace "The registrar SHOULD
include the REG_FAILED parameter in its R2 or UPDATE packet, if
registration with the registration types listed has not completed
successfully and a requester is asked to try again with additional
credentials." with "The registrar SHOULD include the REG_FAILED
parameter in its R2 or UPDATE packet if registration with the
registration types listed has not completed successfully. A requester
should then try again with additional credentials."

11. In section 5, second paragraph replace "and to accommodate for
existing timeouts of state established in middleboxes " with "and to
accommodate existing timeouts of state established in middleboxes "

12. In section 6, third paragraph replace "should not introduce and
serious additional" with "should not introduce any serious additional"

13. In section 8, it says that "Adding a new type requires new IETF
specifications.", but do we really mean this for private allocations?
This section also has the same problem as outlined in issue 6.