Re: Network Infrastructure

[Thomas Johannsen <[e-mail]>]

Mark,

I went through your Internet-Draft "Representing Networking Infrastructure
Information in X.500" in detail now.

It seems to solve several administrative problems. There is no doubt that
we need a network object. Speaking about your ipNetwork and its attributes 
I came across the following points:

a) While you didn't mention it explicitly I read that for you a network
   is determined by its class-X address. That is certainly true and useful
   for the registration of networks. On the other side, many organizations
   do subnetworking within their (let's say class-B) address space. 
   I think some of these subnetworks have similiar properties as class-X 
   networks (physical location, contactPerson, services running, etc.).
   The Directory should be able to show the relationship between a network
   and its subnetworks as well as holding attributes for both objects.
   
b) In figure 1 and 2 you show where to hold network objects in the DIT. 
   Let's forget about aliases for a  moment and only consider the ou=IP
   Networks subtree. Actually, we (i.e. Soft Pages Project) followed the
   idea of holding entries for all networks at one level for a while as
   well (see our doc ip.ps). However, we already have several thousand
   class-X networks and with more organizations joining (and asking for
   class-C addresses) we will end up with a _very large_ single flat tree.
   Using it is problematic because it has to be held at one central place
   (how else can you find a network by its name?). Last but not least
   Steve H-K advised against this proposal while discussing the topic with us.
   Meanwhile we switched to a multi-level structure which should solve both
   problems: Subtrees can be spread to several DSAs and networks can have 
   networks as subordinates. (Actually, the multi-level IP tree only holds
   pointers to "top-level" networks and those have subnetworks).

c) Unfortunately, I couldn't find any information about representing the
   "in-AddrServer" object ("...is assumed to be a computer in the
   directory."). Perhaps I have to explain here that we are very much
   interested in putting a detailed picture of the network in the
   Directory, including single computers and their interconnection. If you
   came across a brilliant idea how to represent computers I'd love to know
   more about that. 
   One thing I'll definitely need is some kind of IP look-up service. With
   your scheme I can come to the network and then...?

d) The aSPath attribute seems to be very specific to NSFNET. Is that just 
   an example or are there other reasons to stick to NSFNET? Our scheme
   (far from being perfect :-) knows of links between networks, including
   routing information. Would that cover the info you want to get out of 
   aSPath?

To summarize: Obviously, you and we have started from a different point
of view. For you policy (registration, service provider, etc.) is
important and for us single physical networks and nodes. But, once we put 
network objects in the Directory, they should be able to answer several 
question, right? I think there is no sense in defining "your" and "our"
network objects and holding them both in. That's why I'd like to see some 
form of conglomerate evolving. Hopefully Boston will bring some progress.

Sylvain, I hope we can find a way to include your information as
well. Unfortunately, I don't know what your objectives are in detail.  
We have already thought about using the RIPE line database for our
purpose. This would put most of that line info in the Directory. What do
you think of this? 


Comments welcome,

Thomas