Subject: RE: Further comments & update proposals to rtcphr-02; Re: [AVT] draft-clark-avt-rtcphr-02

From: "Alan Clark" <[email-masked]>
Date: Wed, 8 Nov 2006 09:20:12 -0500

Albrecht

Great - thanks for the comments.  I've been a little swamped during the last
few months but will get a new draft out shortly

Regards

Alan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, November 08, 2006 6:37 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: Further comments & update proposals to rtcphr-02; Re: [AVT]
draft-clark-avt-rtcphr-02

Alan et al.,

please find attached some change proposals.
I've used word and revision bars in order to indicate new proposed material.

List of major changes:
* additional NOTE in § 5
* new clause (§ 6) on SDP items
* initial text proposals for § 6.2, 6.3, 6.4, 6.5 (get update numbers § 7.2
etc)

Regards, Albrecht
(See attached file:
draft-clark-avt-rtcphr-02_comments_Albrecht_20061108.zip)

                      Keith Lantz

                      <[email-masked]         To:      [email-masked]

                      m>                       cc:

                                               Subject: [AVT]
draft-clark-avt-rtcphr-02                                               
                      11.07.2006 22:10

[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

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

---

From: [email-masked]
Date: Wed, 8 Nov 2006 12:36:38 +0100

Alan et al.,

please find attached some change proposals.
I've used word and revision bars in order to indicate new proposed
material.

List of major changes:
* additional NOTE in § 5

Regards, Albrecht
(See attached file:

                      Keith Lantz                                                                                                     
                      <[email-masked]         To:      [email-masked]                                                                  
                      m>                       cc:                                                                                    
                                               Subject: [AVT] draft-clark-avt-rtcphr-02                                               
                      11.07.2006 22:10                                                                                                

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.

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

- 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

- 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

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