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

Hi Alexey,

Thank You for the review! Please see inline.

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

It refers to the text about hash functions in section 5 of 8122.

Perhaps I should say "hash functions" instead?

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

Martin T has written the following draft, which was recently WG adopted:

https://tools.ietf.org/id/draft-ietf-mmusic-sdp-uks-00.txt

However, we did not want to create a MISREF by referencing it in draft-dtls-sdp.

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

There is no single solution defined (it often depends on the attribute), and we normally try to specify such procedures, as they may vary depending on implementation, use-case etc.

Regards,

Christer