Subject: [xrblock] FW: I-D Action: draft-ietf-xrblock-rtcp-xr-pdv-06.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 16 Sep 2012 10:55:34 +0200

A revised version of raft-ietf-xrblock-rtcp-xr-pdv was issued in order
to address the problems raised in DISCUSSes and COMMENTs during the IESG
review. 

We believe that the changes are editorial and clarification in nature,
they do not affect bits on the wire and improve the quality of the
document. However, more scrutiny from the other WG participants never
harms. Please read the revised version and let us know before 9/21 if
you see any problems. 

Thanks and Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Friday, September 14, 2012 12:26 PM
To: [email-masked]
Cc: [email-masked]
Subject: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-pdv-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
 This draft is a work item of the Metric Blocks for use with RTCP's
Extended Report Framework Working Group of the IETF.

	Title           : RTCP XR Report Block for Packet Delay
Variation Metric Reporting
	Author(s)       : Alan Clark
                          Qin Wu
	Filename        : draft-ietf-xrblock-rtcp-xr-pdv-06.txt
	Pages           : 21
	Date            : 2012-09-14

Abstract:
   This document defines a Real-Time Control Protocol (RTCP) Extended
   Report (XR) block that allows the reporting of Packet Delay Variation
   metrics for a range of Real-time Transport Protocol (RTP)
   applications.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-pdv

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-pdv-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-pdv-06

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

---

From: Colin Perkins <[email-masked]>
Date: Sun, 16 Sep 2012 12:52:48 +0100

On 16 Sep 2012, at 09:55, Romascanu, Dan (Dan) wrote:
> A revised version of raft-ietf-xrblock-rtcp-xr-pdv was issued in order to address the problems raised in DISCUSSes and COMMENTs during the IESG review. 
> 
> We believe that the changes are editorial and clarification in nature, they do not affect bits on the wire and improve the quality of the document. However, more scrutiny from the other WG participants never harms. Please read the revised version and let us know before 9/21 if you see any problems. 

The abstract is changed to expand RTCP as "Real-Time Control Protocol", but the correct expansion is "RTP Control Protocol". 

-- 
Colin Perkins
http://csperkins.org/

---

From: Qin Wu <[email-masked]>
Date: Mon, 17 Sep 2012 09:12:18 +0800

Good catch, thanks and will fix this.

Regards!
-Qin

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 17 Sep 2012 17:24:28 +0200

Thanks, Colin for catching this. 

Gonzalo, can you fix this in a note to the RFC Editor as follows: 

'In the Abstract": s/ This document defines a Real-Time Control Protocol
(RTCP)/ This document defines a RTP Control Protocol (RTCP)/

Thanks and Regards,

Dan

> From: Colin Perkins [mailto:[email-masked]]
> Sent: Sunday, September 16, 2012 2:53 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> The abstract is changed to expand RTCP as "Real-Time Control
Protocol",
> but the correct expansion is "RTP Control Protocol".
> 
> --
> Colin Perkins
> http://csperkins.org/
> 
>

---

From: Glen Zorn <[email-masked]>
Date: Mon, 17 Sep 2012 22:59:01 +0700

> harms. Please read the revised version and let us know before 9/21 if

The change to Section i.1 introduced a punctuation error: s/,,/,/

I find the change to Section 1.4 rather confusing:

                 Application designers can know the range of delay 
variation they must
                 accommodate, whether they are designing fixed or 
adaptive buffer
                 systems.

Are these app designers clairvoyant?  If not, how can they "know the 
range of delay variation they must accommodate, whether they are 
designing fixed or adaptive buffer systems" from measurements that can't 
be made until the system is not only implemented but deployed (at least 
in a test bed)?  The next sentence doesn't make much sense, either, as 
written.  I suggest deleting the first and rewriting the second to make 
more sense; for example: "For example, network managers can use this 
metric to compare actual delay variation to targets (i.e., a numerical 
objective or Service Level Agreement) to help ensure the quality of 
real-time application performance." Or something like that.

What does Section 2 mean?  How can one use an entire RFC as a 
"terminology statement"?  Does it actually mean "This document uses ABNF 
notation [RFC5234] in Section 4."?   If so, just say that; OTOH, since 
the ABNF usage is in the context of SDP & RFC 3611 both references the 
ABNF spec and is listed as a normative reference in this draft, why 
bother?  I suggest just deleting Section 2.

> From:[email-masked]  [mailto:[email-masked]] On
> Behalf [email-masked]
> To:[email-masked]
> Cc:[email-masked]

---

From: Qin Wu <[email-masked]>
Date: Tue, 18 Sep 2012 10:10:03 +0800

Hi, Glen:
Thank for your comments, please see my reply inline.

Regards!
-Qin
----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, September 17, 2012 11:59 PM
Subject: Re: [xrblock] FW: I-D Action: draft-ietf-xrblock-rtcp-xr-pdv-06.txt

> The change to Section i.1 introduced a punctuation error: s/,,/,/

[Qin]: Good catch and will fix this. Thanks.

> in a test bed)? 

[Qin]: Sorry to bring confusing here, what we want to convey is
these application designers need to know the range of delay variation they must accomodate,
and then based on the range of delay variation to determine whether they are designing
fixed or adaptive buffer systems. 
You can get more details in the section 3.2 of RFC5481.
Do we really need to delete this first sentence you mentioned above?

> The next sentence doesn't make much sense, either, as 

[Qin]: Your proposed change to the second setence looks good to me.

> notation [RFC5234] in Section 4."?   

[Qin]: Yes, this statement doesn't intend to apply to the whold document.
Thank for your proposed change.

>If so, just say that; OTOH, since 
> bother?  

[Qin]: The reason is ABNF spec referenced by SDP document (i.e., RFC4566) and RFC3611
is outdated or obsoleted RFC4234, this RFC should be replaced by RFC5234.

>I suggest just deleting Section 2.

[Qin] How about move this statement to the first place in the section 4?

---

From: Qin Wu <[email-masked]>
Date: Tue, 18 Sep 2012 10:33:07 +0800

Hi,
----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Colin Perkins" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, September 17, 2012 11:24 PM
Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-pdv-06.txt

> (RTCP)/ This document defines a RTP Control Protocol (RTCP)/

[Qin]: On typo I spot, I think "a" before RTP in this sentence should be "an".

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 18 Sep 2012 10:02:46 +0200

Gonzalo,

We can do one more update before the document is approved, in order to
incorporate these changes. This would spare a lengthy note to the RFC
editor. 

Dan

> From: Qin Wu [mailto:[email-masked]]
> Sent: Tuesday, September 18, 2012 5:10 AM
> To: Glen Zorn; Romascanu, Dan (Dan)
> Cc: [email-masked]
> and then based on the range of delay variation to determine whether
they
> are designing

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 18 Sep 2012 12:44:56 +0300

Hi Dan,

yes, it is better to update the document. Just make sure you coordinate
the document update with the conversation with Benoit to clear his
discuss so that nobody gets confused when the new revision is posted.

Cheers,

Gonzalo

---

From: Glen Zorn <[email-masked]>
Date: Tue, 18 Sep 2012 17:41:15 +0700

> [Qin]: On typo I spot, I think "a" before RTP in this sentence should be "an".

No, 'a' is correct.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 18 Sep 2012 17:54:31 +0200

Hi Gonzalo and Benoit,

Please correct me if I am wrong, but my impression is that Benoit's
DISCUSS is related to the process of defining the  metrics in the
different places in the IETF in a consistent manner and keeping them in
one repository with a clear owner. Are there any text changes required
in draft-ietf-xrblock-rtcp-xr-pdv? 

Thanks and Regards,

Dan

> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Tuesday, September 18, 2012 12:45 PM
> To: Romascanu, Dan (Dan)
> Cc: Qin Wu; Glen Zorn; [email-masked]
> >> Subject: Re: [xrblock] FW: I-D Action:
> >> draft-ietf-xrblock-rtcp-xr-pdv- 06.txt
> >>
> >> Hi, Glen:
> >> Subject: Re: [xrblock] FW: I-D Action:
> >> draft-ietf-xrblock-rtcp-xr-pdv- 06.txt
> >>
> >>
> >>>
> >>>> to address the problems raised in DISCUSSes and COMMENTs during
the
> >> IESG
> >>>> harms. Please read the revised version and let us know before
9/21
> > if
these
> >> application designers need to know the range of delay variation
they
> >> must accomodate, and then based on the range of delay variation to
> >> determine whether
> > they
> >> are designing
> >>> The next sentence doesn't make much sense, either, as written.  I
> >>> suggest deleting the first and rewriting the second to
> >> make
> >>> "terminology statement"?  Does it actually mean "This document
uses
> >> ABNF
> >> [Qin] How about move this statement to the first place in the
section
> > 4?
To:[email-masked]

