Re: Doc[1] Charting Networks

Peter.Sylvester@inria.fr Mon, 09 November 1992 18:22 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19808; 9 Nov 92 13:22 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19804; 9 Nov 92 13:22 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa03831; 9 Nov 92 13:23 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.06089-0@haig.cs.ucl.ac.uk>; Mon, 9 Nov 1992 16:48:14 +0000
Received: from concorde.inria.fr by bells.cs.ucl.ac.uk with Internet SMTP id <g.28628-0@bells.cs.ucl.ac.uk>; Mon, 9 Nov 1992 16:47:47 +0000
Received: from nuri.inria.fr by concorde.inria.fr; Mon, 9 Nov 92 17:46:23 +0100
Received: from localhost.inria.fr by nuri.inria.fr; Mon, 9 Nov 92 17:43:37 +0100
Message-Id: <9211091643.AA27157@nuri.inria.fr>
To: Glenn Mansfield <glenn@aic.co.jp>
Cc: spp@aic.co.jp, ic-tech@isode.com, osi-ds@cs.ucl.ac.uk, thomas@aic.co.jp
Subject: Re: Doc[1] Charting Networks
In-Reply-To: Your message of 09 Nov 92 11:20:08 +0900. <9211090220.AA07142(l)a(r)aic-wide.aic.co.jp>
Date: Mon, 09 Nov 92 17:43:36 N
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Peter.Sylvester@inria.fr

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 

  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. 
 
  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.
 
have fun.
Peter Sylvester -- INRIA France
PS: I certainly would like to use the "network schema" also for networks
of message transfer agents and other kinds of distributed applications.