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

From: [email-masked]
Date: Mon, 28 May 2012 20:18:53 -0700

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 Delay metric Reporting
	Author(s)       : Geoff Hunt
                          Alan Clark
                          Kevin Gross
                          Qin Wu
	Filename        : draft-ietf-xrblock-rtcp-xr-delay-06.txt
	Pages           : 15
	Date            : 2012-05-28

   This document defines an RTCP XR Report Block that allows the
   reporting of Delay metrics for use in a range of RTP applications.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-xrblock-rtcp-xr-delay-06.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-xrblock-rtcp-xr-delay-06.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-delay/

---

From: Shida Schubert <[email-masked]>
Date: Tue, 29 May 2012 13:16:07 +0900

All;

 This version reflects some of the comments I provided 
during the pre-proto write up review that I was conducting. 

 Some normative texts have been changed based on 
the exchange I had with the authors. The most recent spec 
reflects these but I want to get a WG consensus on the 
changes that were made. I apologize for my belated comments, 
this should have really gone out sooner.. 

 Anyway, if I see no objections, I will send the publication 
request this Friday. 

 Many Thanks
  Shida

** My comments and response from the author **

1. Section 3 
 - The delay report block should be sent with the 
   measurement information block and should be 
   ignored when it is not. 

    I believe this is a normative behavior thus uppercase 
    SHOULD is more appropriate for both "should"s.. 

[Qin]: Okay. Good suggestions.

2. Section 3.2  -  Reserved
 - Currently it is a MUST to set 0 but SHOULD ignore 
   when there is a value.

   PDV spec is a MUST/MUST.. I think there should be consistency. 

[Qin]: I remember I fix this based on Glen's comments. Glen commented that "They SHOULD be set to zero by senders and MUST be ignored by
receivers."  in he early description is backwards, instead it should read "They
MUST be set to zero by senders and SHOULD be ignored by receivers."
"
So I take his suggestion and use  MUST/SHOULD. To be consistent, I also use MUST/SHOULD in the newly updated PDV draft.
Does this make sense?

3. Section 3.2 - mean/min/max
 - Does "measurement period" in the first paragraph and "timespan of the report" 
   in the second paragraph means the same thing? If so I think it is clearer if you 
   use same langauge.  

[Qin]:Yes, they are same. How about the following change:
OLD text:
"
If only one measurement of Round Trip Delay is available for the

     timespan of the report(whether Interval or Cumulative), this

     single value should be reported as the mean value.

"
NEW Text:
"
If only one measurement of Round Trip Delay is available for the

timespan of the report(i.e.,the measurement period) (whether Interval or Cumulative), 

 this single value should be reported as the mean value.

"

4. Section 3.2 - mean/min/max
- The second paragraph talks about setting the only measurement if that is all 
  that is available. Same note is repeated for mean/min/max, are you saying that 
  mean/min/max can have a same value if there is only one measurement? 
   There is nothing wrong with it, I am just confirming this.

[Qin]: You are correct.

- Also, ".. single value should be reported as mean value", should I think should be 
  "SHOULD".

[Qin]: Okay and will fix this.

5. Section 3.2 - mean/min/max
- Last paragraph proposes to set the value to 1 when measurement is unavailable, 
  should this be MUST instead of SHOULD? Is there a reason why it is not a MUST?

[Qin]: no reason, I can use MUST.

* This holds true for End System Delay as well.. Currently SHOULD but should it be MUST?

[Qin]: Okay, I can use MUST.

**********

On May 29, 2012, at 12:18 PM, [email-masked] wrote:

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 29 May 2012 10:30:00 +0200

Hi, 

All proposed changes make sense to me and I have no objection, but I do
not understand the second half of the sentence in 1 below:  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Shida Schubert
> 
> 1. Section 3

What should (or SHOULD) 'be ignored when it is not'. When it's not sent
what is to be ignored? Something seems to be missing here (or I am
missing something). 

Regards,

Dan

---

From: Qin Wu <[email-masked]>
Date: Tue, 29 May 2012 16:52:50 +0800

----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Shida Schubert" <[email-masked]>; "xrblock" <[email-masked]>
Sent: Tuesday, May 29, 2012 4:30 PM
Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-delay-06.txt

> what is to be ignored? Something seems to be missing here (or I am

[Qin]: For clarification, this comment is just summarization by Shida and applies to the
following description of 1st paragraph, section 3 in the new version -06.
"
  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 in the same
   compound RTCP packet as this metric block, this metric block **SHOULD**
   be discarded.
"
The old description in the previous version -05 is:
"
 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 in the same
   compound RTCP packet as this metric block, this metric block **should**
   be discarded.

"

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 29 May 2012 11:02:52 +0200

Makes sense now, thanks for the clarification. 

Regards,

Dan

> From: Qin Wu [mailto:[email-masked]]
> Sent: Tuesday, May 29, 2012 11:53 AM
> To: Romascanu, Dan (Dan); Shida Schubert; xrblock