Re: [AVT] Working group last call: draft-ietf-avt-avpf-ccm-07

As promised, here are my comments on the latest draft:

- First and foremost, this is *much* improved since the last version 
I reviewed (version 03). The result is that these comments are almost 
exclusively minor editorial nits. My compliments to the authors (and 
anyone else who contributed to that improvement)!

- Arguably the only non-editorial comment is this: In Section 4.3.3.2 
it says that if the recipient of a TSTR receives several TSTRs with 
different sequence numbers, it "SHALL" only respond to the request 
with the highest sequence number. Unfortunately, the sequence numbers 
are modulo 256, which means there will be occasions where the 
recipient will respond to an *older* request -- when a more recent 
request wraps back to 0. Is this not a problem?

Now for the editorial comments:

- The "header" on the 2nd and subsequent pages contains a fairly 
non-descriptive title: "AVPF RTCP-RR Extensions". Something like 
"Codec Control Messages in AVPF" would seem much more appropriate.

- Section 2.1 and elsewhere: "AMID" --> "AIMD".

- Section 2.2, defn. of stream thinning: "when subject to" --> "when 
subjected to"

- Section 2.3, defn. of Topo-Multicast: consider deleting "as in RFC 3550"

         defn. of Topo-Translator: "translator based as" --> 
"translator-based communication" & consider deleting "as in RFC 3550"

         defn. of Topo-Mixer: "mixer based as" --> "mixer-based 
communication" & consider deleting "as in RFC 3550"

         defn. of Topo-Video-switch-MCU: eliminate the closing comma

         defn. of Topo-RTCP-terminating MCU: replace with 
"RTCP-terminating, mixer-based communication"

- Section 3.1, item 7: "AMID" --> AIMD"

         "does generally result" --> "generally results"

- Section 3.5.1, 2nd paragraph: Given the widespread use of "FVU" for 
this functionality, add "fast video update" to the list of "also known as".

         3rd paragraph: "MPEG-4" --> "MPEG-4 Part 2"

         5th paragraph: Restructure 2nd sentence as "A receiver that 
receives a request closely after sending a decoder refresh point -- 
within 2 times the longest Round Trip Time (RTT) known, plus and 
AVPF-induced RTCP packet sending delays -- should await ..."

- Section 3.5.2, 3rd paragraph: "finally the new trade-off is 
selected" --> "the new trade-off is finally selected"

         4th paragraph: "translator, mixer or endpoint's" --> 
"translator's, mixer's or endpoint's"

- Section 3.5.2.3, 2nd paragraph: Remove comma after "(and bit rate)".

- Section 3.5.2.4: Consider replacing "request-sender" with "requester".

- Section 3.5.3: "oversimplifying" --> "oversimplified"

         p. 19: Insert comma after "messages" in "In response to the 
opaqueness of the H.271 messages"

- Section 3.5.3.1: Remove the closing period from "clause 3.5.1.1.". 
(This is the case for several other cross-references as well. Then 
too, several cross-references have line breaks inserted -- e.g. the 
reference to section 3.5.4.2 at the top of p. 40.)

- Section 3.5.4, 3rd paragraph: Restructure last sentence as "... 
because calculations are carried out in terms of variables that have 
the same value at the sender as at the receiver -- for example, 
packet rate and net media rate."

- Section 3.5.4.2, 2nd paragraph: Insert commas after "First" and 
"Fortunately".

         p. 26, the "basic idea" paragraph: This discussion should 
probably make explicit that the X and Y axes comprise two sides of 
the "polygon" under discussion. Perhaps "The lower envelope of the 
set of lines corresponding to the complete set of TMMR tuples, 
together with the X and Y axes, defines a polygon."

- Section 3.5.4.3, 2nd paragraph: Restructure as "In practice, 
unfortunately, media-aware streaming thinning is a very ..."

- Section 4.2, opening paragraph: Note that the syntax used here is 
not identical to that used in Section 4.3. Here you write "RTCP 
packet type value RTPFB", whereas in Section 4.3 you write "RTCP 
packet type value PT=PSFB" -- i.e. you insert the "PT=". Either way 
works, but you should be consistent.

- Section 4.2.1.1, defn. of Measured Overhead: "according to 
description" --> "according to the description"

- Section 4.2.1.1 (& also 4.2.2.1): Similar to the next to previous 
comment, the structure used here is not identical to that used in 
Sections 4.3.1, 4.3.2 and 4.3.3. In the latter sections you include 
sentences that specify the PT and FMT values -- e.g. "The FIR message 
is identified by RTCP packet type value PT=PSFB and FMT=4." Here (and 
in 4.2.2.1) you do *not* include such sentences. Again, either way 
works, but you should be consistent.

- Section 4.2.1.2: As per a similar comment above, "See section 5." 
--> "See section 5".