---

From: Qin Wu <[email-masked]>
Date: Wed, 19 Sep 2012 09:09:11 +0800

Hi,
----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Romascanu, Dan (Dan)" <[email-masked]>; "Colin Perkins" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 18, 2012 6:41 PM
Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-pdv-06.txt

>> [Qin]: On typo I spot, I think "a" before RTP in this sentence should be "an".

[Qin]: I agree we use 'a' before 'Real'. However Real-Time Control Protocol is not correct
full name of RTCP. So when Real-time is corrected as 'RTP', we should use 'an' before
RTP. 
Also I think usually we don't expand RTP and RTCP in  the same sentence.

---

From: Glen Zorn <[email-masked]>
Date: Wed, 19 Sep 2012 09:01:23 +0700

On 09/19/2012 08:09 AM, Qin Wu wrote:

...

> Also I think usually we don't expand RTP and RTCP in  the same sentence.

The rule is that 'a' is used before words that start with consonants; 
'r' is a consonant.  See 
<http://owl.english.purdue.edu/owl/resource/591/01/>A versus An.

---

From: Glen Zorn <[email-masked]>
Date: Wed, 19 Sep 2012 15:16:27 +0700

On 09/18/2012 09:10 AM, Qin Wu wrote:

...

> You can get more details in the section 3.2 of RFC5481.

I'm not arguing w/RFC 5481, but the idea that app designers can use 
measurements obtained after the app has already been implemented and 
deployed confuses the heck out of me.  I suppose that they could use 
studies of similar apps operating under similar conditions, but 
describing that would require more than a cut-and-paste from 5481.

> Do we really need to delete this first sentence you mentioned above?

Deleting it would be the simplest option, but it could be changed to 
make a little more temporal sense.  How about something like this: "For 
example, applications could use these measurements to help adjust the 
size of adaptive jitter buffers to improve performance."?

...

> is outdated or obsoleted RFC4234, this RFC should be replaced by RFC5234.

Yes, but it doesn't seem to me that the job of this draft is to fix the 
references section in the SDP spec.  I guess the real question is 
whether or not the syntax follows that used in RFC 4566.  If so, then it 
should be fine; the fact that it's not the latest & greatest version of 
ABNF is immaterial.

...

---

From: Qin Wu <[email-masked]>
Date: Wed, 19 Sep 2012 16:47:51 +0800

Hi,
----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Glen Zorn" <[email-masked]>; "Romascanu, Dan (Dan)" <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 19, 2012 4:16 PM
Subject: Re: [xrblock] FW: I-D Action: draft-ietf-xrblock-rtcp-xr-pdv-06.txt

> size of adaptive jitter buffers to improve performance."?

[Qin]: Looks good to me.

> should be fine; the fact that it's not the latest & greatest version of 

[Qin]: Agree. In ABNF spec, parenthese usage in RFC4234 doesn't change in RFC5234.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 19 Sep 2012 14:31:44 +0300

Hi Dan,

no, as far as I understand it, the current revision of the draft
addresses Benoit's discuss. I guess he will clear it as soon as he gets
around to reading the new revision.

Cheers,

Gonzalo

---

From: Benoit Claise <[email-masked]>
Date: Thu, 20 Sep 2012 15:56:24 +0200

Dear all,
> one repository with a clear owner.
Exactly.
Regarding the consistency, we must do something now by updating the 
XRBLOCK drafts to use the RF C6390 template for performance metrics 
definition.
Regarding the single location for performance metrics, the idea would be 
to start with a WIKI. This work should be initiated by the PMOL directorate.

Regards, Benoit.
> Are there any text changes required

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 20 Sep 2012 17:58:36 +0300

Hi Benoit,

the authors introduced the following information in the draft, which was
missing before, per our request:

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-xrblock-rtcp-xr-pdv-06.txt

Could you please let the authors know whether or not that addresses your
discuss and, in case it doesn't, what needs to be done?

Thanks,

Gonzalo

---

