Re: [rohc] Gen-ART review of draft-ietf-rohc-ikev2-extensions-hcoipsec-09

[<Black_David at emc.com>]

> Review Date: 18 August 2009
> IETF LC End Date: 17 August 2009

Of course those are both actually September ...

Thanks,
--David
 

> -----Original Message-----
> From: Black, David 
> Sent: Friday, September 18, 2009 7:15 PM
> To: ertekin_emre at bah.com; christou_chris at bah.com; 
> ro at breakcheck.com; kivinen at safenet-inc.com; cabo at tzi.org; 
> gen-art at ietf.org
> Cc: Black, David; Carl Knutsson; Magnus Westerlund; rohc at ietf.org
> Subject: Gen-ART review of 
> draft-ietf-rohc-ikev2-extensions-hcoipsec-09
> 
> I have been selected as the General Area Review Team (Gen-ART) 
> reviewer for this draft (for background on Gen-ART, please see 
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> Please resolve these comments along with any other Last Call
> comments  you may receive. 
> 
> Document: draft-ietf-rohc-ikev2-extensions-hcoipsec-09.txt
> Reviewer: David L. Black
> Review Date: 18 August 2009
> IETF LC End Date: 17 August 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.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> black_david at emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>