Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)
draft-ietf-mmusic-dtls-sdp-32

This falls well into the "This is outside my area of expertise" part of:
This ballot position may be interpreted as "This is outside my area of expertise or have no cycles", in that you exercise the ability to move a document forward on the basis of trust towards the other ADs.
:-)

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

Thank you for addressing my DISCUSS/comments.

Mostly a nit...

RFC4572 has been Obsoleted by RFC8122.  I think that this change in status implicitly means that all references to RFC4572 should now really refer to RFC8122.  I then don't think there's a need to explicitly Update the references from RFC4572 to RFC8122.

In the text Updating RFC5763 (10.2.1), the document says: "The reference to [RFC4572] is replaced with a reference to [RFC8122]."  I don't think that is necessary.

Also, the Update to RFC7345 (10.3.3) adds a Normative bibliographical entry to RFC8122, but no text is updated to point at that RFC.  I don't think this is necessary either.

S 5.1.
   media session immediately (see [RFC8122]).  Note that it is
   permissible to wait until the other side's fingerprint(s) has been
   received before establishing the connection; however, this may have
   undesirable latency effects.

I agree that it's permissible, but why would you do this? This does
not seem like helpful guidance.



S 10.
Please do something about the "NEW" constructions. I literally had to
pull these into ediff to know what had changed. That's not useful to
people. I'm not a fan of this construction in general, but at minimum
you need to explain what has changed.


S 9.
   Regardless of the
   previous existence of a DTLS association, the SDP 'setup' attribute
   MUST be included according to the rules defined in [RFC4145] and if
   ICE is used, ICE restart MUST be initiated.

What is the rationale for this rule?

I agree with Alexey's discuss, thanks for addressing it.

Thanks for addressing my discuss by simply removing section 7.1!

Old comments:

A couple mostly editorial comments:
- Probably a nit: In section 3.2 'must' is used while in section 3.3 'MUST' is used. I would assume that both sections should probably use the same.

- in sec 5.1: "Because of
   this, if an unordered transport is used for the DTLS association, a
   new transport (3-tuple) must be allocated by at least one of the
   endpoints so that DTLS packets can be de-multiplexed."
Why is this a 3-tuple (instead of a 5-tuple)? I guess you talk about the source address, source port, transport 3-tuple? May say this more explicitly.  Also the word of the use transport is confusing to me here because it's used for the transport protocol as well as for the transport 'connection' (if a connection-oriented transport protocol is used). Maybe s/new transport/new flow/? Moreover, there should probably be a 'MUST' here instead of 'must'!

- sec 5.2:"In addition, the offerer MUST insert in the
   offer an SDP 'tls-id' attribute with a unique attribute value."
Is that a MUST or rather a SHOULD? The rest of the text reads like this should be a SHOULD.

- Shouldn't this document cite RFC6347 normatively, e.g. here (sec 5.3):
"... the answerer MUST initiate a DTLS handshake by sending a
   DTLS ClientHello message towards the offerer."

- I would like to see more discussion about linkability based on the introduction of the "tls-id" in the security considerations section.