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

["MORTON JR., ALFRED C (AL)" <[e-mail]>]

Alan, 
Since you reviewed this draft, are you satisfied with the revisions?
Al

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[e-mail]]
> Sent: Wednesday, May 15, 2013 11:21 AM
> To: Qin Wu
> Cc: Benoit Claise; Alan Clark; [e-mail]; Dan (Dan); Shida Schubert;
> Huangyihong (Rachel); [e-mail]; [e-mail]; MORTON JR.,
> ALFRED C (AL)
> Subject: Re: 答复: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability
> 
> Hi Benoit,
> 
> what is the status of this? Can I progress this draft at this point?
> 
> Thanks,
> 
> Gonzalo
> 
> On 11/04/2013 5:14 AM, Qin Wu wrote:
> > 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?
> >
> > 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]>; <pm-
> [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).
> >>
> >>
> >>
> >