Subject: [AVT] draft-clark-avt-rtcphr-02

From: Keith Lantz <[email-masked]>
Date: Tue, 11 Jul 2006 13:10:28 -0700

[This time without my original critique from last January, since that 
exceeded the 20 KB limit.]

Alan, Amy, Rajesh, et al.:

This draft is much improved since I reviewed the 00 draft back in 
January. Good work! And thanks for accommodating many of my previous 
comments. Please note, however, that several of those previous 
comments now apply to draft-clark-avt-rtcpxr-video-02, since some of 
the original prose from rtcphr-00 was copied to rtcpxr-video *before* 
addressing my earlier comments. :-( I will follow up with a separate 
message detailing my concerns with rtcpxr-video-02.

Following are some comments on rtcphr-02, in page order:

- p. 3, Section 2.1: Remove the hyphen from "A translator may:-".

         The phrase "with the translation which it performs RFC3550" is broken.

- p. 5, Section 2.3: The paragraph on concealed seconds suggests that 
*time* is "lost", which doesn't sound quite right to me. I suggest 
that paragraph be rewritten as follows: "The term Concealed Seconds 
defines a count of seconds during which packets were either lost or 
discarded. The term Severely Concealed Seconds defines a count of 
seconds in which the cumulative duration of all lost or discarded 
packets exceeds a specified threshold."

- p. 5, Section 2.4: I can't parse "in the range 0.0, 0.0039 to 
255.996". (More generally, I'm not convinced it's 
appropriate/necessary to show the decimal equivalent of n-bit binary 
fractions to three decimal places.)

- p. 6, diagram for Concealed Seconds metrics sub-block: "threshold" 
should be "SCS Threshold" (to match with subsequent prose).

- p. 13, Sections 3.6.1 & 3.6.2: The phrase "that have occurred on 
this call" suggests that the count in question is *cumulative*. 
Presuming this need not be the case -- i.e., that like all other 
metrics this could be an interval metric -- I suggest simply deleting 
the phrase (in both sections).

- p. 14, Section 3.7.2: For clarity, I think it would be helpful to 
insert "reporting" before "endpoint" -- yielding "The End System 
Delay is the internal round trip delay within the reporting endpoint..."

- p. 14, Section 3.7.3.: "If the external network is VoIP based then" 
--> "If the external network is IP-based, then".

- p. 16, Section 3.8.1 & 3.8.2: Per my original critique, these 
sections both refer to a "Voice/Data Quality Metric Algorithm block" 
that is not defined anywhere else in the document. I presume this 
should be the "RTCP HR Configuration Block" defined in Section 4 ... ???

- p. 17, Section 3.8.5: I still don't understand why "media type" is 
defined in the Call Quality Metrics sub-block.

- p. 20, Section 3.9: Per previous occurrences of like prose, rewrite 
"MAY be present. Their presence MUST be indicated" as "MAY be present 
and if present MUST be indicated",

- p. 22, Section 4.2.2: "An Map field" --> "A Map field".

- p. 22, Section 4.3: "for an endpoint may convey" --> "for an 
endpoint to convey"

- p. 23f, Section 4.4: I'm still pretty dissatisfied with this 
section. It simply doesn't do a good job, IMHO, of explaining the 
purpose/use of the block in question -- in large part, perhaps, 
because the example is so meaningless. Why not pick an actual metric? 
(One, perhaps, that isn't promoted by one of the authors ;-) -- 
Sage's SMOS metric, for example.)

- p. 26: Insert em-dashes in the first sentence of the paragraph 
following the bullet list, yielding "In the next section we 
illustrate how policies may be applied to control these behaviors and 
hence achieve three end-to-end reporting modes -- "end system 
peering," "local reporting" and "global reporting" -- for a 
hypothetical bidirectional unicast connection using translators."

         Also, the horizontal lines in the diagram in Section 5.1 are 
misaligned so as not to create the desired boxes ... at least in the 
hardcopy I reviewed.

- p. 28, end of Section 5.1.1: The phrase "may include modification 
of the RTCP" seems inappropriate -- as if you're actually modifying 
the protocol rather than the payload. Perhaps this usage is common, 
and I missed it previously, but here it finally caught my eye. 
Suggest simply inserting "payload" after "RTCP".

         Similarly, in subsequent prose the phrase "forwarded further 
in RTCP" is used several times. In this case I suggest simply 
deleting the "in RTCP".

- p. 31, Section 5.1.4: "forward end system reports (End System 
Peering)" --> "forward end system reports". The parenthetical remark 
is confusing.

- p. 32: Echoing the previous remark (and then some), rewrite the 
global mode paragraph as

         "Global mode - Translators forward both end system report and ..."

- p. 33, Section 10: Remove the two authors (Kevin and Geoff) from the list.

- Finally, a *complete* nit: There are many occurrences of "<text> 
however <more text>", where either (a) the "however" is not set off 
with commas and/or (b) where "but" would seem more appropriate. 
Similarly for "hence", "for example" and "finally". Edit as desired. ;-)

Regards, Keith

----------------
Keith Lantz, Ph.D.                        Voice: +1 (408) 902-3302
Cisco Distinguished Engineer              FAX:   +1 (408) 525-4971
Voice & Video Systems Architecture        Email: klantz (at) cisco.com
Cisco Systems, Inc.

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