[MMUSIC] Spencer Dawkins' No Objection on draft-ietf-mmusic-rid-14: (with COMMENT)

[Spencer Dawkins <[e-mail]>]

Spencer Dawkins 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:
----------------------------------------------------------------------

(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?