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

"John Levine" <johnl@taugh.com> Tue, 01 March 2016 16:39 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0301B2EED for <dnsop@ietfa.amsl.com>; Tue, 1 Mar 2016 08:39:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.862
X-Spam-Level:
X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 tkQLl12-6FUi for <dnsop@ietfa.amsl.com>; Tue, 1 Mar 2016 08:39:31 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67A091B2EEE for <dnsop@ietf.org>; Tue, 1 Mar 2016 08:39:31 -0800 (PST)
Received: (qmail 74445 invoked from network); 1 Mar 2016 16:39:27 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 1 Mar 2016 16:39:27 -0000
Date: Tue, 01 Mar 2016 16:39:05 -0000
Message-ID: <20160301163905.71179.qmail@ary.lan>
From: John Levine <johnl@taugh.com>
To: dnsop@ietf.org
In-Reply-To: <56D5B3BC.6050206@dcrocker.net>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/m4dQCNrjxiXoVt3Fam6PrYPeRxc>
Cc: dcrocker@bbiw.net
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.15
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: Tue, 01 Mar 2016 16:39:32 -0000

>If SRV continues to specify _Proto choices from a separate IANA 
>registry, ....

It never did and does not now.  There is no protocol name registry or
_proto tag registry.  (There is a S-NAPTR application protocol tag
registry, but since it contains entries like "diameter.tls.tcp" this
is not the registry you are looking for.)

>In the case of _Proto names, the set is tiny, so the burden of 
>explicitly registering these names in an _underscore registry is not 
>onerous, given that it is the only way to ensure that name collisions 
>are avoided.

I agree.  The current set of _proto names used by SRV. NAPTR, and URI
is sort of defined by examples and hints.  RFC 2782 which defined SRV
calls out _TCP and _UDP as interesting protocols and then waves its
hands about possible other ones.  It creates no registry.  

RFC 6335 calls out SCTP, DCCP, TCP, and UDP as interesting protocols,
and then says that future protocols that support services should use
the same services registry.  It has a lot of advice for IANA, but it
doesn't create a protocol name or tag registry either.

RFC 2780 created a protocol number registry updated by RFCs 5237 and
7045.  It has a "keyword" column, but many of the keywords include
undesirable characters like +./.  Most of the protocols are dead
experiments from 20 or 30 years ago, and most of the live ones like
ICMP aren't suitable for services.  One possibility would be to add a
tag column to that registry and populate it with the four tags that
seem plausibly useful.  But ugh.

The other which I prefer is simply to put the four _proto tags into
the new underscore registry.  Add a note that they have subnames from
the RFC 6335 services registry, and for anew new protocol tags try to to
keep the protocol names consistent with the keywords in the protocol
number registry.


I see the universe of underscore tags falling into three categories.

1.  Tags that mean something under a hostname.  This includes the
_proto tags and things like _domainkey and _vouch.

2.  Tags that only mean something under a _proto tag.  This is 
the set of service names in the RFC 6335 registry and _nnn (port number)
used to name TLSA records.

3.  Tags that only mean something under some other underscore tag.
This is a very small list, _adsp._domainkey and _report._dmarc are
the only ones I know.

It would be useful to define the registry for the first kind of tags.
The second already has a registry, the third is uninteresting since it
has no collision issues.

R's,
John