Re: IP namespace (Was: Re: root knowledge)

[[e-mail]]

> I thought IPs (as representatives of
> network nodes) could be hold in the geographical White Pages name space
> until recently :-(. The main problem I see with these IP entries is how to 
> organize the database.
> 
> Let me discuss some alternatives:
> 
> 1) There is one root entry o=IP and immediately below we have all (valid)
> IP addresses, each as one object
> 
> 2) Below o=IP we have non-leaf-entries for each IP address group
> (according to A, B, C class adresses).  [ ... ] Within the proper
> class address you'll find all (valid) IP [addresses[ [ ... ]
> 
> 3) We get involved with DNS and build a DNS structure holding domain names
> and their IP addresses. But I don't like it very much and see your point,
> Wengyik, as given below.

All three of these are of valid alternatives, and in fact (2) on a slightly
more general scale is what I had in mind.

(1) I am inclined to reject because the namespace is too 'flat'. What
you're essentially proposing with (1) can have only two consequences
depending on how the address space is distributed in reality:

	- the entire IP address space is held in an entity operated
	  by a single administration. This is nothing more than
	  loading /etc/hosts into the DIT, and for all the same reasons
	  we moved from /etc/hosts to the DNS, we should try to avoid
	  this scheme.

	- the flat space is carved up with subordinate references into
	  'pieces' held by several administrations. The likelihood here
	  is that the 'owner' of an IP address (or its designee) will
	  want to hold the 'piece' that corresponds to the IP address
	  (and in fact, should be encourage to do so).  This leads to
	  severe fragmentation of a namespace that doesn't
	  have the hierarchical depth to deal with it: there are
	  thousands of IP addresses assigned now. Think what would happen
	  if you had to do a search that had to chase a few thousand
	  subordinate references (which is what this flat namespace
	  essentially requires, modulo any caching/slaving that is
	  being done).

(2) is much better (or at least, it is what I had in mind :-)). I'm somewhat
puzzled by your characterizing it as an alternative to a separate hierarchy,
because if I understood (2) correctly, you've described a separate hierarchy
that happens to be rooted at someplace other than the root of the DIT. That's
fine: I wasn't suggesting rooting the separate hierarchies under the
root of the DIT. To be honest, I haven't given much thought to the problems
of representing the IP address space, so I couldn't tell you where I
would want to put the separate hierarchies. My personal knee-jerk reaction
is that it should go under o=Internet actually (but don't hold me
to this :-)).

I only have one little quibble with (2) which is that I still think
there is insufficient hierarchy. If I understood what you're suggesting
in (2) correctly, you're proposing carving up the IP address space
into three large subtrees, respectively for class A, B, C addresses.
Underneath each 'subtree' is again a large flat space containing
all addresses in that class. My objection to the large flat space are
the same as in (1).

What little thinking I've done on this subject has however been along
the lines of (2) except that I want to carve up the namespace into
a hierarchy so that subtrees corresponding to a IP network can be delegated
to the 'owner' of the network assignment. The 'brute force' method
is to borrow from the DNS and carve along the same lines as the
INADDR.ARPA space is carved, by network byte components. The problems
with doing this is

	(a) that scheme has a lifetime that will hopefully
	    be measured in months due to the big-internet work
	    on classless, enormously scaleable IP addressing and
	    routing. There are already discussion within the
	    DNS context as to how to carve up INADDR.ARPA in the
	    future, and by going this route, we're essentially
	    investing in a scheme that could easily be obsolete
	    by the time it is deployed.

	(b) you end up with interior nodes like 192.0.0.0 and 
	    128.0.0.0 which don't really 'belong' to anybody but
	    are instead public resources. This is a minor problem
	    which could easily be handled the same way we're handling
	    the infrastructure between national nodes and organizational
	    nodes (in the case of the U.S. these would be the 
	    U.S. state/equivalents and the U.S. counties within states),
	    but is a problem nonetheless.

	(c) by representing IP addresses by their byte components,
	    some semantic information is lost, for example the
	    fact that 128.1 (just to pick an example) is a network
	    in its own right, and that it is not the case that
	    128.1 is a subnet of a larger network 128.0.0.0. This
	    only gets worse when the Internet stops 'hard coding'
	    in distinctions between network-component and host-component
	    and starts viewing networks as classless.

[That said, this is still closest to the ideal for me, since I can't think
 of anything better at the momement.]

(3) is essentially a suggestion to continue the status quo by pretending
that IP addresses are 'special' domain names. This is actually not
such a bad idea in my opinion since we already know how to deal with
this case. I would like to at least try to do better, since I get the
impression that this was a tack-on to the DNS proper to begin with,
and had its own problems.


Wengyik