Re: Comments from C Huitema ...
pays@faugeres.inria.fr Wed, 06 January 1993 11:10 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00963;
6 Jan 93 6:10 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00959;
6 Jan 93 6:10 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa04461;
6 Jan 93 6:11 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP
id <g.01514-0@haig.cs.ucl.ac.uk>; Wed, 6 Jan 1993 10:00:05 +0000
Received: from faugeres.inria.fr by bells.cs.ucl.ac.uk with Internet SMTP
id <g.04821-0@bells.cs.ucl.ac.uk>; Wed, 6 Jan 1993 09:59:58 +0000
X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed;
06 Jan 93 10:59:51+0100
Date: 06 Jan 93 10:59:51+0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: pays@faugeres.inria.fr
To: osi-ds@cs.ucl.ac.uk
Subject: Re: Comments from C Huitema ...
Message-ID: <726314391.20040.0@faugeres.inria.fr>
I don't understand why my "Reply-all" did not made its way to osi-ds... here it is again -- PAP > Date: 06 Jan 93 10:22:59+0100 > From: pays@faugeres.inria.fr > To: Christian.Huitema@sophia.inria.fr, > wright@lbl.gov > Subject: Re: Comments from Christian H. on LDAP > cc: "(Paul-Andre.PAYS)" <Paul-Andre.Pays@faugeres.inria.fr>fr>, > wg-nap@rare.nl > > > > > If you allow non-authoritative data to be modified in X.500, you must > > provide an automatic way to transfer the information back to the > > authoritative source. I believe that the University of Michigan is doing > > this. > > > > > It would be interesting to start a discussion on this issue of > X.500 data managemnt. > > 1. Could U. Michigan describe their solution? > > 2. One way we are just starting to explore is the following: > > to manage two parallel and well identified subtrees > . one will be the "authoritative" subtree > it will only be modified (probably not using DAP) ONLY by the > entity managing the subtree > . the second one will be "open" > ie. using the appropriate ACL the entries could be modified by > "delegated" authorities (typically the users for their personal > data, or network managers for a given network subtree aso.) > Periodically the "authoritaive" manager would "collect" information > from the "open" subtree, apply any filtering or checking suitable > and then from this (and possibly from other sources) update the > "authoritative" subtree. There is thus the possibility to > control and correct incosistancies or eliminate "offensive or false" > information ... > > The directory users will thus have the choice to search either for > the "official" information with the responsibilty of the operator, > or to select the "open" information such as provided by > the users > > What about this solution? > > all my best wishes for '93 > > -- PAP > > >