[AVTCORE] Adam Roach's No Objection on draft-ietf-payload-tsvcis-03: (with COMMENT)

Adam Roach has entered the following ballot position for
draft-ietf-payload-tsvcis-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-payload-tsvcis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the work the authors and working group put into this document.
I have a handful of comments of varying importance.

---------------------------------------------------------------------------

§2:

>  At the RTP transport layer, only the
>  speech coder related bits need to be considered and are conveyed in

Nit "...speech-coder-related bits..."

>  Depending on the bandwidth available
>  (and FEC requirements), a varying number of TSVCIS specific speech

Nit: "...TSVCIS-specific..."

---------------------------------------------------------------------------

§2:

>  Byte packing of TSVCIS speech data into packed parameters is
>  processed as per the following example:
>
>     Three-bit field: bits A, B, and C (A is MSB, C is LSB)
>     Five-bit field: bits D, E, F, G, and H (D is MSB, H is LSB)
>
>          MSB                                              LSB
>           0      1      2      3      4      5      6      7
>       +------+------+------+------+------+------+------+------+
>       |   H  |   G  |   F  |   E  |   D  |   C  |   B  |   A  |
>       +------+------+------+------+------+------+------+------+
>
>  This packing method places the three-bit field "first" in the lowest
>  bits followed by the next five-bit field.  Parameters may be split
>  between octets with the most significant bits in the earlier octet.

I've read over this example several times and I still can't make sense
of how I might go about implementing the intended packing. I can kind
of make out an implication that there are some TSVCIS parameters that
I'm supposed to... bit reverse into a byte? I think? But then we get
to the notion of "earlier" octets, with MSB (which one? TSVCIS or
RTP?) bits appearing in these "earlier" octets, and I'm at a near
complete loss. Once I get into concrete examples (e.g., Figure 2),
parameter MSBs appear to be in what I think most people would term "later"
bytes rather than "earlier" bytes.

This explanation really needs clarification, as I suspect that
readers will have several conflicting interpretations of what
this is supposed to mean.

---------------------------------------------------------------------------

§4.1:

>     tcmax: specifies the TSVCIS maximum value for TC supported or
>        desired ranging from 1 to 255.  If "tcmax" is not present, a
>        default value of 35 is used.
>
>        [EDITOR NOTE - the value of 35 is suggested based on a
>        preferred 8kbps TSVCIS coder bitrate.]

It's unclear to me whether this EDITOR NOTE is intended to be
left in the final document. It doesn't appear to be a note for
the RFC Editor (as it's not actionable from an editing perspective),
but neither does it look like the kind of thing that typically appears
in a published RFC. Please either remove this text, or make sure the intended
disposition of this text is clearly indicated.


_______________________________________________
Audio/Video Transport Core Maintenance
[email protected]
https://www.ietf.org/mailman/listinfo/avt