Last Modified: 2005-01-07
Done | Submit OPES scenarios document and architecture document to IESG for Informational. | |
Done | Submit document on protocol (callout and tracing) requirements to IESG for Informational. | |
Done | Submit document on endpoint authorization and enforcement requirements to IESG for Informational. | |
Done | Submit document on threat/risk model for OPES services to IESG for Informational. | |
Done | Initial protocol document for OPES services including their authorization, invocation, tracking, and enforcement of authorization. | |
Done | Initial document on rules specification method. | |
Done | Submit protocol document for OPES services including their authorization, invocation, tracking, and enforcement of authorization to IESG for Proposed Standard. | |
Nov 04 | Revised document on OPES rules language. | |
Dec 04 | Submit use cases document for OPES services operating on SMTP to IESG for Informational. | |
Feb 05 | Initial document on OCP/SMTP profile for MTAs, including mechanisms for tracing and bypass. | |
Apr 05 | Submit document on OCP/SMTP profile for MTAs, including mechanisms for tracing and bypass, to IESG for Proposed Standard. | |
Jun 05 | Submit document(s) on OCP/SMTP profile(s) for those other SMTP agents the WG has decided to work on, if any, to IESG as Proposed Standard(s). | |
Jul 05 | Submit document(s) on OPES rules language to IESG for Proposed Standard. | |
Jul 05 | Consider additional OPES work such as extension to traffic beyond HTTP and RTSP and present new charter to IESG, or conclude working group. |
RFC | Status | Title |
---|---|---|
RFC3752 | I | OPES Use Cases and Deployment Scenarios |
RFC3835 | I | An Architecture for Open Pluggable Edge Services (OPES) |
RFC3836 | I | Requirements for OPES Callout Protocols |
RFC3837 | I | Security Threats and Risks for Open |
RFC3838 | I | Policy, Authorization and Enforcement Requirements of OPES |
RFC3897 | I | OPES entities and end points communication |
RFC3914 | I | OPES Treatment of IAB Considerations |
OPES WG Meeting, March 8, 2004; Minneapolis, MN, USA; IETF 62 ------------------------------------------------------------- - agenda bashing - status, milestones - discussion of SMTP use cases - next steps - WG status - 7 RFCs published - one in rfc editor queue - one AD followup - one I-D being worked on: smtp-use-cases - goal to finish with next 1-2 weeks - milestones - falling behind on OPES rules language - ditto on SMTP uses cases - cannot start OCP/SMTP profile until use cases done - SMTP use cases (presented by Paul Knight) - as always, more input, especially substantive, would be good - overview of draft and OPES use - desire to provide interoperability - desire to use callout servers with different app. protocols - for SMTP, OPES is focused on (hanging off) the MTA - Philip: pointer to Crocker's arch doc should be used/added - Randy: are intermediate MTAs truly appropriate? - Newman: yes: enterprises need to do filtering at their gateways - Rob: don't bother flagging as sane; each site may need to make its own guarantees - Keith Moore: need tracing info; extreme care in all modifications; multiple modifications are likely to interact poorly - Markus: tracing will be addressed according to IAB considerations - activation points - look appropriate - as SMTP server - as SMTP client - look inappropriate - on queued mail - but it really is appropriate as there is an envelope context and there are reasons to scan messages in the queue - as SMTP proxy - SMTP callout modes - command modification - command satisfaction (catch request and supply reply) - reply modification - message modification - use cases - three groups: - command modification - some similar to HTTP use cases (RFC 3752) - virus scanning, spam filtering, verify S/MIME signatures - command satisfaction - logging or validating MAIL FROM or RCPT TO addresses - OPES mail delivery side effects - reject a message whose content violates a possible trigger condition - delay a message, change queues - generate additional notification messages - modifications - callout servers need more context - Newman, Moore: modifying protocol as wrong model consent issues on changes - Freed: interest in modifying parameters to commands (change DSN parameters) - use cases may preclude each other - where are the administrative boundaries - goal: message modifications need to move as close to sender as they have the most information - ...but you can't cross boundaries - milter as model/example - Open issues: - can't treat satisfaction as modification, as some commands change state - legal restrictions on modification? - responsibility moves at acceptance - if called post-acceptance, how to reflect back into the SMTP world - monkeying with signed messages causes problems - Moore: 822 model as permitting additions to headers, but not modifications to content; and the IETF does not bless the evil already done by SMTP servers - timeout prevention methods? - trust issues? - IAB considerations, privacy considerations, etc - Discussion: - Moore: OPES should be closed down: SMTP work not driven by people who know SMTP - Freed: need to start with _useful_ use cases, got to winnow down your scope - Moore: no problem with that - Markus: Need to re-focus use cases document to discuss specific scenarios; helps setting the scope - Guenther: current document is list of tools for attacking problems; should start with use cases and figure out needed tools from there |