Subject: [MMUSIC] Alissa Cooper's Discuss on draft-ietf-mmusic-rfc4566bis-35: (with DISCUSS and COMMENT)

From: Alissa Cooper via Datatracker <[email-masked]>
Date: Tue, 28 May 2019 12:35:32 -0700

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

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

Section 8.2.8:

"In the RFC specifications that register new values for SDP "media",
   "proto", "fmt", "bwtype", "nettype", and "addrtype" parameters, the
   authors MUST include the following information for IANA to place in
   the appropriate registry:"

It doesn't look like all the fields that are listed after this text actually
appear in the registries. For some of these I don't see why the information
would be put into the registries (e.g., contact name, contact email address,
since those appear in the RFCs themselves). I think this needs to be clarified.

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

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.