From: Kevin Gross <[email-masked]>
Date: Thu, 20 Sep 2012 14:11:08 -0600

That reference is not jargon aware. Article selection is done based on
sound, not spelling. "An" is used in front of a vowel _sound_. RTP is
pronounced "arr-tee-pee" so "An" is the correct article here.

On Tue, Sep 18, 2012 at 8:01 PM, Glen Zorn <[email-masked]> wrote:
>
>
> The rule is that 'a' is used before words that start with consonants; 'r'
> is a consonant.  See <http://owl.english.purdue.**edu/owl/resource/591/01/<http://owl.english.purdue.edu/owl/resource/591/01/>>A
> versus An.
>
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 21 Sep 2012 10:31:15 +0200

Right. 

I agree that documents defining new metrics should follow the format in
RFC 6390, and the XRBLOCK WG will align to this guidance. 

This document however does not define new metrics, but uses for PDV the
metric definitions in G.1020 and Y.1540 and the metrics type field
points to which of those is being used. Unless I am missing something I
see no reason to hold this document. 

Regards,

Dan

> Sent: Thursday, September 20, 2012 5:59 PM
> To: Benoit Claise
> Cc: Romascanu, Dan (Dan); Qin Wu; Glen Zorn; [email-masked]
http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-xrblock-
> rtcp-xr-pdv-06.txt
> >> different places in the IETF in a consistent manner and keeping
them
> >> in one repository with a clear owner.
> > Exactly.
> > Regarding the single location for performance metrics, the idea
would
> > be to start with a WIKI. This work should be initiated by the PMOL
> directorate.
> >
> > Regards, Benoit.
> >>>> We can do one more update before the document is approved, in
order
> >> to
> >>>>>>> A revised version of raft-ietf-xrblock-rtcp-xr-pdv was issued
in
> >>>>> order
> >>>>>>> document. However, more scrutiny from the other WG
participants
> >>>> never
> >>>>>>                  Application designers can know the range of
> >>>>>> delay variation they must
> >>>>>> Are these app designers clairvoyant?  If not, how can they
"know
> >>>>>> designing fixed or adaptive buffer systems" from measurements
> >>>>>> that
> >>>>> can't
> >>>>>> be made until the system is not only implemented but deployed
(at
> >>>>> least
> >>>>>> objective or Service Level Agreement) to help ensure the
quality
> >> of
> >>>>>> If so, just say that; OTOH, since the ABNF usage is in the
> >>>>>> context of SDP & RFC 3611 both references
> >>>> the
> >>>>>>> From:[email-masked]
[mailto:[email-masked]]
> >> On
> >>>>>>>      Report (XR) block that allows the reporting of Packet
Delay
> >>>>> Variation

---

From: Qin Wu <[email-masked]>
Date: Fri, 21 Sep 2012 18:09:51 +0800

+1
----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Gonzalo Camarillo" <[email-masked]>; "Benoit Claise" <[email-masked]>
Cc: "Qin Wu" <[email-masked]>; "Glen Zorn" <[email-masked]>; <[email-masked]>
Sent: Friday, September 21, 2012 4:31 PM
Subject: RE: [xrblock] FW: I-D Action: draft-ietf-xrblock-rtcp-xr-pdv-06.txt

Right. 

Regards,

Dan

