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: Wed, 06 Jan 1993 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>,
> 	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
>
>
>