Subject: [midcom] Meeting notes, first draft

From: Melinda Shore <[email-masked]>
Date: Thu, 16 Aug 2001 16:46:59 -0400

Mary Barnes and Cedric Aoun took outstanding notes at Friday's
meeting.  Unfortunately I had to edit them down to meet the
IETF keeper-of-the-minutes requirements, but I will put the
original up for download and let you know where they are.

In the meantime, I've appended a first draft of the minutes.
Please look them over and post comments to the mailing list.

And many, many thanks to Mary and Cedric.

Melinda

Minutes of midcom working group at 51st IETF Meeting London, England
Friday, August 10, 2001, 9:00-11:30

Chaired by Melinda Shore ([email-masked])
Reported by Mary Barnes ([email-masked]) and
   Cedric Aoun ([email-masked]), edited by
   Melinda Shore

Status update/working methods:
  * Neither document editor was able to be present.
  * Both docs are supposed to be in last call this month.
  * Framework document was in last call, had to be stopped
    due to issues raised.
  * Issues (showstoppers) need to be raised ASAP.  4 people
    need to object for consensus not to be agreed.

Relationship to OPES - Open Pluggable Edge Services  (Michael Condry)
--------
OPES is about building application level services between
where the content starts and where the content ends (both IP
endpoints), typically web services.  The working group is
looking at callout protocols that go to something like an
ALG.  Does service and ships elsewhere.  Will ensure that
overlap with MIDCOM is cross pollinated.  OPES is looking at
application middleboxes, while MIDCOM is looking at
transport middleboxes.

Example:
Presentation services at the edge of the network (close to
the "consumer")

Framework document (discussion led by Jiri Kuthan):
--------
Current Issues:
There's a great deal of terminology that isn't agreed
upon.  We will form a design team 

There's currently a requirement for rule "ownership.  The
intent is to keep someone from closing someone else's
pinhole.  Some folks want multiple owners to handle
takeover-type scenarios.

The ensuing discussion centered around the following
points/questions: 
1) is "ownership" useful"
2) what is the basis of ownership?
3) what is the underlying model (file locking
   vs. authorization) 
4) is this the correct robustness model?

Jiri Kuthan will develop some text around the ownership
question and submit it to the list.

Another unresolved issue is whether the MIDCOM protocol will
be peer-to-peer or client/server.  The consensus was that it
will be client/server.

A discussion of identifiers/handles for the open "pinholes"
and "sessions" raised additional questions about how pinhole
requests should be specified.  There was a suggestion that
the things that are created on the middlebox (firewall
pinholes, NAT mappings) may be identified by the contents of
the things themselves (such as a 5-tuple describing a
firewall pinhole) or by an identifier allocated by the
middlebox.  Concerns included how (and whether) to
aggregate, directionality, whether allocation and open are
separate operations, and whether or not atomic actions
across multiple middleboxes should be supported.  The group
concluded that there was a need for a design team, to be
shepherded by Christian Huitema.  Their job is to restate
the problem more clearly.

Jiri asked if there's an issue with fragmented packets
traversing the middlebox.  The consensus was that this is
not the working group's problem.

The working group has been unable to resolve the question of
how network topology should be handled by the midcom agent.
Because we've had so little progress despite extensive
discussion, the chair proposed forming a design team.  Ted
Hardie suggested that instead we should use the old IETF
contest of champions approach, in which champions write
drafts describing their solution to the problem.  The chair
agreed.  The Area Director present, Scott Bradner, agreed
with this approach and indicated that the Transport Area
Directors will assist in evaluating the proposals.

Someone asked why we have a design team for one problem and
a contest for another area.  The design teams are for work
that's currently within the charter and on which there's
fundamental agreement about what we're doing.  The contest
of champions approach is being used for the topology
question because there is not even basic agreement on what
the question is, and there's a need to define the problem.

Requirements document (discussion led by Paul Sijben)
--------
Status:
* Information get togethers have given a lot of input

* Scott Brim has been maintaining a list of requirements
  that are either implicit in the framework document and are
  unresolved or are explicit and unresolved.

The discussion in the meeting focused on 1) the structure of
working group deliverable, and 2) trying to get common
understanding on remaining issues (based on Scott's list)

There was general agreement that there were far too many
requirements, although Graham Travers disagreed with trying
to place a limit on the number of requirements.  Christian
Huitema said that the document should be about six pages
long.

Paul Sijben said that the document should not be simply a
bulleted list of requirements.  It was reiterated that it
shouldn't be necessary to have no requirements in the
framework document and no discussion in the requirements
document, but that some seepage was inevitable.  Scott
Bradner said that a list of requirements without explanation
is almost useless, and that a thick document is almost
useless.  If it takes more than a paragraph then it's
probably too long.

Terminology needs to be defined in the framework document
and then used consistently in both documents.

Unresolved Issues:
Elliot Lear is preparing the definition of a pinhole.
Elliot said that there were a bunch of requirements
describing the purpose of a pinhole with regard to
associated resources, and this should roll up to policy.
He's come come up with a general description but it may be
misconstrued as describing the protocol.  The only
information in the protocol should be that necessary to
describe the policy.  An extensive discussion of which
elements to include, including directionality, left the
question still unresolved.  

The issue of whether or not agents must be known to
endsystem applications has been closed, and the text has
been deleted.

Requirement R18 from Scott Brim's list of unresolved issues
says that the middlebox MUST NOT alter packet information
unless it appears in the packet header.  Paul Sijben said
taht the reason for the requirement is to have a clear
separation of concerns.  Objections included that the
definition of "header" is unclear.  It was pointed out that
we cannot put requirements on the middlebox.  Dave Oran said
that the requirement has no technical content and proposed
that it could be rewritten to say that the middlebox is not
permitted to write a transformation rule that operates on
something that is not specified in a filter.  The chair
started a poll asking how many people wanted the requirement
gone completely (some), how many people wanted to keep the
requirement as is (none), and how many people want to
discuss Dave Oran's proposal.  The last was interrupted by
Scott Bradner, who said that the requirement would not go
through the IESG.  It was therefore dropped.

* Requirement R3a: The MIDCOM protocol MUST support
  communication between multiple MIDCOM agents and multiple
  middleboxes.

Someone said that the requirement should be that one agent
may open a pinhole and another may close it, and that the
requirement needs to be reworded.  Scott Brim responded that
it wasn't intended for two agents working on the same
pinhole, but that a middlebox can talk to more than one
midcom agents (and tell the difference).  Scott then said
that it should either be tossed out or split in two.  It was
agreed that it should be split into two requirements.

* Issue: There must be ownership of resources/pinholes, and
  there must be a way to transfer this ownership from one
  agent to another

Christian said to leave it to the policy server.  There is
authorization, but it's not expressed in terms of ownership.
Someone responded that we don't want it expressed in terms
of policy, and proposed that agents should coordinate
ownership outside the protocol.  Dave Oran asked whether
ownership is a 1) security or 2) mutual exclusion property.
Paul said it's not about mutual exclusion.  Dave then
suggested that this is a capability-based authorization,
although he thinks that capabilities are a bad idea.
Christian said that he didn't like the implications of
ownership transfer.  Jiri is going to work on some alternate
text.

_______________________________________________
midcom mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/midcom