Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02

From: Colin Perkins <[email-masked]>
Date: Tue, 11 Dec 2012 22:16:14 +0100

On 29 Nov 2012, at 13:48, Romascanu, Dan (Dan) wrote:
> This is a Working Group Last Call for http://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-decodability-02.txt.  
> 
> Please read and review this document, and send your comments, questions and concerns to the WG list before December 13, 2012. If you have no comments and you believe that the document is ready for submission to the IESG as a Standards Track document please send a short message as well to help us in determining the level of review and consensus. 

I have some minor, primarily editorial, comments below, but in general this looks okay.

- should expand “TS” -> “MPEG Transport Stream” in the title

- the first sentence of the Abstract could usefully be changed to “An MPEG Transport Stream (TS) is a...”

- change “this draft” to “this memo” throughout

- “occurances” -> “occurrences” in the Introduction

- The packet diagram at the end of page 4 says “BT=TBD” but the text at the top of page 5 says “...is identified by the constant <TDM>”. These should be consistent, and should match the value in Section 5.

- The description of SDP offer/answer usage in Section 4.2 is insufficient, and needs to be updated in a manner analogous to the other recent RTCP XR blocks.

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

---

From: Glen Zorn <[email-masked]>
Date: Wed, 12 Dec 2012 11:24:27 +0700

On 12/12/2012 04:16 AM, Colin Perkins wrote:
 >> This is a Working Group Last Call for
 >> http://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-decodability-02.txt.
 >>
 >>
 >> Please read and review this document, and send your comments,
 >> questions and concerns to the WG list before December 13, 2012. If
 >> you have no comments and you believe that the document is ready for
 >> submission to the IESG as a Standards Track document please send a
 >> short message as well to help us in determining the level of review
 >> and consensus.
 >
 >

OK.

 > MPEG Transport Stream (TS) is a...”

I disagree: the sentence is not referring to a particular instance of 
TS, but to TS in general.  However, it might be useful to apply the same 
change here as you suggest for the title.

 > - change “this draft” to “this memo” throughout

OK.

 > - “occurances” -> “occurrences” in the Introduction

OK.

>
 >
 > - The packet diagram at the end of page 4 says “BT=TBD” but the text
 > at the top of page 5 says “...is identified by the constant <TDM>”.
 > These should be consistent, and should match the value in Section 5.

OK.

>
 >
 > - The description of SDP offer/answer usage in Section 4.2 is
 > insufficient, and needs to be updated in a manner analogous to the
 > other recent RTCP XR blocks.

Can you be more specific, please?

---

From: Qin Wu <[email-masked]>
Date: Wed, 12 Dec 2012 15:06:40 +0800

[Qin]: In my interpretation, the other recent RTCP XR blocks are referred to Burst gap loss draft
and Burst gap discard draft which get SDP Directorate review recently.

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 12 Dec 2012 08:13:01 +0100

On 12 Dec 2012, at 08:06, Qin Wu wrote:
> [Qin]: In my interpretation, the other recent RTCP XR blocks are referred to Burst gap loss draft and Burst gap discard draft which get SDP Directorate review recently.

Correct, sorry if I wasn't clear.

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 13 Dec 2012 14:05:51 +0000

Hi,

I have a few comments concerning this I-D: 

1. This document relies on ETSI work. Should we not send it to ETSI for review? Is the group were TR 101 290 developped still active? 

2. In the definition of the Reserved field: 

>     This field is reserved for future definition.  In the absence of
      such a definition, the bits in this field MUST be set to zero and
      SHOULD be ignored by the receiver.

Why is the behavior of the receiver defined as a SHOULD and not a MUST?

3. In the definition of the block length field: 

>     The constant 11, in accordance with the definition of this field
      in Section 3 of RFC 3611.

What is the definition of the receiver if a value other than 11 is received? 

4. For all count fields starting with TS_sync_loss_count - there is no definition or reference about what each metric means, and how the measurments or computation of the values are to be performed. Please provide this information for each field, I guess references to the respective sections in TR 101 290 would be fine. 

5. Usage of acronyms (excepting very obvious ones) is discouraged in the title of the documents. Please expand TS - Transport Stream in the title

6. Typo to fix in section 3: s/implentations/implementations/

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Romascanu, Dan (Dan)
> Sent: Thursday, November 29, 2012 2:48 PM
> To: [email-masked]
> Subject: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02
> 
> 
> Please read and review this document, and send your comments, questions
> and concerns to the WG list before December 13, 2012. If you have no
> comments and you believe that the document is ready for submission to
> the IESG as a Standards Track document please send a short message as
> well to help us in determining the level of review and consensus.
> 
> Thanks and Regards,
> 
> Dan
> 
> 
>

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 18 Dec 2012 01:20:57 +0000

Hi Dan,

Sorry for so late reply. Please see inline.

Best Regards!
Rachel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, December 13, 2012 10:06 PM
To: [email-masked]
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02

Hi,

[Rachel]: TR101.290 has been published for 13 years. I suspect the group who produce this document has already been closed down.

[Rachel]: I agree with you that it should be "MUST".

[Rachel]: Good point. We propose to add following texts:

"The block MUST be discarded if the block length is set to a different value.
"

[Rachel]:  Okay, we will fix this based on your suggestion.

[Rachel]: Okay.

[Rachel]: Okay.

Regards,

Dan

---

From: "Roni Even" <[email-masked]>
Date: Wed, 19 Dec 2012 15:13:39 +0200

Hi,
Sorry for the late posting.
I noticed that ETSI TR 101 290 has eight first priority and eight second
priority indications (section 5.2.1 and 5.2.2) while here we list only half
of them claiming that the others do not apply to all MPEG implementations. 

I do not have a major problem with keeping the XR block as is but we can
look at two other options.

1. Have all 16 indications.
2 Add two new parameters " # of First Priority Errors"  and   "# of Second
Priority Errors  "

Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Romascanu, Dan (Dan)
Sent: 29 November, 2012 2:48 PM
To: [email-masked]
Subject: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02

Please read and review this document, and send your comments, questions and
concerns to the WG list before December 13, 2012. If you have no comments
and you believe that the document is ready for submission to the IESG as a
Standards Track document please send a short message as well to help us in
determining the level of review and consensus. 

Thanks and Regards,

Dan

---

From: Qin Wu <[email-masked]>
Date: Thu, 20 Dec 2012 09:56:39 +0800

Hi, Roni:
Thank for raising this issue.
 In this draft, we are not choosing to report all indications in the first priority and second priority. Instead, we are 
choosing to report all the parameters that can be easily gathered by parsing
the TS header. What we ignore is all the other PSI/SI related parameters in
the first priority and second priority. These parameters usually fixs and repeatly occur in the received stream 
and need deep parsing not only TS header but also TS payload which introduce complexity in the test and
measurment instrument. However I do agree with you these PSI/SI related parameters
are still very important parameters. Any error of these PSI/SI related parameters will
lead to very serious quality problem.

Regarding the option you proposed, I am not favoring the second approach since it doesn't solve the problem
you raised and we already clarified the parameter we are taking belong to 1st and 2nd prioirty in the description
 before the format. I checked section 5.3.5 of TR 101.290, which provide TS parameters in transmission system with
"reduced SI data". I think if we really want to take some new parameters, we like to choose to take additional missing parameters 
in the 1st and 2nd priority of section 5.3.5, which belong to "reduced SI data".

Otherwise we prefer to leave as it is. 

Regards!
-Qin

---

From: "Roni Even" <[email-masked]>
Date: Thu, 20 Dec 2012 10:44:17 +0200

Hi Qin,
Thanks for the explanation. I see no problem with the current parameters. I
assume that we can define  later a second report block that will cover the
other parameters and it will be inline with the concepts of the monitoring
architecture
Roni

-----Original Message-----
From: Qin Wu [mailto:[email-masked]] 
Sent: 20 December, 2012 3:57 AM
To: Roni Even; 'Romascanu, Dan (Dan)'; [email-masked]
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02

Hi, Roni:
Thank for raising this issue.
 In this draft, we are not choosing to report all indications in the first
priority and second priority. Instead, we are choosing to report all the
parameters that can be easily gathered by parsing the TS header. What we
ignore is all the other PSI/SI related parameters in the first priority and
second priority. These parameters usually fixs and repeatly occur in the
received stream and need deep parsing not only TS header but also TS payload
which introduce complexity in the test and measurment instrument. However I
do agree with you these PSI/SI related parameters are still very important
parameters. Any error of these PSI/SI related parameters will lead to very
serious quality problem.

Regarding the option you proposed, I am not favoring the second approach
since it doesn't solve the problem you raised and we already clarified the
parameter we are taking belong to 1st and 2nd prioirty in the description
before the format. I checked section 5.3.5 of TR 101.290, which provide TS
parameters in transmission system with "reduced SI data". I think if we
really want to take some new parameters, we like to choose to take
additional missing parameters in the 1st and 2nd priority of section 5.3.5,
which belong to "reduced SI data".

