IETF Logo Mail Archive

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

"John R. Levine" <johnl@iecc.com> Mon, 26 March 2018 19:49 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 C55D4126CC4 for <dnsop@ietfa.amsl.com>; Mon, 26 Mar 2018 12:49:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 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] 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 TUXvqZvKc80h for <dnsop@ietfa.amsl.com>; Mon, 26 Mar 2018 12:49:39 -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 757271276AF for <dnsop@ietf.org>; Mon, 26 Mar 2018 12:49:39 -0700 (PDT)
Received: (qmail 46426 invoked from network); 26 Mar 2018 19:49:37 -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=b557.5ab94ed1.k1803; bh=+laLuD1Mts8dh1IdLTUCk/QTxevYBXuEFnbyApAw748=; b=Z2eOF6Sl3zFJ1KnfDjw1md7wRaZhZwjgpZEB2OFAw42DuQDS7a0mnTAh968qm9mdlBlySEUN6zSRjg0stxtgabHjVP1IcnR99YGeX2bplRslZk/aW0nr/Gel4ThdDiccjV9zpx+TJUxTwn2i9LdtfcKLZYD3qLHrEt10vy7uuZWsPM/L55Xslz53p+QsRXasjRCaDGx1JqG0jCbIsps3ETqgvaDh/7G/le0Em/hclFZBU9PWyOFh5b/HE5Q63cEX
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; 26 Mar 2018 19:49:36 -0000
Date: Mon, 26 Mar 2018 20:49:36 +0100
Message-ID: <alpine.OSX.2.21.1803262042080.19530@ary.home>
From: "John R. Levine" <johnl@iecc.com>
To: "Kurt Andersen (b)" <kboth@drkurt.com>
Cc: art@ietf.org, dnsop@ietf.org
In-Reply-To: <CABuGu1qZuqtH5qntOhsOZYXXQX8ZkBpMuKmBL3egiiazwLwmWw@mail.gmail.com>
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>
User-Agent: Alpine 2.21 (OSX 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1cujzRYjE7USuOTQcZsoHePOZbk>
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: Mon, 26 Mar 2018 19:49:41 -0000

>>       | _spf        | TXT | [RFC7208]  | <-----

That's just a mistake.  Take it out.

Apropos of John K's comment about per-type names, he's right.  Given that 
people can do whatever they want I have to agree that if people want to 
define names that way, we can't prohibit them.

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.

R's,
John

v2.23.0 | Report a Bug | By Email