Re: [DNSOP] attrleaf

Paul Vixie <paul@redbarn.org> Tue, 28 March 2017 19:37 UTC

Return-Path: <paul@redbarn.org>
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 42BDE129A02 for <dnsop@ietfa.amsl.com>; Tue, 28 Mar 2017 12:37:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 2TBLf_qwxdAI for <dnsop@ietfa.amsl.com>; Tue, 28 Mar 2017 12:37:29 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 281331294A1 for <dnsop@ietf.org>; Tue, 28 Mar 2017 12:37:21 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:50e4:c235:dee1:8442] (unknown [IPv6:2001:559:8000:c9:50e4:c235:dee1:8442]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 1710861F9D; Tue, 28 Mar 2017 19:37:20 +0000 (UTC)
Message-ID: <58DABB6F.1060208@redbarn.org>
Date: Tue, 28 Mar 2017 12:37:19 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.12 (Windows/20170323)
MIME-Version: 1.0
To: John R Levine <johnl@taugh.com>
CC: dnsop@ietf.org
References: <20170328183740.2502.qmail@ary.lan> <58DAB425.8060100@redbarn.org> <alpine.OSX.2.20.1703281422420.4385@dhcp-80f1.meeting.ietf.org>
In-Reply-To: <alpine.OSX.2.20.1703281422420.4385@dhcp-80f1.meeting.ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/CYgcGAlq5mA9fRBVaZQAqnfe-So>
Subject: Re: [DNSOP] attrleaf
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: Tue, 28 Mar 2017 19:37:31 -0000


John R Levine wrote:
>>> ...  It's not offering advice that
>>> underscore names are wonderful, it's recognizing the ones that are in
>>> use now.
>>
>> as you wrote above, it's also saying "how to add new names". i'd like
>> our advice in this regard to be considered excellent.
> 
> It's only providing the mechanics to add a name to the registry, same as
> is in every other RFC that defines a registry.  It's not policy advice
> on using them in protocols.  If you want to write Underscore Prefixes
> Considered Harmful, that's fine, but it's a different document.

we're dancing on the heads of pins here.

if someone wants a new _ name entered into a registry, and if they plan
to use it in a way that creates a sub-hierarchy, they should be advised
not to follow SRV's example, and in my opinion, the example that ought
to be set for them would be what SRV (and DS) ought to have done, as
described up-thread.

to describe a registry and its mechanics for _ names, without showing
some example of how they would be used or why a reserved name is
important for rendezvous purposes, would be a quarter-step.

-- 
P Vixie