Document: draft-ietf-rohc-ikev2-extensions-hcoipsec-09.txt Reviewer: David L. Black Review Date: 18 September 2009 IETF LC End Date: 17 September 2009 I apologize for being a day late on this review. Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: The draft does not use RFC 2119 keywords (e.g., MUST), but the draft is clearly written with clearly stated requirements, so the authors' non-use of RFC 2119 keywords is not a problem. Figure 2 is confusing; it would be better to separate it into two ASCII diagrams, one each for the AF=0 and AF=1 cases. For AF=0, tilde (~) characters should be used in the vertical sides of the ROHC Attribute Value box to indicate that the value is variable length. In Section 2.1.2, the discussion of ROHC Profile neglects to say where the profile numbers come from. It looks like they come from the IANA registry for ROHC Profile Identifiers: http://www.iana.org/assignments/rohc-pro-ids/rohc-pro-ids.xhtml That should be stated. Truncating an integrity algorithm's output via use of a ROHC_ICV_LEN value that is less than the algorithm's normal output size weakens the security protection of that integrity algorithm. That needs to be noted as a security consideration in Section 3. The last sentence of the description of the MRRU attribute is: If MRRU is 0 or if no MRRU attribute is sent, no segment headers are allowed on the ROHCoIPsec channel. What's a segment header? Please add a sentence or two to explain. idnits 2.11.13 ran clean after correctly guessing that this draft is intended for Proposed Standard status.