Alexey Melnikov's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT)

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



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

This is a fine document, but I have one [hopefully easy to answer] question and
a couple of other minor ones:

In Section 5.1.  General

   Endpoints MUST support the cipher suites as defined in [RFC8122].

I don't see any ciphers specified in that RFC. Can you clarify what you mean?


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


8.  TLS Considerations

   NOTE: Even though the SDP 'connection' attribute can be used to
   indicate whether a new TLS connection is to be established, the
   unique combination of SDP 'tls-id' attribute values can be used to
   identity a TLS connection.  The unique value can be used e.g., within
   TLS protocol extensions to differentiate between multiple TLS
   connections and correlate those connections with specific offer/
   answer exchanges.

Are any such extensions defined or in the process of being standardized?

   If an offerer or answerer receives an offer/answer with conflicting
   attribute values, the offerer/answerer MUST process the offer/answer
   as misformed.

I think a pointer to document and section where such handling is specified would be useful here.