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: Thu, 04 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
- Re: [apps-discuss] Draft of interest in DNSOP: dr… HANSEN, TONY L
- Re: [apps-discuss] Draft of interest in DNSOP: dr… Ned Freed
- Re: [apps-discuss] Draft of interest in DNSOP: dr… Patrik Fältström
- Re: [apps-discuss] Draft of interest in DNSOP: dr… John R Levine
- Re: [apps-discuss] Draft of interest in DNSOP: dr… Tony Finch
- Re: [apps-discuss] Draft of interest in DNSOP: dr… Dave Crocker
- Re: [apps-discuss] Draft of interest in DNSOP: dr… John Levine
- Re: [apps-discuss] Draft of interest in DNSOP: dr… Dave Crocker
- Re: [apps-discuss] Draft of interest in DNSOP: dr… John Levine
- Re: [apps-discuss] Draft of interest in DNSOP: dr… Patrik Fältström
- [apps-discuss] Draft of interest in DNSOP: draft-… Tim Wicinski