Subject: Draft minutes from IETF 57

From: Markus Hofmann <[email-masked]>
Date: Thu, 24 Jul 2003 14:05:31 -0400

Hi,

below the draft minutes from the OPES meeting in Vienna. In the 
absence of substantive comments, the minutes get filed on Monday, 8/4/03.

Thanks,
   Markus

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

Minutes of the 57th Vienna OPES WG.

CHAIRS: Markus Hofmann <[email-masked]>

Minutes by Dimitri Tombroff.

1 Introduction and General Status:
----------------------------------

Status of OPES documents: Initial versions of tracing/bypassing 
(draft-ietf-opes-end-comm-00.txt) and OPES core protocol

(draft-ietf-opes-ocp-core-00.txt) have been published. An individual 
submission about OCP/HTTP mapping has also been published,

and the group intendes to adopt this draft as WG document.

General comments from the chair:
- WG needs more participants for reviewing drafts and brings in arguments.
- WG needs additional focusing on tracing/bypassing issues.
- WG is late with the rule language. Need expert contributors to start 
this.

2 Work on "Tracing/Bypass" document [P. Knight]
-----------------------------------------------

Main issues is to decide on is traceable in an OPES flow, how to do 
it, and what are the requirements and privacy issues.

The WG approach is to use in-band tracing on a per message flow with 
the following requirements:
- an OPES system MUST be traceable
- an OPES processor SHOULD be traceable
- an OPES service  MAY be traceable.

question: this works only for application protocols that allow for 
in-band signaling of meta information. How would the first

MUST apply to other application protocols?
answer: At this point, it is assumed that the appplication protocol 
will have to support in-band signaling, which is in-line

with the WG's charter to focus on HTTP. This issue should be mentioned 
in the drafts.

question : what motivates the MUST, SHOULD, and MAY at three different 
levels ?
answer: if you have a chain of processor, it may be unecessary that 
each processor adds a trace. One per domain is enough.

On 'How to support tracing', the chair noted that although the WG has 
so far ruled out out-of-band notifications, more  input is

needed to confirm it is the correct approach. It was suggested that 
the resulting discussion should be reflected in the

document(s).

On another issue, the WG needs to detail the definition of an "OPES 
system".

3 OPES Core Callout Protocol presented [Martin Stecher]
-------------------------------------------------------

The core OCP  was presented. This was a rather detailed presentation, 
the remarks and questions were the following:

The chair pointed out that there are still many open issues and 
optional mechanisms to discuss - just see the TBD section and

the sections marked with XXX in the drafts. If no one is supporting 
the inclusion of currently open/optional mechanisms (e.g.

capability query) on the mailing list, they will be removed for the 
sake of protocol simplicity.

Performance is of big concern, and the WG needs to show benefits of 
OCP over ICAP.

It was noted that after long discussions about using BEEP, SOAP, or 
HTTP, the consensus has been to move forward with a custom

tailored transport protocol for OCP, and see how it works. Progresses 
have been mostly made on  OCP messages format.

The 'can you' and 'do you' set of messages might bring unecessary 
complication. Some input is needed to check if they are

worthwhile.

question : Since OCP is defined by a BNF grammar, is or will a parser 
be provided ?
answer: none so far.

4 OCP Http Adaptation [Martin Stecher]
--------------------------------------

The http adaptation was presented, as well as the status of prototype 
callout servers by A. Rousskov and M. Stecher.

One issue was raised about HTTP keep-alive connections and HTTP/1.1 
pipelining. The problem is that the callout server may have

to transform a keep-alive http reply into a closed reply, because it 
may not be able to set the correct Content-Length http

header, nor use the chunked transfer encoding.

Having a callout generating closed http replies is bad because it 
breaks two desirable http properties: keep-alive connections

and thus http pipelining (if any). It was also pointed out that it is 
not clear if it's the callout server responsability or the

OPES processor responsability to handle such closing.

5 OPES treatment of IAB Consideration [P. Knight]
-------------------------------------------------

IAB considerations were discussed. The goal is to show that all IAB 
considerations are addressed.
Only IAB considerations are mentioned in this document that triggered 
some remarks/questions during the meeting.

5.0 IP layer Addressability

Comment: must be addressible at IP layer. Otherwise encryption will 
not work.

5.1 Notification:

As pointed out before, the tracing/notification issue is still at an 
early stage. Following Remarks:
- hit metering analogy may not be approriate here,
   content providers might want at least some limited
   help in the OPES case
- (out-of-band) notification may be a problem for the
   recipient if it must  handle a lots of notification
   information. A solution (should notification be needed)
   would be to perform aggregation. I.e send me a
   notification every hour rather than for each message.

5.2 Non-blocking:

OPES intermediaries MUST support a bypass feature. There is a clear 
open issue if the OPES service is essential.

5.3 Privacy.

 From the tracing information, the user can contact the OPES first 
node, then ask its privacy policy.
What is not clear nor explicitely stated here is that the first OPES 
node is not necessarilly addressible. A statement like "at

least one trace per domain must identify one addressible node" is needed.

question : is there any relationship with the ALIAS WG wrt to 
establishing a trust relationship with an intermediary.
answer: OPES is application level while ALIAS deals with the transport 
level.