Re: [DNSOP] Some distinctions and a request

[Andrew Sullivan <[e-mail]>]

On Tue, Jun 30, 2015 at 11:43:42AM +0000, Edward Lewis wrote:
>  You can then divide the list into names that have a responsible party and
> those that don't - and call that (positively registered) and not (or
> negatively) registered.

This is a different use of "positively|negatively registered" than I
outlined.  The case that I was talking about I think _does_ have an RP
for the negaitve registration.  But that registration is there to
prevent delegation.  Another example of this is the controversial
reservation practices in xxx and sucks: you pay your money for a
registration to guarantee that the name will _not_ be delegated.

> I separate registration from delegation.  Registration means I have
> entered the domain name in database (or register as a noun) with some
> characteristics.  The characteristics include contact information (e.g.,
> technical, abuse) and/or whether the name is available for some operations
> (etc., delegation, re-registration).
> 
> Delegation refers to the "DNS as per STD 13" action of entering NS records
> and giving total control of the names below the name in the DNS namespace
> tree to an (possibly different) authority.

Yes, exactly.

> I'm not aware of "the rule" that declares Onion names as part of the
> domain name space.  Not an argument, just a data point.  I've always
> heard, and have been running on this, that Onion names are not part of the
> DNS name space.

You're conflating "DNS name space" and "domain name space" again.  I
didn't say they're part of the DNS name space; and given what the
top-level label onion. does, they can't possibly be.  At the
beginning, I claimed that the domain name space was all the logically
possible domain names, not all the ones in fact possibly in the DNS.
Under this definition, local. is part of the domain name space and not
part of the DNS name space (because of local. being registered in the
special use names registry).

When I asked about this before, one of the onion proponents told me
that onion names have to conform to DNS (and, he claimed, LDH) rules
right now, though that is a possibly temporary convention. 

> Let me go backwards.  I asked the WhoIs server of IANA and it does not
> know of "IETF."  "IETF." is in the finite roster of domain names, it is
> not delegated (owns no NS records) and is not present in a register as far
> as I can tell.

That's because you're assuming that the whois contains all
registrations in the top-level name space.  I wish it were true that
ICANN, in its role as steward of the root zone, registered things in
the root whois that it was registering/reserving from allocation to
others.  But it doesn't, for reasons known best to itself.  The AGB
clearly reserves some names from use, which I think pretty plainly
puts them into the DNS name space and outside of eligibility for other
registration.  That is, I claim, a negative registration of the name.

> I think/assume/believe that Onion is name that has been deployed through
> out the network in such a way as to set up a potential conflict with the
> use of "onion." as a domain name.

This line of argument is collapsing the very distinction I was trying
to make.  Onion and (say) corp both have that property, but only one
of them is functioning to signal a protocol change.

> register the name.  But to me that is an incomplete process.  Who or what
> is the entity that is assigned/owns the name?  (Okay, the registry
> identifies an RFC that ought to have that information.)

Are you arguing that is inadequate?  If so, a reason why would be nice.

> Once registered
> in that way, should the name be delegated?  What I hear is no.

I think pretty obviously this depends on the use case, which goes in
the defininig RFC if I read 6761 correctly.

> My analogy is human spoken languages.

Where computers are concerned, that is almost always a mistake.

> Not programatically.  Code can't read RFC. ;)

But it can implement one.

> Alain Durrand and I talked about this a few weeks back.  He made the point
> that you can distinguish the namespace of an identifier "on the right" or
> "on the left" imaging the use of names in URLs.  I.e., there could be a
> "http-tor://tor-name.onion/path" and use http-onion to tag this as a Tor
> identifier or "http://tor-name.onion/path" and assume it's Tor because of
> the onion where I'd expect(*) a domain name to be.

I think this is a terrible confusion of URI schemes vs. name-space
switches.  It's true that if you treat the URI as an unformatted
string you can parse it this way; but there are already rules for
that.  But I think anyway that's a distraction.  We don't need
uri-schemes to creep into this.

Best regards,

A

-- 
Andrew Sullivan
[e-mail]