Re: [MMUSIC] 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp

Hi,

>1. I would like to add justification for tls-id to the introduction and
>change:
>
>The SDP 'tls-id' attribute can also be used for negotiating a TLS
>connection, using the procedures
>in this document in conjunction with the procedures in [RFC5763] and
>[RFC8122].  The TLS specific considerations
>are described in Section 8.
>
>to:
>
>The SDP 'tls-id' attribute can be specified when negotiating a TLS
>connection, using the procedures in this
>document in conjunction with the procedures in [RFC5763] and [RFC8122].
>The unique combination of SDP 'tls-id¹
>attribute values can be used to identity the negotiate TLS connection.
>The unique value can be used, for example,
>within TLS protocol extensions to differentiate between multiple TLS
>connections and correlate those connections
>with specific offer/answer exchanges.  The TLS specific considerations
>are described in Section 8.

Ok, I can add that.

>2. In section 8 "mulitple" should be "multiple"

Will fix.

>3. I think in section 10 RFC Updates it would look better if the title of
>the section would be formatted like
>"10.2.1. Update to RFC 5763 Section 5: Establishing a Secure Channel² and
>then "OLD TEXT:/NEW TEXT:" sections without
>titles or section numbers. This way section numbers from previous RFC
>will not interrupt section flow of the current
>document. Also, "RFC 5763 Section 5" should reference to section 5 of RFC
>5763, not to the unexciting section number in the current draft.

How would you fix section 10.3.1, where the old text refers to multiple
sections (4., 4.1., etc)?

>4. I think there is a lot of confusion on the list about handling of
>ClientHello before the answer is received. Should we
>add the following text to section 5.2 or 5.4:
>
> If DTLS ClientHello message is received before the answer is received
>ClientHello message MUST be cached, but not
> processed. When the answer is received and if SDP 'setup' attribute in
>the answer is 'passive', then DTLS handshake
> MUST proceed by processing the cached DTLS ClientHello message. If SDP
>'setup' attribute in the answer is 'active¹,
> the cached DTLS ClientHello message must be discarded and offerer MUST
>initiate a new DTLS handshake by sending a
> DTLS ClientHello message towards the answerer.

Is that supported by DTLS? Shouldn¹t it be considered an error if you
receive a ClientHello that you shouldn¹t receive?

Also, has the WG community agreed on the procedure you suggest? This WGLC
is not about adding new functionality that has not been discussed.

Regards,

Christer

> NOTE: DTLS handshake cannot proceed before the answer is received since
>before this point remote address, ICE candidates,
> and ICE ufrag and password are not known and DTLS ServerHello message
>cannot be sent to the answerer. Since DTLS handshake
> does not proceed until server answer is received, unlike TLS, it is
>impossible to receive data over DTLS association
> before remote fingerprints are received and verified.

On Fri, Apr 21, 2017 at 9:08 AM, Flemming Andreasen
<fandreas@cisco.com> wrote:

Greetings MMUSIC

Following the recent changes in dtls-sdp, we are issuing a 1-week WGLC on
the changes from -22 to -24, i.e.:

https://www.ietf.org/rfcdiff?url1=draft-ietf-mmusic-dtls-sdp-22&url2=draft-
ietf-mmusic-dtls-sdp-24

If you have any comments on the changes, please provide those by Friday,
April 28. Comments should be sent to the document authors and the MMUSIC
WG list.

Thanks

-- Flemming (as MMUSIC co-chair)

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic