Subject: RE: Open issue: DPV relay

From: "Trevor Freeman" <[email-masked]>
Date: Mon, 15 Apr 2002 10:51:17 -0700

Stephen,
There is obviously a relationship between implementation complexity and
protocol design. 
We are proposing a simple model where the client only has to consider
two responses from the DPV server, success or failure. Nothing in that
model excludes a DPV server for accessing or requesting any resource it
chooses. A DPV server can therefore act as a DPC client to other DPV
servers. What is not clear is why you seem to be so keen for the
original PDV client to do this work of contacting other DPV servers
instead of the client's original DPV server. If the DPV server truly
believes that an answer can be obtained from anther resource - why can't
it go get that answer for the client? What does the client know that the
server does not which would make that work? What piece of information is
missing from the DPV server that by returning a DPV referral to the
client, something will be accomplished that it could not do itself?

Trevor

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Monday, April 15, 2002 6:54 AM
To: Housley, Russ
Cc: pkix
Subject: Re: Open issue: DPV relay

Russ,

It seems that essentially you want to change "protocols MAY
re-direct/m-c" 
into "protocols MUST NOT re-direct/m-c", right?

- I fail to see how the MAY option adds complexity to clients since 
presumably the protocol you like that meets the requirements won't 
take up the "MAY" option and it won't be an issue for such clients.
Even if a conforming protocol does include re-direct, the text 
proposed ensures that there is mandatory impact on clients.

- Allowing re-direct/m-c does allow for some interesting server to
server interactions (in an IMO clean way) as previously discussed on 
the list. I see no reason to prohibit those or cause vendors to
re-invent or corrupt their use of a dpv protocol in order to 
support such cases.

- We can in any case judge relative compexity issues (only?) when 
concrete protocols are being compared against these requirements.

So, all in all, I see no reason to forbid protocols to support these
mechcnisms and some reasons to allow protocols to do so and no reason
at all to make a premature decision on this.

Regards,
Stephen.

"Housley, Russ" wrote:
> 
> I am strongly opposed to any requirements regarding re-direction
(a.k.a.
> referrals) or multicasting.  These services would add considerable
> complexity to the client side of the interface, making support for
> lightweight clients more difficult.
> 
> I have specific comments below...
> 
> >4.2. Relaying, re-direction and multicasting.
> >
> >Protocols designed to conform to these requirements MAY include
> >optional fields and extensions to support relaying, re-direction or
> >multicasting features. DPV clients are NOT REQUIRED to support relay,
> >re-direct or multicast, therefore clients or servers which do not
> >support such features still conform to the basic set of requirements.
> >DPV servers are NOT REQUIRED either to support relay, re-direct or
> >multicast.
> 
> I can support relaying (a.k.a. chaining) because it does not add
complexity
> to the client.
> 
> These are not protocol requirements.  They are implementation
requirements,
> and we are not defining a protocol in this document.
> 
> I prefer:
> 
> Protocols designed to satisfy these requirements MAY include
mechanisms for
> relaying.  However, such protocols MUST NOT include mechanisms for
> re-direction or multicasting.  Re-direction or multicasting mechanisms
> would add considerable complexity to the client side of the interface,
> making support for lightweight clients more difficult.
> 
> >1. Where relay or re-direct mechanisms are supported by a server
> >    a mechanism to detect loops or repetition SHOULD be supported.
> 
> I think that SHOULD ought to be changed to MUST.
> I think that re-direct ought to be deleted.
> 
> >2. Where a DPV server chooses to re-direct the request to another
> >    DPV server (i.e. chooses to provide a referral), a mechanism to
> >    provide information to be used for the re-direction SHOULD be
> >    supported. Note: In case where information to be used for the
> >    re-direction is sent back, clients are NOT REQUIRED to interpret
> >    that information (but MAY do so).
> 
> I think that this should be deleted.
> 
> >3. These features MAY be supported by using additional parameters
> >    in the request and/or response. Clients and servers that do not
> >    support such additional parameters MUST still be able to
use/offer
> >    DPV service. In this way, implementers need not understand the
> >    semantics of any such extensions.
> 
> I think that additional ought to be changed to optional.
> 
> Russ

-- 
____________________________________________________________
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

---

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

Hi Trevor,

> There is obviously a relationship between implementation complexity and

True. My point was simply that the relative complexity of the protocols
that get proposed as meeting these requirements can't be judged yet and,
I believe, isn't impacted by Russ' latest text anyway.

> two responses from the DPV server, success or failure. 

No change there then. Read Russ' latest text and see if you agree
with it.

> Nothing in that
> chooses. 

Good.

> A DPV server can therefore act as a DPC client to other DPV
> instead of the client's original DPV server. 

I'm not. Once again, the scenario in which I like referrals is the one
I gave in a message back on the 8th:

Alice -> Bob - is this a good key?
    Robert -> Charlie - is this a good key? (relaying)
    Chaz -> Robert - I dunno, ask Denis (re-direct/referral)
    Robbie -> Denis - is this a good key?
    Denis -> Rob - I strongly disagree (with apologies:-)
Robert -> Alice - Nope

> If the DPV server truly
> server does not which would make that work? 

See above.

> What piece of information is

In the above example, Charlie is a kind of "gateway" server that tells
Bob which of the other servers that exist (with which they can establish
a good answer via the ultimately WG-selected DPV protocol:-). Bob often
won't know that, and sometimes Charlie won't be able to connect to
Denis due to firewalls.

Stephen.