Re: [art] draft-ietf-dnsop-attrleaf
Dave Crocker <dhc@dcrocker.net> Wed, 02 August 2017 17:18 UTC
Return-Path: <dhc@dcrocker.net>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53117131C28; Wed, 2 Aug 2017 10:18:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.791
X-Spam-Level:
X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] 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 L9Y_wxYOZNyt; Wed, 2 Aug 2017 10:18: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 944CC131C25; Wed, 2 Aug 2017 10:18: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 v72HJFHJ015102 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 2 Aug 2017 10:19:15 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1501694356; bh=zoFDscr9ZEJE6umnUXSaVno7QEThL9qMd5tc3pGub7A=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=Sy6mY6k2Dmyg4zIUZ2AtY96TfUNN4irgYAwpaJkoc8ZmhvLGFPaavVb+D0DKfJm4U 5FQTI5JLEIzYZ2SxP5ictG3Rd/fUzoHOld5pZkRgKVNfSOo9+tor85Vk8CkKnOpibr JuvJ14d11kffaSpH24D5kxcn1wQLZ4BG5+UtKhmI=
To: art@ietf.org
Cc: tjw ietf <tjw.ietf@gmail.com>, "dnsop-chairs@ietf.org" <dnsop-chairs@ietf.org>
References: <CADyWQ+HiVOz1zrhNeEYnzy4hryrhFu+v5GNWqcXdOqQBeB9Cig@mail.gmail.com> <9fc7ff7d-9f5a-ce2b-9fb1-e9b1c9eb0108@nostrum.com>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Reply-To: dcrocker@bbiw.net
Message-ID: <426c7855-76f7-accf-52e0-45480c778ca4@dcrocker.net>
Date: Wed, 02 Aug 2017 10:18:35 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <9fc7ff7d-9f5a-ce2b-9fb1-e9b1c9eb0108@nostrum.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/8IwWG9hqKdCc0ycx1YyAVpRqu_0>
Subject: Re: [art] draft-ietf-dnsop-attrleaf
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Aug 2017 17:18:52 -0000
On 7/28/2017 8:54 AM, Adam Roach wrote: > The document is pretty clear about its intended scope, containing > statements like: > >> Only the right-most names are registered in the IANA Underscore table > > and > >> The current definition of a global underscore registry attends only to >> the "upper-level" names used for these RRs, that is the "_proto" names. > > But then the table includes things like "_ldap" and "_certificates". The > only SRV records for (e.g.) LDAP will look like "_ldap._tcp...", which > (according Howdy. (Posting this on ART, since that's got the active thread on attrleaf, for the moment.) Thanks for the thoughtful comments on the draft. I've been mulling over the challenges of this registration topic for more than a decade, constantly being hoisted on the petard of established practice... First, underscores can be used for multiple levels of node name. Trying to deal with that fully, in a single spec produced an especially confused draft, roughly 10 years ago. More recently it became clear that this is best handled by the described simplification the spec now declares -- essentially distinguishing between 'top-level' underscore names and separately deal with those below. But, as you note, this is not fully or adequately implemented in the latest versions of the draft. But I'll leave details about further fixes for that, for the moment, because... Second, and much worse, is that the original documentation of underscore use created an inherently-problematic arrangement: Attempting to synthesize some of the registration by incorporating entries in independent registration tables documented in SRV and URI specifications. The semantics therefore would mean there would be more than one 'authority' for name registration. This is a registration model designed to produce collisions. Efforts have been to retrofit an administrative model that accommodated this, where the idea of real-time conflict detection and resolution -- by infinitely diligent and perfectly perceptive -- IANA staff is one of the more recent suggestions. Unfortunately, there is an essential and practical difference between 'excellent' and 'perfect', where the latter is an inappropriate goal for human performance. I've come to the conclusion that "accommodating" the established registration practices is a fundamentally wrong path. The only way to solve a problem of multiple registration authorities is to create a single registration authority. That is, the right path is to create a simple and obvious registration model, and, separately, go back and fix the problematic documents. Therefore I propose to: 1. Have this document define the simple, sole, authoritative mechanism for registering "top-level" (global scope) underscore names. 2. Create a separate document that specifies modifications to the SRV and URI documents, rationalizing the use of underscore names, through the mechanism defined in -attrleaf-. Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
- [art] draft-ietf-dnsop-attrleaf tjw ietf
- Re: [art] draft-ietf-dnsop-attrleaf John Levine
- Re: [art] draft-ietf-dnsop-attrleaf Cullen Jennings
- Re: [art] draft-ietf-dnsop-attrleaf Adam Roach
- Re: [art] draft-ietf-dnsop-attrleaf John C Klensin
- Re: [art] draft-ietf-dnsop-attrleaf Adam Roach
- Re: [art] draft-ietf-dnsop-attrleaf John Levine
- Re: [art] draft-ietf-dnsop-attrleaf Adam Roach
- Re: [art] draft-ietf-dnsop-attrleaf John R Levine
- Re: [art] draft-ietf-dnsop-attrleaf Mark Andrews
- Re: [art] draft-ietf-dnsop-attrleaf John R Levine
- Re: [art] draft-ietf-dnsop-attrleaf Dave Crocker
- Re: [art] draft-ietf-dnsop-attrleaf John Levine
- Re: [art] draft-ietf-dnsop-attrleaf Dave Crocker
- Re: [art] draft-ietf-dnsop-attrleaf John R Levine
- Re: [art] draft-ietf-dnsop-attrleaf Adam Roach
- Re: [art] draft-ietf-dnsop-attrleaf John R Levine
- Re: [art] draft-ietf-dnsop-attrleaf Mark Andrews
- Re: [art] draft-ietf-dnsop-attrleaf John R Levine
- Re: [art] draft-ietf-dnsop-attrleaf Dave Crocker
- Re: [art] draft-ietf-dnsop-attrleaf Adam Roach
- Re: [art] draft-ietf-dnsop-attrleaf Dave Crocker
- Re: [art] draft-ietf-dnsop-attrleaf Adam Roach
- Re: [art] draft-ietf-dnsop-attrleaf Adam Roach
- Re: [art] draft-ietf-dnsop-attrleaf Mark Andrews
- Re: [art] draft-ietf-dnsop-attrleaf Tim Wicinski