Last Call Review of draft-ietf-hip-rfc5203-bis-09
review-ietf-hip-rfc5203-bis-09-opsdir-lc-wu-2016-01-04-00
Request | Review of | draft-ietf-hip-rfc5203-bis |
---|---|---|
Requested revision | 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 | |
I-D 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 | |
Request | Last Call review on draft-ietf-hip-rfc5203-bis by Ops Directorate Assigned | |
Reviewed revision | 09 (document currently at 11) | |
Result | Has nits | |
Completed | 2016-01-04 |
review-ietf-hip-rfc5203-bis-09-opsdir-lc-wu-2016-01-04-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