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

From: Alexey Melnikov <[email-masked]>
Date: Mon, 14 Aug 2017 03:09:53 -0700

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.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 14 Aug 2017 17:15:34 +0000

Hi Alexey,

Thank You for the review! Please see inline.

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

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

Perhaps I should say "hash functions" instead?

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

> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 14 Aug 2017 19:30:33 +0100

Hi Christer,

> Thank You for the review! Please see inline.

Yes, these are different things :-).

I suggest you add an Informative reference to this draft. Such reference
will not delay publication, but might still be useful to readers.

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

Ok. I was hoping there was a single prescribed behaviour in this case.

Best Regards,
Alexey