Re: [DNSOP] Some distinctions and a request

Andrew Sullivan <ajs@anvilwalrusden.com> Tue, 30 June 2015 22:53 UTC

Return-Path: <ajs@anvilwalrusden.com>
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 4E0531AC42D for <dnsop@ietfa.amsl.com>; Tue, 30 Jun 2015 15:53:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 bvlF7Cs2mMys for <dnsop@ietfa.amsl.com>; Tue, 30 Jun 2015 15:53:36 -0700 (PDT)
Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 942361AC428 for <dnsop@ietf.org>; Tue, 30 Jun 2015 15:53:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id DFAAA10370 for <dnsop@ietf.org>; Tue, 30 Jun 2015 22:53:34 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwkjYZpRZN0o for <dnsop@ietf.org>; Tue, 30 Jun 2015 22:53:33 +0000 (UTC)
Received: from mx2.yitter.info (unknown [IPv6:2601:18d:8600:22:c9f0:75d4:bee4:7fb1]) by mx2.yitter.info (Postfix) with ESMTPSA id CF5EF1000B for <dnsop@ietf.org>; Tue, 30 Jun 2015 22:53:33 +0000 (UTC)
Date: Tue, 30 Jun 2015 18:53:32 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20150630225332.GR29767@mx2.yitter.info>
References: <20150623160722.GA26267@mx2.yitter.info> <D1B17D4F.C773%edward.lewis@icann.org> <20150629174259.GE29767@mx2.yitter.info> <D1B7EDC5.C8A6%edward.lewis@icann.org> <20150630151801.GN29767@mx2.yitter.info> <D1B83710.C8FF%edward.lewis@icann.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <D1B83710.C8FF%edward.lewis@icann.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/MCo90-yDRam0u1F0euZNfAPXyvY>
Subject: Re: [DNSOP] Some distinctions and a request
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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, 30 Jun 2015 22:53:41 -0000

On Tue, Jun 30, 2015 at 04:27:10PM +0000, Edward Lewis wrote:
> 
> So this is about words - what you call a negative registration is a
> registration nonetheless, with an responsible party.

Well, it's about conceptual clarity.  If we want to call that
"negative registration" instead "skippy the wonder dog", I don't care.
But there's a difference between "positively registered with someone
that delegation is not allowed" and "a possible name enumerable in the
namespace that is not registered."  I hope we can agree on that.

> How can I not (conflate them)?  I don't follow you.

I am trying to draw a distinction.  I'm going to try one more time
here on the list, begging everyone else's indulgence, and then if that
doesn't work I'm going to figure that I can't explain it.  Perhaps
another way to say this is that the term "DNS" has taken on a separate
meaning from "domain name", but I think that's not necessary:

On the one hand, we have the domain name space.  It encompasses within
it all the logically-possible domain names.  These are all the names
of one or more labels, where one label is null length and is the last
label, and all the other labels are between 1 and 63 octets.  The
whole name must be under 255 octets.  Otherwise, there is a variable
number of labels and each label may vary in length according to the
above restrictions.  It is, as you point out, a finite name space.

On another hand, we have the _DNS_ space.  This is a subset of the
domain name space as such.  The DNS space is all the names covered in
the domain name space, that may in fact be registered (not just
delegated, but registered) in the DNS.  (Note that DNS means domain
name system, so another way to say this is that these are the domain
names that are in fact allowed in the system.)  I say that
protocol-switch names like local. are inside the domain name space,
but not in the DNS space, because they function to switch any lookup
out of the domain name system and into some other resolution
mechanism.  Other special names do not have the same effect --
invalid., for instance, does not.  (Note that one consequence of this
is that the null-length label is special in more than one way, because
it has to exist in every system namespace.  I think that's all right,
because these different names are all within the domain name space,
just not in the DNS space.  It's conceptually hideous, but I can see
why people do it in implementation.)

(I'm leaving out the zone space here, because that's yet another
subset, of DNS space, and we seem to agree about that.)

> what I understand that would be a $key.onion.  I don't grok how
> $key.onion. "can't possibly be" a domain name given that "onion." is.

both $key.onion. and onion. are domain names, but they're not in the
DNS namespace.

> DNS."  Do you mean names of greater than 256 octets, etc., not possible
> because they violate syntax rules?  Or...I don't follow.

There are names outside the domain name space, yes.  A name that has a
label longer than 63 octets is outside the domain name space.

> special-use domain name registry.  Perhaps it's confusing because RFC 6761
> defines "Special-Use Domain Names" and not Special-Use Names.  From the

Yes, they're domain names, but not DNS names.  

> Well, it's odder than that.  There is ICANN's WhoIs and IANA's WhoIs.  I
> mentioned IANA's specifically for a reason. 

Ok, a fair point.  But surely ICANN could register names that it will
not (by policy) admit to the IANA root zone in the IANA whois without
any delegation?  Hmm, I suppose not, given the IANA rules for
registrations.  This is an interesting policy problem, but fortunately
not one we have to discussion on DNSOP.  I understand there was a
large meeting recently that might have presented a forum for this.

> database (anywhere, all the time).  I really don't know if there is a
> formal listing of "IETF." as having any status in any register.  (Using
> the dictionary definition of register as an official roll.)

It's in a list in the Applicant Guide Book, as I mentioned in the
previous message.  Given that the AGB is the holy tome of new
non-ccTLD allocations for registration by ICANN, I think that counts
as an official roll.
 
> What's "the AGB"?

"Applicant Guide Book".  "AGB" seems to be a common shorthand for this
in ICANN circles.  Sorry for the jargon.

> No, people can implement an RFC.  

Yes, and then they have an implementation which implements the RFC.
At least, that's the way people say such things to me.  I agree it's
too bad that we don't have the lexico-grammatical precision in English
that Latin does, but here we are.

Anyway, I hope this helps.  If not, then perhaps I'm completely wrong
or perhaps I'm just doing a poor job explaining myself to you.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com