Subject: Draft Agenda for IETF 56

From: Markus Hofmann <[email-masked]>
Date: Mon, 10 Mar 2003 07:02:00 -0500

Hi,

we want to continue the lively discussion on the mailing list at the 
IETF 56 meeting in San Francisco next week.

We intend to spend a few minutes provding a quick update on the status 
of our five submitted WG documents, and then go immediatelly over to 
the OPES prototol work. Focus will be on resolving the higher-level 
issues, starting with a discussion of major decision points for 
protocol design and of the "protocol pre-draft" throughts. We will 
cover further topics under "general discussion".

If you've topics to be dicussed under "general discussion" and would 
be interested to present in San Francisco, please send Marshall and 
myself a note ASAP.

Thanks,
   Markus

-----------------------------------------------------

Open Pluggable Edge Services WG (opes)
======================================
Monday, March 17, 1530-1730

CHAIR(S):
    Marshall Rose <[email-masked]>
    Markus Hofmann <[email-masked]>

TECHNICAL ADVISOR(S):
    Allison Mankin <[email-masked]>
    Hilarie Orman <[email-masked]>

AGENDA:
    - Introduction, minutes taker, blue sheets
    - Agenda bashing
    - Status of WG documents
        draft-ietf-opes-architecture-04
        draft-ietf-opes-protocol-reqs-03
        draft-ietf-opes-scenarios-01
        draft-ietf-opes-authorization-02
        draft-ietf-opes-threats-02
    - Start on OPES protocol work
      - Introduction
      - Major decision points for protocol design
      - OPES protocol pre-draft thoughts
      - General discussion

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 10 Mar 2003 10:15:45 -0700 (MST)

>         draft-ietf-opes-threats-02

      - OPES scope clarifications

>       - OPES protocol pre-draft thoughts

I would like to propose to add another agenda item, "OPES scope
clarifications", as shown above.  We have good architecture and
requirements drafts, but they appear to leave some scope questions
unanswered (or there may be no consensus how to interpret the drafts).
These questions seem to be one "level" higher than callout protocol
work because they affect more than the callout protocol.

Specifically, I would like to discuss the following, under the new
agenda item:

	1) Can OPES redirect application messages? That is,
	  can OPES change the final destination of an application
	  message? If yes,
		~ What OPES agents can do that (dispatcher and/or
		  callout server)?
		~ What techniques are allowed (e.g., rewriting
		  application message headers, responding with
		  a "redirect" response if supported by the
		  application protocol)?

	  And if no,
		~ Can generating a response without forwarding
		  the request be considered a form of redirection?
		  Is that kind of transaction termination allowed
		  for application error messages only? What is an
		  error?

	2) Can OPES fan out messages (a single application
	   message is forwarded as multiple messages)? Can OPES
	   aggregate messages (multiple application messages are
	   forwarded as a single application message)?

	3) Can OPES provide protocol translation service? That is,
	  can OPES switch flow from one application protocol to
	  another (e.g., HTTP transaction with FTP URL to an FTP
	  transaction)?

	4) Can OPES agents communicate with providers and consumers
	  using application protocols? For example, can an OPES-aware
	  proxy do this:
		~ suspend an HTTP request (do not forward it)
		~ "respond" with a OPES-generated HTML page
		  containing a <form>, asking for user
		  password/preferences
		~ receive the result of form submission
		~ forward the original HTTP request,
		  possibly adjusted based on user answers in
		  the form
		~ forward the response back to the client

	  The above is a relatively common behavior supported by
	  existing HTTP intermediaries (especially popular at
	  ISPs). It opens the door for many "enhanced" services.
	  Should OPES support this?

Question 1-3 attempt to clarify scope of OPES services; what can be
modified by OPES: just message content and affected headers; content,
headers, and transport-level connections (destination/source); number
of messages; protocol itself? The answer to question 4 will draw the
line between OPES agents and providers/consumers: what kinds of
communication are allowed?

Are these real issues worth discussing? Or do they already have
precise answers in WG drafts? Do they fit into existing agenda items?
Any changes to the above list?

Thank you,

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 11 Mar 2003 00:11:44 -0500

Folks,

