Subject: [MMUSIC] Eric Rescorla's No Objection on draft-ietf-mmusic-rid-14: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Apr 2018 12:56:24 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-mmusic-rid-14: 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-mmusic-rid/

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

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3309

It took me a while to figure out how this works. I think I would
instead say something like "This document makes it possible to specify
multiple media profiles in a given session, e.g., for different
sending rates for simulcast. Each profile is associated with one or
more payload type and identified by a rid value which is carried in
the RTP payload [REF], thus allowing the receiver to demultiplex
different profiles (and hence sending streams within the session)"

COMMENTS
>      payload format and the associated SDP media description.  The SDP
>      rtpmap and/or fmtp attributes are used, for a given PT, to describe
>      the properties of the media that is carried in the RTP payload.
>
>      Recent advances in standards have given rise to rich multimedia
>      applications requiring support for multiple RTP Streams within a RTP

Nit; "an RTP"

>      To expand on these points: [RFC3550] assigns 7 bits for the PT in the
>      RTP header.  However, the assignment of static mapping of RTP payload
>      type numbers to payload formats and multiplexing of RTP with other
>      protocols (such as RTCP) could result in a limited number of payload
>      type numbers available for application usage.  In scenarios where the
>      number of possible RTP payload configurations exceed the available PT

Nit: exceeds

>      a=rid:<rid-id> <direction> [pt=<fmt-list>;]<restriction>=<value>...
>
>      An "a=rid" SDP media attribute specifies restrictions defining a
>      unique RTP payload configuration identified via the "rid-id" field.
>      This value binds the restriction to the RTP Stream identified by its
>      RTP Stream Identifier SDES item [I-D.ietf-avtext-rid].  To be clear,

SDES is kind of an overloaded term at this point.

>      the RtpStreamId SDES item described in [I-D.ietf-avtext-rid].  Such
>      implementations MUST send it for all streams in an SDP media
>      description ("m=") that have "a=rid" lines remaining after applying
>      the rules in Section 6 and its subsections.
>
>      Implementations that use the "a=rid" parameter in SDP and that make

This is pretty hard to follow. Let me see if I understand this.  You
have a bunch of PTs and then each RID further restricts the parameters
for the set of PTs that it applies to?

>      media section ("m-line"); they do not necessarily need to be unique
>      within an entire RTP session.  In traditional usage, each media
>      section is sent on its own unique 5-tuple, which provides an
>      unambiguous scope.  Similarly, when using BUNDLE
>      [I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP
>      streams uniquely to a single media description.

So you send both MID and RID in this case? That doesn't seem ideal,
but perhaps it should be stated.

>
>      1.  The answerer ensures that the "a=rid" line is syntactically well
>          formed.  In the case of a syntax error, the "a=rid" line is
>          discarded.
>
>      2.  Extract the rid-id from the "a=rid" line and verify its

This is in the imperative mode whereas the other steps are
descriptive. You probably want them to match

>      1.  The value of the "direction" field is reversed: "send" is changed
>          to "recv", and "recv" is changed to "send".
>
>      2.  The answerer MAY choose to modify specific "a=rid" restriction
>          values in the answer SDP.  In such a case, the modified value
>          MUST be more restricted than the ones specified in the offer.

restrictive?

>          the offer, then the offerer SHALL discard the "a=rid" line.
>
>      3.  If the restrictions have been changed between the offer and the
>          answer, the offerer MUST ensure that the modifications can be
>          supported; if they cannot, the offerer SHALL discard the "a=rid"
>          line.

Should you be checking for "more restricted"

>          comparison necessarily requires an understanding of the meaning
>          of codec parameters, rather than a rote byte-wise comparison of
>          their values.
>
>      6.  If the "a=rid" line contains a "pt=", the offerer verifies that
>          the attribute values provided in the "a=rid" attributes are

Why did you break this out. It seems to just be an addition (5)