Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt

Andy Hutton <andyhutton.ietf@gmail.com> Fri, 03 November 2017 09:18 UTC

Return-Path: <andyhutton.ietf@gmail.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 B461C13FA91 for <mmusic@ietfa.amsl.com>; Fri, 3 Nov 2017 02:18:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 tPhpw1fjWVys for <mmusic@ietfa.amsl.com>; Fri, 3 Nov 2017 02:18:10 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 24D8513FD22 for <mmusic@ietf.org>; Fri, 3 Nov 2017 02:18:10 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id b9so125115wmh.0 for <mmusic@ietf.org>; Fri, 03 Nov 2017 02:18:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=RfX98m6fLW0dekY1aspnHpakY7mMHPfiiYGVg7f08sE=; b=pufitLRn2+QxFxxG3Yc0A71Tid1z8F4COtpNLSZHCcym0X7kghZUcIQCI9+VFxHMrc awWNCArAlxYPi+ypejb8QluJCmmy0ckK4Q+miF7n/Tlnzs6DWLHz7xZIG4uzkFr7n3rK tveJoEpaDrLnqGv5h0J7W1UseC+ATMFG3DRqNRe6vLa5r/NBYHS3lF9YIMwkQwcEI0mW P2ofKhxEdIKHAejSl0XAs09S68bRM/mogOd3mEpzVF9G1HZnc0LgQ0BjWNT91/k9E2gv 0Be7R75rifORAJw5Vgk4BYPwip8xmSyM8gN7TqygSMAzjjGbuK2YneHaSs8g9tL/LFcP /Iew==
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:content-transfer-encoding; bh=RfX98m6fLW0dekY1aspnHpakY7mMHPfiiYGVg7f08sE=; b=FOa2O8u/E8UzIZwnmHToRLxRmSivqUIqePBFkCV37hbVPTVK1svj3LyzP/YFSLtM15 +Bj4IlaX6MhjolRVc5UE6q96Z3WKKi0Lo7OZcY65w03LFuP7iQsubaGZma9zHiE2O6QZ v1Xaql6z0mghx8G18cXrLQoZwAsshSMoqcAvgD2DbFsFRO38OkoyxzIlL2nTBGGmr0qP /4LAhOyWP3mWO2O+SmDDwwXKIXo9oR7iLIGT/Gon7qdmxfPkRNDECmplCpC9Ba50Odta qlTQSUBrwsnBEg8FHSZamBEy/VCGOQzlARCFTBXlN6tPQVriESaiBy18mg32Y3kJaPM2 HXEQ==
X-Gm-Message-State: AMCzsaX8EczBv7ohlWhC+6yIVrRK+Tqx9DdDWxzVUrazojhf4B9gMCuy Ii9toUaiSiUWa9mQlU9gq5paIN8qPDtKHRcN1Oc=
X-Google-Smtp-Source: ABhQp+QNYN2hkhggfj/d0hbUbTPjxP3dqYZnCZhFt4Kf0lghYk2wM/AS2/nhbiPB/TwX/0F6ADEM/5w+RjtDjnDUihk=
X-Received: by 10.28.111.206 with SMTP id c75mr3912148wmi.123.1509700688597; Fri, 03 Nov 2017 02:18:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.136.154 with HTTP; Fri, 3 Nov 2017 02:18:07 -0700 (PDT)
In-Reply-To: <D5F29DE2.22D34%christer.holmberg@ericsson.com>
References: <150540502703.12603.17962279219166496882@ietfa.amsl.com> <D5F17F72.22C18%christer.holmberg@ericsson.com> <2833E3F5-9646-40CD-995E-8A7F61DA77CA@cisco.com> <7594FB04B1934943A5C02806D1A2204B56302CF2@ESESSMB109.ericsson.se> <CAB7PXwR0QtxSS4fkmVo8+0Z7FepWU0D0OL9_Hh0TFRvMToGtBQ@mail.gmail.com> <D5F29DE2.22D34%christer.holmberg@ericsson.com>
From: Andy Hutton <andyhutton.ietf@gmail.com>
Date: Fri, 03 Nov 2017 09:18:07 +0000
Message-ID: <CAB7PXwQaTvx7WDe2n4Mg3SjQZSQcQPz5qU9KYGhQPS1phkZVFQ@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/3sA7XLhRRdI-aVdHgsADOpSjZ1U>
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt
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: Fri, 03 Nov 2017 09:18:13 -0000

The comment from Christer below was the only WGLC comment I believe.

Whilst I see some value in what Christer suggests I think this is a
simple draft which already adequately describes the solution and to be
honest I don't really want to go round the loop of making significant
changes to the draft and going through more last calls etc.

Please can the chairs let us know how we should proceed.

Unfortunately I will not be in Singapore to discuss but lets find a
way to get this done.

Regards
Andy




