Subject: [xrblock] (2nd) WGLC for draft-ietf-xrblock-rtcp-xr-jb

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 8 Apr 2013 14:06:14 +0000

This is the second WGLC for the Internet-Draft 'RTP Control Protocol (RTCP) Extended Report (XR) Block for Jitter Buffer Metric Reporting'. Please send your comments, questions, and concerns to the WG list before Monday 4/22 COB. If you have no comments or questions and you believe that this document is ready for submission to the IESG for consideration as a Proposed Standard, please send a message stating this. 

The latest version of the document can be retrieved from http://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-jb-10.txt.

Thanks and Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 8 Apr 2013 14:19:33 +0000

Hi,

Runing id-nits results in a warning downref message concerning [RFC6709] which is an Informational RFC being a Normative Reference. I suggest to move this reference to the Informative References section in the next version of the document. 

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Romascanu, Dan (Dan)
> Sent: Monday, April 08, 2013 5:06 PM
> To: xrblock
> Subject: [xrblock] (2nd) WGLC for draft-ietf-xrblock-rtcp-xr-jb
> 
> 
> This is the second WGLC for the Internet-Draft 'RTP Control Protocol
> (RTCP) Extended Report (XR) Block for Jitter Buffer Metric Reporting'.
> Please send your comments, questions, and concerns to the WG list before
> Monday 4/22 COB. If you have no comments or questions and you believe
> that this document is ready for submission to the IESG for consideration
> as a Proposed Standard, please send a message stating this.
> 
> The latest version of the document can be retrieved from
> http://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-jb-10.txt.
> 
> Thanks and Regards,
> 
> Dan
> 
> 
> 
> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock

---

From: Qin Wu <[email-masked]>
Date: Tue, 9 Apr 2013 00:24:13 +0000

Okay and thanks for your comment.

Regards!
-Qin
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Romascanu, Dan (Dan)
发送时间: 2013年4月8日 22:20
收件人: Romascanu, Dan (Dan); xrblock
主题: Re: [xrblock] (2nd) WGLC for draft-ietf-xrblock-rtcp-xr-jb

Hi,

Regards,

Dan

---

From: "Roni Even" <[email-masked]>
Date: Wed, 10 Apr 2013 11:09:10 +0300

Hi,
I reviewed the document and it is ready for publication.

Just some nits

1. Section 3 5th paragraph "then then"

2. In section 3.1 "In practice jitter buffer implementations vary
considerably however should behave" suggest " In practice jitter buffer
implementations vary considerably however they should behave".

3. in section 4 change the two "should" to "SHOULD"

4. in section 4.2  in the " jitter buffer maximum delay" description "
earliest arriving packet In simple queue" to "earliest arriving packet. In
simple queue"

5. in section 5.2 " When SDP is used in offer-answer" suggest adding a
reference to RFC3264.

Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Romascanu, Dan (Dan)
Sent: 08 April, 2013 5:06 PM
To: xrblock
Subject: [xrblock] (2nd) WGLC for draft-ietf-xrblock-rtcp-xr-jb

This is the second WGLC for the Internet-Draft 'RTP Control Protocol (RTCP)
Extended Report (XR) Block for Jitter Buffer Metric Reporting'. Please send
your comments, questions, and concerns to the WG list before Monday 4/22
COB. If you have no comments or questions and you believe that this document
is ready for submission to the IESG for consideration as a Proposed
Standard, please send a message stating this. 

Thanks and Regards,

Dan

---

From: Qin Wu <[email-masked]>
Date: Thu, 11 Apr 2013 07:14:34 +0000

Hi, Roni:
Thank for your valuable comments, see my reply below.

Regards!
-Qin

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Roni Even
发送时间: 2013年4月10日 16:09
收件人: 'Romascanu, Dan (Dan)'; 'xrblock'
主题: Re: [xrblock] (2nd) WGLC for draft-ietf-xrblock-rtcp-xr-jb

Hi,

Just some nits

[Qin]: Okay, thank for your good catch.

[Qin]: Okay.

[Qin]: In IESG review to burst gap loss draft, similar comment was raised,
It was suggested to use "MUST" in two places. So I think we should use 
"MUST" here. But thanks for raising this issue.

[Qin]: Good catch, thanks.

[Qin]: Okay, make sense.

Roni Even

-----Original Message-----

Thanks and Regards,

Dan

---

From: Colin Perkins <[email-masked]>
Date: Mon, 22 Apr 2013 15:57:25 +0100

> The latest version of the document can be retrieved from http://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-jb-10.txt.

I think this is essentially ready, but I did have a quick comments on re-reading the draft:

How is the jitter buffer nominal delay calculated for an interval metric or for a cumulative metric? The draft talks about "the current nominal jitter buffer delay", which makes sense for a sampled metric, but it's not clear how it applies for an interval or as a cumulative metric?

It might also be necessary to clarify the other jitter buffer metrics for the cumulate case.

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

---

From: Qin Wu <[email-masked]>
Date: Tue, 23 Apr 2013 03:34:23 +0000

Hi, Colin:
I realized jitter buffer nominal delay metric can only be sampled and is not desirable to measuring them over definite intervals.
jitter buffer maximum delay metrics is corresponding to the earliest arriving packet in the reporting interval and it is more desirable 
to classify it as sampled metric. When we have several packets that arrives exactly on time in the reporting interval, we can know
which packet has the highest value of the jitter buffer nominal delay, which packet has the lowest value of the jitter buffer nominal delay.
So I like to revoke my proposed change used to address Claire's comment and add the following sentence at the end of definition of interval metric flag to say: 
"
In this document, Jitter Buffer Metrics can only be sampled , and cannot be measured over definite intervals. 
 Also, the value I=00 is reserved for future use.  Senders MUST NOT use the values I=00 or I=10 or I=11.  
If a block is received with I=00 or I=10 or I=11, the receiver MUST discard the block.
"
Note that as described in the draft, if any measurement to these metrics is not available, the value 0xFFFF MUST be reported  

Regards!
-Qin
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Colin Perkins
Sent: Monday, April 22, 2013 10:57 PM
To: Romascanu, Dan (Dan)
Cc: xrblock
Subject: Re: [xrblock] (2nd) WGLC for draft-ietf-xrblock-rtcp-xr-jb

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 30 Apr 2013 11:56:14 +0100

Thanks, this change looks good to me.
Colin

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