Subject: [AVT] draft-wenger-avt-avpf-ccm-00

From: Keith Lantz <[email-masked]>
Date: Fri, 29 Jul 2005 14:06:07 -0700

I previously submitted an extensive review of this draft to the folks 
listed in the To: line below. Stephan asked me last week to redistribute an 
abridged version to avt, such that the larger community could comment in 
advance of IETF, but ... I failed to notice the request until now. :-( 
Nevertheless, in the event it's of any help, here's a quickly edited 
version of my previous comments. (The original recipients can of course 
reply to my previous message as they wish.)

Regards, Keith

-------------------

Date: Thu, 21 Jul 2005 18:40:56 -0700
To: <[email-masked]>
From: Keith Lantz <[email-masked]>
Subject: Re: Codec commands draft submitted
Cc: <[email-masked]>,<[email-masked]>,<[email-masked]>,
  <[email-masked]>,<[email-masked]>,<[email-masked]>,
  <[email-masked]>,<[email-masked]>,
  <[email-masked]>,<[email-masked]>
X-OriginalArrivalTime: 22 Jul 2005 01:41:01.0526 (UTC) 
FILETIME=[6A877760:01C58E5E]

Sorry for the delay in responding.

I'm happy to say that I am generally supportive of the draft. But I do have 
the following comments, in page order (against the -00 version as posted to 
AVT). These range from substantive (?) to editorial nits:

- In general, the "Introduction" seems to be much beefier than the average 
I-D or RFC -- constituting much more of an "executive summary" than is the 
norm. I don't have a particular problem with that ... other than it being 
unexpected.

<snip>

- p. 6 and elsewhere throughout the document: Is "decoder refresh point" a 
generally accepted label? I find it rather cumbersome ... but don't have 
anything better to suggest.

<snip>

- p. 8, first line: I'm not quite sure what "used congestion control 
algorithms" means. Perhaps you need to be specific, e.g. "The congestion 
control algorithms used in <x> and <y> (AMID and TFRC, respectively) probe ..."

         The last sentence of that list item is broken. I think you're 
trying to say the following: "To minimize disruption of service, especially 
in reduced-bandwidth environments, quick convergence is desired. This 
suggests the use of media path signalling." (???)

<snip>

- p. 10, first paragraph: You probably meant "implicitly" when writing 
"imlicitely", but then ... what does "not implicitly synchronized with the 
media stream" mean?

<snip>

- Section 3.2.4, top of p. 11: "bit-rate for a media to, or below," --> 
"bit-rate for a media stream to". I don't think you need emphasis the 
"below" part.

         In the rest of the document you then mention "stream thinning" 
quite a bit. I'm not sure this concept is well enough known as to *NOT* 
include a definition and/or some examples -- especially when referring to 
media-aware and media-unaware stream thinning. I at least am not sure what, 
specifically, you're talking about. :-( For example, on the next page, 
there appears to be an opportunity to reference layered coding as one 
potential mechanism to support stream thinning, but ... I'm not sure.

<snip>

- p. 11, last paragraph, before the list and/or in list and elsewhere: The 
discussion surrounding the need/decision to select the slowest reported 
rate is clearly only relevant if you're not doing "transrating". But rather 
than saying "transrating", you say you're not doing "transcoding". Well, 
right or wrong, some people thing those two things are different ... so you 
might want to be more specific. That is, you might want to say transrating, 
rather than transcoding?

<snip>

- pp. 15ff: Sections 4.3, 4.4, 4.5 and 4.6 seem overly redundant with 
Sections 3.2.2, 3.2.1, 3.2.3 and 3.2.4, respectively. Maybe this is 
sufficiently common practice as to leave it be, and I certainly don't have 
the cycles to suggest that significant a rewrite, but ... think about it.

<snip>

         3rd paragraph: I can't parse the last sentence. I understand why 
the freeze request should contain *a* timestamp ... but I'm not sure 
exactly what it's the timestamp of -- and can't tell from this sentence.

- Section 4.4: First, refer to comment about redundancy above. Beyond that:

         "sends an decoder" --> "send a decoder"
         "the SSRC of the" --> "the SSRCs of both the"

- Section 4.5: Refer to comment about redundancy above.

- Section 4.6: Refer to comment about redundancy above. (Am I being 
redundant enough? ;-))

<snip>

- p. 27: What are "group-external" threats?!

<snip>

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt