Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt

"John R. Levine" <johnl@iecc.com> Sat, 31 March 2018 12:15 UTC

Return-Path: <johnl@iecc.com>
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 4497C124C27 for <dnsop@ietfa.amsl.com>; Sat, 31 Mar 2018 05:15:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com
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 5ozYhE9kAe_U for <dnsop@ietfa.amsl.com>; Sat, 31 Mar 2018 05:15:42 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 74AA5124BAC for <dnsop@ietf.org>; Sat, 31 Mar 2018 05:15:42 -0700 (PDT)
Received: (qmail 43119 invoked from network); 31 Mar 2018 12:15:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=a86d.5abf7bec.k1803; bh=T/IXuVUbOloYS5u5AfmRjxTZrgVRumiIw0EvIwAAPqA=; b=CwhnfoUmWwS0hH8DQHG3Q0vG+nT8H2pdALFnugldSPoDuRoll7U/33g/dXob+7Ud7JKlN6uui8NDGKzwsWZvFWpenL/9s3UNeEKCdC9zmJ4bIgAAyUTL9w7tqLTM5vTuBTSbr+OBlcTfseJGRmxreFtOIUdQssc61YhSPhw/jGS3XhAcZiodLFiRujCqFwbziP8326bjptQynHp8fTrStDmH63hz5Sx07fO9EJi3M07rQwSoYXgsOK0yxTfqPIyd
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 31 Mar 2018 12:15:40 -0000
Date: 31 Mar 2018 08:15:40 -0400
Message-ID: <alpine.OSX.2.21.1803310814090.2524@ary.qy>
From: "John R. Levine" <johnl@iecc.com>
To: "Paul Vixie" <paul@redbarn.org>
Cc: dnsop@ietf.org
In-Reply-To: <5AB96669.8050004@redbarn.org>
References: <f7b85bac-b050-5003-2df0-a48b1ef2f929@dcrocker.net> <e1f41670-ada8-eaac-468c-c712b338a10b@dcrocker.net> <alpine.OSX.2.21.1803201804440.8940@dhcp-8344.meeting.ietf.org> <A7711F58-5145-49E8-9158-B2F94D0EABBF@redbarn.org> <7c168dc1-2ea7-d47e-78b7-0380e5d0aa84@dcrocker.net> <alpine.OSX.2.21.1803211104210.9553@ary.local> <5244d327-f8ea-1590-c663-1d92e0b194c4@dcrocker.net> <5F44FA5B42805C52479DE491@PSB> <alpine.OSX.2.21.1803211507380.9666@dhcp-935d.meeting.ietf.org> <1DF1564CC2B88726B2B54CF4@PSB> <5AB89C4C.7090300@redbarn.org> <4C79BE1080735A41C8697C8D@PSB> <alpine.OSX.2.21.1803260915260.19119@ary.local> <0DC55A40A5F920C5F41AB044@PSB> <CABuGu1qZuqtH5qntOhsOZYXXQX8ZkBpMuKmBL3egiiazwLwmWw@mail.gmail.com> <alpine.OSX.2.21.1803262042080.19530@ary.home> <5AB96669.8050004@redbarn.org>
User-Agent: Alpine 2.21 (OSX 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/wocmuU5mHiFNVRUDDxRh_9p2BJA>
Subject: Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.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: Sat, 31 Mar 2018 12:15:44 -0000

Catching up:

>>  Assuming we agree that the table also says where to find the registry
>>  for second level names, this removes and need for special cases. The top
>>  level names _tcp _udp _sctp _dccp all work for SRV and URI and take
>>  service names on the second level.
>
> if you view the use of _tcp by more than one rrtype as a coincidence rather 
> than as evidence for the need for a registry, then we can simply define the 
> global registry out of existence (where it has been until now) and ensure 
> that every rrtype's registry of "_" names is public and easily found on the 
> IANA web site.

I don't think it's a coincidence, but as you noted people will do what 
they do.  One registry should make it easier for sensible people to look 
and say aha, _foo already means something for BAR records so I will use a 
different name for unrelated tags for BAZ records.  Or for unsensible 
people, we can at least be aware of what they do.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly