Re: [pm-dir] 答复: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability

[Benoit Claise <[e-mail]>]

Hi Qin,
> Hi,Benoit:
> As Alan observed in PM-DIR review, this draft does not define new metrics but refers to metrics that are
> clearly defined in a normative reference.
> I think we can skip RFC6390 template usage just like PDV draft(RFC6798) did, can't we?
I finally had to the time to review this document, which is on the IESG 
telechat on Thursday.
Basically, Alan is right, the answer is "yes, you can skip RFC6390"
And I'm balloting "no objection".
For once, I don't have any DISCUSS on your document. I thought I would 
let you know. ;-)

Regards, Benoit
>
> Regards!
> -Qin
> -----邮件原件-----
> 发件人: Benoit Claise [mailto:[e-mail]]
> 发送时间: 2013年4月10日 21:53
> 收件人: Qin Wu
> 抄送: Alan Clark; Gonzalo Camarillo; [e-mail]; Dan (Dan); Shida Schubert; Huangyihong (Rachel); [e-mail]; [e-mail]; Al Morton
> 主题: Re: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability
>
> Hi Qin,
>
> And don't forget the RFC 6390 template usage.
>
> Regards, Benoit
>> Hi, Alan:
>> Thank for your valuable comments.
>> We have updated the draft to incorporate your comments in the new version (-v11).
>> The diff is:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-decodability-11
>> Please also see my reply below.
>>
>> Regards!
>> -Qin
>> ----- Original Message -----
>> From: "Alan Clark" <[e-mail]>
>> To: "Gonzalo Camarillo" <[e-mail]>; <[e-mail]>; "Benoit Claise" <[e-mail]>; "Dan (Dan)" <[e-mail]>; "Shida Schubert" <[e-mail]>; <[e-mail]>; <[e-mail]>; <[e-mail]>; <[e-mail]>; "Al Morton" <[e-mail]>
>> Sent: Saturday, April 06, 2013 3:10 AM
>> Subject: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability
>>
>>
>> There are quite a few issues with the draft - I can re-review as soon as
>> these are addressed.
>>
>> Alan Clark
>>
>>
>>
>> A. General Comments
>>    
>> This draft does not define new metrics but refers to metrics that are
>> clearly defined in a normative reference.  The normative reference (ETSI
>> TR101290) predates RFC6390 however does contain a fairly clear description
>> of the metrics with explanation of their usage. It is not recommended that
>> this draft redefines the metrics in RFC6390 template form
>>
>> [Qin]: Exactly.
>>
>> however there is
>> considerable scope for improvement in the clarity of definition of how these
>> metrics are used.
>>
>> [Qin]: Agree.
>>    
>> B. Applicability Section
>>    
>> 1.4 Applicability
>> Metrics only measure transport stream quality not content stream quality.
>> Also the metrics are not defined in this draft but are encodings of the
>> metrics defined in ETSI TS 101290.
>>    
>> Suggest
>>    
>> ³This block type allows a counts of MPEG Transport Stream quality metrics
>> that are measured in accordance with ETSI TR 101290 [ETSI] to be reported by
>> an endpoint.  These metrics are useful for identifying bitstream
>> packetization and transport stream encoding problems that may affect the
>> user¹s perception of a video service delivered over RTP.²
>>
>> [Qin]: Okay. Your proposed text have been incorporated in (-v11).
>>    
>> C. Metrics Definitions
>>    
>> C.1 General
>>    
>> For clarity the draft should preface the metrics definitions with a general
>> explanation of how these metrics relate to ETSI TR101290. TR101290 generally
>> defines error events and this draft contains counts of those metrics.
>>
>>    
>> If there are any ³edge² cases where a problem in one measurement interval
>> would be reflected in the count in the next measurement interval then this
>> should be articulated in the general description and also in the specific
>> metric.  For example, a sync byte error is defined as multiple consecutive
>> errored sync bytes and if this was reported in an interval it may have
>> occurred at the end of the preceding interval or at some time during the
>> present interval - hence the description should state that the count may
>> reflect a problem in the current or previous interval. This would also be
>> the case for PCR errors and even continuity count errors.
>>
>> [Qin]: Okay, I have added some text in the 2nd paragraph of section 3
>> and incorporated your suggested text in (v-11).
>>    
>> C.2  Sequence numbers
>>    
>> begin_seq and end_seq
>>    
>> These definitions simply say ³As defined inS² which requires the reader to
>> refer to another document. It is good practice to at least mention what the
>> definition refers to and then to include a reference that contains the
>> normative definition.
>>    
>> SoS..
>>    
>> ³begin_seq: 16 bits
>>
>> The RTP sequence number corresponding to the start of the measurement
>> period, as defined in Section 4.1 of RFC 3611²
>>
>> [Qin]: Fixed in (-v11).
>>    
>> C.3 Metrics definitions
>> The metrics definitions should contain a firmer statement of what is being
>> measured and, if the normative definition is in another standard, then
>> clearly state ³as defined in Section X.Y of NNNNN². This applies to all the
>> metrics definitions and the example below can be used as a template for
>>    
>> For example
>>    
>> Existing language S..
>>    
>> TS_sync_loss_count: 32 bits
>>    
>> Number of TS_sync_loss errors in the above sequence number interval.  It is
>> calculated based on the occurrence of errors for "TS_sync_loss"parameter
>> defined in the section 5.2.1 of [ETSI] (Also see section 5.5.1 of [ETSI]).
>>    
>> This is very vague language and it is unclear why the ³Also see² reference
>> is there.  A better approach is:
>>    
>> Replacement language (use this format for each of the metrics)
>>    
>> TS_sync_loss_count: 32 bits
>>    
>> A count of the number of TS_sync_loss errors that occurred in the above
>> sequence number interval.  A TS_sync_loss error occurs when there are two or
>> more consecutive incorrect sync bytes within the MPEG TS stream, as defined
>> in section 5.2.1 of [ETSI]. This parameter may be used as part of a Service
>> Availability calculation, as defined in section 5.5.1 of [ETSI].
>>
>> [Qin]: Fixed in (-v11).
>>    
>> C.4 Service Availability
>>    
>> Following on from the previous comment,  section 5.5.1 of TR101290 describes
>> a service availability error as a combination of TS_sync_loss, PAT_error and
>> PMT_error whereas draft-ietf-xrblock-rtcp-xr-decodability-10 does not
>> contain the PAT and PMT error metrics.  The resolution for this would either
>> be to remove the reference to 5.5.1 or to add the metrics required to
>> calculate the service availability.
>>    
>> [Qin]: Agree. I prefer to remove the reference to 5.5.1 since there was consensus in the past WGLC to this draft
>> that having a second report block later to cover the other parameters and get inline with concept of RFC6792
>> and letting this draft focus on PSI indpendent parameter reporting.
>> See details for the WGLC discussion in the following link:
>> http://www.ietf.org/mail-archive/web/xrblock/current/msg01032.html
>>
>> It is recommended that PAT_error , PAT_error_2,  PMT_error and PMT_error_2
>> be included as metrics as these ³are² generally present in MPEG Transport
>> streams and errors within these can prevent correct decoding of the stream.
>>    
>> C.5 PCR_error_count
>>    
>> PCR_error_count is defined twice - the second of these should be
>> PCR_accuracy_error_count
>>    
>>    [Qin]: Good catch and have fixed in (-v11).
>>
>>
>>
>
>