Re: [RAI] RAI processes for handling work effectively

John Leslie <> Wed, 19 June 2013 14:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F4BA21F9CAF for <>; Wed, 19 Jun 2013 07:43:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.098
X-Spam-Status: No, score=-106.098 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jSFUKG-4nek8 for <>; Wed, 19 Jun 2013 07:43:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6DA8B21F9C41 for <>; Wed, 19 Jun 2013 07:43:30 -0700 (PDT)
Received: by (Postfix, from userid 104) id 3174F33C20; Wed, 19 Jun 2013 10:43:29 -0400 (EDT)
Date: Wed, 19 Jun 2013 10:43:29 -0400
From: John Leslie <>
To: Gonzalo Camarillo <>
Message-ID: <20130619144329.GC44982@verdi>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.4.1i
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 14:43:35 -0000

Gonzalo Camarillo <> wrote:
> 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.

   There is a very obvious three-way interaction among CLUE, RTCWeb, and
MMUSIC. The process is dangerously close to stalled because there's no
hope of reaching agreement on which roadblock needs to be cleared first.

   :^( :^( :^(

> 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.

   Alas, it's not as clear as you think.

> 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.

   That's not the problem. Communication among the WGs is quite good:
there are essentially no arguments which piece belongs in which WG.
The problem perhaps stems from all three WGs needing to follow the work
of both RTCWeb and MMUSIC (thus including folks who otherwise wouldn't
pay attention); but the actual problem is that the dependencies are
too strict.

   My advice, when this sort of situation occurs, is to chop out the
strict dependencies. In this case, MMUSIC seems unable to resolve
"Plan A" vs. "Plan B". Thus, management should find a way to make
that choice no longer gating on RTCWeb and CLUE.

   Perhaps it's not obvious how to do that; but once you give your
attention to _that_ as the problem, several approaches should become

> 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?

   This doesn't strike me as a "process" question exactly. But we do
need some mechanism to find a way to decouple issues which deserve to
be settled in a different WG without requiring everyone to join that
other WG.

   (This is particularly painful to me right now, since I find myself
unable to give enough attention to both RTCWeb and MMUSIC, when what
I really want is to make progress in CLUE.)

   I'm not going to make any particular recommendation on how to
decouple these issues in this email; but I'm willing to do so in a
different email if Gonzalo asks for it.

John Leslie <>