Re: [Inip-discuss] Domain Names

[Lyman Chapin <[e-mail]>]

On Jan 15, 2016, at 2:03 PM, Warren Kumari wrote:

> On Fri, Jan 15, 2016 at 5:43 AM Olaf Kolkman <[e-mail]> wrote:
> 
>> On 14 Jan 2016, at 15:11, Lyman Chapin wrote:
>> 
>> Hmm… but I thought we were discussing the syntax of the name-space. It
>> seems that we then arrive at 3 things that all hook together: syntax,
>> namespace, and resolution protocol.
>> 
>> 
>> A domain name that identifies a point within the domain name space has a
>> syntax, but the name space itself does not. Syntax is a set of rules that
>> govern the structure of (in this case) domain names - the composition of
>> labels, and how they may be ordered. The domain name space is just a
>> labelled directed rooted tree, a math/graph construct that doesn't have (or
>> need) a syntax. (I apologize for the way in which this sounds "preachy" -
>> I'm just trying to be as precise as possible in the way in which these
>> terms are used.)
>> 
>> 
>> 
>> The Internet DNS namespace is specifically defined through the resolution
>> system starting at the IANA root. To first approximation it is the hints
>> file used at the resolver that defines the name-space.
>> 
>> 
>> The domain name space is explicitly (going back to RFC 1034) not defined
>> by the DNS resolution system. If it's useful to do so, we can define the
>> "Internet DNS namespace" to be the domain name space overlaid with the
>> semantics expected by the resolution system (servers and resolvers). But
>> that would assume an answer to at least one of the questions we're still
>> discussing: "if it is resolved by something other than the DNS, is it a
>> domain name?"
>> 
>> Aha…
>> 
>> I conceptually I always thought there are multiple domain name spaces
>> where each names space is internally consistent (In the context of
>> alternate roots: different root-hints implies different namespace). So for
>> me name-spaces are plural. When you talk about the domain namespace I note
>> you talk about as singular.
>> 
>> In your definition you say "The domain name space constitutes a labelled
>> directed rooted tree" I guess the specifics of that root are important. I
>> tend to think of my.server.in.my.home as being part of a different
>> name-space as the isoc.org in my email address.
>> Both seem to be captured under your definition. Correct?
>> 
>> So perhaps as a question: Does your definition allow for multiple
>> namespaces, do we want a definition to allow for multiple namespaces.
>> 
> 
> ... and I have a larger / meta question.
> Much of this discussion seems to have turned into deep navel gazing.

Is that a particularly intense form of the well-defined activity of gazing at navels, or an unspecified level of interest in gazing at a subclass of navels that have the property "deep"? Be precise, man! :-)

> 
> Let's pretend for a bit that we come up with a perfect definition of
> "namespace" and "domain namespace". It's clean, it's pretty, it's
> understandable by the average monkey....
> Great. Now what?

The point of the definition is not to be perfect, but to be useful. If you establish (by definition, which in this case begins with RFC 1034) that the domain name space is a LDRT with [L]abels that adhere to a specific well-defined syntax, you can use that to structure and constrain the discussion that really matters, which is indeed your "now what?"

Because it's the rules and procedures for domain name resolution that add meaning (semantics) to domain names - which in themselves are simply sequences of labels directed to the root of the domain name space, with no intrinsic meaning - we can start by saving ourselves the time and effort necessary to pursue any discussion that invokes "multiple namespaces." We have a protocol (semantic) problem, not a problem with the domain name space or the syntax of its labels. That seems like a valuable, tangible, and practical benefit of having a good definition - we know something useful about where to go looking for a solution to the problem of what we've been calling "special names." It's not the names as identifiers that are special - they follow all of the composition rules, and are as ordinary as any other name in the domain name space - it's what we want them to mean to the protocol machinery that manipulates them.

I understand your argument to be that until we get to the specification of the semantics, we have nothing that we can actually work with, so we might as well start at the point at which the domain name space is associated with the specific semantics of the DNS, and simply call that the "domain name space." But as I pointed out in an earlier reply to Olaf, that puts you past the point at which you can meaningfully ask "can some resolution system other than the DNS associate a different semantics with the domain name space?" And the problem we have right now is that different other systems are "not-DNS" in different ways - the .onion case is not the same as the .local case, much less the YetiDNS case. All of them, in fact, rely on the idea that they can be entirely "DNS" in most respects, but observe a specific exception to the semantics that the DNS associates with domain names - because there's a lot of convenient software out there that implements the "DNS" semantics, so the more your stuff looks just like that, the shorter your product development time (and user learning curve) can be.

So we want these "special names" to behave normally with respect to DNS resolution right up to the point at which they hit their special switch - and at that point, we want the resolution process to do something different. It's the switch point in processing that matters, not the name; so I would be inclined to look for solutions in the RRsets that direct the resolution process, not in the names of the zones.

However, because a "special name" is a piece of the commonly shared domain name space, the political question "who gets to have one?" is not answered by any solution to the technical problem of implementing the processing switches that would be required to create the "special" behavior. The bar for reserving a special name should be very high, and higher the more it burdens everyone else. But now we're at a different layer of the reference model :-)

- Lyman

> 
> Does this somehow help solve the underlying issues? Do we have a clear
> description of what the underlying issues actually *are*? Who uses this
> definition? Where? How?
> 
> Yes, having a definition so that we all know what we are talking about is
> useful; it's like having a good tool in our toolbox, but what are we
> actually going to build with this tool? Who has the plans?
> 
> W
> 
> 
> 
> —Olaf
>> 
>> ------------------------------
>> Olaf M. Kolkman
>> Chief Internet Technology Officer Internet Society
>> <http://www.internetsociety.org/>
>> e-mail: [e-mail]
>> LinkedIn:OlafKolkman <https://nl.linkedin.com/in/olafkolkman>
>> Twitter: @Kolkman <https://twitter.com/kolkman>
>> ------------------------------
>> 
>> _______________________________________________
>> Inip-discuss mailing list
>> [e-mail]
>> https://www.iab.org/mailman/listinfo/inip-discuss
>> 
> _______________________________________________
> Inip-discuss mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/inip-discuss