OPAX plans

[[e-mail]]

[[ Steve K: if you think that this is of interest for osi-ds,
feel free to forward to this much larger list  -- PAP ]]

[[ WG-NAP: this is an example of the type of things I wanted to be
investigated in the proposed but never started task force
about DSA operational management, but was to unable to explain
clearly]]


OPAX (the french pilot) is planning a new stage in the pilot,
and this evolution may have some effect on the the whole Paradise
pilot service.

This is the reason for this message, as we would like
   1. to inform you well in advance so that no one will be surprised
   2. to receive any comment and advice before this really goes
	into operation


The main goals of this move are:
-------------------------------
   1. to investigate and adcquire know-how in a new mode of operation
   2. to, hopefully, better prepare a large deployement of X.500
	within the R&D community and even outside

The objectives are:
--------------------

  1. to limit as far as possible the burden of OPAXdsa (our C=fr; master)
	- because of expected high increase of use and the
		possible bottle neck
	- and to prepare for a minimal shared infrastructure and room
		for Value Added Service providers

  2. to allow as easily as possible for nice coexistence of
	organisations running their own servers, and for service
	providers either hosting subtrees or selling added-value
	such as multi-stack connectivity or index-dsas.

  3. to enable organisations with DSA servers on a filtered network
	accepting only requests from a few well identified PSAPs
	to really "partcipate" in The Directory


The approach:
-------------
  This a slightly simplified picture of what is planned

 (still under close investigation and isolated experiment, and for which
we would appreciate technical comments)


    . The french master will only be a "knowledge server" (ie. in
	other words it will only return references to the actual
	servers, and will NO longer accept to CHAIN)
	This is an operational parameter of our Pizarro/UCOM.X to
	be able to control the processing modes for chaining and
	referals)

    . Based upon "market law" a few servers may/will act as "relayDSAs"
	or front-ends to some of the organisation level DSAs
	(ie. they will receive and process -chain- requests for
	these DSAs)




-------------------------------

problems and questions:

1. How will this impact the rest of Paradise?
	what will be the behaviour of "requesters" (DSA or DUIs) when
	receiving only 'references' from the french Master?
	  QUIPU servers?
	  others DSAs?
	  de DUI?
	  other Directory User Interfaces?
	  gopher-gateway?
	  others?
	All software not designed to process directly such references
	will have to "pass through" a 'clever' DSA able to receive
	the references and actually process them.
	This may lead to the requirment of providing such 'clever relays'.

	Is this something Paradise can atke over, provide, or at least
	coordinate?

2. There is a serious question about QUIPU behaviour with such references,
	and the overwhelming majority of QUIPUs around makes it a
	crucial issue.

	As far as we have understood it, QUIPU with its EDB approach
	has only a concept of subordinate reference for it's own data.
	(ie. "all the subordinates of entry DN will be found by
	contacting server S") even if at analysing the PDUs it says
	that "this is a cross reference".

	What will be returned by our master will be of the cross-reference
	type (ie. "if you want to access the entry DN, please contact
	server S").

	How Quipu family software will react to this type of references?
	they seem to interpret when in a QUIPU environement a cross-ref
	as being a subordinate ref. Will they be able to
	interpret our references for what they are?


3. This is also a requirment on new X.500 client designers.

	Is it cheap/easy/acceptable to design software with
	a correct and performant behaviour when faced to
	our planned mode of operation?
	[[Hint beware of design only suited or tested in a ISODE
	QUIPU environment]]


----------------------------------


additional and minor item:

In order to provide a more robust service even to X.500 clients
not using the master/slave knowledge, we plan to install
a "transparent backup" for key servers (including OPAXdsa):
  the PSAP for a logical server (say OPAXdsa) will contain
  several NSAPs for the same stack (say RFC1006);
  these NSAP will indeed direct to separate independant 
  but tightly synchronised servers holding exactly the same
  information AND pretending each one to be THE SERVER (ie. master).
  
The idea is that a single and unique logical server (to conform
to the standard model) will be in fact "realized" over independant
multiple physical servers.

We don't put any requirements on the "clients" appli (DSP or DAP),
just propose several possibilities, leaving each free to
order them as they like. The only constraint in order to take profit
of this is to be able to take into account several NSAPs
for the same stack.


=====================================================


Comments expected and welcome

-- PAP