Subject: OPES document status

From: Markus Hofmann <[email-masked]>
Date: Sat, 16 Nov 2002 01:45:48 -0500

Hi,

quick update on the current OPES document status.

In August, we submitted three WG drafts on

  Architecture (draft-ietf-opes-architecture-03)
  Protocol Requirements (draft-ietf-opes-protocol-reqs-02)
  Scenarios (draft-ietf-opes-scenarios-01)

to the IESG for consideration as informal RFCs. We've received 
feedback from the IESG discussion on all three documents, and we had 
an initial call of the author teams to discuss how we should address 
the issues. Thanks to Allison, who joined this call and 
explained/helped understanding the various issues.

Below an attempt to summarize the IESG feedback and how we envision to 
incorprate it into all three drafts. (Thanks to Andre for the nice 
summary! Hope we didn't miss anything).

The authors are currently working on updated draft versions, which 
we'll re-submit to the IESG after our discussion in Atlanta and on the 
mailing list. We want to do this shortly after the Atlanta meeting - 
so please read the comments carefully, participate in the upcoming 
meeting, and send your thoughts and comments to the mailing list.

We also have initial versions of our documents on

   Enforcement/Authorization (draft-ietf-opes-authorization-00)
   Threats/Risk (draft-ietf-opes-threats-00)

published. We'll discuss those in Atlanta with the goal of wrapping 
them up and submitting to IESG shortly. So, please also read those two 
drafts very carefully and provide feedback in the meeting and on the 
mailing list.

Thanks,
   Markus

================= Summary of IESG Feedback ===========================

Feedback: It was suggested that tracing/audit/authorization and other
           requirements from RFC 3238 were not properly addressed in
           the drafts.
Solution: - We will list and address all OPES considerations in a
             separate section in the architecture document.
           - Solutions to some of these requirements might be beyond
             the group's current charter, in which case this will be
             spelled out explicitely.
           - WG will explain in the architecture and possibly other
             drafts what is needed to accomplish tracing/audit/
             authorization.

Feedback: It was suggested to remove all references to callout server
           chaining due to concerns over transitive trust issues.
Solution: - We will revise drafts accordingly without ruling out
             callout server chaining performed within a single
             trusted domain (e.g. within an ISP’s data center)

Feedback: Concern was expressed about the way the drafts address
           privacy issues.
Solution: - We will add more details to discussion of privacy in
             architecture draft.
           - WG will add references to existing privacy solutions that
             could be applied to OPES (e.g. W3C P3P).

Feedback: It was asked that protocol requirements draft clearly states
           that for transport issues such as congestion avoidance,
           ordered/unordered, reliability etc., OPES should rely on
           existing solutions on the transport layer, rather than
           defining separate mechanisms.
Solution: Protocol requirements draft will be revised accordingly

Feedback: Concern was expressed over requirement that the OPES callout
           protocol be application protocol-agnostic (since OPES
           charter is limited to HTTP/RTP)
Solution: Being protocol-agnostic is still an important goal, but we
           will soften the protocol requirement ("SHOULD" instead of
           "MUST").

Feedback: The WG was discouraged to ask for a mechanism to negotiate
           the transport protocol to be used for OPES callout protocol
           transactions.
Solution: We will drop this requirement and instead suggest a fixed
           mapping of a given application protocol (e.g. HTTP, RTP) to
           a certain transport protocol (e.g. TCP, UDP).

Feedback: It was proposed proposed to link scenarios draft with
           threats draft
Solution: - WG sub-teams expressed some doubt about this proposal
           - Allison will re-read both drafts and re-evaluate this
             comment

Feedback: There was a complain about terminology not being aligned
           between scenarios and architecture draft
Solution: Will be addressed in the next draft versions

---

From: "Reinaldo Penno" <[email-masked]>
Date: Tue, 19 Nov 2002 22:54:18 -0800

So,

we need to modify/come up with two protocols: callout and a in-path.

The in-path have requirements such as tracing, notifications,
authorizations, etc..We can modify HTTP (extra headers, or something like
it) to do it, or we can come up with a different out of band protocol.

The advantages of an out of band signalling protocol is that it can be used
by all applications, and doesn't need to modify existing protocols.

I think whatever NSIS produces might be a good out of band in-path protocol
for OPES. I wonder if somebody have some ideas on this...

regards,

Reinaldo

> -----Original Message-----
> From: Markus Hofmann [mailto:[email-masked]]
> Sent: Saturday, November 16, 2002 1:46 AM
> To: OPES Group
> Subject: OPES document status
> 
> 
> 
> Hi,
>