[MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT)

[Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-mmusic-dtls-sdp-28: 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-dtls-sdp/



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

Thanks for the quick answer to my DISCUSS.

I agree with the core assertion of EKR's DISCUSS: this document needs to be
aligned with JSEP. I think we're going to need a little additional work
figuring out which document needs to change where they disagree. In addition to
those areas he highlights in his DISCUSS, the following text is also in
conflict:

DTLS-SDP: "the offerer and answerer generate their own local 'tls-id' attribute
values, and the combination of both values identify the DTLS association."

JSEP: "If this is an answer, the tls-id value, if present, MUST be the same as
in the offer."

[Note: this does appear to be an issue in JSEP rather than this document]

I would think the long-form title of this document should include "TLS," to
reflect that it also contains TLS-related procedures.

Section 1: "...but currently there is no way..." will not age well once this is
an RFC. Suggest "...previously, there was no way..." or somesuch.

Section 2 uses RFC 2119 boilerplate, and then the very next sentence uses a
non-normative "must." I would strongly recommend moving to RFC 8174 boilerplate.

The conventional name for DTLS-SRTP is "DTLS-SRTP" -- please change replace
"SRTP-DTLS" with "DTLS-SRTP" everywhere it appears.

The last paragraph in section 5.4 starts with "NOTE" (which implementors
frequently read as non-normative) and then contains a normative statement.
Suggest removing "NOTE:"

Please expand the following acronyms upon first use and in the title;
see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

 - SDP - Session Description Protocol
 - DTLS - Datagram Transport Layer Security
 - TLS - Transport Layer Security
 - ICE - Interactive Connectivity Establishment
 - SCTP - Stream Control Transmission Protocol
 - SRTP - Secure Realtime Transport Protocol
 - UDPTL - UDP Transport Layer