- Section 4.3: As noted above, the syntax used here is not identical 
to that used in Section 4.2. Here you write "RTCP packet type 
value  PT=PSFB", whereas in Section 4.3 you write "RTCP packet type 
value RTPFB" -- i.e. *without* the "PT=". Either way works, but you 
should be consistent.

- Section 4.3.1: Similarly, the structure use here (and in Sections 
4.3.2 and 4.3.3) is not the same as that used in Sections 4.2.1.1 and 
4.2.2.1. See the comment on Section 4.2.1.1 above for further clarification.

- Section 4.3.1.2: There are a *lot* of "Notes" in this section that 
really impair readability. Strongly suggest that this section be 
rewritten/restructured to incorporate most of that content in the 
body of the section itself.

         Also, in the 2nd note: "However a session" --> "However, a 
session". (This happens elsewhere as well. I just didn't flag them all.)

         And "reasons, such an application SHOULD also be capable to 
receive and react" --> "reasons such an application SHOULD also be 
capable of receiving and reacting".

- Section 4.3.1.5: "Hence waiting" --> "Hence, waiting". (Ditto for 
similar sentences elsewhere.)

- Section 4.3.2: See comment on Section 4.2.1.1 above.

         Defn. of Index (& elsewhere): "trade off" --> "trade-off"
                 "value of 0 index" --> "value of 0 indicates"

- Section 4.3.2.2: "to which the TSTR applies to" --> "to which the 
TSTR applies"

- Section 4.3.2.3: "requires a quick feedback" --> "requires quick feedback"

- Section 4.3.2.4: Contains another of several cross-references where 
line breaks have been erroneously inserted.

- Section 4.3.2.5: "refer to the resolution, measured" --> "refer to 
resolution as measured"

- Section 4.3.3: See comment on Section 4.2.1.1 above.

- Section 4.3.3.2: The second sentence is really hard to follow. The 
following might be at least marginally better: "One TSTN entry in a 
TSTN feedback message SHALL be sent for each TSTR entry targeted at 
the sender (of the TSTN message) -- i.e., each TSTR entry that 
contains the sender in its SSRC field."

- Section 4.3.4: See comment on Section 4.2.1.1 above.

- Section 4.2.4.5: Contains another of cross-reference where a line 
break has been erroneously inserted.

- Section 5 (& elsewhere): "Thus modified" --> "Thus, modified"

         "reduced transmission bit rate thus" --> "reduced 
transmission bit rate, thus"

- Section 6, enumerated list: The structure of these bullets is 
inconsistent -- with the first three being structured as if they were 
all part of the same sentence, separated by semi-colons, and the 
fourth being its own sentence. They should all be structured as 
self-standing sentences or the fourth should incorporated into the 
same "sentence" as the previous three.

- Section 7: Drop the "protocol" from "codec control protocol".

         first paragraph on p. 59: Insert comma after "For example".

         Rewrite the two sentences preceding the bullet list as 
follows: 'The "ccm" feedback value SHOULD be used with parameters 
that indicate the specific codec control commands supported. In this 
draft we define four such parameters, namely:"

         Then, in every bullet: "indicates the support" --> "indicates support"

- Section 7.2: "are similar those" --> "are similar to those"

         "parameters which it does" --> "parameters that it does"

         "everyone shall use" --> "everyone SHALL use"

- Section 7.3, last sentence: "So in the above example only" --> "So, 
in the above example, only".

That's it!

Regards, Keith

At 02:51 AM 6/20/2007, Even, Roni wrote:

>This is to announce a working group last call on the Codec Control 
>Messages in the RTP Audio-Visual Profile with Feedback (AVPF).
>
>This is a second last call after the authors addressed comments in the list
>
>Please send any final comments to the mailing list by July 6th 2007.
>
>If no issues are raised, we will request the IESG consider this for 
>publication as a Proposed Standard RFC.
>
>Thanks
>Roni Even - AVT co-chair
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Audio/Video Transport Working Group 
>of the IETF.
>
>         Title           : Codec Control Messages in the RTP 
> Audio-Visual Profile with Feedback (AVPF)
>         Author(s)       : S. Wenger, et al.
>         Filename        : draft-ietf-avt-avpf-ccm-07.txt
>         Pages           : 71
>         Date            : 2007-6-1
>
>This document specifies a few extensions to the messages defined
>    in the Audio-Visual Profile with Feedback (AVPF).  They are
>    helpful primarily in conversational multimedia scenarios where
>    centralized multipoint functionalities are in use.  However some
>    are also usable in smaller multicast environments and point-to-
>    point calls.  The extensions discussed are messages related to the
>    ITU-T H.271 Video Back Channel, Full Intra Request, Temporary
>    Maximum Media Stream Bit Rate and Temporal Spatial Trade-off.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-avt-avpf-ccm-07.txt
>
>
>_______________________________________________
>Audio/Video Transport Working Group
>avt@ietf.org
>https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt