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

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)

> -----Original Message-----
> From: Qin Wu [mailto:bill.wu@huawei.com]
> Sent: Thursday, December 20, 2012 12:03 PM
> To: Romascanu, Dan (Dan); Roni Even; xrblock@ietf.org
> Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02
> 
> 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
> ----- Original Message -----
> From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
> To: "Qin Wu" <bill.wu@huawei.com>; "Roni Even" <ron.even.tlv@gmail.com>;
> <xrblock@ietf.org>
> Sent: Thursday, December 20, 2012 5:36 PM
> Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02
> 
> 
> > (speaking as a contributor)
> >
> > Solution (a) seems to me closer to the 'philosophy' we adopted with
> the modular monitoring architecture.
> >
> > Regards,
> >
> > Dan
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Qin Wu [mailto:bill.wu@huawei.com]
> >> Sent: Thursday, December 20, 2012 11:29 AM
> >> To: Roni Even; Romascanu, Dan (Dan); xrblock@ietf.org
> >> Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-
> decodability-02
> >>
> >> 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
> >> ----- Original Message -----
> >> From: "Roni Even" <ron.even.tlv@gmail.com>
> >> To: "'Qin Wu'" <bill.wu@huawei.com>; "'Romascanu, Dan (Dan)'"
> >> <dromasca@avaya.com>; <xrblock@ietf.org>
> >> Sent: Thursday, December 20, 2012 4:44 PM
> >> 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
> >> >
> >> > -----Original Message-----
> >> > From: Qin Wu [mailto:bill.wu@huawei.com]
> >> > Sent: 20 December, 2012 3:57 AM
> >> > To: Roni Even; 'Romascanu, Dan (Dan)'; xrblock@ietf.org
> >> > 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".
> >> >
> >> > Otherwise we prefer to leave as it is.
> >> >
> >> > Regards!
> >> > -Qin
> >> > ----- Original Message -----
> >> > From: "Roni Even" <ron.even.tlv@gmail.com>
> >> > To: "'Romascanu, Dan (Dan)'" <dromasca@avaya.com>;
> <xrblock@ietf.org>
> >> > Sent: Wednesday, December 19, 2012 9:13 PM
> >> > Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-
> decodability-
> >> 02
> >> >
> >> >
> >> >> 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: xrblock-bounces@ietf.org [mailto:xrblock-bounces@ietf.org]
> On
> >> Behalf
> >> >> Of Romascanu, Dan (Dan)
> >> >> Sent: 29 November, 2012 2:48 PM
> >> >> To: xrblock@ietf.org
> >> >> Subject: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-
> 02
> >> >>
> >> >>
> >> >> 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.
> >> >>
> >> >> Thanks and Regards,
> >> >>
> >> >> Dan
> >> >>
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> xrblock mailing list
> >> >> xrblock@ietf.org
> >> >> https://www.ietf.org/mailman/listinfo/xrblock
> >> >>
> >> >> _______________________________________________
> >> >> xrblock mailing list
> >> >> xrblock@ietf.org
> >> >> https://www.ietf.org/mailman/listinfo/xrblock
> >> >>
> >> >
> > _______________________________________________
> > xrblock mailing list
> > xrblock@ietf.org
> > https://www.ietf.org/mailman/listinfo/xrblock