Subject: [xrblock] recommendations for draft-ietf-xrblock-rtcp-xr-meas-identity

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 19 Mar 2012 11:56:41 -0700

I am the document shepherd for draft-ietf-xrblock-rtcp-xr-meas-identity.
I believe the content of the draft is generally in good shape. However,
I did find myself reading parts of the draft multiple times in order to
grasp some of the content completely. I think the draft would benefit
from some rearranging of pieces of the Introduction section, and that
doing so will improve flow and make it easier for the reader to digest.

My main suggestions as follows:

1) Abstract
Current:
   This document defines a RTCP SDES item and a RTCP XR Block carrying
   parameters which identify a measurement, to which one or more other
   RTCP XR Report Blocks may refer.
Proposed:
   This document defines an RTCP SDES item and an RTCP XR Block carrying
   parameters that identify and describe a measurement period, to which
   one or more other RTCP XR Report Blocks may refer.

2) Introduction
General Proposal: Consistently state the SDES item first, then the XR
block. For example:
Current:
   This draft defines one new RTCP SDES item and one new XR Report Block
   to carry parameters which identify a measurement for use in a range
   of RTP applications.  The XR Report Block and the SDES item do not
   contain any measurement results (metrics).
Proposed:
   This draft defines one new RTCP SDES item and one new XR Report Block
   carrying parameters that identify and describe a measurement period,
to which
   one or more other RTCP XR Report Blocks may refer. This SDES item and
XR Report
   Block do not contain any measurement results (metrics).

Following this, I would hold off on the part that reads, "However, the
XR Report", keeping this sentence, the bulleted points that follow, and
the rest of the XR block specific information for later. Instead, I
would move directly to the text pertaining to the SDES time, removing
the "And as the start of the sentence.
Current:
   And the SDES item provides a measurement identity reported in one or
   more other block types, i.e.,a field for incorporation of an
   application-specific auxiliary identifier,
Proposed:
   The SDES item provides a field for an application specific auxiliary
identifier.
   This identifier may be used to correlate data in XR Blocks within an
RTP session
   with data from a non-RTP session.

After this I would include you existing paragraph that reads,

   A RTCP Measurement Identity SDES packet MAY be associated with a set
   of RTCP XR metrics blocks which share the same application specific
   measurement identifier.

Only at this point would I start including all the XR block specific
information, ordered as follows:

   The XR Report Block does not contain any measurement results
(metrics).  Rather, 
   it provide information relevant to a measurement reported in one
   or more other block types, including:

   o  the sequence number of the first packet of the RTP session,

   o  the extended sequence numbers of the first packet of the current
      measurement interval, and the last packet included in the
      measurement,

   o  the duration of the most recent measurement interval and

   o  the duration of the interval applicable to cumulative measurements
      (which may be the duration of the RTP session to date).

   The method for calculation of the extended RTP sequence number is
   provide in [RFC3550].

and

   The RTCP XR Report Block containing the measurement information is
intended to
   provide a single copy of the information necessary to relate
   measurement data in the RTCP XR blocks to the stream, and measurement
   period, to which they refer.  Commonly, multiple other small metric
   blocks contain measurement data for the same stream and period, and
   it would be a large overhead if all of these metric blocks carried
   duplicated data for measurement identification.

and

   The RTCP XR Report Block MAY be associated with a set of RTCP XR
   metrics blocks which share the same information relevant to a
   reported measurement.  There MAY be several such sets in an RTCP
   packet, in which each set share the same information relevant to a
   reported measurement.  There MAY also be RTCP XR blocks in the packet
   which are not associated with a Measurement Information block, for
   example blocks which were defined before the Measurement Identity and
   information mechanism was introduced by this document.

Other minor comments are as follows:

Section 1.2 Performance Metric Framework
Current:
   Metrics or the SDES item described in
   this draft either reference external definitions or define metrics
   generally in accordance with [RFC6390] and [MONARCH].
Proposed:
   The SDES item and XR Block described in this draft are in accordance
with
   [RFC6390] and [MONARCH].

Section 1.3 Applicability
s/to the measurement/to the measurements

Section 3 Measurement Identity SDES Item
s/format of Measurement/format of the Measurement

Section 3.1 APSI
Move the sentence, "This item MUST be ignored ...", to immediately
before the sentence, "The identifier is variable length."
The reason is that in its current location, it appears to be applicable
to the case where the length is zero, where really it is applicable
regardless of the length.

Section 4.2, Reserved 8 bits
The wording you have for the 16 bit reserved field is more complete, in
my opinion. I suggest reusing that wording here, changing the length
from 16 to 8 bits of course.

Section 4.2, Measurement Duration Cumulative and Interval
In both definitions, the word "receiver" is a bit ambiguous. Is this
meant to be the receiver of this XR block, or the receiver of the RTP
media stream that is now constructing and sending the XR Block? I think
it is the latter, but it would be good to clarify.

Section 6, Security Considerations
Current:
   RTCP reports can contain sensitive information since they can provide
   information about the nature and duration of a session established
   between two or more endpoints.  Therefore, the use of security
   mechanisms with RTP documented in Section 9 of [RFC3550] should
   apply.
Proposed:
   RTCP reports can contain sensitive information, including
   information about the nature and duration of a session established
   between two or more endpoints.  Therefore, the use of security
   mechanisms with RTP, as documented in Section 9 of [RFC3550], apply.

Section 7.2 Informative References
Update reference to MONARCH.

Cheers,
Charles

---

From: Qin Wu <[email-masked]>
Date: Tue, 20 Mar 2012 13:44:56 +0800

Hi, Charles:
Thank for your valuable comments. I agree that SDES part and XR Block part 
are a little bit mingled together in this version.. Your proposed change looks 
good to me. please see my replies below.

Regards!
-Qin

----- Original Message ----- 
From: "Charles Eckel (eckelcu)" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, March 20, 2012 2:56 AM
Subject: [xrblock] recommendations fordraft-ietf-xrblock-rtcp-xr-meas-identity

>   one or more other RTCP XR Report Blocks may refer.

[Qin]: Okay.

>   Block do not contain any measurement results (metrics).

[Qin]: Okay.

>   information mechanism was introduced by this document.

[Qin]: Okay.

>   The SDES item and XR Block described in this draft are in accordance

[Qin]: Okay.

> s/to the measurement/to the measurements

[Qin]: Okay.

> s/format of Measurement/format of the Measurement

[Qin]: Okay.

> regardless of the length.

[Qin]: Okay.

> from 16 to 8 bits of course.

[Qin]: Okay.

> it is the latter, but it would be good to clarify.

[Qin]: Yes, It should be the  the receiver who is  the cosumer of the RTP media stream.
I will change the "receiver" into "the receiver of the RTP media stream".

>   mechanisms with RTP, as documented in Section 9 of [RFC3550], apply.

[Qin]: Okay.

> Update reference to MONARCH.

[Qin]: Okay.

> Cheers,
> Charles
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 20 Mar 2012 13:23:49 -0700

Hi Qin,

That all sounds good to me. 

Thanks,
Charles

> -----Original Message-----
> From: Qin Wu [mailto:[email-masked]]
> Sent: Monday, March 19, 2012 10:45 PM
> To: Charles Eckel (eckelcu); [email-masked]
> Subject: Re: [xrblock] recommendations fordraft-ietf-xrblock-rtcp-xr-
> meas-identity
> 
> Hi, Charles: