Re: [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf

"John Levine" <johnl@taugh.com> Thu, 04 August 2016 02:00 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4738B12B05D for <apps-discuss@ietfa.amsl.com>; Wed, 3 Aug 2016 19:00:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 pG_F-2f1j2L4 for <apps-discuss@ietfa.amsl.com>; Wed, 3 Aug 2016 19:00:11 -0700 (PDT)
Received: from miucha.iecc.com (miucha.iecc.com [64.57.183.18]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66F3E12B00F for <apps-discuss@ietf.org>; Wed, 3 Aug 2016 19:00:11 -0700 (PDT)
Received: (qmail 56436 invoked from network); 4 Aug 2016 01:59:03 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 4 Aug 2016 01:59:03 -0000
Date: 4 Aug 2016 01:58:40 -0000
Message-ID: <20160804015840.60405.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: apps-discuss@ietf.org
In-Reply-To: <d883251c-8bfb-9e96-4e5b-2e76960064e4@dcrocker.net>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/apps-discuss/xm08MJraBTiCkU4E4AY-biEbGKU>
Cc: dcrocker@bbiw.net
Subject: Re: [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Aug 2016 02:00:13 -0000

>As for the second-level underscore names, I propose that they /also/ be 
>registered in this one table.  In theoretical terms, one could argue for 
>a separate table, or maybe many of them (one under each top-level 
>underscore protocol name) but that purity-drive choice seems somewhere 
>between inefficient and silly.

That doesn't seem like a great idea.  According to RFC 2782, SRV names
are:

 _service._protocol.blah.example

Name assignment was a mess due to the rather casual advice in 2782
until RFC 6335 cleaned it up five years ago.

There appear to be only four protocols that have ever been used for
SRV records: _udp, _tcp, _sctp, and _dccp.  RFC 6335 refers to them
but doesn't set up a registry.  The names are in the Assigned Internet
Protocol Numbers registry, but most of the entries in that registry
are obsolete and some have names with plus signs and other unfortunate
characters, so I think it'd be fine to put the live protocol tags into
your list.

The services, on the other hand, were thoroughly cleaned up by RFC
6335.  It collected a bunch of informal lists into one place, renamed
a few old names with unfortunate characters, and put them into a tidy
and very large Service Name and Transport Protocol Port Number
Registry.  It says in section 5.2 that the service name for a SRV
record MUST follow the syntax rules (ldh with at least one letter and
no leading or trailing or double hyphens, prefixed with an underscore)
and SHOULD be registered in the registry.

That registry is FCFS for service names and now contains over 10,000
entries, so if you are aware of any SRV service names not listed, it'd
make a lot more sense to register them than to try to define something
new that sort of mirrors one of the largest registries that IANA manages.

For URI records RFC 7553 says they're either named the same as SRV
records, or they use enumservice names from the Enumservice
Registrations registry which lists two dozen types, most of which have
specific allowed subtypes.  This registry is a lot smaller than the
service name registry, but it exists, the RFC points to it, and it
seems unwise to copy its contents somewhere else.

Other than SRV and URI records, there's a handful of two component
prefix names like _adsp._domainkey and _report._dmarc.  As far as I
tell the rest are all all one or two per main name, so listing them
shouldn't be too hard.  But please, don't duplicate registries that
already exist.

R's,
John