[MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-rfc4566bis-37: (with COMMENT)

[Alissa Cooper via Datatracker <[e-mail]>]

Alissa Cooper has entered the following ballot position for
draft-ietf-mmusic-rfc4566bis-37: 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-rfc4566bis/



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

Thank you for addressing my DISCUSS. Original COMMENT is below.

-----

Section 5.1:

Since both this document and RFC 4566 specify version 0 and this version makes
semantic and syntactic changes, does that mean the protocol versioning is
non-functional? Or if not, what kinds of changes would require a new version
number?

Section 7:

"Use of the "k=" line poses a significant security risk, since it
   conveys session encryption keys in the clear.  SDP MUST NOT be used
   to convey keying material, unless it can be guaranteed that the
   channel over which the SDP is delivered is both private and
   authenticated.  Moreover, the "k=" line provides no way to indicate
   or negotiate cryptographic key algorithms.  As it provides for only a
   single symmetric key, rather than separate keys for confidentiality
   and integrity, its utility is severely limited.  The "k=" line MUST
   NOT be used, as discussed in Section 5.12."

It's odd to me that this text was retained from RFC 4566 as-is, except for the
last sentence. I would have expected this to lead with something like 'Use of
the "k=" line is obsolete due to security risk.' And then perhaps some of the
rest of the text could remain by way of explanation why it was obsoleted.

Section 8.2.8:

"IANA may refer any registration to the IESG for review, and may
   request revisions to be made before a registration will be made."

This is trivially true and would be better left out, using RFC 8126 as the
definitive guidance instead.