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

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 17 Apr 2018 12:46:30 -0700

Benjamin Kaduk 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:
----------------------------------------------------------------------

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?