Re[2]: Root DSA

[[e-mail]]

From: Steve Kille <[e-mail]>

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.

My reply:

I was asked by Dante to look into the removal of the root DSA by May 1995.
Hence my intial document circulated to all. Now if the REAL requirements are
actually to open up first level DSAs to non-Quipu products, and not to actually
remove the root DSA, then of course, solutions such as Bruno's and Colin's are
far more sensible. We should still use the root DSA as a source of automatic
updates of the root context for Quipu first level DSAs, and have a less
automated method for non-Quipu DSAs. We should also remove the root DSA from
the chaining/referrals path, so that it is simply an information provider, but
not part of name resolution. We are obviously going to discuss this next week
in Utrecht, and I will try to update my paper in time for the meeting, by
taking account of all of the comments that I have received. But until the REAL
requirements are actually known, we cannot finalise a migration path.

David


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.

Steve,
The reason for this was as described above, and also that the pseudo root in
phase 2 was a standard conforming product, whereas the root in phase 1 was
quipu specific.
David


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.

Steve, Agreed that these functions need to be removed pretty quickly.



3) is a function which should not be performed centrally. > AGREED! < 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.

Steve, this is probably where we disagree, primarily due to timing. I do not
expect 1993 systems supporting replication to be available in under a year (but
then you do have more inside knowledge than me on this topic!) We thus make the
pilot less open if we require the root DSA to master first level information.
David


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.

Steve, we agree (nearly) on this point. The small point of disagreement is that
I believe that only 5 (knowlegde) is needed, and not 4 (data). Data should be
mastered in each of the first level DSAs.
David

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