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

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

Hello Elwyn,

Thanks again for your updated review.
We'll try to adress the remaining concerns.
We will fix the text regarding DSCP and ECN, see below.
Hopefully this can be to your satisfaction.

Cheers,

The authors,
Ghyslain and Kristofer

----Original Message----
From: Elwyn Davies [mailto:[e-mail]]
Sent: den 22 mars 2008 23:56
To: General Area Review Team
Cc: Mary Barnes; Kristofer Sandlund; Ghyslain Pelletier;
[e-mail]; [e-mail] Subject: Gen-art
review of draft-ietf-rohc-rfc3095bis-rohcv2-profiles-06 

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

[GHPE] ACK, this will be fixed. We will prepare RFC-Editor's notes.

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

[GHPE] ACK, this was fixed in
http://www.ietf.org/internet-drafts/draft-ietf-rohc-rfc3095bis-rohcv2-pr
ofiles-06.txt

      Clock resolution: Unsigned integer that represents the clock
      resolution of the decompressor expressed in milliseconds.
 
> 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. 

We can make the change.

We propose the following changes (as RFC-Editor's notes)

Appendix A.1:
-------------

OLD:
   Type Of Service
      The Type Of Service field is expected to be constant during the
      lifetime of a flow or to change relatively seldom.

NEW:
   Type Of Service
      For the type of flows compressed by the ROHCv2 profiles, the 
      DSCP and ECN fields are expected to change relatively seldom.

Appendix A.2:
-------------

OLD:
   Traffic Class
      The Traffic Class field is expected to be constant during the
      lifetime of a flow or to change relatively seldom.

NEW:
   Traffic Class
      For the type of flows compressed by the ROHCv2 profiles, the 
      DSCP and ECN fields are expected to change relatively seldom.

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

[GHPE] Thanks for providing a text proposal. In a previous mail, we had
also provided a text proposal, althought we expressed the preference of
leaving the current text untouched.

Regarding your new text proposal, although it is in the introduction
section and should be rather easy to agree upon, we see some issues with
it:

1) the meaning of "alternative versions" is unclear, currently the
   ROHC framework uses "variants". We are reluctants to call it yet
   something else.
2) when writing Section 4.2, some contributors to the wg list were
clearly
   opposed to using a wording such as "improved performance"; for some 
   unknown reason, they seemed worried that the comparison between
RFC3095
   and RoHCv2 would place RFC3095 at a disadvantage, so we had to
back-off
   from a similar wording as the one you propose.
3) "without sacrificing robustness or compression efficiency" is not
exactly
   true; one has to be traded-off to the other, as explained in section
4.2.
4) the use of "communicating parties" is undefined from a ROHC channel
   perspective and may lead to confusion; we normally use "compression 
   endpoints"
5) to "advertise" profile is undefined from the ROHC framework
perspective.
   The ROHC-FW only places requirements to the link layer on the
resulting
   configuration of the endpoints. This is outside scope of ROHC.

We know the above might sound extremely picky (we apologize for looking
cheap in our reply), and we honestly would like to accomodate your wish
as best we could, as shown in a previous proposed text to address your
comment. However, we still feel that this text is better left untouched,
mainly because it goes outside the scope of a profile definition and
because we feel the ROHC framework provides all the necessary guidance.

However, would you really insist, we can make another try to find a
suitable formulation and come with yet another proposal, altought we do
not have one coming to mind immediately. 

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

[GHPE] The authors have considered this comment once more, but still
disagree. The authors strongly believe that agreeing to this comment
would introduce confusion to the document, and depart from agreed
practice in the working group. Also, the authors would like to put this
comment into perspective as appearing to be much related to a matter of
taste.
_______________________________________________
Gen-art mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/gen-art