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

Christer,

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.

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

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

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.

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.

Regards,

_____________
Roman Shpount

On Tue, Sep 5, 2017 at 4:22 AM, Christer Holmberg <
[email protected]> wrote:

>
> 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" <[email protected]>
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic