Subject: Gen-art review of draft-ietf-rohc-rfc3095bis-rohcv2-profiles-05

From: Elwyn Davies <[email-masked]>
Date: Fri, 07 Mar 2008 18:54:55 +0000

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Ghyslain Pelletier" <[email-masked]>
Date: Sun, 16 Mar 2008 13:51:42 +0100

Thanks you for your careful review and for your comments.

We have looked into your comments, and we try to provide answers inline
within your original email included below.

We will update the draft according to our answers below, please let us
know in case the proposed resolutions to your comments is not to your
satisfaction as well as, if possible, a quick resolution.

Best regards,

The authors,
Ghyslain Pelletier
Kristofer Sandlund

----Original Message----
From: Elwyn Davies [mailto:[email-masked]]
Sent: den 7 mars 2008 19:55

> knowledge of ROHC that the reason that the document does not 'update
> RFC 3095, etc' is because the protocol negotiates the available
> profiles 

[AUTHORS] We propose to not make any change to the current text.

RFC4995 in section 5.1.2 defines the channel parameter "PROFILES" where
the workings of the profile identification mechanism are clearly
expressed; section 8 also defines some guidance on how to assign profile
identifiers in ROHC specifications. In short, ROHC profiles use
identifiers of the format "0xYYXX", while common parts of (framework)
packet formats use only the "XX" part. Therefore, the setup of a ROHC
channel cannot result in a set of profiles that include two profiles
having the same value for "XX". When the channel is being setup, if it
is the case, the profile that has the highest value for "YY" then has
precedence and shall be used in the final configuration of the channel.

draft-rohcv2 states that the ROHCv2 profiles update corresponding
profiles in RFC3095; it also clearly assigns new profile identifiers to
each of the profile defined in the document directly under this text,
where each identifier defined has "YY" = "01".

More specifically, we motivate not changing the current text mainly
because our view is that knowledge of RFC4995 is a necessary
prerequisite to draft-rohcv2 (and to any other ROHC profile
specification). We also believe that there is no reason to mention
whether a specification updates another one, unless it actually does so.

As a side note for clarity, it is incorrect to state that the ROHC
"protocol negotiate the available profiles"; the framework only places a
requirement that a number of parameters, including the set of available
ROHC profiles, be consistent between two endpoints of a ROHC channel.
Whether this is negotiated, statically provisioned or achieved in
another way is actually outside the scope of the protocol.

However, this being said, we could still propose a modified text --
although we do not believe this would improve the current draft and we
have struggled somewhat with its formulation:

OLD:

   This document defines an updated version for each of the above
   mentioned profiles, and its definition is based on the specification
   of the ROHC framework as found in [RFC4995].

NEW:

   This document defines a set of profiles called ROHCv2 profiles. Each
   ROHCv2 profile is defined with its own profile identifier.
   Identifiers are assigned to conceptually represent the ROHCv2 profile
   as a variant of the profile that can compress similar header
   combination(s) from the list above. The definition of the ROHCv2
   profiles complies with the specification of the ROHC framework as
   found in [RFC4995].

Note: Please let us know which way forward is according to your
preference. By default, we will not make the modification. Would you not
be satisfied with any of the proposed alternatives, please provide a
text proposal that would resolve your comment.

> names should be capitalized or not.  Please choose one version.

[AUTHORS] We propose to not make any change to the current text.

We believe that the draft is consistent in its usage of profile names
and their corresponding hexadecimal values. Basically, we deliberately
avoid to use profile names and prefer to use the hexadecimal values for
clarity, precision and conciseness (e.g. the draft uses profile 0x0101
instead of ROHCv2 RTP).

Wrt capitalization, names in small letters are a consequence from the
formal notation in the packet format section. The ROHC-FN (RFC4997) is
case-sensitive and capital letters are normally used only for keywords
within the formal notation itself. In the specification text (plain
english part), some of the encoding method names are still referred
there, and these cannot be capitalized otherwise it would create
confusion.

In case we misunderstood your comment, please provide more clear
indications on this issue. We have reviewed the document and could not
find inconsistencies from our perspective.
 
> s6.6.9, last para: -- ditto --

[AUTHORS] We agree to this and will make the change.

> and post-update specifications for a short period if I understand

[AUTHORS] We propose to not make any change to the current text.

We motivate this from the fact that this is handled in draft-rohcv2 by
section 5.1.2, which in turn refers to section 5.1.1 (Optimistic
Approach) for seldom  changing fields. In other words, sending updates
to lists wrt reordering is a typical topic that is handled by the
recommendations about how to implement the optmistic approach in section
5.1.1, being no different than any other update to non-sequentially
(e.g. lsb-encoded) changing  fields.

> to be specified (unsigned ints I guess).

[AUTHORS] We agree that the diagrams on the feedback options are not
consistent.

We also agree that the encoding of the clock resolution should be
specified, but we do not see any other field for which this is needed.

We will fix this.

> Should this be taken into account?

[AUTHORS] We propose to not make any change to the current text.

The motivations are that how fields are classified only matters wrt to
helping choosing a compression strategy for the field. The
classification  should only match the most expected case, otherwise a
slightly less efficient compression could occur. Wrt to this, the only
thing that matters is that the compression protocol is always
transparent, which ROHC must be as a requirement from the framework and
from general IETF practices.

As our understanding is that ECN codepoints are expected to be used only
for TCP traffic -- we are not aware of any specifications/deployments
for ECN and rate control for RTP applications as of this writing -- and
because ROHCv2 does not explicitely compress TCP traffic (RFC4996
defines ROHC compression for TCP), we see no reason to optimize the
compression of the ECN codepoints or to modify this part of the text to
further clarify expected behavior.

> General: Capitalization of (Most) Words in Section Headings needs

[AUTHORS] Wrt to capitalization, as explained earlier we believe that
the document is consistent wrt to the plain english text part of the
specifications, wrt the formal notation part and wrt the "mixed" parts.

If you still disagree, please provide specific examples in light of the
answers in this mail.

We agree wrt section headers, we will fix this.
 
> s5, para 1:  s/concepts relates/concepts relate/

[AUTHORS] ACK

> s5.1.3, last para: s/to determine/for determining/

[AUTHORS] ACK

> s5.2, para 2: s/to always verify the outcome of/for verifying the

[AUTHORS] ACK

> s6.2, para 3: s/increasing/to increase/

[AUTHORS] ACK

> s6.6.8, para 2: s/notation ./notation./

[AUTHORS] ACK

> s6.8.2.1: Extra blank line needed after first bullet for consistency.

[AUTHORS] ACK blank line needed after first bullet for consistency.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf