Early Review of draft-ietf-hip-rfc6253-bis-05
review-ietf-hip-rfc6253-bis-05-intdir-early-korhonen-2015-11-24-00
| Request | Review of | draft-ietf-hip-rfc6253-bis |
|---|---|---|
| Requested rev. | no specific revision (document currently at 09) | |
| Type | Early Review | |
| Team | Internet Area Directorate (intdir) | |
| Deadline | 2015-11-24 | |
| Requested | 2015-11-20 | |
| Authors | Tobias Heer, Samu Varjonen | |
| Draft last updated | 2015-11-24 | |
| 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 | Jouni Korhonen |
| State | Completed | |
| Review | review-ietf-hip-rfc6253-bis-05-intdir-early-korhonen-2015-11-24 | |
| Reviewed rev. | 05 (document currently at 09) | |
| Review result | Ready | |
| Review completed: | 2015-11-24 |
Review
review-ietf-hip-rfc6253-bis-05-intdir-early-korhonen-2015-11-24
I reviewed this document as part of the Int-Dir reviews activity. You should treat the comments as any IETF LC comments. The document is ready for piblication with minor nits. My comments follow the line numbering as seen in IDnits. Editorial Comments: * Line 28: s/extends/updates * Line 72: s/extends/updates * Line 269: replaces or obsoletes.. typically when following the cover page terminology I would prefer "obsoletes" here as well. * Line 287: a verb is missing? e.g. "..are discussed.." etc * Lines 264-265: I cannot parse this sentence. "in order" meanning the 2 octets contain first Cert Group and followed by Cert ID? Please clarify. * Figure line 136: although text is clear about the padding behavior the figure makes one think there is always 2 octets of padding.. suggest coming up with slightly different ascii art here. Other (substantial) comments: * Lines 95-98: I find the recommendation of not including the CERT in the I1 packet odd. Actually, allowing it in I1 is a bit odd in general. A well behaving initiator would not do that unless it has a very good reason to do so but a hostile initiator would most certainly do that just to cause more processing at the responder. Why the CERT has to be possible in I1 if it is not recommended to be added in the first place? * Lines 103-14: The "MUST be set" text is a bit strange. Why not stating the same for Cert ID and type as well? Actually as these fields are in fixed positions and cannot be "optionally" left out. I suggest doing some rewording here. * Section 7 security considerations does not discuss the possible hostile use of CERT payload in I1 packet.. this is already hinted in Section 2. - Jouni