Re: [RAI] RAI processes for handling work effectively

Ben Campbell <> Wed, 19 June 2013 15:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3AB921F9D73 for <>; Wed, 19 Jun 2013 08:54:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y5sf4totI88q for <>; Wed, 19 Jun 2013 08:54:47 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id 6FD4C21F9D3E for <>; Wed, 19 Jun 2013 08:54:47 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id r5JFsdrB003138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Jun 2013 10:54:40 -0500 (CDT) (envelope-from
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ben Campbell <>
In-Reply-To: <>
Date: Wed, 19 Jun 2013 10:54:34 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Brian Rosen <>
X-Mailer: Apple Mail (2.1508)
Received-SPF: pass ( is authenticated by a trusted mechanism)
Subject: Re: [RAI] RAI processes for handling work effectively
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Jun 2013 15:54:49 -0000

Hi Brian,

It's not clear to me what scope you intend for the mini-wg. Does it handle the "higher-level constructions"? Is it responsible for breaking the interdependency logjams? Something else?

What keeps the min-wg from becoming the union of all interested parties from all the existing wgs? (Or was that what you intended?)



On Jun 19, 2013, at 8:05 AM, Brian Rosen <> wrote:

> Suppose we treated this as a mini-WG
> 1. The chairs and ADs work out a charter, with a limited WG time period to discuss. No IESG participation.
> 2. One chair is appointed from among the affected WG chairs
> 3. A new email list is created
> 4. Discussion is held during one of the WG meeting slots.  It can alternate perhaps between the affected groups.  The mini-group doesn't get a slot, but of course it may result in a WG asking for two slots for a particular meeting.
> 5. If there are cross AD issues, one AD is selected
> Put a cap on this effort, and make it short - 2 meeting cycles maybe.  If they can't agree, then most likely each of the WGs will need to come up with their own solutions.
> The mini-WG milestone may not be a submitted draft, it could be a mature draft, that would be finished in one of the affected WGs.  It could even be a general agreement on the solution, rather than an actual mature draft.  At the end, the mail list is closed., further discussion if any happens in the WGs.
> Brian
> On Jun 19, 2013, at 3:03 AM, Gonzalo Camarillo <> wrote:
>> Folks,
>> as you know, in the RAI area we have always considered having effective
>> processes to help us produce relevant and timely specifications a very
>> important issue. When our environment has changed, we have sometimes
>> modified or fine tuned our processes in order to continue being
>> effective. A few examples (among many others) of such changes were the
>> introduction of mentors, the old SIPPING process, P headers, and the
>> current DISPATCH process.
>> It is time for us to look at the current state of affairs and discuss
>> whether or not we need to do certain things in a different way.
>> In particular, we currently have a few groups (e.g., RTCWeb and CLUE)
>> that work on higher-level constructions, which use elements developed in
>> other working groups. For example, CLUE could potentially specify a
>> mechanism that used mechanisms developed in MMUSIC or AVTEXT such as the
>> offer/answer model and a number of RTP extensions.
>> Note that what we called "higher-level constructions" above are referred
>> to by different names by different people: architectures, applications,
>> frameworks, etc. It does not really matter how we call them because this
>> discussion is not about terminology and it is fairly clear what this
>> type of work is about.
>> The way this type of work is currently done in RAI requires the
>> high-level WGs and the WGs developing the individual pieces to
>> communicate often. Those communications are not always easy, since
>> different WGs sometimes have different views on priorities,
>> requirements, use cases, etc.
>> What we would like to get your feedback on is: do we need a better way
>> to handle this type of work in RAI or our current process is as good as
>> it gets?
>> Note that we are interested in getting constructive feedback and ideas
>> on how to improve things. Please, focus your feedback on those aspects.
>> Thanks,
>> Gonzalo
>> (on behalf of both RAI ADs)
>> _______________________________________________
>> RAI mailing list
> _______________________________________________
> RAI mailing list