[MMUSIC] Spencer Dawkins' Discuss on draft-ietf-mmusic-rid-14: (with DISCUSS and COMMENT)

[Spencer Dawkins <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-ietf-mmusic-rid-14: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Please consider this to be an opportunity to explain something to an AD who
doesn't understand codecs super well ... so I doubt it will be hard to clear my
Discuss.

I'm not entirely comfortable that Section 8 isn't normative. Is the theory that
if (for example) I decide that my H.264 format parameter maps onto a
codec-independent parameter that you don't think it maps to, then you and I
probably would probably end up ignoring the rid and doing what we would do, if
one of us didn't support rids? If not, what's supposed to happen (normatively)?


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

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?