IP namespace (Was: Re: root knowledge)

[Thomas Johannsen <[e-mail]>]

> From: [e-mail]

> For starters, in the Internet, I think we need to get the
> domain namespace and the IP address space (which is a "namespace"
> of sorts -- and yes, I do mean network addresses in general, not just
> IP addresses, but the reality right now is that the pressing need
> is for IP address representation) in. There are a number
> of relationships, network <--> network contact, domain <--> domain
> contact, domain(s) <--> network(s) to name just three pairs, which are
> best (from both modeling and performance standpoints) represented
> by pointers between hierarchies, and not as explicit entries shoehorned
> into the existing geographical namespace.

Putting the IP name space in the Directory certainly requires its own
hierarchy. But I must admit that 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. I am not going into detail what this "IP
address object" might look like, probably something about performance and
admin contact. The whole subtree could be hold by one DSA and searches can
be resolved within that DSA (or not at all).

2) Below o=IP we have non-leaf-entries for each IP address group
(according to A, B, C class adresses). Just for the rest of this
mail I'll call them "sub". Within the proper class address
(e.g. sub=1.0.0.0) you'll find all (valid) IPs (e.g. 1.2.3.4). In case 
again the whole subtree is hold by one DSA we can compare search operations 
with respect to speed / answer time (at least I'm interested in getting the
answer as soon as possible and without causing hundreds of DSA contacts :-)
). While the search for a specific IP address is now restricted to one
subtree within o=IP and therefore probably faster than in 1) (because there
are not so many entries at this level), it might require another look-up
to find out how the appropiate sub is called (in case I don't know
that 240.80.4.1 is supposed to be in sub=240.80.4.0 because it's class C).

However, to stress the positive point, this naming scheme allows to
distribute the DIT. Each sub can be hold (and maintained) by a DSA
near to the subnetwork. Therefore local IP address look-ups can be
answered locally - for me a very important point. I am aware that "near"
is a relative term in this case. Of course some subclass addresses are
spread all over one country or among several countries. Anyway, there are
locally maintained subclasses within universities and the like.

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.

> (b) specifically in reference to putting the DNS into the DIB, all
>     the DNS proponents are invited to note that I did not mention
>     "domain name <--> IP address" as a relationship that needs to
>     be represented above. Not that it isn't a useful relationship, of
>     course, just that the Internet already has a perfectly good
>     way of representing this relationship in the DNS system itself.
>     The point is this: I'm not interested in playing the "my
>     protocol is better than your protocol" game [...]
> 
> Wengyik
> 

At the moment I see 2) as best choice of the three discussed. But I am not
really happy with it, because still the database isn't well organized and
searches might cause a lot of traffic.

Is there a point I am totally ignorant about? What is the current state of
implementing IP name space (apart from @o=Internet@ou=Site Contacts)?

Any comments are highly appreciated,

Thomas