Last Call Review of draft-ietf-hip-rfc5203-bis-09

Request Review of draft-ietf-hip-rfc5203-bis
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-12-28
Requested 2015-12-22
Authors Julien Laganier, Lars Eggert
Draft last updated 2016-01-04
Completed reviews Genart Last Call review of -09 by Francis Dupont (diff)
Genart Telechat review of -10 by Francis Dupont (diff)
Secdir Last Call review of -09 by Takeshi Takahashi (diff)
Secdir Telechat review of -10 by Takeshi Takahashi (diff)
Intdir Early review of -09 by Jouni Korhonen (diff)
Opsdir Last Call review of -09 by Qin Wu (diff)
Assignment Reviewer Qin Wu
State Completed
Review review-ietf-hip-rfc5203-bis-09-opsdir-lc-wu-2016-01-04
Reviewed rev. 09 (document currently at 11)
Review result Has Nits
Review completed: 2016-01-04



Merry Christmas and Happy new year to everybody.

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational
 aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.


This document provides a generic means for a HIP aware host to register with a service and is a companion document of draft-ietf-hip-rfc5204-bis-06.

I think this document is also well written and ready for publication. Here are a few editorial comments:



Section 3.3, paragraph 4:

I think what requires authentication is registration type  listed in the REG_REQUEST parameter, rather than HI of the requester or the certificate of the requester? Checking HI of the requester or certificate of the requester
 is just an way to perform authentication on registration type?


So my suggestion is to propose the following change:



whether the HI of the requester is in the allowed list for all the

   Registration Types in the REG_REQUEST parameter




whether the HI of the requester associated with the registration type is in the allowed list for all the Registration Types in the REG_REQUEST parameter


The similar change is applied to certificate checking related text.



Section 3, two figures:

Would it be great to add abbreviation of I1,I2, R1,R2 in the terminology section.



Section 3, Figure 1

What’s the relationship between service, e.g., S1, S2, S3 and registration type? I think S1, S2, S3 is an example of registration type, please correct me if I am wrong, if not, please make this clear in the text.



Section 3, figure 1

I am wondering how do we distinct S1, S2, S3 from HIP message type,e.g., I1, I2, R1, R2, I feel confusion after taking a first look at that, Can we change S1, S2, S3 into S-1, S-2, S-3? That is one way I think to
 make distinction between the service and HIP message and avoid confusion.



Section 4.1

I think The exact range is from 2^-8 seconds to 2^24seconds,The the range from 4ms to 178 days

Seems not inaccurate to me.



Section 4.2, Minimum Lifetime definition

I think the measurement unit is seconds, do we make this clear in the definition of Min Lifetime?