Re: Draft Minutes from IETF 62

Hi,

no comments have been receivde, so these minutes are final.

Thanks,
   Markus

Markus Hofmann wrote:
> 
> Folks,
> 
> attached the draft minutes from our meeting at IETF 62. Thanks to Philip 
> for taking the minutes, and thanks to Tony for taking care of the Jabber.
> 
> In case you've comments, please provide them by Thursday, 3/24, 5pm 
> (EST), so that we can forward the minutes to the IETF in a timely manner.
> 
> Thanks,
>   Markus
> 
> ------
> 
> 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
>