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.