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

Hi David,

Thank you for reviewing our drafts.  Please find our responses below.

> 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.

Thanks for pointing this out--actually, another reviewer requested
that we include these keywords as well.  Therefore, we decided to
include them in the next release of the draft.

> 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.

I feel that the figures/description provided are pretty
straightforward for IKE implementers, as they are identical to the
figures/description presented in Section 3.3.5 of IKEv2 [RFC 4306] and
the IKEv2bis draft.  However, if you feel that it is necessary to
separate these figures, I'm happy to entertain further discussion
here.

> 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.

Sounds good, I can add a statement with this reference.

> 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.

Although I agree with the intent of your comment, I do not think that
this causes a security consideration for IKE.  However, I would like
to add text in the companion ROHCoIPsec framework draft
[draft-ietf-rohc-hcoipsec] that speaks to your point.  Is this alright
with you?

> 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.

Sure; I'll add a reference to Section 5.2.5 of RFC 3095.

> idnits 2.11.13 ran clean after correctly guessing that this
> draft is intended for Proposed Standard status.

Ok!  Thanks again.

Best Regards,
Emre

> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email protected]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------