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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf