Subject: Re: [rohc] WG last-call for the RFC 3095 Implementer's Guide - Again

From: Magnus Westerlund <[email-masked]>
Date: Mon, 02 Oct 2006 16:28:54 +0200

Hi,

Some comments on the specification:

1. I think the policy defined for section references:

   "In this document, a reference to a section or a chapter that is made
    without an explicit mention of a specific document refers to a
    section or a chapter in RFC 3095 [1], unless stated otherwise."

Creates some confusion and I think the text could benefit from instead 
using a prefix letter to indicate that the section reference is to 3095 
instead of within the document. An example of this issue is the below 
section:

4.4. Scaled RTP timestamp encoding

    This section redefines the algorithm for scaled RTP timestamp
    encoding, defined as a 5-step procedure in section 4.5.3. Two formal
    errors have been corrected, as described in subsections 4.4.1 and
    4.4.2 below, and the whole algorithm has been reworked to be more
    concise and use well-defined terminology. The resulting text can be
    found in 4.4.3 below.

Where if I interpret it correctly 4.5.3 is in 3095, while the rest of 
uses "below" to indicate that it is within the document. Using my 
proposal would instead change this to (using R for ROHC as prefix):

    This section redefines the algorithm for scaled RTP timestamp
    encoding, defined as a 5-step procedure in section R4.5.3. Two formal
    errors have been corrected, as described in subsections 4.4.1 and
    4.4.2 below, and the whole algorithm has been reworked to be more
    concise and use well-defined terminology. The resulting text can be
    found in 4.4.3 below.

2. Although RTP, GRE, AH and ESP can be considered well known 
abbreviations, I still think would should include references to them. At 
least at there first usage.

3. Usage of multiple in below text. If it is only possible two be two 
"m" bits then I would propose that the text may be somewhat rewritten as 
it may be interpreted that there are more than two "m" bits.

8.4. Multiple occurrences of the M bit

    The RTP header part of Extension 3, as defined by section 5.7.5,
    includes a one-bit field for the RTP Marker bit. This field is also
    present in all compressed base header formats except for UO-1-ID,
    meaning there may be multiple occurrences of the field within one
                         ^^^^^^^^
    single compressed header. In such cases, the two M fields must have
    the same value.

    FORMAL ADDITION TO RFC 3095:

       "When there are two occurrences of the M field in a compressed
        header (both in the compressed base header and in the RTP part of
        Extension 3), the compressor MUST set both these occurrences of
        the M field to the same value.

        At the decompressor, if the two M field values of such a packet
        are not identical, the packet MUST be discarded."

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 02 Oct 2006 17:35:29 +0200

Please note that these are comments as an individual contributor. There 
is no comments in here that I would like to apply AD level to.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Wed, 4 Oct 2006 09:40:16 +0200

Magnus,

Thanks for these comments, responses inline...

>    "In this document, a reference to a section or a chapter
>     that is made without an explicit mention of a specific
>     document refers to a section or a chapter in RFC 3095 [1],
>     unless stated otherwise."
> 
> Creates some confusion and I think the text could benefit
> from instead using a prefix letter to indicate that the
> section reference is to 3095 instead of within the document. 

Good point, I tend to agree with you. When this policy was
introduced, the document had almost no "internal" references,
or references to any other document than 3095. Therefore, we
agreed it was a good idea to define this convention.

> Using my proposal would instead change this to (using R for
> ROHC as prefix):
> 
>     This section redefines the algorithm for scaled RTP
>     timestamp encoding, defined as a 5-step procedure in
>     section R4.5.3. Two formal errors have been corrected,
>     as described in subsections 4.4.1 and 4.4.2 below, and
>     the whole algorithm has been reworked to be more
>     concise and use well-defined terminology. The resulting
>     text can be found in 4.4.3 below.

I like your proposal, conceptually, but I propose to use any
of the following prefixes:
 1)   ...in section 3095:4.5.3.
 2)   ...in section 3095-4.5.3
 3)   ...in section RFC3095:4.5.3
 4)   ...in section RFC3095-4.5.3

Opinions, anyone?

> abbreviations, I still think would should include references
> to them. At least at there first usage.

OK, maybe, but RFC 3095 already provides all references one can
ever ask for in this context, can't we just be happy with that?
One can never read THIS document as a stand-alone without 3095
anyway.

> 3. Usage of multiple in below text. If it is only possible
> two be two "m" bits then I would propose that the text may be
> somewhat rewritten as it may be interpreted that there are
> more than two "m" bits.
> 
>     The RTP header part of Extension 3, as defined by section
>     5.7.5, includes a one-bit field for the RTP Marker bit.
>     This field is also present in all compressed base header
>     formats except for UO-1-ID, meaning there may be multiple
>                                                      ^^^^^^^^
>     occurrences of the field within one single compressed
>     header. In such cases, the two M fields must have the
>     same value.

Ok, let's just replace "multiple" with "two".

/L-E

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 04 Oct 2006 10:06:31 +0200

>  4)   ...in section RFC3095-4.5.3

Either is fine with me with a preference with 2 and 4 for being easier 
to read.

> One can never read THIS document as a stand-alone without 3095

Well, unfortunately the IESG, the security directorate and gen-art will 
do that. And someone will provide nits. Thus having references on the 
first occurrences will avoid that criticism and reduce the feeling that 
the document is sloppy made.

> Ok, let's just replace "multiple" with "two".

Fine.

Cheers

Magnus Westerlund

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Thu, 5 Oct 2006 10:12:41 +0200

> Well, unfortunately the IESG, the security directorate and
> gen-art will do that. And someone will provide nits. Thus having
> references on the first occurrences will avoid that criticism
> and reduce the feeling that the document is sloppy made.

OK, I've fixed this!

/L-E

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Fri, 13 Oct 2006 15:19:41 +0200

This WG last-call has ended. The editorial comments received
have been addressed in an updated draft, which will be submitted
to the IESG with a request for publication as Proposed Standard.

Thanks to all who have contributed to the development of this
draft!

/L-E

----Original Message----
From: Lars-Erik Jonsson (LU/EAB)
[mailto:[email-masked]]
Sent: den 26 september 2006 08:03
To: [email-masked]
Subject: [rohc] WG last-call for the RFC 3095 Implementer's
Guide - Again

> ROHCers,
> 
> Since the previous WGLC attempt for this draft, the draft has
> been through a significant re-work, mainly editorial but also
> some additional technical issues with RFC 3095 have been discovered
> and resolved. 
> 
> This document is important to ensure RFC 3095 implementations
> can be made interoperable, and we believe it should now be
> taken further for RFC publication. We are therefore now issuing
> a third working group last-call on the following document:
> 
>              draft-ietf-rohc-rtp-impl-guide-20.txt
>                   (for publication as Proposed Standard)
> 
> This will be the usual two-week WG last-call as suggested in
> RFC 2418. Please direct last-call comments to the ROHC mailing
> list [email-masked] before Tue, 2006-10-10, 18:00 UTC.
> 
> Rgds,
> /L-E
>