[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