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

["Ghyslain Pelletier" <[e-mail]>]

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:[e-mail]]
Sent: den 7 mars 2008 19:55
 
> Document: draft-ietf-rohc-rfc3095bis-rohcv2-profiles-05

> 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.

[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.


> 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.

[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.8, next to last para:  I believe the 'optional' should be an
> 'OPTIONAL'.
> s6.6.9, last para: -- ditto --

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

 
> 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. 

[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.

> 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).

[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.

> 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?

[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.

> Editorial:
> 
> General: use of lsb or LSB.  The document is extremely inconsistent.
> General: Capitalization of (Most) Words in Section Headings needs
> Attention. 

[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
> outcome of every/

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