Subject: Re: Open issue: DPV relay

From: "Housley, Russ" <[email-masked]>
Date: Mon, 15 Apr 2002 13:25:40 -0400

All:

I remain strongly opposed to any requirements that impose re-direction 
(a.k.a. referrals) or multicasting on the client.  After a private e-mail 
exchange with Steve Farrell, I now realize that this is not the 
intention.  This intent was to permit the use of re-direction and 
multicasting between a collection of DPV servers.

I think that a bit of rationale will greatly help all readers.

I propose the following text.  Note that the rationale paragraph does not 
include any MUST, SHOULD, or MAY sentences.

Russ

= = = = = = = = = =

4.2. Relaying, re-direction and multicasting.

In some network environments, especially ones that include firewalls, a DPV 
server might not be able to obtain all of the information that it needs to 
process a request.  However, the DPV server might be configured to use the 
services of one or more other DPV servers to fulfill all requests.  In such 
cases, the client is unaware that the queried DPV server is using the 
services of other DPV servers.  In such environments, the client-queried 
DPV server acts as a DPV client to another DPV server.  Unlike the original 
client, the DPV server is expected to have moderate computing and memory 
resources, enabling the use of relay, re-direct or multicasting mechanisms. 
The requirements in this section support such mechanisms for DPV 
server-to-DPV server exchanges without imposing them on DPV client-to-DPV 
client exchanges.

Protocols designed to satisfy these requirements MAY include optional 
fields and/or extensions to support relaying, re-direction or multicasting. 
However, DPV clients are not expected to support relay, re-direct or 
multicast.  If the protocol supports such features, the protocol MUST 
include provisions for DPV clients and DPV servers that do not support such 
features, allowing them to conform to the basic set of requirements.

1. When a protocol provides a relay or re-direct mechanism, a companion 
mechanism to detect loops or repetition MUST also be provided.

2. When a protocol provides the capability for a DPV server to re-direct a 
request to another DPV server (i.e. the protocol chooses to provide a 
referral mechanism), a mechanism to provide information to be used for the 
re-direction SHOULD be supported.  If such re-direction information   is 
sent back to clients, then the protocol MUST allow conforming clients to 
ignore it.

3. Optional parameters in the protocol request and/or response MAY be 
provide support for relaying, re-direction or multicasting. DPV clients 
that ignore any such optional parameters MUST still be able to use the DPV 
service.  DPV servers that ignore any such optional parameters MUST MUST 
still be able to offer the DPV service, although they might not be able to 
overcome the limitations imposed by the network topology. In this way, 
protocol implementors need not understand the syntax or semantics of any 
such optional parameters.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 16 Apr 2002 11:09:21 +0100

Russ,

(modulo typos) I'm fine with this text.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com