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