[DNSOP] comments ( was Re: Call for Adoption: draft-crocker-dns-attrleaf)

Dave Crocker <dhc@dcrocker.net> Mon, 29 February 2016 22:07 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CECB1B3DAC for <dnsop@ietfa.amsl.com>; Mon, 29 Feb 2016 14:07:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level:
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
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 y3HyivSBQzMd for <dnsop@ietfa.amsl.com>; Mon, 29 Feb 2016 14:07:19 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA931B3DA6 for <dnsop@ietf.org>; Mon, 29 Feb 2016 14:07:19 -0800 (PST)
Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u1TM7G41006240 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 29 Feb 2016 14:07:16 -0800
To: Paul Wouters <paul@nohats.ca>
References: <3713017b-cbe6-f4fc-c045-074e0f684952@gmail.com> <alpine.LFD.2.20.1602291046140.15752@bofh.nohats.ca>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <56D4C10C.7070100@dcrocker.net>
Date: Mon, 29 Feb 2016 14:07:08 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <alpine.LFD.2.20.1602291046140.15752@bofh.nohats.ca>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 29 Feb 2016 14:07:16 -0800 (PST)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/0nL6Zkyt5_hNStWBkfsHkLEZ_f4>
Cc: dnsop <dnsop@ietf.org>
Subject: [DNSOP] comments ( was Re: Call for Adoption: draft-crocker-dns-attrleaf)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
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, 29 Feb 2016 22:07:20 -0000


On 2/29/2016 7:54 AM, Paul Wouters wrote:
> Some comments so far:

thanks for pursuing this.  responses:


> Normally we try to leave "private use" ranges in registries for people
> to experiment on. It would be good to have that here as well, or else we
> won't be able to differentiate experimentation from standarization. I
> suggest reserving the double underscore space (__*) for private use
> (provided this isn't already in wide use)

There is a real problem with private naming, and that is that any use of 
private names that becomes successful is then faced with having to 
change all existing behaviors to move to a publicly-registered name.

I think it makes more sense to have new uses choose a name that can 
eventually be registered and simply experiment with it 'raw' until then. 
  Given the size of the namespace, the likelihood of a collision during 
initial testing is quite small.  To make it even smaller, we can make 
the barrier to getting an entry in the _Underscore registry very low.


> The document should probably explain the RRtype listed in the registry
> and interaction/allowance with CNAME/DNAME.

1. What do you mean 'explain' and why should the registry contain this 
information?  Specifically, how is that information essential to simple 
and useful operation of the registry?

2. Entries of this type run the risk of either repeating text in the 
actual specification -- and therefore diverging from it if the spec 
changes -- or badly summarizing the spec.


> Are there any known already existing conflicts where two protocols use
> the same underscore entry. If so, how do we resolve that issue?

I don't recall seeing any, in spite of how many _underscore names there 
already are.


> What are the requirements for entry into this registry. I would not want
> to see a rush of people registering vanity names for pet projects,
> taking away all the sensible one word entries. I see _mail is available :)

Well, we know the concern about vanity use of DNS-related names is a 
long way from silly, so alas I guess we have to worry about that.  grrr...

 From the list of IANA choices for this:

      http://tools.ietf.org/html/rfc5226#section-4.2

I'm inclined to suggest 'Specification Required'.  In my own view, an 
internet draft ought to qualify, since they no longer disappear, but I 
believe the community view is that it would require an RFC or the like.

d/

-- 
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net