Regards!
-Qin
----- Original Message -----
From: "Roni Even" <[email-masked]>
To: "'Romascanu, Dan (Dan)'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, December 19, 2012 9:13 PM
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02

> Please read and review this document, and send your comments, questions
and

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 20 Dec 2012 09:23:57 +0000

I agree as well. 

The only question I have is whether we should add more detailed text to explain the choice, on the line of the explanation given by Qin. 

Thanks and Regards,

Dan

> From: Roni Even [mailto:[email-masked]]
> Sent: Thursday, December 20, 2012 10:44 AM
> To: 'Qin Wu'; Romascanu, Dan (Dan); [email-masked]
> Subject: RE: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02
> 
> Hi Qin,
> Thanks for the explanation. I see no problem with the current
> parameters. I assume that we can define  later a second report block
> that will cover the other parameters and it will be inline with the
> concepts of the monitoring architecture Roni
> 
>  In this draft, we are not choosing to report all indications in the
> first priority and second priority. Instead, we are choosing to report
> all the parameters that can be easily gathered by parsing the TS header.
> What we ignore is all the other PSI/SI related parameters in the first
> priority and second priority. These parameters usually fixs and repeatly
> occur in the received stream and need deep parsing not only TS header
> but also TS payload which introduce complexity in the test and
> measurment instrument. However I do agree with you these PSI/SI related
> parameters are still very important parameters. Any error of these
> PSI/SI related parameters will lead to very serious quality problem.
> 
> since it doesn't solve the problem you raised and we already clarified
> the parameter we are taking belong to 1st and 2nd prioirty in the
> description before the format. I checked section 5.3.5 of TR 101.290,
> which provide TS parameters in transmission system with "reduced SI
> data". I think if we really want to take some new parameters, we like to
> choose to take additional missing parameters in the 1st and 2nd priority
> of section 5.3.5, which belong to "reduced SI data".
> 
> > I noticed that ETSI TR 101 290 has eight first priority and eight
> > second priority indications (section 5.2.1 and 5.2.2) while here we
> > list only
> half
> > I do not have a major problem with keeping the XR block as is but we
> > can look at two other options.
> >
> > questions
> > concerns to the WG list before December 13, 2012. If you have no

---

From: Qin Wu <[email-masked]>
Date: Thu, 20 Dec 2012 17:29:21 +0800

Hi, Roni:
We have two ways:
(a) If we choose to define a second report block later, we also need to change
 the current block name from "The MPEG-TS Decodability Metrics Block"
to "The MPEG-TS PSI Independent Decodability Metrics Block" to avoid block name confusing.

(b) If we choose to take all PSI related parameters into the current block, we don't need
to change block name but block length will grow into 17 from 11.

If people don't think the block size growth is a problem, I perfer the (b).

Regards!
-Qin

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 20 Dec 2012 09:36:18 +0000

(speaking as a contributor)

Solution (a) seems to me closer to the 'philosophy' we adopted with the modular monitoring architecture. 

Regards,

Dan

> Sent: Thursday, December 20, 2012 11:29 AM
> To: Roni Even; Romascanu, Dan (Dan); [email-masked]
> (a) If we choose to define a second report block later, we also need to
> change  the current block name from "The MPEG-TS Decodability Metrics
> Block"
> (b) If we choose to take all PSI related parameters into the current
> block, we don't need to change block name but block length will grow
> into 17 from 11.
> 
> parameters. I
> first
> the
> second
> >> priority indications (section 5.2.1 and 5.2.2) while here we list
> only
> > half
> comments

---

From: Qin Wu <[email-masked]>
Date: Thu, 20 Dec 2012 17:36:20 +0800

Not need, we have text in the draft to say the parameters we get are gathered from TS header.
But If we choose to add PSI related parameter into the current block, we should change
"the parametes are gathered from TS header" into something like
"the parametes are gathered from TS packet"

Regards!
-Qin
----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Roni Even" <[email-masked]>; "'Qin Wu'" <[email-masked]>; <[email-masked]>
Sent: Thursday, December 20, 2012 5:23 PM
Subject: RE: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02

I agree as well. 

Thanks and Regards,

Dan

---

From: Qin Wu <[email-masked]>
Date: Thu, 20 Dec 2012 18:03:06 +0800

It depend on whether we need to classify them into different categories. We shouldn't forget they are all Decodability Statistis parameters.
in my thinking, putting these parameters together in the same  block doesn't looks to conflict with the rules provided by 
monitoring architecture.

Regards!
-Qin

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 20 Dec 2012 10:27:22 +0000