them
would
order
in
participants
"know
(at
quality
Delay

---

From: Glen Zorn <[email-masked]>
Date: Fri, 21 Sep 2012 19:51:39 +0700

More editorial comments.

Section 1.4
OLD:
variation[RFC5481].  For example, applications could use the
NEW:
variation [RFC5481].  For example, applications could use the

Section 3
OLD:
    Metrics in this block report on packet delay variation in the stream
    arriving at the RTP system.  The measurement of these metrics are
    made at the receiving end of the RTP stream.  Instances of this
    Metrics Block refer by Synchronization source (SSRC) to the separate
    auxiliary Measurement Information block [MEASI] which contains
    measurement intervals.  This metric block relies on the measurement
    interval in the Measurement Information block indicating the span of
    the report and SHOULD be sent in the same compound RTCP packet as the
    measurement information block.  If the measurement interval is not
    received for this metric block, this metric block MUST be discarded (
    See section 5.4 of[MONARCH]for timing details).
NEW:
    Metrics in this block report on packet delay variation in the stream
    arriving at the RTP system.  The measurement of these metrics are
    made at the receiving end of the RTP stream.  Instances of this
    metric block refer by Synchronization Source (SSRC) to the separate
    auxiliary Measurement Information Block [MEASI] which contains
    measurement intervals.  This metric block relies on the measurement
    interval given by the value of the "Measurement Duration (Interval)"
field in the Measurement Information Block to indicate the span of
    the report and SHOULD be sent in the same compound RTCP packet as the
    Measurement Information Block.  If the measurement interval is not
    received for this metric block, this metric block MUST be discarded (
    See section 5.4 of [MONARCH]for timing details).

COMMENT
I find this reference rather confusing, because can't see anything about 
timing in Section 5.4.
Actually, the last 2 sentences are quite confusing in that they appear 
to be rather self-contradictory:
they say that the Measurement Information Block SHOULD be sent in the 
same packet as this block, but if it's not received the block MUST be 
discarded.  Wouldn't it be simpler just to say the following?

    This metric block relies on the measurement
    interval given by the value of the "Measurement Duration (Interval)"
field in the Measurement Information Block to indicate the span of
    the report and MUST be sent in the same compound RTCP packet as the
    Measurement Information Block.  If the measurement interval is not
    received for this metric block, this metric block MUST be discarded.

Section 3.2

COMMENT
If the bits in the diagram absolutely MUST be labeled in octel, please 
be consistent.  For example, Section 3.2 states that the SSRC of the 
source is 32 bits in length, but the diagram in Section 3.1 clearly 
shows it to be 37 bits long.

COMMENT
In the definition of the Interval Metric flag (I) field the last two 
sentences say "The value I=00 is reserved, and MUST NOT be used.  If the 
value I=00 is received, it MUST be ignored by the receiver."  The last 
sentence says that a value of 00 is received then the value must be 
ignored but I think it means that if a value of 00 is received then the 
XR block must be ignored.

OLD
       Packet Delay Variation Metric Type is of type enumerated and is
       interpreted as Integer.
NEW
       Packet Delay Variation Metric Type is of type enumerated and is
       to be interpreted as an unsigned, 4-bit integer.

OLD
         bits 014-011
NEW
         bits 012-015

COMMENT
I don't know what "more positive than" & "more negative than" mean WRT 
to numbers: my understanding is that real numbers are positive, negative 
or zero.  Is there some reason why we can't just say "greater than" and 
"less than"?

Section 3.3

OLD
    MAPDV2 (Clause 6.2.3.2 of [G.1020]) is the envelope of instantaneous
    (per-packet) delay when compared to the short term moving average
    delay.  This metric could be useful in determining residual
    impairment when an RTP end system uses an adaptive de-jitter buffer
    which tracks the average delay variation, provided the adaptive de-
    jitter buffer have similar averaging behaviour as the MAPDV2
    algorithm.
NEW
    MAPDV2 (Clause 6.2.3.2 of [G.1020]) is the envelope of instantaneous
    (per-packet) delay when compared to the short term moving average
    delay.  This metric could be useful in determining residual
    impairment when an RTP end system uses an adaptive de-jitter buffer
    which tracks the average delay variation, provided that the averaging
    behavior of the adaptive algorithm is similar to that of the MAPDV2
    algorithm.

OLD
    2-point PDV (Clause 6.2.4 of [Y.1540]) reports absolute packet delay
    variation with respect to a defined reference packet transfer delay .
    Note that the reference packet is generally selected as the packet
    with minimum delay based on the most common criterion (See section 1
    and section 5.1 of [RFC5481] ).  In an RTP context, the two "points"
    are at the sender (the synchronization source which applies RTP
    timestamps) and at the receiver.  The value of this metric for the
    packet with index j is identical to the quantity D(i,j) defined in
    Section 6.4.1 of [RFC3550] and the packet index i should be set equal
    to the index of the reference packet for the metric in practice.  The
    metric includes the effect of the frequency offsets of clocks in both
    the sender and receiver end systems, so it is useful mainly in
    network where synchronisation is distributed.
NEW
    2-point PDV (Clause 6.2.4 of [Y.1540]) reports absolute packet delay
    variation with respect to a defined reference packet transfer delay.
    Note that the reference packet is generally selected as the packet
    with minimum delay based on the most common criterion (See section 1
    and section 5.1 of [RFC5481]).  In an RTP context, the two "points"
    are at the sender (the synchronization source which applies RTP
    timestamps) and at the receiver.  The value of this metric for the
    packet with index j is identical to the quantity D(i,j) defined in
    Section 6.4.1 of [RFC3550] and the packet index i should be set equal
    to the index of the reference packet for the metric in practice.  The
    metric includes the effect of the frequency offsets of clocks in both
    the sender and receiver end systems, so it is useful mainly in
    networks where synchronisation is distributed.

Section 3.4

OLD
       (b) To report MAPDV2 [G.1020]:

          Pos PDV Threshold = 50.0; Pos PDV Percentile = 95.3; Neg PDV
          Threshold = 50.0 (note this implies -50ms); Neg PDV Percentile
          = 98.4; PDV type = 1 (MAPDV2)

          causes average MAPDV2 to be reported in the Mean PDV field.
NEW
       (a) To report MAPDV2 [G.1020]:

          Pos PDV Threshold = 50.0; Pos PDV Percentile = 95.3; Neg PDV
          Threshold = 50.0 (note this implies -50ms); Neg PDV Percentile
          = 98.4; PDV type = 0 (MAPDV2)

          causes average MAPDV2 to be reported in the Mean PDV field.
COMMENT
The last phrase is confusing, because it seems that what causes MAPDV2 
to be reported is that really
the fact that the value of the pdvtype field is 0; the rest of the 
values seem irrelevant (or at least esoteric).

Section 4
COMMENT
Is "<as defined in Section 3.4 of [RFC5234]>" valid ABNF?

COMMENT
    When SDP is used in offer-answer, a system sending SDP may request a
    specific type of PDV measurement.  In addition, they may state a
    specific percentile or threshold value, and expect to receive the
    corresponding threshold or percentile metric, respectively. The
    system receiving the SDP SHOULD send the PDV metrics requested, but
    if the metric is not available, the system receiving the SDP MUST
    send the metric block with the flag value indicating that the metric
    is unavailable.
I don't see any flag value in this block that indicates that the metric 
is unavailable.

Section 5.4
COMMENT
    o  Initial assignments are as follows:

       *  0: MAPDV2, Clause 6.2.3.2 of [G.1020],

       *  1: 2-point PDV, Clause 6.2.4 of [Y.1540]

Are the rest of the values reserved?

Section 6
OLD
    The authors gratefully acknowledge the comments and contributions
    made by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin
    Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert
    Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith
    Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho,
    Ravi Raviraj, Albrecht Schwarz, Tom Taylor, and Hideaki Yamada,Jing
    Zhao,Kevin Gross, Colin Perkins, Charles Eckel, Glen Zorn,Shida
    Schubert, Benoit Claise, Adrian Farrel, Pete Resnick.
NEW
    The authors gratefully acknowledge the comments and contributions
    made by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin
    Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert
    Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith
    Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho,
    Ravi Raviraj, Albrecht Schwarz, Tom Taylor, Hideaki Yamada, Jing
    Zhao, Kevin Gross, Colin Perkins, Charles Eckel, Glen Zorn, Shida
    Schubert, Benoit Claise, Adrian Farrel and Pete Resnick.

COMMENT
The first sentence says "The authors gratefully acknowledge the comments 
and contributions"
but there is a "Contributors" section.  If some of these people actually 
contributed to the document (i.e., text), shouldn't they at a minimum be 
in that section, if not added as authors?

RANT
Is nobody else bothered by the amazing lack of precision in the xrblock 
WG drafts (perhaps not all, but not just this one, either)?  For 
example, the (presumably) same thing is referred to by 2, 3 or even 4 
different names in this document, leaving the reader to figure out that 
"Pos PDV Threshold/Peak", "Positive PDV Threshold/Peak" and "Pos PDV 
Threshold" all mean the same thing.  It's not rocket science, but it 
does (like labeling block diagrams in octal and the characterizing the 
fields in decimal and inconsistent capitalization) make reading the 
documents unnecessarily tedious.

---

From: Qin Wu <[email-masked]>
Date: Sat, 22 Sep 2012 10:17:51 +0800

Hi,Glen:
Thank for your proposed change for text improvement, you save a lot of work for RFC Editor.
Please see my reply inline.

Regards!
-Qin
----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 21, 2012 8:51 PM
Subject: Re: [xrblock] FW: I-D Action: draft-ietf-xrblock-rtcp-xr-pdv-06.txt

> variation [RFC5481].  For example, applications could use the

[Qin]:Okay.
>    See section 5.4 of [MONARCH]for timing details).

