Subject: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-re qs-00.txt

From: Graham Klyne <[email-masked]>
Date: Wed, 29 May 2002 14:18:10 +0100

This mostly looks pretty reasonable to me.  A couple of comments below.

I'm a little confused by terminology.  The term "data processor" is not one 
I recall from the architecture document.  I do recall the term "data 
dispatcher" (or something like that) which seems to be what is meant there.

>3.12 Asynchronous Message Exchange
>
>    The OPES callout protocol MUST support an asynchronous message
>    exchange between an OPES data processor and a callout server.
>
>    In order to allow asynchronous processing on the OPES data processor
>    and callout server, it MUST be possible to separate request issuance
>    from response processing.  The protocol MUST therefore allow multiple
>    outstanding requests and provide a method to correlate responses to
>    requests.
>
>    Additionally, the callout protocol MUST enable a callout server to
>    respond to a callout request before it has received the entire
>    request.

How far is asynchrony to be taken?  In particular, I'm wondering if it is 
to be possible for a response to be received on a channel different from 
the request.  (E.g. suppose a channel between data dispatcher and callout 
processor fails, and is re-established - can an outstanding response arrive 
on the re-established channel?)

>4.1 Protocol Efficiency
>
>    The OPES callout protocol SHOULD be efficient in that it minimizes
>    the additionally introduced latency, for example by minimizing the
>    protocol overhead.  At a minimum, the callout protocol SHOULD satisfy
>    the performance requirements of the application-layer protocol whose
>    messages are forwarded from the OPES data processor to the callout
>    server.

The sentence "At a minimum..." seems to be a bit vague, in the sense that 
it's not really possible to determine whether it is satisfied by any given 
callout protocol.  Especially given that the callout protocol is required 
to be application protocol agnostic.  I'm not sure that anything 
significant would be lost by deleting this sentence.

>6. Security Considerations
>
>    The security requirements for the OPES callout protocol are discussed
>    in Section 5.

I think section 5 or section 6 should say something about honouring the 
security/privacy requirements of the endpoints of the "original" transfer 
(the provider and/or consumer).  In particular, if either party has 
provided authority for limited kinds of processing to be performed, the 
extent of that authority should be communicated to the callout processor.

Related to this, the callout processor should return an indication of the 
processing steps performed so that the OPES architectural requirements for 
tracing can be satisfied.

#g

-------------------
Graham Klyne
<[email-masked]>

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 29 May 2002 23:52:50 -0400

Graham,

thanks for your comments. Let me offer some responses until the 
co-authors get a chance to reply.

 > I'm a little confused by terminology.  The term "data processor" is
 > not one I recall from the architecture document.  I do recall the
 > term "data dispatcher" (or something like that) which seems to be
 > what is meant there.

Previous discussions already showed that we need to clarify these 
terms in the architecture document - point taken.

The term "data processor" is used here in the sense as introduced in 
Figure 2 of the architecture document. Looking at Figure 3 in the 
architecture document, "data processor" refers to the box including 
the "data dispatcher", i.e. the "data dispatcher" is part of a "data 
processor". So, I believe the usage of "data processor" is correct here.

 > How far is asynchrony to be taken?  In particular, I'm wondering if
 > it is to be possible for a response to be received on a channel
 > different from the request.  (E.g. suppose a channel between data
 > dispatcher and callout processor fails, and is re-established - can
 > an outstanding response arrive on the re-established channel?)

Hm, good question, anybody any opinions on that?

 > The sentence "At a minimum..." seems to be a bit vague, in the
 > sense that it's not really possible to determine whether it is
 > satisfied by any given callout protocol.  Especially given that the
 > callout protocol is required to be application protocol agnostic.
 > I'm not sure that anything significant would be lost by deleting
 > this sentence.

I agree that this is quite vague, we cannot really give any concrete 
numbers. The feeling was that it would be nice to have some 
comparison, trying to make the point that the callout protocol itself 
should not slow down the interaction between client and server 
significantly. Maybe that's already captured in the first sentence, 
and we don't realy need the second one. But I believe it's important 
that we have some requirement(s) about the expected performance of the 
callout protocol - otherwise we could end up with a protocol that 
slows down the communication so that's it's basically unusable.

 > I think section 5 or section 6 should say something about honouring
 > the security/privacy requirements of the endpoints of the
 > "original" transfer (the provider and/or consumer).  In particular,
 > if either party has provided authority for limited kinds of
 > processing to be performed, the extent of that authority should be
 > communicated to the callout processor.

