Subject: Re: Draft minutes from IETF 57

From: Markus Hofmann <[email-masked]>
Date: Fri, 08 Aug 2003 10:13:21 -0400

Hi,

since there were no comments, these minutes have been submitted as final.

-Markus

Markus Hofmann wrote:

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