Re: Doc[1] Charting Networks

[Glenn Mansfield <[e-mail]>]

Peter,

   >>With great interest I have read the "Charting Networks in the Directory"
   >>document from G.M, T.J, and M.K. I would like to provoke some discussion
   >>by presenting some thoughts, ideas, and problems that came up while I was
   >>experimenting with a "representation of EARN network information in x.500"
   >>in the view of this text, and 

Thanks for your interest. 

   >>
   >>  Some directory user agents may not have enough capabilities to 
   >>  work with arbitrary schema.  
   >>  This is not really a problem of hard coded software, but rather
   >>  of unclear methods to distribute schema information. 
   >> 
You may be aware of work is going on to tackle this problem- by keeping
	"Schema Information in the X.500 Directory"
The document was in the form of a draft proposal in July 1992. I donot know
the current status. Possibly Tim Howes ([e-mail]) or Steve E Kille
([e-mail]) could enlighten us on the status.

   >>  Trying to define a schema for network information may be an non converging
   >>  process. There may be other "things" (I am avoiding the word attribute) 
   >>  associated to CommunicationObject than just "technical contact person", 
   >>  "adminstrative contact person".
   >>  At least a semantic definition is missing in the text but in
   >>  addition I also see other possible "roles" like "operator". "hotline",
   >>  etc. (I will not give the semantics here either). 
   >>
   >>  There is an alternative: Instead of defining attributes for such
   >>  "roles" one could use an object class similar to "organizational role"
   >>  This leave the schema stable while allowing extensions. 
   >> 
   >>  One aspect is is whether one wants to treat certain things just 
   >>  as attributes of some object OR as different objects.
   >> 
   >>  As an example: If the collection of PORTs are treated as separate objects, 
   >>  then a list of persons who (may)perform certain actions on a device
   >>  may also be a list of roles in a subtree under the object.
   >> 

Absolutely true. That is the reason we used the concept of "images" which is 
an abstraction of the role a "thing" plays or the view in which the "thing" is
seen. This method has helped us accomodate several "real world" requirements.

Below I have attempted to show how the class hierarchy accomodates the various 
functional images of the same CO


                        +------------+                               
                        |    CO      |                                                   
                        |            |                                                   
                        +------------+                                           
                           /       \                                                  
                          /         \                                                 
            +------------+           +-------------+                             
            |   PCO      |           |    ICO      |                             
            |            |           |             |                             
            +------------+           +-------------+                             
                                     /      |      \                             
                                    /       |       \                            
                                   /        |        \                           
                                  /         |         \                          
                     +------------+  +------------+   +------------+             
                     | INTERNET-  |  |    SNA-    |   |    OSI-    |                     
                     |   ICO      |  |    ICO     |   |    ICO     |                     
                     +------------+  +------------+   +------------+                     
                         
                                              
I hope the above clarifies our thinking on some of the issues we have raised.

   >>PS: I certainly would like to use the "network schema" also for networks
   >>of message transfer agents and other kinds of distributed applications.

That is somemore food for thought. Thank you.

Cheers

glenn

 *****************************************************************
 * Glenn Mansfield                                               *
 * AIC Systems Laboratory                Phone : [phone] *
 * 6-6-3, Minami Yoshinari               Fax   : [phone] *
 * Sendai, Japan. 989-32                 e-mail: [e-mail] *
 *****************************************************************