Re: Root DSA
Steve Kille <S.Kille@isode.com> Tue, 15 November 1994 10:27 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00988; 15 Nov 94 5:27 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00984; 15 Nov 94 5:27 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa02129; 15 Nov 94 5:27 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.01683-0@haig.cs.ucl.ac.uk>; Tue, 15 Nov 1994 09:30:10 +0000
Received: from glengoyne.isode.com by bells.cs.ucl.ac.uk with Internet SMTP id <g.26013-0@bells.cs.ucl.ac.uk>; Tue, 15 Nov 1994 09:30:04 +0000
To: D.W.Chadwick@iti.salford.ac.uk
cc: osi-ds@cs.ucl.ac.uk, punters@nameflow.dante.net
Subject: Re: Root DSA
Phone: +44-81-332-9091
In-reply-to: Your message of 28 Oct 1994 22:57:00.
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8417.784891770.1@glengoyne.isode.com>
Date: Tue, 15 Nov 1994 09:29:38 +0000
Message-ID: <8418.784891778@glengoyne.isode.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Kille <S.Kille@isode.com>
David, I've looked at your proposal, and the followup discussion. First, I believe that it does not make sense to make changes of the form that you suggest, other than as a part of an X.500(93) transtion. I believe that our current focus should be on transition to X.500(93) and not on the current pilot. The timescales are too short and the pain too large to justify anything else. In particular, the first phase changes you make will have a nasty ripple down effect onto all QUIPU DSAs in the pilot. The only pre-X.500(93) change I would advocate, is incremental changes of the form suggested by Bruno to facilitate the participation of non-QUIPU DSAs in the 1988-based pilot. Second, you started with a proposal to phase out the root DSA. You do this in phase 1, and then in phase 2 you bring it back (as the pseudo root DSA). This suggests to me that phasing out the root DSA may be the wrong idea. I believe that what is needed is to evolve the root DSA service, rather than to phase it out. The current root DSA service performs five functions. 1) Resolving queries 2) Relaying queries 3) Mastering Data 4) Distributing top level data 5) Distributing top level knowledge The first two functions are a problem, as performing it at a central site will just lead to bottlenecks. Work needs to be done to distribute this function and to phase out the service at the root DSA. This is likely to be hard to do completely whilst 3) is done centrally. 3) is a function which should not be performed centrally. The RFC 1276 approach requires this if the level below is replicated (which in my view is pretty much essential in the pilot). Removing this restriction will fall out as a part of the X.500(93) transition, and this is the right stage to do this. 4/5 are functions which need to be provided in the long term. Given the X.500 nature of the data involved, use of X.500 replication protocols and some form of DSA seems to be a natural means to achieve this (you reach this conclusion too). I believe that the key issue here is to define a mechanism to enable the co-ordination service to transition to use of X.500(93) replication protocols for distributing this data and knowledge information. To summarise, we should focus our efforts onto X.500(93) transition, and avoid doing disruptive things to the current pilot. It is important that products are available to enable the transition to be made. Steve Kille ISODE Consortium
- Root DSA D.W.Chadwick
- Re: Root DSA pays
- Re: Root DSA Colin Robbins
- Re: Root DSA Thomas Lenggenhager
- Re: Root DSA Andrew Waugh
- Re: Root DSA D.W.Chadwick
- Re: Root DSA D.W.Chadwick
- Re: Root DSA Steve Kille
- Re[2]: Root DSA D.W.Chadwick