Re: [MMUSIC] Eric Rescorla's No Objection on draft-ietf-mmusic-sdp-bundle-negotiation-51: (with COMMENT)

Adam Roach <adam@nostrum.com> Mon, 21 May 2018 15:15 UTC

Return-Path: <adam@nostrum.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 87AF012E89F for <mmusic@ietfa.amsl.com>; Mon, 21 May 2018 08:15:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no
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 CxexcMY0m7kK for <mmusic@ietfa.amsl.com>; Mon, 21 May 2018 08:15:46 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 0961C1273E2 for <mmusic@ietf.org>; Mon, 21 May 2018 08:15:43 -0700 (PDT)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4LFFbJj025848 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 21 May 2018 10:15:38 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: Eric Rescorla <ekr@rtfm.com>, Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Flemming Andreasen <fandreas@cisco.com>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" <draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org>, The IESG <iesg@ietf.org>, mmusic WG <mmusic@ietf.org>
References: <152676110260.28001.7412898846338225219.idtracker@ietfa.amsl.com> <CABcZeBN43yTCK+XbLLih_xeaBwsGVMa6XcPQkrcyQjzQHfzNuQ@mail.gmail.com> <CABcZeBO5b4OMaV5z-XhQPVOUpX6eB_GZKPu7b9Ti6MOCwsJ5xQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B72EF825B@ESESSMB109.ericsson.se> <CABcZeBM5Vqmw-txmTmrcOXndwsW=20oUvXywdeLR9OMBPFp1cQ@mail.gmail.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <701d1e42-fcb9-a849-2865-9f1a71176a50@nostrum.com>
Date: Mon, 21 May 2018 10:15:32 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBM5Vqmw-txmTmrcOXndwsW=20oUvXywdeLR9OMBPFp1cQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------22AB7A89098C26D411F45674"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/UNUsSRG297svx_u8V4g-BxtT3rA>
Subject: Re: [MMUSIC] Eric Rescorla's No Objection on draft-ietf-mmusic-sdp-bundle-negotiation-51: (with COMMENT)
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: Mon, 21 May 2018 15:15:48 -0000

On 5/21/18 7:55 AM, Eric Rescorla wrote:
>
>     >I have made a few notes of things that I still think are problematic, but I
>     >am clearing my DISCUSS.
>     >
>     >   o  Initial offer: The first offer, within an SDP session (e.g.
>     a SIP
>     >      dialog when the Session Initiation Protocol (SIP) [RFC3261] is
>     >
>     > This appears still not to be resolved. Here is the 3264 definition "
>     > Protocol operation begins when one agent sends an initial offer to
>     > another agent. An offer is initial if it is outside of any context
>     > that may have already been established through the higher layer
>     > protocol." I'm not making this part of my DISCUSS, but I think it's
>     > very confusing and I would strongly urge the AD to address it.
>
>     This is based on the structure that MMUSIC has previously agreed
>     on, and is used in many drafts.
>
>
> Yes, but it also contradicts the SDP RFC.
>
>
>     The text does explain what “initial offer” means in the context of
>     the document.
>
>     I am happy to re-visit that discussion in MMUSIC on a generic
>     level, but as far as this document is concerned I think we shall
>     keep the currently agreed structure.
>
>
> Ben, Adam? You're the ADs for this.


Ben is the responsible AD here, so I'm deferring to his judgement 
regarding whether the document can proceed.

Speaking only as a SIP protocol expert, I agree with EKR that the 
redefinition of a frequently used RFC-3264-defined term is problematic, 
and will probably lead to interoperability issues. When readers 
encounter a term that they believe they understand, it's unlikely that 
they will notice that it has been redefined to mean something different 
[1]. I believe that replacing the phrase with something distinctive -- 
such as "initial bundle offer" -- would alleviate this issue, with no 
real drawback. I would not think that such a change warrants sending the 
document back to the WG, but I won't argue against doing so if someone 
else thinks it does.

/a

____
[1] For the issue at hand, I'm reminded of Lewis Carrol's take on 
lexical semantics: 
http://www.literaturepage.com/read/throughthelookingglass-54.html