[Qin]: Okay.

>    received for this metric block, this metric block MUST be discarded.
[Qin]: Correct, I agree, thank for your proposal.

> shows it to be 37 bits long.

[Qin]: Okay, that is misunderstanding, I will change bits in the diagram labeled in octal into
bits in the diagram in decimal. 

> XR block must be ignored.

[Qin]: Agree, I will change as you proposed.
OLD TEXT:
"If the value I=00 is received, then it MUST be ignored by the receiver."
NEW TEXT:
"If the value I=00 is received, then the XR block MUST be ignored by the receiverit."

>       to be interpreted as an unsigned, 4-bit integer.

[Qin]: Okay.

>         bits 012-015
[Qin]: I think the range from the 11th bit to the 14th bit counted from leftmost is correct.

> or zero.  Is there some reason why we can't just say "greater than" and 

[Qin]: I think it is kind of habit for language using. I have no difficult to understand
what "more positive than" & "more negative than" mean. But I am okay with your proposed
change, i.e.using less than to replace "more negative than" and using "greater than" to replace
"more positive than".
>    behavior of the adaptive algorithm is similar to that of the MAPDV2

[Qin]: Okay.

>    networks where synchronisation is distributed.
[Qin]: Okay.

>          causes average MAPDV2 to be reported in the Mean PDV field.

