Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-summary-stat-03

[Glen Zorn <[e-mail]>]

On 12/12/2012 04:48 AM, Colin Perkins wrote:
> On 29 Nov 2012, at 13:55, Romascanu, Dan (Dan) wrote:
>> This is a Working Group Last Call for http://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-summary-stat-03.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.
>
> Section 3.2.2 of the draft cites draft-ietf-xrblock-rtcp-xr-discard and suggests that the gap discard rate is based on the value of DT=3 packets, but there was some discussion at IETF 85 about removing DT=3, since it’s redundant with the sum of DT=1 and DT=2. Was that discussion resolved?

In order for this metric to be meaningful, exactly one of the following 
conditions must hold:

  * the packet contains a block with DT=3

OR

  * the packet contains 2 blocks with DT=1 and DT=2, respectively

If we are going to force the latter in this case, is there any argument 
for keeping DT=3 in the other draft?

Personally, if we include DT=3 in draft-ietf-xrblock-rtcp-xr-discard, I 
would like the flexibility to use it here - saves space, etc.

>
> Otherwise, I just had some minor comments:
>
> - Section 3.2 references draft-ietf-xrblock-rtcp-xr-discard, which is not a burst/gap metric draft, in the context of burst/gap metrics.

I believe that the reference is in the context of /discards/, not 
burst/gap metrics and is completely appropriate.  If you found it 
confusing, can you suggest a better wording?

> This is confusing, and it would help to separate the discussion of the burst/gap discard metrics from the reference to the non-burst/gap discard draft.
>
> - Section 4.1.2: the term “derivation frame” is unclear.

Maybe a reference would help?

>
> - Section 5.2 is insufficient, and needs to be updated in a manner analogous to the other recent RTCP XR blocks.

Can you be a bit more specific?

>