[Gen-art] Gen-art review of draft-ietf-rohc-rfc3095bis-rohcv2-profiles-05

[Elwyn Davies <[e-mail]>]

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.





_______________________________________________
Gen-art mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/gen-art