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, 07 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 >
- Re: root knowledge Colin Robbins
- Re: root knowledge pays
- Re: root knowledge Steve Hardcastle-Kille
- Re: root knowledge Sylvain Langlois
- DSAs through ISDN connections Sylvain Langlois
- Re: root knowledge pays
- Re: root knowledge Colin Robbins
- Re: root knowledge pays
- Re: root knowledge Colin Robbins
- Re: root knowledge pays
- Re: root knowledge Colin Robbins
- Re: root knowledge pays
- Re: root knowledge Christian Huitema
- Re: root knowledge Steve Hardcastle-Kille
- Re: root knowledge yeongw
- Re: root knowledge Andrew Waugh
- Re: root knowledge yeongw
- Re: root knowledge Andrew Waugh
- Re: root knowledge yeongw
- Re: root knowledge Thomas Johannsen