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-rfc3095bis-rohcv2-profiles-05
Reviewer: Elwyn Davies
Review Date: 7 March 2008
IETF LC End Date: 20 March 2008
IESG Telechat date: (if known)
Summary:
The document is almost ready for the IESG. There are a couple of minor
issues that ought to be resolved as detailed below (especially
concerning DSCP in IPv4 and IPv6 headers and the notes about out of
sequence list specification change packets) and a few editorial nits.
Caveat: I have not rigorously checked the ROHC-FN specifications in
section 6.8.2.4 although they seem superficially sensible.
Comments:
s1: It would be worth a sentence to remind readers without deep
knowledge of ROHC that the reason that the document does not 'update RFC
3095, etc' is because the protocol negotiates the available profiles
between compression endpoints - so the extra profiles defined here just
add to the available set.
s6.3.x/s6.8.2.1: It would be easier for the reader (and more robust) to
use the profile names rather than the expected hexadecimal values when
referring to profiles here and anywhere else apart from the
definitions. Also there is some inconsistency as to whether the profile
names should be capitalized or not. Please choose one version.
s6.6.8, next to last para: I believe the 'optional' should be an
'OPTIONAL'.
s6.6.9, last para: -- ditto --
s6.6.13: Given that the protocol is supposed to tolerate some
reordering, I think some words about how to handle sequentially early
packets containing updates to list specifications wuld be useful.
Implementations might have to ensure that they can cope with the pre-
and post-update specifications for a short period if I understand correctly.
s6.9.1: The diagrams of feedback formats are inconsistent (some have bit
numbers, some don't). Also values should be specified in the text as
well as as labels in the diagrams, and the encosing of the fields needs
to be specified (unsigned ints I guess).
Appendices A.1 and A.2: The Type of Service/Traffic Class fields are
also known as DSCP (DiffServ Code Points) as of six or seven years ago.
With the advent of Early Congetion Notification which uses bits in these
octets, the values in these fields may not be as 'rarely changing' as
would have been expected previously. It is also possible that some of
the DiffServ PHBs might lead to more variable values in these fields
although this is probably less likely in regions where ROHC is in use.
Should this be taken into account?
Editorial:
General: use of lsb or LSB. The document is extremely inconsistent.
General: Capitalization of (Most) Words in Section Headings needs Attention.
s5, para 1: s/concepts relates/concepts relate/
s5.1.3, last para: s/to determine/for determining/
s5.2, para 2: s/to always verify the outcome of/for verifying the
outcome of every/
s6.2, para 3: s/increasing/to increase/
s6.6.8, para 2: s/notation ./notation./
s6.8.2.1: Extra blank line needed after first bullet for consistency.
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf