Early Review of draft-ietf-hip-rfc6253-bis-05
review-ietf-hip-rfc6253-bis-05-intdir-early-korhonen-2015-11-24-00

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