agreed.Minutes of the 57th Vienna OPES WG.
Tuesday, July 15 at 0900-11:30
=================================
CHAIRS: Markus Hofmann <hofmann@bell-labs.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
|