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 intend to merge the PR today, and submit a new version of the draft.

Regards,

Christer


On 07/09/17 16:28, "Christer Holmberg" <[e-mail]>
wrote:

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