RTP Payload Format Restrictions
draft-ietf-mmusic-rid-15

The document is generally fine, but I have a few minor comments:

In the ABNF:

   rid-width-param   = "max-width" [ "=" int-param-val ]

   rid-height-param  = "max-height" [ "=" int-param-val ]

   rid-fps-param     = "max-fps" [ "=" int-param-val ]

   rid-fs-param      = "max-fs" [ "=" int-param-val ]

   rid-br-param      = "max-br" [ "=" int-param-val ]

   rid-pps-param     = "max-pps" [ "=" int-param-val ]

   rid-bpp-param     = "max-bpp" [ "=" float-param-val ]


Maybe I missed that, but what is the meaning of "max-width" (and others) with no value?
Or to rephrase that: are the values really optional?


12.2.  Registry for RID-Level Parameters

   New restriction registrations are accepted according to the
   "Specification Required" policy of [RFC5226], provided that the
   specification includes the following information:

   o  contact name, email address, and telephone number

Considering the European GDPR directive is going to come into force in May: is there any legitimate use for collecting phone numbers for this registry?

   o  restriction name (as it will appear in SDP)

   o  long-form restriction name in English

   o  whether the restriction value is subject to the charset attribute

   o  an explanation of the purpose of the restriction

   o  a specification of appropriate attribute values for this
      restriction

   o  an ABNF definition of the restriction

   The initial set of "a=rid" restriction names, with definitions in
   Section 5 of this document, is given below:

     RID Parameter Name           Reference
     ------------------           ---------
     max-width                    [RFCXXXX]
     max-height                   [RFCXXXX]
     max-fps                      [RFCXXXX]
     max-fs                       [RFCXXXX]
     max-br                       [RFCXXXX]
     max-pps                      [RFCXXXX]
     max-bpp                      [RFCXXXX]
     depend                       [RFCXXXX]

And now you just registered them without following your registration template that you've specified above ;-).

The Gen-ART reviewer made some useful suggestions. Please take a look. https://datatracker.ietf.org/doc/review-ietf-mmusic-rid-14-genart-lc-sparks-2018-02-27/

Presumably I'm just being dense, but from perusing the formal grammar
I couldn't decide if it's allowed to have both PT and parameter
restrictions applied on the same rid-id.


Section 5

Similarly (me being dense), I'm a bit confused at the relationship between max-fps and max-pps
-- aren't there encodings that can send update frames that do not include the full pixel density of a frame?


Section 6.2.2

   4.  If the "direction" field is "recv", The answerer ensures that
       "a=rid" restrictions are supported.  In the case of an
       unsupported restriction, the "a=rid" line is discarded.

"that "a=rid" restrictions are supported" reads like a feature test
for being able to parse a=rid at all, but the context suggests that
this is intended to refer to the Section-5 restriction stanzas that
appear on an a=rid line.


Section 8

I thought I remembered something going by to the effect of s/non-empty union/non-empty intersection/
but didn't find it in a quick search, so dropping a note just in case.

Section 8.2

   The following codec format parameters correspond to restrictions on
   receiver capabilities, and never indicate sending restrictions.

Maybe "The codec format parameters covered in the following
subsections [...]"?


Section 10

Should
    float-param-val   = 1*DIGIT "." 1*DIGIT
have the last entry be 1*4DIGIT to catch the "four digits after the
decimal place" requirement of max-bpp, or are we leaving the float-param-value
grammar less restricted in case of potential future use?

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)

(Meta-comment - thanks for helping me understand what's going on in Section 8, when discussing my previous Discuss)

If "rid" actually means something, it might be nice to expand it in the Abstract and Introduction. After the first couple of pages, I was guessing that it means something like "RTP Stream Identifier", based on a quick scan of https://tools.ietf.org/html/draft-ietf-avtext-rid-09, but that draft doesn't ever expand "rid" or use "rid" in the text, so then I think I'm wrong, because this draft also uses "rid-id", and I'm guessing that's probably not "RTP Stream Identifier Identifier". By the time I get down to Section 5, I decide it means "Restriction Identifier", but then I'm not any happier that I'm guessing "rid-id" means "Restriction Identifier Identifier" :-)

I'm confused by the SHOULD NOT in 

  o  max-fps, for frame rate in frames per second.  For encoders that
      do not use a fixed framerate for encoding, this value should
      restrict the minimum amount of time between frames: the time
      between any two consecutive frames SHOULD NOT be less than 1/max-
      fps seconds.

The related description of max-pps, also uses a SHOULD, but explains why excursions outside this value are permissible.

(I'm also confused by "this value should restrict the minimum amount of time between frames" - I saw that you're using RFC 8174 for keywords, but is this just saying "this value restricts the minimum amount of time between frames", or something else?)

I note that 8.1 and 8.2 both include something like 

   Both
   correspond to restrictions on receiver capabilities, and never
   indicate sending restrictions.

Is that true for all format parameters, for all codecs? If so, perhaps that should be explicit, in one of the normative sections (in which case, it wouldn't be useful here). If not, are implementations supposed to know what to do?