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

[Gonzalo Camarillo <[e-mail]>]

Thanks for your note, Benoit :-)

Gonzalo

On 24/05/2013 6:06 PM, Benoit Claise wrote:
> 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).
>>>
>>>
>>>
>>
>>
>