On Thu, Sep 28, 2017 at 10:35 AM, Christer Holmberg
<christer.holmberg@ericsson.com> wrote:
> Hi,
>
>>I agree that ideally we should have all the associated procedures in
>>one place and having two specs is not ideal however we have been going
>>round this circle for a couple of years now and just need to get this
>>done.
>>
>>Originally we wanted this work to be done in MMUSIC but it got
>>dispatched to SIPBrandy but it was later discovered that an update to
>>RFC 4568 was needed and that the SIPBrandy charter did not allow this
>>so we were told an MMUSIC draft was needed after all to update the RFC
>>before the SIPBrandy work could be completed.
>>
>>I do not want to start again and waste another couple of years lets
>>just get it finished.
>
> I suggest that we:
>
> 1)      Keep the SIPBRANDY draft as it is. Perhaps they could add a sentence
> pointing out that that the normative procedures will be described
> elsewhere.
> 2)      Keep the MMUSIC draft, but we add a proper 'SDP Offer/Answer
> Considerations’ section, where we include the normal subsections (create
> initial offer, process offer, process answer etc).
>
> Regards,
>
> Christer
>
>
>
>
>>On Wed, Sep 27, 2017 at 9:35 PM, Christer Holmberg
>><christer.holmberg@ericsson.com> wrote:
>>> Hi,
>>>
>>>
>>>
>>> In the mail you referenced the following is said:
>>>
>>>
>>>
>>> “I see your point but Currently SIPBRANDY is chartered to produce
>>> Opportunistic SRTP as a BCP. There is also a milestone to
>>>
>>> inform MMUSIC or other appropriate WGs of any changes needed to support
>>> Opportunistic SRTP (Not expected to be published
>>>
>>> as an RFC).  I think SIPBRANDY is just carrying out what they are
>>>chartered
>>> to do.”
>>>
>>>
>>>
>>> But, draft-ietf-mmusic-opportunistic-negotiation doesn’t really define
>>>any
>>> procedures ­ it references the SIPBRANDY draft for everything.
>>>
>>>
>>>
>>> “[I-D.ietf-sipbrandy-osrtp] describes how Secure Real-time transport
>>>
>>>               protocol (SRTP) can be negotiated opportunistically.”
>>>
>>>
>>>
>>> But, as the SIPBRANDY is only Informational, where are the normative
>>> procedures?
>>>
>>>
>>>
>>> “The exact negotiation mechanism is however outside the scope of this
>>> document,
>>>
>>>               an example mechanism can be found in
>>> [I-D.ietf-sipbrandy-osrtp].”
>>>
>>>
>>>
>>> How can negotiation be outside the scope of the document, when the
>>>title of
>>> the document contains “negotiating”?
>>>
>>>
>>>
>>> In addition, the text says that the sipbrandy only contains “an example
>>> mechanism”.
>>>
>>>
>>>
>>> If we are going to have this document, I think we shall include
>>>normative
>>> offer/answer procedures. The draft DOES contain some normative
>>>procedures,
>>> but I think we shall have it all in one place. One shall not have to
>>>read
>>> both documents just to figure out the offer/answer procedures.
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Christer
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> From: Gonzalo Salgueiro (gsalguei) [mailto:gsalguei@cisco.com]
>>> Sent: 27 September 2017 21:58
>>> To: Christer Holmberg <christer.holmberg@ericsson.com>
>>> Cc: mmusic@ietf.org
>>> Subject: Re: [MMUSIC] I-D Action:
>>> draft-ietf-mmusic-opportunistic-negotiation-01.txt
>>>
>>>
>>>
>>> Hi Christer -
>>>
>>>
>>>
>>> See this:
>>> https://mailarchive.ietf.org/arch/msg/mmusic/wov2yErrgtUZURyRyVuVZ6K-nLI
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>>
>>> -G
>>>
>>>
>>>
>>> On Sep 27, 2017, at 9:19 AM, Christer Holmberg
>>> <christer.holmberg@ericsson.com> wrote:
>>>
>>>
>>>
>>> Hi,
>>>
>>> I am currently reviewing draft-ietf-sipbrandy-osrtp-03, and the
>>>following
>>> question comes to my mind: do we really need
>>> draft-ietf-mmusic-opportunistic-negotiation? :)
>>>
>>> Section 3 of draft-ietf-sipbrandy-osrtp-03 already more or less contains
>>> SDP Offer/Answer procedures for OSRTP. We can change the name of
>>>section 3
>>> in that draft to ³SDP Offer/Answer Procedures², modify the structure a
>>> little, and add whatever might be missing.
>>>
>>> Or, am I missing something?
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>>
>>>
>>> On 14/09/17 19:03, "mmusic on behalf of internet-drafts@ietf.org"
>>> <mmusic-bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote:
>>>
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Multiparty Multimedia Session Control
>>>WG
>>> of the IETF.
>>>
>>>       Title           : Negotiating SRTP and RTCP Feedback using the
>>> RTP/AVP Profile
>>>       Authors         : Andrew Hutton
>>>                         Roland Jesske
>>>                         Alan Johnston
>>>                         Gonzalo Salgueiro
>>>                         Bernard Aboba
>>> Filename        : draft-ietf-mmusic-opportunistic-negotiation-01.txt
>>> Pages           : 7
>>> Date            : 2017-09-14
>>>
>>> Abstract:
>>>  This document describes how the use of the Secure Real-time transport
>>>  protocol (SRTP) [RFC3711]. can be negotiated using the RTP/AVP (Audio
>>>  Video Profile) defined in [RFC3551].  Such a mechanism is used to
>>>  provide a means for encrypted media to be used in environments where
>>>  support for encryption is not known in advance, and not required.
>>>  The same mechanism is also applied to negotiation of the Extended RTP
>>>  Profile for Real-time Transport Control Protocol Based Feedback (RTP/
>>>  AVPF) [RFC4585].
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>>
>>>https://datatracker.ietf.org/doc/draft-ietf-mmusic-opportunistic-negotiat
>>>i
>>> on/
>>>
>>> There are also htmlized versions available at:
>>>
>>>https://tools.ietf.org/html/draft-ietf-mmusic-opportunistic-negotiation-0
>>>1
>>>
>>>https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-opportunistic-neg
>>>o
>>> tiation-01
>>>
>>> A diff from the previous version is available at:
>>>
>>>https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-opportunistic-negotia
>>>t
>>> ion-01
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>