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(_at_)mhof(_dot_)com]
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