Document: draft-ietf-rohc-rfc3095bis-rohcv2-profiles-06
Reviewer: Elwyn Davies
Review Date: 21 March 2008
IESG Telechat date: 27 March 2008

Summary:
Most of the issues and editorial nits from my last call review have been resolved.  There are a few remaining minor issues that probably deserve RFC Editor notes, but it is otherwise ready for PS.

Comments:
s1: Suggest adding an extra explanatory sentence to s1 to motivate the addition of alternative profiles:
   The alternative versions offer improved performance (especially tolerance to
   packet reordering, see Section 4.2) without sacrificing robustness or
   compression efficiency.  Communicating parties may choose to use the variants
   if all parties implement and advertise these profiles.

ss6.3.2, 6.6.11 and 6.8.2.1: I think it would assist readers without really impacting length to use the profile names either additionally or in place of the hexadecimal profile numbers in Sections 6.3.2, 6.6.11, and 6.8.2.1.

s6.9.2: s/lenght/length/; opt_len needs to specify how the value is encoded (4 bit unsigned integer presumably).

s6.9.2.4: clock_resolution needs to specify how the value is encoded (8 bit unsigned integer presumably).

Appendices A.1 and A.2: The changed interpretations of the Type of Service/Traffic Class fields as DSCP and ECN should be mentioned.  The authors take the view that this does not affect the 'rarely changing' nature of the fields in the usual cases when ROHC is used - however, there may be circumstances under which this is not true (e.g., when the AF DiffServ code point is in use or on TCP connections using ECN). This caveat ought to be mentioned.