Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) - All comments should now have been addressed
Roman Shpount <rshpount@turbobridge.com> Wed, 06 September 2017 22:05 UTC
Return-Path: <rshpount@turbobridge.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD55132C23 for <mmusic@ietfa.amsl.com>; Wed, 6 Sep 2017 15:05:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level:
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=turbobridge.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcgDRyWJGwl9 for <mmusic@ietfa.amsl.com>; Wed, 6 Sep 2017 15:05:04 -0700 (PDT)
Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5AC126B6E for <mmusic@ietf.org>; Wed, 6 Sep 2017 15:05:04 -0700 (PDT)
Received: by mail-pf0-x22a.google.com with SMTP id e1so819605pfk.1 for <mmusic@ietf.org>; Wed, 06 Sep 2017 15:05:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=turbobridge.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rKXtLP60bWfgODrXqXO3NAfUYGxzXV/lY3I0Myp4y9Y=; b=Zm8ItSucrLsbVx0AtOpYtPQ5Uc/cenGg1ysgaT4RYJWlBKcpaHXlV1Py7Y8M6KCKTi STnfNnSdZgX/Tcdg2kAbyBeUbgai/saFWjcva2jKlPnciIls9aOX7XnYCMKt+WtodgX3 uXe996SuzJQVikz38LVXbBbhL8yJjlzYGxxlA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rKXtLP60bWfgODrXqXO3NAfUYGxzXV/lY3I0Myp4y9Y=; b=nG3NYcEreiBI6OZru/wK2nRUxxs5rrrTPrZ0kH1WeL6hFqFp6wURduKW40Hg06uMe2 Y+MUF2nR4zh0PhfNLjpuPaIK0YCqnE8zshY8F0NYfzDaliNLVJiXsYNgFGQINGM18LAt mkKuAvKfE2xhmQj721g88UBlry+M8TLHbH86FEUrW6e+tnlGY1zQDlF/0T1VKaOBsxDt Qj8VuIq9QB63RGLLjyIX6k/eBb0TBeBuC7lojLaFBamfmPLd3vIJTWNfciPHjYFcL3yq HufLUESIWH+UUOFRVVWaY1oG04EX+pF/3j097u7x8WMuxnK2Kj21nde7sF4FU9p0oyEa 1JWQ==
X-Gm-Message-State: AHPjjUjsrilbi9mUcY6uwUlPbpFKBUXguJlhNlLGt+JmbMlVq6u8QVqW vMMhCtuFm45FJUTs
X-Received: by 10.98.70.136 with SMTP id o8mr594731pfi.241.1504735504259; Wed, 06 Sep 2017 15:05:04 -0700 (PDT)
Received: from mail-pg0-f47.google.com (mail-pg0-f47.google.com. [74.125.83.47]) by smtp.gmail.com with ESMTPSA id o19sm795851pgn.76.2017.09.06.15.05.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Sep 2017 15:05:03 -0700 (PDT)
Received: by mail-pg0-f47.google.com with SMTP id 188so14236327pgb.2; Wed, 06 Sep 2017 15:05:03 -0700 (PDT)
X-Google-Smtp-Source: ADKCNb4fpSpT0vsRKWwnehry5juHES845UWeEfUtoImalruq115f3TyqqfmIRxkpxYhav5DSex/i3JrpP8YKivOtUYk=
X-Received: by 10.84.133.99 with SMTP id 90mr652893plf.374.1504735503065; Wed, 06 Sep 2017 15:05:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.191.8 with HTTP; Wed, 6 Sep 2017 15:05:02 -0700 (PDT)
In-Reply-To: <D5D43A0C.20FE7%christer.holmberg@ericsson.com>
References: <D5CC6091.208BE%christer.holmberg@ericsson.com> <244f9778-9cc4-eb99-bec1-f1905e7ec00e@nostrum.com> <D5CD8354.20BF4%christer.holmberg@ericsson.com> <D5D43A0C.20FE7%christer.holmberg@ericsson.com>
From: Roman Shpount <rshpount@turbobridge.com>
Date: Wed, 06 Sep 2017 18:05:02 -0400
X-Gmail-Original-Message-ID: <CAD5OKxsE2iZox_tkpq81YAappDtWH=WYJjMqBHM5tHnknAzwFA@mail.gmail.com>
Message-ID: <CAD5OKxsE2iZox_tkpq81YAappDtWH=WYJjMqBHM5tHnknAzwFA@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Adam Roach <adam@nostrum.com>, Ben Campbell <ben@nostrum.com>, Eric Rescorla <ekr@rtfm.com>, Alexey Melnikov <aamelnikov@fastmail.fm>, Mirja Kühlewind <ietf@kuehlewind.net>, "draft-ietf-mmusic-dtls-sdp@ietf.org" <draft-ietf-mmusic-dtls-sdp@ietf.org>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c030c9824376005588c8933"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/7dJyNYPP4Gp5MWjvV1h2x5-vsUY>
Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) - All comments should now have been addressed
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Sep 2017 22:05:07 -0000
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 < christer.holmberg@ericsson.com> 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" <christer.holmberg@ericsson.com> > 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 > > > >
- Re: [MMUSIC] Adam Roach's No Objection on draft-i… Christer Holmberg
- Re: [MMUSIC] Adam Roach's No Objection on draft-i… Adam Roach
- Re: [MMUSIC] Adam Roach's No Objection on draft-i… Ben Campbell
- Re: [MMUSIC] Adam Roach's No Objection on draft-i… Flemming Andreasen
- Re: [MMUSIC] Adam Roach's No Objection on draft-i… Cullen Jennings (fluffy)
- Re: [MMUSIC] Adam Roach's No Objection on draft-i… Christer Holmberg
- Re: [MMUSIC] Adam Roach's No Objection on draft-i… Christer Holmberg
- Re: [MMUSIC] Adam Roach's No Objection on draft-i… Roman Shpount
- Re: [MMUSIC] Adam Roach's No Objection on draft-i… Christer Holmberg
- Re: [MMUSIC] Adam Roach's No Objection on draft-i… Christer Holmberg
- Re: [MMUSIC] Adam Roach's No Objection on draft-i… Christer Holmberg