Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT)

Ben Campbell <ben@nostrum.com> Thu, 24 August 2017 18:02 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 D368E13202D; Thu, 24 Aug 2017 11:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GO4KlZKmYaDd; Thu, 24 Aug 2017 11:02:47 -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 A1DE1132113; Thu, 24 Aug 2017 11:02:47 -0700 (PDT)
Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7OI2gHx087666 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 24 Aug 2017 13:02:42 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63]
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <9cdb8f3b-eb9b-f478-ecb0-2095cdba2484@nostrum.com>
Date: Thu, 24 Aug 2017 13:02:41 -0500
Cc: "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>, Flemming Andreasen <fandreas@cisco.com>, The IESG <iesg@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <83BCB0B5-0F74-43A2-9EF1-1D04EF4F9A0E@nostrum.com>
References: <150301038555.14103.1567567703984434290.idtracker@ietfa.amsl.com> <D5C324F2.201A9%christer.holmberg@ericsson.com> <aa248a72-9b32-f1bc-e9f8-8471303c7bae@nostrum.com> <8EB6BD4A-26A9-4F98-A57A-FCCFC3F6AC97@nostrum.com> <9cdb8f3b-eb9b-f478-ecb0-2095cdba2484@nostrum.com>
To: Adam Roach <adam@nostrum.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/FTatHhdKzBcn9qhIgar5MbOvkgw>
Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (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, 24 Aug 2017 18:02:49 -0000

> On Aug 24, 2017, at 12:52 PM, Adam Roach <adam@nostrum.com> wrote:
> 
> On 8/24/17 12:48, Ben Campbell wrote:
>>> On Aug 23, 2017, at 1:30 PM, Adam Roach <adam@nostrum.com> wrote:
>>> 
>>> On 8/23/17 04:38, Christer Holmberg wrote:
>>>>> I would think the long-form title of this document should include "TLS,"
>>>>> to
>>>>> reflect that it also contains TLS-related procedures.
>>>> The issue is that the document doesn¹t really define the O/A procedures
>>>> for TLS. It simply adds the usage of the tls-id attribute to the existing
>>>> procedures defined elsewhere.
>>> Right, so make that clear. I note that simply adding "and Identification of TLS Connections" to the end is ambiguous (since it makes it sound like it defines O/A for TLS), but you can fix this by reversing the existing title; e.g., something like: "Establishing Datagram Transport Layer Security (DTLS) Using the Session Description Protocol (SDP) Offer/Answer Mechanism and Identification of Transport Layer Security (TLS) Connections in SDP”
>> Wow, that’s petty cumbersome as a title—it’s pretty much an abstract. Does it need that much detail?
>> 
> 
> It's the result of taking a reasonably short title ("Establishing DLTS using the SDP Offer/Answer Mechanism and Identification of TLS Connections in SDP") and applying RFC Editor policies of acronym expansion to it. If you can think of some shorter way to say it, that'd be great -- but if I'm perusing a list of titles for something TLS-related and come across one that mentions only DTLS, I'd skip over it. The original title seems like a genuine flaw.

Here’s a sacrificial proposal from the _much_ more general side:  

    “DTLS and TLS considerations in the SDP Offer/Answer Mechanism” 

… with appropriate acronym expansions of course. That may be too expansive, but we do have the abstract to narrow the focus. Some alternatives:
 
   “DTLS and TLS Session Management in the SDP Offer/Answer Mechanism” 
   “DTLS and TLS Security Association Management in the SDP Offer/Answer Mechanism” 

Ben.