based on various feedback, attached an updated draft agenda for our 
OPES meeting in San Franciso.

Thanks,
   Markus

CHAIR(S):

TECHNICAL ADVISOR(S):

AGENDA:
    - Introduction, minutes taker, blue sheets [2 min]
    - Agenda bashing [3 min]
    - Status of WG documents [M. Hofmann, 10 min]
        draft-ietf-opes-architecture-04
        draft-ietf-opes-protocol-reqs-03
        draft-ietf-opes-scenarios-01
        draft-ietf-opes-authorization-02
        draft-ietf-opes-threats-02
    - Start on OPES protocol work
      - Introduction to protocol work
        [M. Hofmann, 10 min]
      - Protocol layering and the OPES callout protocol
        [H. Orman, 15 min]
      - OPES scope clarifications
        [A. Barbier, ? min]
      - Major decision points for protocol design
        [A. Rousskov, ? min]
      - OPES protocol pre-draft thoughts
        [A. Rousskov, ? min]
      - General discussion [? min]

---

From: jfcm <[email-masked]>
Date: Mon, 10 Mar 2003 16:14:22 +0100

My main question is about the entry and the ending points of the OPES 
concept. If it is accepted that  not only HTTP but any protocol is OK, and 
that alternatively both end points can be user/producer or that we may have 
a peer to peer support, it will mean that any entry/output protocol is OK, 
including a keyboard/user file/application etc, towards a screen, a file, etc.

This means there is no pseudo-synchoronous (like in hhtp) obligation (or as 
options).
This means that we have a general purpose concept of a filter/transformer 
system on a flow.
Which will standardize everywhere.

This means that, the filter/transformer relation (callout protocol) can be 
anything from realtime to soap. Am I correct? Because this means that we 
will  have a good general framework for a protected/acked balanced protocol 
able to support one to many or even many to many relations.

Then the next question will be: will it always be under TCP?
jfc

At 13:02 10/03/03, Markus Hofmann wrote:
>we want to continue the lively discussion on the mailing list at the IETF 
>56 meeting in San Francisco next week.
>
>We intend to spend a few minutes provding a quick update on the status of 
>our five submitted WG documents, and then go immediatelly over to the OPES 
>prototol work. Focus will be on resolving the higher-level issues, 
>starting with a discussion of major decision points for protocol design 
>and of the "protocol pre-draft" throughts. We will cover further topics 
>under "general discussion".
>
>If you've topics to be dicussed under "general discussion" and would be 
>interested to present in San Francisco, please send Marshall and myself a 
>note ASAP.
>
>Thanks,
>   Markus
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 11 Mar 2003 10:06:29 -0700 (MST)

On Mon, 10 Mar 2003, jfcm wrote:

> My main question is about the entry and the ending points of the
> OPES concept. If it is accepted that not only HTTP but any protocol
> is OK, and that alternatively both end points can be user/producer
> or that we may have a peer to peer support, it will mean that any
> entry/output protocol is OK, including a keyboard/user
> file/application etc, towards a screen, a file, etc.
>
> This means there is no pseudo-synchoronous (like in hhtp) obligation
> (or as options). This means that we have a general purpose concept
> of a filter/transformer system on a flow. Which will standardize
> everywhere.
>
> This means that, the filter/transformer relation (callout protocol)
> can be anything from realtime to soap. Am I correct?

I doubt we can design a good OPES system that can support adaptation
of anything from highly optimized realtime protocols to
structure-rich, super extensible XML protocols. There will be
tradeoffs that we will have to resolve one way or the other. That is
why it is important to agree on scope and use cases up-front.

> Because this means that we will have a good general framework for a
> protected/acked balanced protocol able to support one to many or
> even many to many relations.

We should strive for that, but IMO we will come short as things get
more specific.

> Then the next question will be: will it always be under TCP?

Transport protocol binding wise, TCP is probably not the only option.
We do need a reliable, order-preserving, congestion-aware protocol
though (see protocol requirements draft for details). These features
may already exclude certain realtime optimizations where losing
packets is not only acceptable but desirable in the presence of
unexpected delays or congestion.

An important design question is whether the OPES protocol should allow
multiple transport bindings/encodings or just one.

Alex.