Re: [MMUSIC] Adam Roach's Yes on draft-ietf-mmusic-sdp-bundle-negotiation-49: (with COMMENT)

Ben Campbell <ben@nostrum.com> Thu, 19 April 2018 09:41 UTC

Return-Path: <ben@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 2E92312D7EA; Thu, 19 Apr 2018 02:41:41 -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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 wYycIwRXWVgJ; Thu, 19 Apr 2018 02:41:39 -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 8A5E2124C27; Thu, 19 Apr 2018 02:41:39 -0700 (PDT)
Received: from [10.0.2.111] (ip-32-232-239-173.texas.us.northamericancoax.com [173.239.232.32]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w3J9fUmx013753 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 19 Apr 2018 04:41:32 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host ip-32-232-239-173.texas.us.northamericancoax.com [173.239.232.32] claimed to be [10.0.2.111]
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Ben Campbell <ben@nostrum.com>
X-Mailer: iPad Mail (15E216)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E87BE7@ESESSMB109.ericsson.se>
Date: Thu, 19 Apr 2018 11:41:30 +0200
Cc: Eric Rescorla <ekr@rtfm.com>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, Adam Roach <adam@nostrum.com>, "mmusic@ietf.org" <mmusic@ietf.org>, "fandreas@cisco.com" <fandreas@cisco.com>, The IESG <iesg@ietf.org>, "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" <draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <29FAF45F-5A95-42FC-9FDB-DA8257B85D67@nostrum.com>
References: <152394968680.26207.6988610273307864563.idtracker@ietfa.amsl.com> <D6FB7DAD.2E10A%christer.holmberg@ericsson.com> <CABcZeBPo3tGbAH=45mX7nEtJN=YQQ9vY9hH4WeLhnfNVYJ__cQ@mail.gmail.com> <D6FBD6CA.2E401%christer.holmberg@ericsson.com> <CABcZeBO3rQyMBUvROxU1AbCLSjNkrEZvYXSyKb=t_tTX1ATGxA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B72E87BE7@ESESSMB109.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/PmwjwuEEh0zeRRoyefkVRA03NiY>
Subject: Re: [MMUSIC] Adam Roach's Yes on draft-ietf-mmusic-sdp-bundle-negotiation-49: (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: Thu, 19 Apr 2018 09:41:41 -0000


On Apr 18, 2018, at 9:23 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

>> This doesn't answer my question. Who, specifically, thinks that this terminology
>> of focusing on the address:port and not the m= section is good?
> 
> Considering that the focus has been on the address and port since day one, for 7 years, I think it is good. After all, while there is more to it than the address:port, the main reason for BUNDLE is to be able to multiplex in a single address:port.
> 
> Now, we HAVE discussed changing "address:port" to "transport", but it would still not be about the m= section.
> 
>>> Having said that, if we can change it with a search/replace operation I am
>>> happy to discuss it. I THINK we could do that e.g., with "transport" or
>>> "3-tuple". 
>>> 
>>> But I don¹t want to make yet another re-write of the document just to once
>>> again change the terminology.
>> 
>> This document is going to be used by a lot of people. It's important that it be
>> clear.
> 
> I fully agree. But, I am not sure that endless re-writings the document is going to achieve that.

I think this has turned into an argument about style. One usage may be more pleasing to the “ear” than the other, but I don’t see issues of technical correctness or clarity here. As I asked for the the “associated with” question, is anyone arguing that the word choice here is likely to cause material implementation errors?

Ben.