[Qin]: Good catch.Thanks.

> values seem irrelevant (or at least esoteric).
 
[Qin]:It looks esoteric but required since it is up to measurement method defined in
G.1020 or Y.1540. You can see SDP also signals that.

> I don't see any flag value in this block that indicates that the metric 

[Qin]: The flag value is in the mean PDV field, Positive PDV Threshold/Peak field,Positive PDV Percentile,etc.
e.g., we use 0xFFFF to indicate metric is unavailable.

> Are the rest of the values reserved?

[Qin]: Yes. Here we just give initial assignments.

>    Schubert, Benoit Claise, Adrian Farrel and Pete Resnick.

[Qin]: Okay.

> in that section, if not added as authors?

[Qin]: I can't remember who is contributor and who is not in the history. Sorry about that.

---

From: Glen Zorn <[email-masked]>
Date: Sat, 22 Sep 2012 11:08:53 +0700

On 09/22/2012 09:17 AM, Qin Wu wrote:

...

>> COMMENT The last phrase is  confusing, because it seems that what
 >> causes MAPDV2 to be reported is that really the fact that the value
 >> of the pdvtype field is 0; the rest of the values seem irrelevant
 >> (or at least esoteric).
 >
 > [Qin]:It looks esoteric but required since it is up to measurement
 > method defined in G.1020 or Y.1540. You can see SDP also signals
 > that.
 >
 >>
 >> Section 4 COMMENT Is "<as defined in Section 3.4 of [RFC5234]>"
 >> valid ABNF?
 >>
 >> COMMENT When SDP is used in offer-answer, a system sending SDP may
 >> request a specific type of PDV measurement. In addition, they may
 >> state a specific percentile or threshold value, and expect to
 >> receive the corresponding threshold or percentile metric,
 >> respectively. The system receiving the SDP SHOULD send the PDV
 >> metrics requested, but if the metric is not available, the system
 >> receiving the SDP MUST send the metric block with the flag value
 >> indicating that the metric is unavailable. I don't see any flag
 >> value in this block that indicates that the metric is unavailable.
 >
 > [Qin]: The flag value is in the mean PDV field, Positive PDV
 > Threshold/Peak field,Positive PDV Percentile,etc. e.g., we use 0xFFFF
 > to indicate metric is unavailable.

I see, thanks!

>
 >>
 >> Section 5.4 COMMENT o Initial assignments are as follows:
 >>

OK, but the initial assignments include the reservation of unassigned 
values, right?  I'm pretty sure that IANA will ask this question later , 
so why not save time now?