I do not think that there is a conflict with the rules any way we proceed. It's just a personal preference and not a strong one, we defined the architecture to be modular, so why not use this? (as intended when you wrote the I-D)

Let us maybe hear other opinions. 

Regards,

Dan
(speaking as contributor)

> Sent: Thursday, December 20, 2012 12:03 PM
> To: Romascanu, Dan (Dan); Roni Even; [email-masked]
> It depend on whether we need to classify them into different categories.
> We shouldn't forget they are all Decodability Statistis parameters.
> in my thinking, putting these parameters together in the same  block
> doesn't looks to conflict with the rules provided by monitoring
> architecture.
> 
> Regards!
> -Qin
> >> If people don't think the block size growth is a problem, I perfer
> the
> >> (b).
> >>
> >> Regards!
> >> -Qin
> >> > assume that we can define  later a second report block that will
> cover
> >> the
> >> > Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-
> decodability-
> >> 02
> >> >
> >> > Hi, Roni:
> >> > priority and second priority. Instead, we are choosing to report
> all
> >> the
> >> > parameters that can be easily gathered by parsing the TS header.
> What
> >> we
> >> > second priority. These parameters usually fixs and repeatly occur
> in
> >> the
> >> > received stream and need deep parsing not only TS header but also
> TS
> >> payload
> >> > parameters. Any error of these PSI/SI related parameters will lead
> to
> >> very
> >> > serious quality problem.
> >> >
> >> > parameters in transmission system with "reduced SI data". I think
> if
> >> we
> >> > additional missing parameters in the 1st and 2nd priority of
> section
> >> 5.3.5,
> >> > Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-
> decodability-
> >> 02
> >> >
> >> >
> >> >> Hi,
> >> >> 2 Add two new parameters " # of First Priority Errors"  and   "#
> of
> >> Second
> >> >> Priority Errors  "
> >> >>
> >> >> Roni Even
> >> >>
> >> >> and you believe that the document is ready for submission to the
> IESG
> >> as a
> >> >> Standards Track document please send a short message as well to
> help
> >> us in

---

From: Colin Perkins <[email-masked]>
Date: Thu, 20 Dec 2012 11:16:02 +0000

We don't seem to have any urgent need for the extra parameters, so option (a) – some minor clarifications with the draft title, and possibly to the text – seems most appropriate.

Colin

On 20 Dec 2012, at 10:27, Romascanu, Dan (Dan) wrote:
>>>> (a) If we choose to define a second report block later, we also need to change  the current block name from "The MPEG-TS Decodability Metrics Block" to "The MPEG-TS PSI Independent Decodability Metrics Block" to avoid block name confusing.
>>>> 
>>>> (b) If we choose to take all PSI related parameters into the current block, we don't need to change block name but block length will grow into 17 from 11.
>>>> 
>>>>> Thanks for the explanation. I see no problem with the current parameters. I assume that we can define  later a second report block that will cover the other parameters and it will be inline with the concepts of the monitoring architecture
>>>>> Roni
>>>>> 
>>>>> In this draft, we are not choosing to report all indications in the first priority and second priority. Instead, we are choosing to report all the parameters that can be easily gathered by parsing the TS header. What we ignore is all the other PSI/SI related parameters in the first priority and
>>>>> second priority. These parameters usually fixs and repeatly occur in the received stream and need deep parsing not only TS header but also TS payload which introduce complexity in the test and measurment instrument. However I do agree with you these PSI/SI related parameters are still very important parameters. Any error of these PSI/SI related parameters will lead to very serious quality problem.
>>>>> 
>>>>> Regarding the option you proposed, I am not favoring the second approach since it doesn't solve the problem you raised and we already clarified the parameter we are taking belong to 1st and 2nd prioirty in the description before the format. I checked section 5.3.5 of TR 101.290, which provide TS parameters in transmission system with "reduced SI data". I think if we really want to take some new parameters, we like to choose to take additional missing parameters in the 1st and 2nd priority of section 5.3.5, which belong to "reduced SI data".
>>>>> 

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

---

From: "Roni Even" <[email-masked]>
Date: Thu, 20 Dec 2012 15:06:55 +0200

Hi,
This is also my view.
Roni

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: 20 December, 2012 1:16 PM
To: Romascanu, Dan (Dan)
Cc: Qin Wu; Roni Even; [email-masked]
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02

We don't seem to have any urgent need for the extra parameters, so option
(a) - some minor clarifications with the draft title, and possibly to the
text - seems most appropriate.

Colin

