[DNSOP] Attrleaf _second-Level modifications (was: Re: Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-03.txt)
Dave Crocker <dhc@dcrocker.net> Thu, 22 March 2018 15:12 UTC
Return-Path: <dhc@dcrocker.net>
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 B58EF126D05; Thu, 22 Mar 2018 08:12:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.77
X-Spam-Level:
X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.net
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 2cFF_Jdd2xHr; Thu, 22 Mar 2018 08:12:51 -0700 (PDT)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 98B4C12D883; Thu, 22 Mar 2018 08:12:51 -0700 (PDT)
Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w2MFECob018653 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Mar 2018 08:14:13 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1521731653; bh=/J183rX27vXTfGDGZfsOsVP69sk0yah1hO/DWdAH340=; h=Subject:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=Uf7qAXIdQBW8W/NSAuooLcn0LMWQv6qnsXXd21/93GuwPCjWMt6qKfdnufpMONGKl DgNqz9rVNV1Mm1ArcBejX8pPgJvYwpzmeGG/ij2gyYluYAACILrIG2uNewnuPGU0S0 AtXhZTpN0Z6suNGNCoc9JgXUuyANdttsXQAGE+0k=
Cc: dnsop <dnsop@ietf.org>, Applications and Real-Time Area Discussion <art@ietf.org>
References: <152150434726.9747.3586273536264334521.idtracker@ietfa.amsl.com> <f7b85bac-b050-5003-2df0-a48b1ef2f929@dcrocker.net> <alpine.OSX.2.21.1803201614180.8721@dhcp-8344.meeting.ietf.org>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Reply-To: dcrocker@bbiw.net
Message-ID: <eaa2629a-48de-f858-b3da-e2c84abe6c2c@dcrocker.net>
Date: Thu, 22 Mar 2018 08:12:43 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <alpine.OSX.2.21.1803201614180.8721@dhcp-8344.meeting.ietf.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9gZpQ27I_t1OpBR5uRBvRgOIIIY>
Subject: [DNSOP] Attrleaf _second-Level modifications (was: Re: Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-03.txt)
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: Thu, 22 Mar 2018 15:12:53 -0000
On 3/20/2018 9:31 AM, John R. Levine wrote: >> 2. SRV and URI >> >> These need more detailed text, very much in the s/old/new style. >> >> The current text in them does a use-by-reference of existing tables >> defined for other purposes. The Update text will, instead, specify a >> requirement for adding entries in the Global or Common Second-Level >> registries. > > The second level registry, though, is a problem, because it tries to > redefine the naming rules for SRV records. RFC 2782 said that SRV > second level names are from the services in Assiged Numbers STD 2. RFC > 3400 abolished STD 2 in favor of an IANA registry. That registry, the > Service Name and Transport Protocol Port Number Registry, was cleaned up > by RFC 6335 which reiterates the fact that the service names in that > registry are the services used to name SRV records. RFC 7335 states > that URI records are named the same as SRV, and also says you can use > enumservice _subtype._type. > > We need to change the description of the second level name registry to > say that SRV and URI are special, they use names from Ports and Services > at the second level and URI uses enumservice subtypes, and take out all > of the SRV entries. What's left is the grabbag of second level names > used for other stuff like NAPTR and _adsp._domainkey. Folks, Level set: ***** I think what hung me up was mostly missing the reference to 'second-level' while focusing too much on the presence of the word 'special'. ***** For any use of an underscore first-level name, that also uses a second-level name, the authority over that second-level belongs entirely and solely to that first-level name. ..._my-second._firsta.example and ..._my-second._firstb.example have no conflict. So here's what needs to be clearer in the main attrleaf document and the fixup document: All /first-level/ uses of underscore names MUST be registered in the single, /global/ registry, for in order to avoid collisions. For second-level names, any name assignment scheme can be used, as long as it prevents collisions /within the scope of its own first-level name/. In the case of SRV, for example, that means that for the core SRV template specification document: 1. The first-level, _Proto name assignment text has to be updated to use the new, Attrleaf global table. 2. The second-level _Service name assignment text can remain unchanged, per RFC 6335. Point #2 is actually not 'special' at all. I'd entirely missed that the very strong need to do the first-level fixup did not also require messing with the existing second-level. As for the proposed 'common, second-level' table... Given that this seems to reduce the Attrleaf 'common second-level' table to only _adsp, I think it best to remove that table entirely from the main attrleaf document, and instead have the separate fixup document contain some text specific to the DKIM document's domain naming scheme, to indicate how future second-level names should be assigned. Since ADSP is historic, specifying modification to it doesn't make sense to modify it. Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
- [DNSOP] Fwd: New Version Notification for draft-i… Dave Crocker
- Re: [DNSOP] Fwd: New Version Notification for dra… tjw ietf
- Re: [DNSOP] Fwd: New Version Notification for dra… Dave Crocker
- Re: [DNSOP] Fwd: New Version Notification for dra… John R. Levine
- Re: [DNSOP] Fwd: New Version Notification for dra… Dave Crocker
- Re: [DNSOP] New Version Notification for draft-ie… John R. Levine
- Re: [DNSOP] New Version Notification for draft-ie… P Vix
- Re: [DNSOP] New Version Notification for draft-ie… Dave Crocker
- Re: [DNSOP] New Version Notification for draft-ie… John R. Levine
- Re: [DNSOP] [art] New Version Notification for dr… Dave Crocker
- Re: [DNSOP] [art] New Version Notification for dr… John C Klensin
- Re: [DNSOP] [art] New Version Notification for dr… Paul Vixie
- Re: [DNSOP] [art] New Version Notification for dr… Paul Vixie
- Re: [DNSOP] [art] redefining SRV, New Version Not… John R. Levine
- Re: [DNSOP] [art] redefining SRV, New Version Not… John R. Levine
- Re: [DNSOP] [art] New Version Notification for dr… Dave Crocker
- Re: [DNSOP] [art] New Version Notification for dr… John R. Levine
- Re: [DNSOP] [art] New Version Notification for dr… Dave Crocker
- Re: [DNSOP] [art] New Version Notification for dr… Alexey Melnikov
- Re: [DNSOP] [art] New Version Notification for dr… Dave Crocker
- Re: [DNSOP] [art] redefining SRV, New Version Not… Ray Bellis
- [DNSOP] Attrleaf _second-Level modifications (was… Dave Crocker
- Re: [DNSOP] Attrleaf _second-Level modifications Ray Bellis
- Re: [DNSOP] [art] New Version Notification for dr… John Levine
- Re: [DNSOP] [art] New Version Notification for dr… Andrew Sullivan
- Re: [DNSOP] [art] New Version Notification for dr… Dave Crocker
- Re: [DNSOP] [art] New Version Notification for dr… John R Levine
- Re: [DNSOP] [art] Attrleaf _second-Level modifica… John Levine
- [DNSOP] Another look - draft-ietf-dnsop-attrleaf-… John C Klensin
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Paul Vixie
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… John C Klensin
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Paul Vixie
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… John C Klensin
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… John R. Levine
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… John C Klensin
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Martin Hoffmann
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Dave Crocker
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Martin Hoffmann
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… John C Klensin
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Dave Crocker
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Kurt Andersen (b)
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… John R. Levine
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… John C Klensin
- [DNSOP] _openpgpkey & _smimecert (was: Re: [art] … Dave Crocker
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Paul Vixie
- [DNSOP] namespace and substring reservations (was… Dave Crocker
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Ray Bellis
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Dave Crocker
- [DNSOP] Additional uses of underscore labels (was… Martin Hoffmann
- Re: [DNSOP] Additional uses of underscore labels Dave Crocker
- [DNSOP] End-to-end _underscore arguments (was: Re… Dave Crocker
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Warren Kumari
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Dave Crocker
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Warren Kumari
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Paul Vixie
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… John C Klensin
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Adam Roach
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Dave Crocker
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… John R. Levine
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Paul Vixie
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… John R. Levine