draft minutes from 55th IETF

[Marshall Rose <mrose@xxxxxxxxxxxxxxxx>]

please comment. in the absence of substantive comments, the minutes get filed on
wednesday, november 27th, close-of-business, us/pacific.

/mtr

Monday, November 18 at 1300-1500
=================================

CHAIRS: Marshall Rose <mrose@xxxxxxxxxxxxxxxx>
   	Markus Hofmann <hofmann@xxxxxxxxxxxxx>

    
- Introduction, minutes taker, blue sheets
    
Marshall Rose to take minutes.

    
- Agenda bashing
    
No comments.
    

- Discussion of WG documents
  - Status of documents submitted to IESG (hofmann)
      - draft-ietf-opes-scenarios-00.txt
      - draft-ietf-opes-architecture-02.txt
      - draft-ietf-opes-protocol-reqs-01.txt

    The design teams met to address the IESG comments. Markus enumerated
    the issues, along with the suggested approach.
    
    Comments:
    
    Channels in the callout protocol: why are they there? they introduce
    security issues. They deal with state, but aren't clearly (enough)
    described.
    
    How many OPES callout protocols are there? How do you pick which
    one? There is one, but you can negotiate parameters when using it.
    
    More comments will be sent to mailing list/authors!
    
  - Security Threats and Risks for Open Pluggable Edge Services (bindignavile)
      - draft-ietf-opes-threats-00.txt

    Top-level taxonomy: in-band (datastream) and out-of-band (otherwise)
    threats.
    
    In-band threats: fundamentally, have to use hop-by-hop security to
    deal with opes flow network/application level threats. Authorization
    is also a large issue.
    
    Out-of-band threats: caused by weakness in implementation.
    
    Comments:
    
    There are other types of DOS besides overloading.
    
    The notion of "key manipulation" is puzzling. Why would an encrypted
    link have a generic threat in this area? It is not necessarily the
    case that keys will be sent across OPES, besides the notion of key
    distribution is out of scope.

    A reminder: we must focus only on threats introduced by OPES.
    
  - Requirements for Policy, Authorization and Enforcement of OPES
    Services (beck)
      - draft-ietf-opes-authorization-00.txt

    Top-level taxonomy: requirements for opes policy architecture and
    opes service authorization
    
    Comments:
    
    Reminder: look for a common solution to these requirements, instead
    of trying to come up with a specific solution.
    
    Does it matter if the intermediary is acting on behalf of the client
    or the origin server?  Technically, no, in the sense that the
    requirements deal with OPES endpoints. Further, conflicting rules
    from different endpoints have to be dealt with, but that the actual
    algorithm for conflict resolution is out of scope for OPES.

    
- Summary and wrap up of the ICAP discussion to accompany possible
  informational publication of that protocol (berzau)
      - draft-elson-icap-01.txt
      - draft-stecher-opes-icap-eval-00.txt

    The ICAP I-D is an individual specification that will be published
    as an RFC to document current practice.
    
    First there was ICAP 0.9, then 0.95, then 1.0 (Summer, 2001) which
    is stable and deployed. Various issues have arisen as a result of
    this experience.
    
    Comments:
    
    What about the "it's an RFC" problem? There's the "IESG note"
    to clarify the relationship of the draft to the standards track.

    
- Next WG items to be worked on (hofmann)
  - OPES protocol
    
    Either we identify an existing protocol and declare victory, or we
    modify an existing protocol, or we create a new one.
    
    There are lots of things to choose from: HTTP, ICAP, SOAP, BEEP,
    etc., etc.
    
    Given the group's metabolism, have to be careful in terms of
    allocating resources.  Let's start with the OPES Callout Protocol
    Requirements draft.
    
    Comments:
    
    Also include the OPES Policy/Authorization draft as a part of this.    
    
  - Methods for specification of rules/policies (beck)

    How much can we learn from similar IETF efforts (e.g., CPL)?
    
    Also, what about IRML (an older individual I-D submission)? Is this
    a good start?
    
    Comments:
    
    Perhaps, but there are a lot of uses to be considered.
    
    Do we need more detailed requirements for a specification
    language? Perhaps this falls out of the policy requirements draft,
    (implying that we need to put more details into the policy
    requirements drafts, rather than having a separate document).
    
- Adjourn.