Re: [DNSOP] SRV-related _underscore registry (was Re: Call for Adoption: draft-crocker-dns-attrleaf)

Stuart Cheshire <cheshire@apple.com> Fri, 30 March 2018 05:23 UTC

Return-Path: <cheshire@apple.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618B0126C0F for <dnsop@ietfa.amsl.com>; Thu, 29 Mar 2018 22:23:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 2MmyVo1tJJUx for <dnsop@ietfa.amsl.com>; Thu, 29 Mar 2018 22:23:26 -0700 (PDT)
Received: from mail-in21.apple.com (mail-out21.apple.com [17.171.2.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414C4124B0A for <dnsop@ietf.org>; Thu, 29 Mar 2018 22:23:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1522387405; x=2386301005; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RTOPKuB+i3k/zurCfmwNTCIlhPbUVaJWNdxnyoa9NZ0=; b=Bhso/2PTwKBP9sbONHMQkZD9OH8EDGfLftK1ljpy947PQ1Odgn4f2CULFxuwtaVg spR0Db4Q8UJvXWn3LY8uXKoXDJ5tswG374NQtzssPpfoN+8luJsLlKdNqoJAs0MF IilZci77cv1UTe6s8FRYrprBnBAFRPNskRCWDizE33HsgLsER8785GJCtzfWIjlB W6cbn+zqgBiS93LOoCnnQfOr32YBY0UGuopE43Xs1eOlqX8Y9spY1AliBubLGLIJ cnB1vZHZrZvxQsM2IfEdHb9S2gzSgWm+CJdQeS7xTDsQT7nc/HBUVC2b8F2g6emq ewn7/dDwhDzQCLoIfvokmA==;
Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in21.apple.com (Apple Secure Mail Relay) with SMTP id D9.D2.03684.DC9CDBA5; Thu, 29 Mar 2018 22:23:25 -0700 (PDT)
X-AuditID: 11ab0215-4d5ff70000000e64-d3-5abdc9cc6968
Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id CF.19.18185.CC9CDBA5; Thu, 29 Mar 2018 22:23:24 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Received: from [17.234.53.181] (unknown [17.234.53.181]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180130 64bit (built Jan 30 2018)) with ESMTPSA id <0P6E00CS81MZK9A0@nwk-mmpp-sz13.apple.com> for dnsop@ietf.org; Thu, 29 Mar 2018 22:23:24 -0700 (PDT)
Sender: cheshire@apple.com
From: Stuart Cheshire <cheshire@apple.com>
Content-transfer-encoding: quoted-printable
Date: Thu, 29 Mar 2018 22:23:22 -0700
References: <20160301165633.71260.qmail@ary.lan> <56D5CA62.1030206@bellis.me.uk> <CAMm+LwjJ0xe2wDW98JHJfV5jV3xTeuMNguU=rkqrZMzmei2iHA@mail.gmail.com>
To: "dnsop@ietf.org" <dnsop@ietf.org>
In-reply-to: <CAMm+LwjJ0xe2wDW98JHJfV5jV3xTeuMNguU=rkqrZMzmei2iHA@mail.gmail.com>
Message-id: <F9C5056C-5D2E-48BC-85C6-4FD79F3A6ACD@apple.com>
X-Mailer: Apple Mail (2.3445.5.20)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUi2FAYrHv25N4og2dtQhZ331xmcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRtOJPtaCX/IV166/Zmlg3CvVxcjJISFgIrH89jXmLkYuDiGB NUwSUx7NZYNJrNz9mBEisYFJ4s/2PmaQBK+AoMSPyfdYuhg5OJgF1CWmTMmFqFnCJLFtyUYm kBphASmJVys/g9WzCWhJvPh8BWwos4C2xJN3F1ghavIlmh/+BrNZBFQlXi68CVYjJDCTUeLU qUQQWwQofuHfd7CZnALBEnda97JB3GAjMfHMBHaIQ5Ukpn+/zQZyhITAU1aJY5uOsExgFJqF 5NZZCLfOQnLGAkbmVYzCuYmZObqZeUaGeokFBTmpesn5uZsYQQG7mkl0B+P8V4aHGAU4GJV4 eE8w7o0SYk0sK67MPcQozcGiJM577XljlJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGSMYZ fnvE07c/aTp54NhN7vQQDf/00gvVfUeTedxM1qw5fFKptvCK71rJhvqOSK59MTdafaQ8tZ/Y i9lPUJ8sE83fvNvPIDiR1fyZ087usAcXatbrLd14u7ZknXH4Lf1PhzMf9e9UNlLfFD+9vpf3 bu6pa/H33iuosTfsX7nP7lx8QIrkFEUlluKMREMt5qLiRADvxyRzOQIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUi2FB8Q/fMyb1RBs0fFC3uvrnM4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujKYTfawFv+Qrrl1/zdLAuFeqi5GTQ0LARGLl7seMXYxcHEIC G5gk/mzvYwZJ8AoISvyYfI+li5GDg1lAXWLKlFyImiVMEtuWbGQCqREWkJJ4tfIzWD2bgJbE i89X2EBsZgFtiSfvLrBC1ORLND/8DWazCKhKvFx4E6xGSGAmo8SpU4kgtghQ/MK/72AzOQWC Je607mWDuMFGYuKZCewQhypJTP9+m20CI/8sJOfNQjhvFpLNCxiZVzEKFKXmJFYa6yUWFOSk 6iXn525iBIdXYfAOxj/LrA4xCnAwKvHwKrDsjRJiTSwrrsw9xCjBwawkwls+FSjEm5JYWZVa lB9fVJqTWnyIUZqDRUmct5NrZ5SQQHpiSWp2ampBahFMlomDU6qB0USu7nJBpGz3lcWqG45P 4EioK+I84vMiXuiYbu4HKTe+X1/27Em5fuSr8nl7HkG7Y/ueTvVk8Pu2bVrL2ccX3p0ruMp6 sEWhYa+jw8GlDSmyUnzbDW+uK/507X2fxYVbLf3qAccWsmalXtjkdddKcab8YbUrNcGLL345 WmX3q13BmafdfXrsbiWW4oxEQy3mouJEAILEO2IrAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/H7MwYJACBh6mTtStDhWMIjqt4XI>
Subject: Re: [DNSOP] SRV-related _underscore registry (was Re: Call for Adoption: draft-crocker-dns-attrleaf)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2018 05:23:28 -0000

On 29 Feb 2016, at 14:27, John R Levine <johnl@taugh.com>; wrote:

> The existing port and service registry already has all of the _service names, and is updated as people invent new services. What's the benefit of duplicating it rather than just pointing to it?

I agree. Where possible, it’s better to add to an existing registry, rather than creating an entirely new (but mostly overlapping) one.

When we wrote RFC 6335 we made a conscious choice that 15 ASCII characters is short enough to be efficient over the air and not burdensome to implement in constrained devices, yet long enough for the set of available identifiers to be effectively unlimited, and long enough to allow for reasonably mnemonic identifiers where that is desired (at least in English, which we deemed acceptable since these are protocol identifiers, not generally seen by end users).

A consequence of this abundant namespace is that it’s okay to have some identifiers in it that are not applicable in all contexts, and that’s preferable to having separate per-context namespaces, which risks having some identifier string appear in more than of those namespaces, with unrelated meanings. When RFC 6335 unified the two separate identifier namespaces there were four such unintended overlaps (esp, hydra, recipe, xmp), which fortunately were resolved amicably: <https://tools.ietf.org/html/rfc6335#section-10.1>;.

On 1 Mar 2016, at 09:55, Phillip Hallam-Baker <phill@hallambaker.com>; wrote:

> The _service._protocol approach in SRV is rather obviously a mistake. Given the function of SRV, the protocol tag should have been on the RIGHT hand side of the RR type, not the left. The choice of UDP or TCP should be an OUTPUT from the service discovery process, not an input.

We thought about this too, and concluded that few application protocols offer the luxury of running over both TCP and UDP (NFS and DNS being two examples that come to mind).

In reality, most application protocols are defined as a bundle, such as application-protocol-over-UDP-over-IP, or application-protocol-over-TCP-over-IP, or application-protocol-over-TLS-over-TCP-over-IP. The application protocol name implicitly encodes the transport it expects. In an iPhone looking for AirPrint (i.e., IPP) printers were to be told that it had found an AirPrint printer that supported IPP, but only over SCTP, or DCCP, or whatever, the iPhone would simply fail to print on it, because the iPhone doesn’t implement IPP-over-foo.

In retrospect, I wish we had defined all SRV service type identifiers to be simply “_app-proto._srv”, and let the specification of the “_app-proto” application protocol state what transport layer stack it requires. In practice what happens is that TCP-based protocols use “_tcp” and everything else uses “_udp” as the catch-all for all non-TCP protocols. RFC 6763 talks about this: <https://tools.ietf.org/html/rfc6763#section-7>;.

A common convention that seems to be emerging is that application protocols that run over TLS are given SRV service type identifiers ending in “-tls”, such as, “_dns-update-tls._tcp” and “_dns-push-tls._tcp”. This is just a convention for mnemonic convenience though, and not every service uses it. For example, IPP over TLS uses service type “_ipps._tcp”. When looking for AirPrint (i.e., IPP) printers a modern iPhone will browse for both “_ipp._tcp” and “_ipps._tcp”, and show a unified list to the user. In some ways this is not ideal, but engineering is often a pragmatic choice between imperfect solutions and picking the less bad one. Moving forward we expect that most application protocols that need security will only run over TLS, making this “dual personality” behavior rare.

Stuart Cheshire