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

I have several comments regarding the document:

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.

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

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.

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

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.


Regards,


_____________
Roman Shpount

On Fri, Apr 21, 2017 at 9:08 AM, Flemming Andreasen <[email protected]>
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
> [email protected]
> https://www.ietf.org/mailman/listinfo/mmusic
>

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic