Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) - All comments should now have been addressed

[Christer Holmberg <[e-mail]>]

Hi,

I have created a pull request, that removes the ufrag modification as a
trigger for a new DTLS association (in case there is no tls-id).

https://github.com/cdh4u/draft-dtls-sdp/pull/38


AFAIK, nobody has objected to change.

Regards,

Christer



On 07/09/17 08:16, "mmusic on behalf of Christer Holmberg"
<[e-mail] on behalf of [e-mail]>
wrote:

>Hi,
>
>>I think we should spell this out a little bit more.
>>
>>If tls-id was present in both offer and and answer, end points should
>>use the model
>>specified in this draft and only setup new DTLS association when either
>>of tls-id values changed.
>
>Yes.
>
>>If tls-id was not present in either offer or answer, end points should
>>the legacy mode defined in RFC 5763. In the legacy mode, new DTLS
>>association is established when:
>>
>>a. transport parameters changed in either offer or answer
>>b. fingerprints changed in either offer or answer
>>c. setup roles, negotiated as a result of offer/answer exchange, are
>>different from the setup roles before offer/answer exchange
>
>Yes.
>
>>When ICE is used, transport parameters, including c= and m=  SDP line
>>values, as well as values of ice-ufrag, ice-pwd, or other ICE related
>>SDP attributes have no effect on >when new DTLS association is
>>established,
>
>Currently, in the draft, the ufrag DOES have an impact, but the
>suggestion is to change that.
>
>>After ICE restart, new DTLS association is only established due to
>>changes in fingerprints in either offer or answer, or due to change in
>>negotiated setup role.
>
>Yes.
>
>>Note that new DTLS association is not established due to change in
>>tls-id in the offer if tls-id was not present in the answer and none of
>>the other legacy mode requirements >were satisfied.
>
>Yes.
>
>>Also note, that in the legacy mode, new DTLS association can be
>>established even if transport parameters, fingerprints and setup role in
>>the answer are identical to >previously received values from the same
>>end point, if transport parameters or fingerprints changed in the offer.
>
>Yes.
>
>So, the suggestion is to remove "ICE ufrag value" from the bullet list in
>section 4.
>
>Regards,
>
>Christer
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Hi,
>
>Some other issues have been raised, but I’d like to double check whether
>someone has any issue with the suggestion to remove ufrag change as a
>trigger for a new DTLS association?
>
>Based on the comments received so far, I don’t think anyone has objected.
>
>Regards,
>
>Christer
>
>
>
>
>
>
>
>
>
>
>On 31/08/17 09:10, "Christer Holmberg" <[e-mail]>
>wrote:
>
>>Hi,
>>
>>>>I have updated the PR. It should now address the IESG comments given by
>>>> Adam, Ekr, Alexey and Mirja.
>>>>
>>>> https://github.com/cdh4u/draft-dtls-sdp/pull/35
>>>>
>>>>
>>>> In the latest commit (#7):
>>>>
>>>> - Section 7 (Transport Protocol Considerations) was removed.
>>>> - Text regarding correlation of SDP and TLS connection was added to
>>>>the
>>>> Security Considerations (as requested by Mirja).
>>>>
>>>> Please let me know if there is something I¹ve forgot.
>>>
>>>The list of issues I posted to MMUSIC included the question about
>>>whether ufrag change requires a DTLS restart in the absence of a
>>>'tls-id'. There was a bit of discussion on that list which seemed to
>>>conclude that it should *not*. I believe the document needs to reflect
>>>this -- but I'd specifically ask the MMUSIC chairs whether they see
>>>consensus on this point first.
>>
>>
>>Correct, I forgot to mention that the PR yet does not address the ufrag
>>issue, waiting for a WG consensus.
>>
>>Note that there is currently a discussion in RTCWEB on whether a ufrag
>>change should trigger an ICE restart. But, as an ICE restart does not
>>automatically trigger a DTLS restart I assume it won’t affect
>>draft-dtls-sdp. Worth keeping in mind, though.
>>
>>
>>>On the topic of looking over your changes: it's still easier to read a
>>>text-form document than digging through XML source. Version numbers are
>>>free. I encourage you to drop a new version whenever you ask people to
>>>look at changes.
>>
>>I will submit a new version.
>>
>>Regards,
>>
>>Christer
>>
>
>_______________________________________________
>mmusic mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/mmusic