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

Hi Adam,

Thanks for your review!

I see that you cleared your DISCUSS, but suggested some clarification
text. We will look into that.

>----------------------------------------------------------------------
>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]

Correct.

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

The issue is that the document doesn¹t really define the O/A procedures
for TLS. It simply adds the usage of the tls-id attribute to the existing
procedures defined elsewhere.

>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.

I will modify as suggested.

>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.

I will change the boilerplate.

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

I will modify as suggested.


>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:"

I will remove ³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

I¹ll fix that.

Thanks!

Regards,

Christer