>
 >>
 >> Section 6 OLD The authors gratefully acknowledge the comments and
 >> contributions made by Bruce Adams, Philip Arden, Amit Arora, Bob
 >> Biskner, Kevin Connor, Claus Dahm, Randy Ethier, Roni Even, Jim
 >> Frauenthal, Albert Higashi, Tom Hock, Shane Holthaus, Paul Jones,
 >> Rajesh Kumar, Keith Lantz, Mohamed Mostafa, Amy Pendleton, Colin
 >> Perkins, Mike Ramalho, Ravi Raviraj, Albrecht Schwarz, Tom Taylor,
 >> and Hideaki Yamada,Jing Zhao,Kevin Gross, Colin Perkins, Charles
 >> Eckel, Glen Zorn,Shida Schubert, Benoit Claise, Adrian Farrel, Pete
 >> Resnick. NEW The authors gratefully acknowledge the comments and
 >> contributions made by Bruce Adams, Philip Arden, Amit Arora, Bob
 >> Biskner, Kevin Connor, Claus Dahm, Randy Ethier, Roni Even, Jim
 >> Frauenthal, Albert Higashi, Tom Hock, Shane Holthaus, Paul Jones,
 >> Rajesh Kumar, Keith Lantz, Mohamed Mostafa, Amy Pendleton, Colin
 >> Perkins, Mike Ramalho, Ravi Raviraj, Albrecht Schwarz, Tom Taylor,
 >> Hideaki Yamada, Jing Zhao, Kevin Gross, Colin Perkins, Charles
 >> Eckel, Glen Zorn, Shida Schubert, Benoit Claise, Adrian Farrel and
 >> Pete Resnick.
 >
 > [Qin]: Okay.
 >
 >> COMMENT The first sentence says "The authors gratefully acknowledge
 >> the comments and contributions" but there is a "Contributors"
 >> section. If some of these people actually contributed to the
 >> document (i.e., text), shouldn't they at a minimum be in that
 >> section, if not added as authors?
 >

OK, so maybe change "comments and contributions made by" to "reviews and 
feedback provided by".  The reasons are that

 1. "contributor" is a technical term, denoting a person who has done
    more than just review a draft and thus deserves more credit and
 2. some people are very sensitive about getting the credit them

>
 >> _______________________________________________ xrblock mailing
 >> list [email-masked]

---

From: Qin Wu <[email-masked]>
Date: Sat, 22 Sep 2012 12:41:12 +0800

Hi,
----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Glen Zorn" <[email-masked]>; "Romascanu, Dan (Dan)" <[email-masked]>; <[email-masked]>
Sent: Saturday, September 22, 2012 12:08 PM
Subject: Re: [xrblock] FW: I-D Action: draft-ietf-xrblock-rtcp-xr-pdv-06.txt

> so why not save time now?

[Qin]: Okay, how about add one statement at the end of initial assignment part to say.
value 2-15 are valid and reserved for future use. 

> 2. some people are very sensitive about getting the credit them

[Qin]: Okay, looks reasonable to me, thanks.

---

From: Glen Zorn <[email-masked]>
Date: Sat, 22 Sep 2012 13:36:55 +0700

On 09/22/2012 11:41 AM, Qin Wu wrote:

...

 >> OK, but the initial assignments include the reservation of
 >> unassigned values, right? I'm pretty sure that IANA will ask this
 >> question later , so why not save time now?
 >
 > [Qin]: Okay, how about add one statement at the end of initial
 > assignment part to say. value 2-15 are valid and reserved for future
 > use.

OK, I suggest this:

     0:        MAPDV2, Clause 6.2.3.2 of [G.1020]
     1:        2-point PDV, Clause 6.2.4 of [Y.1540]
     2-15:  Reserved for future use

I.e., lose the asterisks ;-).  Also, in the same section, s/Entries in 
the registry are integers./Entries in the registry are unsigned 4-bit 
integers.

...

---

From: Qin Wu <[email-masked]>
Date: Sat, 22 Sep 2012 14:40:18 +0800

Hi,
----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Glen Zorn" <[email-masked]>; "Romascanu, Dan (Dan)" <[email-masked]>; <[email-masked]>
Sent: Saturday, September 22, 2012 2:36 PM
Subject: Re: [xrblock] FW: I-D Action: draft-ietf-xrblock-rtcp-xr-pdv-06.txt

> the registry are integers./Entries in the registry are unsigned 4-bit 

[Qin]: Okay. Thank for your proposed text.