Subject: [AAA-DOCTORS] FW: Internal WG Review: Dispatch (dispatch)

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 4 Mar 2009 15:28:56 +0100

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
IESG Secretary
Sent: Wednesday, March 04, 2009 2:15 AM
To: [email-masked]; [email-masked]
Subject: Internal WG Review: Dispatch (dispatch) 

A new IETF working group is being considered in the Real-time
Applications and Infrastructure Area.  The draft charter for this
working group is provided below for your review and comment.

Review time is one week.

The IETF Secretariat

Dispatch (dispatch)
--------------------------------------------------
Current Status: Proposed Working Group

Last Modified: 2009-02-27

Group Description: 
The Dispatch working group is chartered to consider proposals for new
work in the RAI area and identify, or help create, an appropriate venue
for the work. Options for handling new work include:

- Assigning the work to an existing WG.
- Developing a proposal for a BOF.
- Developing a charter and establishing consensus for a new WG or
Exploratory Group. This option will primarily be used with fairly mature
and well-defined efforts.

A major objective of the DISPATCH WG is to provide timely, clear
dispositions of new efforts. Where there is consensus to take on new
work, the WG will strive to quickly find a home for it.
Reconsideration of proposal which have failed to gather consensus will
be prioritized behind proposals for new work which have not yet been
considered. In general, requests for reconsideration should only be made
once a proposal has been significantly revised.

The DISPATCH WG will also operate as an area wide WG where ideas can be
discussed that do not currently have a logical venue for the work to be
done. As part of this function, the WG will evaluate SIP Event Packages
that were not developed inside some other area working group.

Guiding principles will include:

1. Providing a clear problem statement for proposed new work.

2. Prioritizing new efforts so that RAI does not take on more work than
it can effectively complete.

3. Looking for commonalities among ongoing development efforts.
Such commonalities may indicate the need to develop more general,
reusable components.

4. Protecting the architectural integrity of RAI protocols and ensuring
that work has general applicability.

The WG may take on some of the previous work items from the SIPPING
working group to allow a smooth transition