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 <hofmann(_at_)bell-labs(_dot_)com>
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.