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)" <eckelcu@cisco.com>
To: <xrblock@ietf.org>
Sent: Tuesday, March 20, 2012 2:56 AM
Subject: [xrblock] recommendations fordraft-ietf-xrblock-rtcp-xr-meas-identity


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

[Qin]: Okay.

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

[Qin]: Okay.

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

[Qin]: Okay.

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

[Qin]: Okay.

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

[Qin]: Okay.

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

[Qin]: Okay.

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

[Qin]: Okay.

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

[Qin]: Okay.

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

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

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


[Qin]: Okay.

> Section 7.2 Informative References
> Update reference to MONARCH.

[Qin]: Okay.

> Cheers,
> Charles
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock
>