Skip to main content

Last Call Review of draft-ietf-hip-rfc6253-bis-06
review-ietf-hip-rfc6253-bis-06-opsdir-lc-wu-2016-04-11-00

Request Review of draft-ietf-hip-rfc6253-bis
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-12-28
Requested 2016-01-05
Authors Tobias Heer , Samu Varjonen
I-D last updated 2016-04-11
Completed reviews Genart Last Call review of -06 by Dan Romascanu (diff)
Genart Telechat review of -08 by Dan Romascanu (diff)
Secdir Last Call review of -06 by Sean Turner (diff)
Secdir Telechat review of -08 by Sean Turner (diff)
Intdir Early review of -05 by Jouni Korhonen (diff)
Intdir Early review of -05 by Pascal Thubert (diff)
Opsdir Last Call review of -06 by Qin Wu (diff)
Assignment Reviewer Qin Wu
State Completed
Request Last Call review on draft-ietf-hip-rfc6253-bis by Ops Directorate Assigned
Reviewed revision 06 (document currently at 09)
Result Has nits
Completed 2016-04-11
review-ietf-hip-rfc6253-bis-06-opsdir-lc-wu-2016-04-11-00

Hi,

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:

1.



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:

OLD TEXT:

“

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

   Registration Types in the REG_REQUEST parameter

”

NEW TEXT:

“

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.

2.



Section 3, two figures:

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

3.



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.

4.



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.

5.



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.

6.



Section 4.2, Minimum Lifetime definition

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



Regards!

-Qin