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:markus@xxxxxxxx]
> Sent: Saturday, November 16, 2002 1:46 AM
> To: OPES Group
> Subject: OPES document status
>
>
>
> 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
>
>
>