Re: root knowledge

pays@faugeres.inria.fr Thu, 07 May 1992 20:12 UTC

Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04707; 7 May 92 16:12 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa10338; 7 May 92 16:18 EDT
Received: from bells.cs.ucl.ac.uk by NRI.Reston.VA.US id aa10324; 7 May 92 16:18 EDT
Via: mhs-relay.ac.uk; Thu, 7 May 1992 20:27:27 +0100
X400-Received: by mta mhs-relay.ac.uk in /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Thu, 7 May 1992 20:26:46 +0100
X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; Relayed; Thu, 7 May 1992 20:26:40 +0100
Date: Thu, 7 May 1992 21:26:40 +0200
X400-Originator: pays@faugeres.inria.fr
X400-MTS-Identifier: [/PRMD=inria/ADMD=atlas/C=FR/; 705266800@faugeres.inria.fr]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Re: root know...
From: pays@faugeres.inria.fr
Message-ID: <705266800.6537.0@faugeres.inria.fr>
To: S.Kille@cs.ucl.ac.uk
Cc: "(Paul-Andre.PAYS)" <Paul-Andre.Pays@faugeres.inria.fr>, osi-ds@cs.ucl.ac.uk
Subject: Re: root knowledge

>>

Let's try an answer to your comments or questions (but please
accept my excuses if some stupidities come from my unforgivable
nearly total lack of knowledge of QUIPU.
Please consider this as naive questions from a user
of some other implementations.

> I can see arguments for other means of distributing the knowledge information,
> additional to the protocol described in RFC 1276.  Use of a file format is
> one appraoch.   Another might be a stub server, whihc allows a standalone
> process to extract the information dynamically, which can be modified to
> allow output in a convenient format.

I am not sure about what you mean by "stub server".
I have 2 things in mind:
 a/ some "specialised DUA" able to dynamically extract the required information
	(typically the knowledge, but that might be any DIT branch as well)
	and produce a text based representation in a convenient format.
   . that is what is being done (experimentaly) both by Paul Barker and by
	Ascan Woerman E3X (thanks to both) on base of script for
	some kind of DS shell (dish and duat), plus additional awk
	or equivalent tools to adjust for an intended input to
	a different brand of DSA. The operation is typically
	a search for all objects of class "DSA" somewhere.
   . this proves to be rather awkward; such a script has to be developped
	for each different implementation; there is no easy way to
	separate what is really relevant from other similar objects;
   . mainly, it has the problem of depending on the specific model/choices
	made by one implementation for knowledge representation.
	  eg. it is enough to read all Pizarro DSA objects in order
		to have all the knowledge
	      but, (as far as I undertand) for QUIPU DSA one has
		to also read other objects (EDB?)
	      in both cases specific attributes/objects have to be red,
		which prevents the use of "common tools": a "dish"
		will not "understand" Pizarro specific knowledge
		attributes, conversely "duat" does not undertand EDB info.
 b/ a sophisticated version of the previous one might be designed
	to dynamically "unload" knowlwdge (or other) information of
	one DSA and dynamicaly input it (DAP) to a second different one.

In both cases the same problem remains: even if from outside the
needs and concepts of repliccation and knowledge are the same,
when coming closer the difference in the model behind pops up
and prevent any easy solution to be designed/developped which
can be completely automated.

Thus the file format (more precisely the text format) I was proposing
is a tentative solution to this. The representation will be
a representation of the concept and not one of the actual technique
or mechanism used by a specific implementation to implement these
concepts.

Trying to be more concrete with the example of QUIPU and PIZARRO
in one case the knowledge information associates the name of master and
slave DSA to a "portion of the DIT" whereas the other does exactly the
opposite by associating (by means of attributes) the "portions of the DIT"
to the DSA entry of the DSA which holds them. Yes it is equivalent,
but it prevents any easy interop whatever the mechanism used.

My proposal is a two stage proposal:

  Level 1.
	We limit to aggree on a common "universaly accepted" textual
	representation of the knowledge (but of the rest would be
	really a plus) which is not a mere textual view of the
	implementations choices but really an aggreed standard.
	It will then be feasible (even if not trivial) to design
	develop the scripts ("stub servers") mentioned above.
	In fact it would even be much better to have each implementation
	have the ability to
		. understand this 'common and logical' representation
			-> for input
		. generate this 'common and logical' representation
			-> for output
	(of course that could be means of improved directory shells
	such as dish or duat, or by any other management tool)

  Level 2.
	If we consider that an external textual representation such as
	the previous one is not enough, we just go one step further
	and have this represented by a new object class in the DIT
	itself.
   	-> that would enable easy "on-line" exhange of such information
	without any protocol modification.
	-> there could be an easy transition from the current chaotic
	situation to this new era: There is no need to modify the DSA
	algorithms and code, it suffices for the manager to "replicate"
	within the DIT the "proprietary knowledge represntation"
	into this additional "common logical representation".
	Of course if suitable, nothing prevents future releases to
	use this "common logical representation" as their own and
	unique internal representation :-)

	of the knowledge
	for each
>
> I don't understand why you are suggesting any new attributes and object
> classes.  Can you explain why RFC 1276 does not suffice?
>

I hope the short text above give some justifications to my
suggestion.
About RFC1276, in my mind it is based not on a logical view
of the knowledge but on the QUIPU choices of implementation
of these concepts. This does not mean at all I am criticizing these
choices, that is not the point. I am simply worried that the
EDB choice is apparently far from being universal, but is
strongly influencing several DUA design in using "one level search"
which are often not the "right" algorithm in really heterogeneous
communities.
Of course you can perfectly reply: OK, let just consider the EDB concept as
being the "common universal logical" representation of knowledge;
and happily it happens that QUIPU is indeed using this universal
representation. :-)
Why not, that is certainly a proposal. But then I would like to see
this discussed/analysed in the view of such a goal (that might be rather
different from implementation constraints/choices). I would also
see it being presented to several X.500 suppliers, as for this purpose
it is of the highest importance to reach (if not consensus) maximal
support in order to have weight enough to push almost every supplier
to implement it soon (I believe it is not a mere Internet Cosine
matter and that the impact and influence must spread over all
and every implementation and usage).
EDB seems an efficient solution for "fast searching", but it has in my
mind a too strong impact (if generalized) on the overal operation
of the global directory (because of the necessary regular read of
subordinates for 'spot shadowing" purpose) to be easily accepted
acceptable in every of implementation and usage (eg privacy,
security etc..). I would largely prefer a much more 'neutral"
approach which will not try to solve two problems at a time
   . one is accessibility/visibility of knowledge
   . another one is the performance issue for which my feeling we
	need much more experience and freedom of implementation
	and management choices.
A "neutral approach" would enable just easy "sharing of knowledge"
by just presenting a universal representation of "who manages what"
(which DSA has "master" or "slave" -- or even "shared" knowledge
of what portion of the DIT).
This, of course would not prevent implemntations to propose
ad-hoc solutions (such as QUIPU "one-level-knowledge, but many
others might be considered) for the performance issue.
this might prove valuable in leaving room to competition
and to tackle with the many many different contexts and usages
the directory will be certainly used for.


I hope you understand better my concern and point of view (despite
my really poor english) but I am really waiting for many comments on
these issues... even if it is to explain me how and why I am
completely wrong in this position

Regards,

-- PAP

>
> Steve
>