Isn't that rather a requirement for "endpoint authorization and 
enforcement" rather than for the callout protocol? The callout 
protocol itself does not care about it, it simply does what the "data 
processor" asks it to do. Of course, the data processor would have to 
implement the kind of considerations you mention, probably in form of 
policies/rules. This has to be written down in the ""endpoint 
authorization and enforcement requirements". Or do you see a direct 
impact on the callout protocol itself?

 > Related to this, the callout processor should return an indication
 > of the processing steps performed so that the OPES architectural
 > requirements for tracing can be satisfied.

Yes, agreed. I believe this is covered in Section 3.11 when saying 
"The OPES callout protocol MUST also allow OPES data processors to 
comply with the tracing requirements of the OPES architecture as laid 
out in [1] and [5].  This implies that the callout protocol MUST 
enable a callout server to convey to the OPES data processor 
information about the OPES service operations performed on the 
forwarded application message."

Cheers,
   Markus

---

From: Andre Beck <[email-masked]>
Date: Thu, 30 May 2002 12:39:09 -0500

Graham, Markus,

see my comments inline.

> Previous discussions already showed that we need to clarify these terms 
> in the architecture document - point taken.

I agree that terminology needs be aligned across WG drafts. The 
architecture draft defines an "OPES processor" as a network element in 
the path between data provider and data consumer. The OPES entities 
"data dispatcher" and (local) "OPES services" reside inside the OPES 
processor. The protocol requirements draft uses the term "OPES data 
processor" in exactly this sense.

> Hm, good question, anybody any opinions on that?

Our main motivation for requiring support for asynchronous message 
exchange was to allow for parallel callout transactions over a single 
callout channel. I am not yet convinced that we need to extend the 
asynchrony requirement to include scenarios like the one you described, 
but if there are good arguments for it, then we can certainly do so.

> enforcement" rather than for the callout protocol? 

Yes, IMO the data dispatcher on the OPES processor is responsible for 
the enforcement of endpoint authorization and uses the callout protocol 
as a means to request the execution of specific OPES services on a 
remote callout server. So I don't think there is a need to communicate 
endpoint authorizations to callout servers.

-Andre

---

From: Graham Klyne <[email-masked]>
Date: Thu, 30 May 2002 19:17:09 +0100

>but if there are good arguments for it, then we can certainly do so.

I don't have a strong view, just trying to clarify the extent of the 
requirement.

#g

-------------------
Graham Klyne
<[email-masked]>

---

From: Graham Klyne <[email-masked]>
Date: Thu, 30 May 2002 19:20:05 +0100

At 12:39 PM 5/30/02 -0500, Andre Beck wrote:
>Yes, IMO the data dispatcher on the OPES processor is responsible for the 
>enforcement of endpoint authorization and uses the callout protocol as a 
>means to request the execution of specific OPES services on a remote 
>callout server. So I don't think there is a need to communicate endpoint 
>authorizations to callout servers.

I think that's OK if:
(a) the callout processor can be trusted by the dispatcher to not save or 
distribute the information provided beyond the immediate requirements of 
processing, and
(b) it is clear that the callout processor only performs transformations 
that are explicitly requested by the dispatcher.

Should that much be mentioned in security considerations?

#g

-------------------
Graham Klyne
<[email-masked]>

---

From: Markus Hofmann <[email-masked]>
Date: Thu, 30 May 2002 18:42:11 -0400

Graham Klyne wrote:

 > I think that's OK if: (a) the callout processor can be trusted by
 > the dispatcher to not save or distribute the information provided
 > beyond the immediate requirements of processing, and

Yes (you probably refer to a "callout SERVER" whan talking about a 
"callout PROCESSOR", right :)

 > (b) it is clear that the callout processor only performs
 > transformations that are explicitly requested by the dispatcher.

Yes.

 > Should that much be mentioned in security considerations?

I wouldn't have a problem with mentioning that, except maybe that it 
does not directly relate to the protocol itself. I rather thought this 
would have to be included either in the architecture draft or maybe 
better in the "policy enforcement" document.

-Markus

---

From: Graham Klyne <[email-masked]>
Date: Fri, 31 May 2002 13:46:28 +0100

>"callout PROCESSOR", right :)

Yes... the terminology isn't burned into my neural paths yet.

>I wouldn't have a problem with mentioning that, except maybe that it does 
>not directly relate to the protocol itself. I rather thought this would 
>have to be included either in the architecture draft or maybe better in 
>the "policy enforcement" document.

The possible protocol issue I see is that the protocol must communicate 
(explicitly or implicitly) such information.

Aside from that, if it's mentioned somewhere else, I suppose it's 
OK.  (Maybe, in the longer term, it would help to collect the various 
security considerations into one place and cite that from all the 
documents?  Security being more than just a sum-of-parts kind of matter.)

#g

-------------------
Graham Klyne
<[email-masked]>