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

[Elwyn Davies <[e-mail]>]

Most of this seems fine.  See few remaining points in line.  I gather I 
didn't respond sufficiently rapidly, and you have published a new version.
The points could be dealt with by RFC Editor notes if your AD considers 
t appropriate.

/Elwyn

Ghyslain Pelletier wrote:
> 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.
>   
Maybe just add:
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.
>
>   
>> 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).
>   
It may be concise but it isn't very readable.  I think it would assist 
readers without really impacting length to use the profile names in 
Sections 6.3.2, 6.6.11,  and 6.8.2.1.
> 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.
>   
Having looked back at this I think you are right.  Leave it as it is.
>  
>   
>> 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.
>   
Fine.
>  
>   
>> 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.
>   
I agree that 5.1.1 and 5.1.2 discuss the general issue, but they do it 
wrt the data packets rather the meta-issue or control issue of changing 
the list definition.  I had a feeling that maybe the problem arising 
from list definition changes added a level of complexity that had not 
been fully addressed.   On careful contemplation, I think I see that the 
optimistic approach should cope.
>   
>> 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.
>
>   
Remaining/new issues:
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).  I presume that this procedure is 
inappropraiate if the clock resolution is bigger than 255ms?


>> 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.
>   
I think a few words about the changed uses of the fields ought to be 
included together with note that this should not make any difference to 
the appropriate encoding if you believe that to be true. The section is 
incomplete as regards the current definitions of IP without a suitable 
caveat.

<<snipped: no problems with the reminaing comments>>

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