Re: [xrblock] 2nd WGLC for draft-ietf-xrblock-rtcp-xr-qoe

Hi Qin,
It looks OK to me
Roni

> -----Original Message-----
> From: Qin Wu [mailto:bill.wu@huawei.com]
> Sent: 23 August, 2013 4:26 AM
> To: Roni Even; 'Romascanu, Dan (Dan)'; xrblock@ietf.org
> Subject: RE: [xrblock] 2nd WGLC for draft-ietf-xrblock-rtcp-xr-qoe
> 
> Hi,Roni:
> Thank for your followup comments, see my reply inline below.
> 
> Regards!
> -Qin
> 
> -----Original Message-----
> From: Roni Even [mailto:ron.even.tlv@gmail.com]
> Sent: Thursday, August 22, 2013 9:55 PM
> To: Qin Wu; 'Romascanu, Dan (Dan)'; xrblock@ietf.org
> Subject: RE: [xrblock] 2nd WGLC for draft-ietf-xrblock-rtcp-xr-qoe
> 
> Hi Qin,
> See inline
> Roni
> 
> > -----Original Message-----
> > From: Qin Wu [mailto:bill.wu@huawei.com]
> > Sent: 22 August, 2013 3:02 PM
> > To: Roni Even; 'Romascanu, Dan (Dan)'; xrblock@ietf.org
> > Subject: RE: [xrblock] 2nd WGLC for draft-ietf-xrblock-rtcp-xr-qoe
> >
> > Hi,Roni:
> > Thank for your valuable comments to the update. Please see my rely
> > inline below.
> >
> > Regards!
> > -Qin
> >
> > -----Original Message-----
> > From: xrblock-bounces@ietf.org [mailto:xrblock-bounces@ietf.org] On
> > Behalf Of Roni Even
> > Sent: Thursday, August 22, 2013 6:38 PM
> > To: 'Romascanu, Dan (Dan)'; xrblock@ietf.org
> > Subject: Re: [xrblock] 2nd WGLC for draft-ietf-xrblock-rtcp-xr-qoe
> >
> > Hi,
> > I reviewed the document looks OK. Two editorial comments
> >
> > 1. In section 4.1, mosref has three values l, m, h yet the text " the
> syntax
> > element "mosref" is referred to the media resolution  relative
> > reference (e.g., Narrowband (3.4kHz) Speech and Standard  Definition
> > (SD) Resolution Video with lower resolution, Wideband
> >    (7kHz) Speech and High Definition (HD) Resolution Video with higher
> > resolution).  MOS scores reported in the mos metrics block might vary
> > with the MoS reference; For example, MOS values for narrowband,
> >    wideband codecs occupy the same range but SHOULD be reported in
> > different value.  For video application, MoS scores for SD resolution,
> > HD resolution video also occupy the same ranges and
> >    SHOULD be reported in different value."
> > I think a better example and division should be for audio l = narrow
> > band
> > 3.5 Khz, m should be wideband 7 Khz and h should be super wideband or
> > higher
> > >14kHz. For video l should be CIF or lower and h should  be 1080HD or
> > >higher
> > and m should be betwee CIF and 1080HD.
> >
> > [Qin]: Good suggestion. Yes, in the syntax of mosref, we distinguish
> mosref
> > with 3 vlaues so does text description.
> > Here is my proposed change:
> > OLD TEXT:
> > "
> > The syntax element "mosref" is referred to the media resolution
> > relative reference (e.g., Narrowband (3.4kHz) Speech and Standard
> > Definition (SD) Resolution Video with lower resolution, Wideband
> >    (7kHz) Speech and High Definition (HD) Resolution Video with higher
> > resolution).  MOS scores reported in the mos metrics block might vary
> > with the MoS reference; For example, MOS values for narrowband,
> >    wideband codecs occupy the same range but SHOULD be reported in
> > different value.  For video application, MoS scores for SD resolution,
> > HD resolution video also occupy the same ranges and
> >    SHOULD be reported in different value.
> > "
> > NEW TEXT:
> > "
> >    The syntax element "mosref" is referred to the media resolution
> >    relative reference and has three valules 'l','m','h'.(e.g.,
> > Narrowband
> > (3.4kHz) Speech and Standard
> >    Definition (SD) Resolution Video have 'l' resolution, Super Wideband
> >    (>14kHz) Speech and High Definition (HD) Resolution Video have 'h'
> >    Resolution,Wideband speech(7khz) and Video with resolution between
> > SD and HD has 'm' resolution).
> >     MOS scores reported in the mos metrics block might vary
> >    with the MoS reference; For example, MOS values for narrowband,
> >    wideband,super wideband codecs occupy the same range but SHOULD be
> > reported in
> >    different value.  For video application, MoS scores for SD
> >    resolution, HD resolution video also occupy the same ranges and
> >    SHOULD be reported in different value.
> 
> 
> [Roni Even]  I have no problem with having SD as 'l' but it should say SD
or
> lower. And for 'h' HD or higher.
> For audio 'h' should be super wideband or higher since the next term is
> fullband (20Khz)
> 
> [Qin]: Okay, I agree, here is the proposed new change:
> OLD TEXT:
>  "
>  The syntax element "mosref" is referred to the media resolution  relative
> reference (e.g., Narrowband (3.4kHz) Speech and Standard  Definition (SD)
> Resolution Video with lower resolution, Wideband
>     (7kHz) Speech and High Definition (HD) Resolution Video with higher
> resolution).  MOS scores reported in the mos metrics block might vary with
> the MoS reference; For example, MOS values for narrowband,
>     wideband codecs occupy the same range but SHOULD be reported in
> different value.  For video application, MoS scores for SD resolution, HD
> resolution video also occupy the same ranges and
>     SHOULD be reported in different value.
>  "
> NEW TEXT:
> "
>    The syntax element "mosref" is referred to the media resolution
>     relative reference and has three valules 'l','m','h'.(e.g., Narrowband
>  (3.4kHz) Speech and Standard
>     Definition (SD) or lower Resolution Video have 'l' resolution, Super
> Wideband
>     (>14kHz) Speech or higher and High Definition (HD) or higher
Resolution
> Video have 'h'
>     Resolution, Wideband speech(7khz) and Video with resolution between SD
>      and HD has 'm' resolution).
>      MOS scores reported in the mos metrics block might vary
>     with the MoS reference; For example, MOS values for narrowband,
>     wideband,super wideband codecs occupy the same range but SHOULD be
> reported in
>     different value.  For video application, MoS scores for SD
>     resolution, HD resolution video also occupy the same ranges and
>     SHOULD be reported in different value.
> "
> 
> > "
> >
> > 2.  section 4.1 defines mapentry =  "calg:" 1*5 DIGIT ["/" direction].
> From
> > section 4.2 I got the impression that the range [4096-4351] is not to
> > be
> used
> > as valid value. I think it should be clarified in section 4.1 what are
> > the
> valid
> > range.
> >
> > [Qin]:Good point, we can add some annotation to mapentry syntax in the
> > section 4.1 as follows:
> > OLD TEXT:
> > "
> > mapentry =  "calg:" 1*5 DIGIT ["/" direction] "
> > NEW TEXT:
> > "
> > mapentry =  "calg:" 1*5 DIGIT ["/" direction];Value 0~4095 are valid "
> [Roni Even] What about values higher than 4351, since it is 1-5 digits,
are they
> valid?
> 
> [Qin]: Good point, how about the following change:
> "
> mapentry =  "calg:" 1*5 DIGIT ["/" direction];Value other than 4095~4351
are
> valid "
> >
> > Thanks
> > Roni
> >
> >
> >
> > > -----Original Message-----
> > > From: xrblock-bounces@ietf.org [mailto:xrblock-bounces@ietf.org] On
> > > Behalf Of Romascanu, Dan (Dan)
> > > Sent: 21 August, 2013 4:36 PM
> > > To: xrblock@ietf.org
> > > Subject: [xrblock] 2nd WGLC for draft-ietf-xrblock-rtcp-xr-qoe
> > >
> > > Hi,
> > >
> > > This is the second WGLC for the Internet-Draft 'RTP Control Protocol
> > (RTCP)
> > > Extended Report (XR) Blocks for MoS Metric Reporting' previously
> > > known as 'RTP Control Protocol (RTCP) Extended Report (XR) Blocks
> > > for QoE Metric Reporting'. Please send your comments, questions, and
> > > concerns to the WG list before Wednesday 9/4. If you have no
> > > comments or questions and you believe that this document is ready
> > > for submission to the IESG for consideration as a Proposed Standard,
> > > please send a
> > message stating this.
> > >
> > > The latest version of the document can be retrieved from
> > > http://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-qoe-10.txt.
> > >
> > > 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