Re: [xrblock] [Gen-art] Review: draft-ietf-xrblock-rtcp-xr-qoe-12

[Gonzalo Camarillo <[e-mail]>]

Hi Joel,

thanks for your review. I am responding to this email because the
address of the XRBLOCK list had a typo in the original email (I have
fixed it in this one). This message should make it to the list.

Authors, please look into this.

Cheers,

Gonzalo

On 12/11/2013 1:06 PM, Joel M. Halpern wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-xrblock-rtcp-xr-qoe-12
>     RTP Control Protocol (RTCP) Extended Report (XR) Blocks for
>                        MOS Metric Reporting
> Reviewer: Joel M. Halpern
> Review Date: 12-November-2013
> IETF LC End Date: 27-November-2013
> IESG Telechat date: N/A
> 
> Summary: This document is nearly ready for publication as a Proposed
> Standard RFC
> 
> Major issues:
> 
> Moderate issues:
>     In section 3.2.2 on Multi-Channel audio per SSRC Segment, the format
> description for the Calculation Algorithm ID (CAID) reads:
> "The 8-bit ID is the local identifier of this segment in the range
> 1-255 inclusive."  I am pretty sure this is supposed to be an algorithm
> ID, not a segment index?
> 
>     The text in section 4.1 indicates that the number after "calg:" in
> the mapentry of the calgextmap is used as the ID in the CAID of the
> xrblock.  The packet format only allows 8 bits of value.  So why does
> the SDP format allow up to 5 digits?  Also, is there some reason that
> the special values 4095-4351 (in section 4.1) or 4096-4351 (in section
> 4.2) are used rather than say equally invalid 512 through some
> appropriate upper bound still in 3 digits?
> 
> Minor issues:
>     Please ensure that all acronyms are expanded on first use.  For
> example, QoE is not expanded.
> 
>     The notes in B.3 indicate that mostype was to be removed from the
> SDP grammar.  But it is still defined.  And section 4.2 still mentions
> it, even though it does not get referenced by the message format. Please
> finish removing it.  (also "most type")
> 
> Nits/editorial comments: