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