[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rohc] 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
> black_david at emc.com Mobile: +1 (978) 394-7754
> ----------------------------------------------------