[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[rohc] Gen-ART review of draft-ietf-rohc-ikev2-extensions-hcoipsec-09
- 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>
- Subject: [rohc] Gen-ART review of draft-ietf-rohc-ikev2-extensions-hcoipsec-09
- From: <Black_David at emc.com>
- Date: Fri, 18 Sep 2009 19:15:09 -0400
- Cc: magnus.westerlund at ericsson.com, rohc at ietf.org, Black_David at emc.com
- Delivered-to: rohc at core3.amsl.com
- List-archive: <http://www.ietf.org/mail-archive/web/rohc>
- List-help: <mailto:rohc-request@ietf.org?subject=help>
- List-id: Robust Header Compression <rohc.ietf.org>
- List-post: <mailto:rohc@ietf.org>
- List-subscribe: <https://www.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=unsubscribe>
- Thread-index: Aco4td2Nqs2YHsG8TVeb/dVXtjweew==
- Thread-topic: 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
----------------------------------------------------