Subject: [midcom] Design team announcement

From: Melinda Shore <[email-masked]>
Date: Wed, 30 Jan 2002 09:16:50 -0500

In the interest of moving the pre-midcom work along quickly,
we've formed a small design team to produce drafts of two
documents for consideration by the working group.  Those two
documents are 1) the STUN protocol, and 2) a protocol to 
allow servers behind NATs to accept incoming connections.
The design team members are Ram Dantu, Steve Davies, Jonathan 
Rosenberg, Sanjoy Sen, and Mahadev Somasundaram.

We've put together a small, closed design team in response to
time pressures - we need to complete the work quickly, and it
was clear from the existing discussions that that wasn't
likely to happen if we kept the initial work on the mailing list.
It's important to understand that the product of a design team
is input to the working group, not the final product.  That is
to say that they will be producing a proposal which may be
accepted, rejected, or modified by the working group.  I've 
appended a copy of a statement from Harald Alvestrand regarding 
the role of design teams within the IETF.

Right now we're working towards having the STUN document through
working group last call by the end of February.  We don't yet
have a date for the second document, but we'll keep you posted
as it becomes clearer.  Note that both documents must address
the issues raised in the IAB's UNSAF draft
(http://www.ietf.org/internet-drafts/draft-iab-unsaf-considerations-00.txt).

Thanks,

Melinda
========

-------------------------------------------------------------------------
Design teams are mentioned in The Working Group Guidelines RFC (RFC 2418)
as follows:

6.5. Design teams

  It is often useful, and perhaps inevitable, for a sub-group of a
  working group to develop a proposal to solve a particular problem.
  Such a sub-group is called a design team.  In order for a design team
  to remain small and agile, it is acceptable to have closed membership
  and private meetings.  Design teams may range from an informal chat
  between people in a hallway to a formal set of expert volunteers that
  the WG chair or AD appoints to attack a controversial problem.  The
  output of a design team is always subject to approval, rejection or
  modification by the WG as a whole.

The key point here is that the output of a design team is input to a
working group, not a final document.  Such a document must not be
considered as more important than any other input to the working group.

Anyone can write an alternative proposal and ask the working group to
consider it. The decision on which document to work further on must be made
by the consensus of the working group. If design teams work as intended,
their output will be of a quality that speaks for itself.

Working group chairs should note that there is a potential of anti-trust
liability if a design team is formed with a restricted membership and then
the output is given priority over other input to the process.

Any time the Working Group decides to form a design team:
 - it must have a clear terse mission statement that must be posted
   on the working group mailing list.
 - the membership of the design team must also be public and posted
   to the mailing list.
 - any design team that lasts for more than a few months should make
   regular public reports on what they are doing.

-------------------------------------------------------------------------
This note was edited for the IESG by Scott Bradner.

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