Re: [RAI] RAI processes for handling work effectively

Brian Rosen <> Wed, 19 June 2013 13:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60E2A21F9BFE for <>; Wed, 19 Jun 2013 06:05:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -100.307
X-Spam-Status: No, score=-100.307 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VIeElYJ72Ovv for <>; Wed, 19 Jun 2013 06:05:38 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id BD58921F9BC8 for <>; Wed, 19 Jun 2013 06:05:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=zxCz4GBxJ7QGa4rw7bSns8bm2aSQA9drXJCWfny4Oek=; b=V0YGVqYw/XFq5LnsqAjeIL/woPCxeZPlV+4F/rXo1y4R8F2kNBWctmjX5/E++UJSMhNVwQShLQHc/UHKV4BXV1Swtgg5wen2O6JN6nHm7wAE7/QkihgB9WsXjdydZ6Sde+Z/s3d1Ea2M8ANXs+hm3MML8aI3Q2Jq6ZPX3oHNH0Y=;
Received: from ([]:42920 helo=[]) by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <>) id 1UpI4k-0000Eq-Aw; Wed, 19 Jun 2013 09:05:26 -0400
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Brian Rosen <>
In-Reply-To: <>
Date: Wed, 19 Jun 2013 09:05:24 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Gonzalo Camarillo <>
X-Mailer: Apple Mail (2.1508)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
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 13:05:42 -0000

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.

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