Skip to main content

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

Request Review of draft-ietf-hip-rfc5203-bis
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-12-28
Requested 2015-12-15
Authors Julien Laganier , Lars Eggert
I-D last updated 2015-12-25
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 Francis Dupont
State Completed
Request Last Call review on draft-ietf-hip-rfc5203-bis by General Area Review Team (Gen-ART) Assigned
Reviewed revision 09 (document currently at 11)
Result Ready
Completed 2015-12-25
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-hip-rfc5203-bis-09.txt
Reviewer: Francis Dupont
Review Date: 20151218
IETF LC End Date: 20151228
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments:
 - 2 page 3: (comment!) I looked at if the re-registration is a refresh or
  a renew (I worked too long on DHCP these times :-): it is soft state
  so I agree the term refresh is the right one.

 - 3.3 page 4: the short description of what is "valid and accepted"
  for a certificate is very loose. I don't know if it will be enough
  for the security directorate... wait and see?

 - 4.[2-5] pages 6 to 9: the section titles should be at the beginning of
  the page, not at the end. Note the formatting will be fixed by the
  RFC Editor anyway.

 - 4.[2-5] pages 7 to 10: there is no details about the padding, e.g.,
  the padding is for a length which is a multiple of 8 bytes. IMHO
  you should add a reference to RFC 7401 section 5.2 "HIP Parameters"
  in section 4 so someone who wants a response to this question
  (or why types are even) knows where to go.

Regards (and Merry Christmas)

Francis.Dupont at