On 20 Dec 2012, at 10:27, Romascanu, Dan (Dan) wrote:
> I do not think that there is a conflict with the rules any way we 
> proceed. It's just a personal preference and not a strong one, we 
> defined the architecture to be modular, so why not use this? (as 
> intended when you wrote the I-D)
> 
>> Subject: Re: [xrblock] WGLC - 
>> draft-ietf-xrblock-rtcp-xr-decodability-02
>> 
>> To: "Qin Wu" <[email-masked]>; "Roni Even" 
>> <[email-masked]>; <[email-masked]>
>> Subject: Re: [xrblock] WGLC - 
>> draft-ietf-xrblock-rtcp-xr-decodability-02
>> 
>> 
>>>> Subject: Re: [xrblock] WGLC - 
>>>> draft-ietf-xrblock-rtcp-xr-decodability-02
>>>> 
>>>> Hi, Roni:
>>>> We have two ways:
change  the current block name from "The MPEG-TS Decodability Metrics Block"
to "The MPEG-TS PSI Independent Decodability Metrics Block" to avoid block
name confusing.
>>>> (b) If we choose to take all PSI related parameters into the current
block, we don't need to change block name but block length will grow into 17
from 11.
>>>> Subject: RE: [xrblock] WGLC - 
>>>> draft-ietf-xrblock-rtcp-xr-decodability-02
>>>> 
>>>> 
>>>>> Hi Qin,
>>>>> parameters. I assume that we can define  later a second report 
>>>>> block that will cover the other parameters and it will be inline 
>>>>> with the concepts of the monitoring architecture Roni
>>>>> 
>>>>> Subject: Re: [xrblock] WGLC - 
>>>>> draft-ietf-xrblock-rtcp-xr-decodability-02
>>>>> 
>>>>> Hi, Roni:
>>>>> In this draft, we are not choosing to report all indications in 
>>>>> the first priority and second priority. Instead, we are choosing to
report all the parameters that can be easily gathered by parsing the TS
header. What we ignore is all the other PSI/SI related parameters in the
first priority and second priority. These parameters usually fixs and
repeatly occur in the received stream and need deep parsing not only TS
header but also TS payload which introduce complexity in the test and
measurment instrument. However I do agree with you these PSI/SI related
parameters are still very important parameters. Any error of these PSI/SI
related parameters will lead to very serious quality problem.
>>>>> 
>>>>> Regarding the option you proposed, I am not favoring the second
approach since it doesn't solve the problem you raised and we already
clarified the parameter we are taking belong to 1st and 2nd prioirty in the
description before the format. I checked section 5.3.5 of TR 101.290, which
provide TS parameters in transmission system with "reduced SI data". I think
if we really want to take some new parameters, we like to choose to take
additional missing parameters in the 1st and 2nd priority of section 5.3.5,
which belong to "reduced SI data".
>>>>>> Subject: [xrblock] WGLC - 
>>>>>> draft-ietf-xrblock-rtcp-xr-decodability-
>> 02
>>>>>> 
>>>>>> 

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

---

From: Qin Wu <[email-masked]>
Date: Fri, 21 Dec 2012 10:16:41 +0800

Okay, fine with me. We will leave as it does and fix this by adding a few explaination texts.

Regards!
-Qin
----- Original Message ----- 
From: "Colin Perkins" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: "Qin Wu" <[email-masked]>; "Roni Even" <[email-masked]>; <[email-masked]>
Sent: Thursday, December 20, 2012 7:16 PM
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02

Colin

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

---

From: "Claire Bi(jiayu)" <[email-masked]>
Date: Fri, 21 Dec 2012 10:32:57 +0800

+1

And the title might be changed in case a new report block will be defined later.

Thanks and Regards,
Claire

From:  Colin Perkins 
Date:  2012-12-20  19:16:20 
To:  Romascanu, Dan (Dan) 
Cc:  [email-masked] 
Subject:  Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02 

-- 
Colin Perkins
http://csperkins.org/
_______________________________________________
xrblock mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/xrblock
__________ Information from ESET NOD32 Antivirus, version of virus signature database 7404 (20120821) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Fri, 21 Dec 2012 02:34:50 +0000

Hi,

I'm also okay with option (a). But It seems PCR_accuracy_error in second priority is not a PSI parameter. So I think it's better to add it.

Best Regards!
Rachel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Thursday, December 20, 2012 9:07 PM
To: 'Colin Perkins'; 'Romascanu, Dan (Dan)'
Cc: [email-masked]
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02

Hi,
This is also my view.
Roni

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: 20 December, 2012 1:16 PM
To: Romascanu, Dan (Dan)
Cc: Qin Wu; Roni Even; [email-masked]
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02

Colin

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