Re: DSA / DUA RFP Development

[Andrew Waugh <[e-mail]>]

> I am in the process of preparing a Request for Proposal / Request for Quote
> for DSAs and DUAs for a significant Canadian organization.

> I know that most of the features we will want are found in the 1993 X.500
> Recommendations (which I believe haven't yet been published, although
> approved) as well as a number of other 'standards' which are in process (
> ISPs and other OIW proposals). I believe that there is a severe shortage of
> products 'compliant' with these new standards so will have to elicit
> commitments and promises from respondant vendors.
> 
> My question: Is anyone receiving this message, willing to share his or her
> own recent work of a similar nature? In other words, has anyone else
> recently written an RFP for Directory products and is willing to grant me a
> copy of the work. I don't intend to plagerize, but I'd like to see how
> others present their requirements, and in what detail.

While I have recently done exactly this, we did it under contract for a client,
so I can't give copies out (:-(. I can, however, give you some advice.

DON'T write a RFP/RFQ for X.500. Instead, write it for the purchase of a
_Directory System_. 

I'm not having a crack at X.500 here. Rather, I am trying to emphasise that
deploying a directory does not just involve purchasing DSAs and DUAs. When
writing the RFP/RFQ think about the system aspects first. How is data to
be entered into the system and subsequently maintained? What tools will this
need? What use is to be made of this data? What tools will this require? How
is the system to be distributed and managed? What tools must be provided?
What machines must these tools run on? How is the directory to be networked?
What response times are necessary for the different classes of users? What
schema is to be used?

A surprising number of the answers to these questions will not involve X.500
at all. For example, one aspect of managing a directory (or any database) is
ensuring that the data can be restored after a crash - so the RFP/RFQ must
have back-ups and journals (or their equivalent). Other requirements may
imply non-X.500 solutions (e.g. a DUA on a small PC at the end of a thin
wire might have better performance if it talked a lightweight directory
protocol to a server, than the full DAP.)

Of course, deep within this RFP/RFQ you will very likely start referring to
X.500 to tie the various components together.

Although it is not directly relevant to your need, you might be interested
in a paper I gave last year on 'Where are the Network Applications?'. In it
I described why I thought there were so few successful network applications.
The major theme of the paper is that few network applications are deployed
because of insufficient attention being paid to the system features. X.500
forms the major example in the paper - both its good points and its bad ones.
The paper was heavily influenced by my experiences in helping to write an
RFP/RFQ for an X.500 system. If you are interested, let me know.

andrew waugh