Re: [RAI] RAI processes for handling work effectively

Mary Barnes <mary.ietf.barnes@gmail.com> Wed, 19 June 2013 16:54 UTC

Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: rai@ietfa.amsl.com
Delivered-To: rai@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA6D21F9DA6 for <rai@ietfa.amsl.com>; Wed, 19 Jun 2013 09:54:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.453
X-Spam-Level:
X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvYlNcDxbfR9 for <rai@ietfa.amsl.com>; Wed, 19 Jun 2013 09:54:55 -0700 (PDT)
Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6B75421F9D8E for <rai@ietf.org>; Wed, 19 Jun 2013 09:54:50 -0700 (PDT)
Received: by mail-qc0-f171.google.com with SMTP id n1so3159683qcw.16 for <rai@ietf.org>; Wed, 19 Jun 2013 09:54:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Z/yakUf/T9hahKOQDlQZFNfJWUozk0ZwSl06oibLOpI=; b=0CvzXlV42Y3Lb5jRaEdxbpxKH3FvDxykDcTkLtwn7jEAFmzqjIVbQo9EoyuQBajQ25 T58NFt4bOiuWyKDikElgUMjDX+FH1vXCRm0TX5fMMro1TE2X/IX7dOhHdLPjIGIH88W3 qi2lNM3DHcXxTAgaRYujN7lSAmwntyZMPjpe9qOZzw14coWjROChE/kJQi7RBi5Or57C e/k9fDvwtMGJX9jMiA2eas/V8d5FzW4geUD7XoKvx5NL2vpP5qvn5sJI0eR/QuUrLF+q Qhxg7CkBnr+6C4USWcXE3789I4TGtlvZMyFMDnGxNJy411LinOlcoY1/9uXHyo5HcXrY nMMw==
MIME-Version: 1.0
X-Received: by 10.229.177.10 with SMTP id bg10mr1379729qcb.135.1371660889932; Wed, 19 Jun 2013 09:54:49 -0700 (PDT)
Received: by 10.49.76.167 with HTTP; Wed, 19 Jun 2013 09:54:49 -0700 (PDT)
In-Reply-To: <CAHBDyN4UJiWY2KZg2Z2qv7AmDPByzeHEg=ft-xq1AZvNkMw9Fw@mail.gmail.com>
References: <51C157BA.70509@ericsson.com> <53BDCCA9-CBC5-4992-BE2D-7A96250202F7@brianrosen.net> <6B7CBDE1-7472-4312-935C-6B7D2284A90F@nostrum.com> <CAHBDyN4UJiWY2KZg2Z2qv7AmDPByzeHEg=ft-xq1AZvNkMw9Fw@mail.gmail.com>
Date: Wed, 19 Jun 2013 11:54:49 -0500
Message-ID: <CAHBDyN6Zfh0nZ53g88nfgNcU3oxEex_6igcVy19Qz1Wv5u4T2A@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "rai@ietf.org" <rai@ietf.org>
Subject: Re: [RAI] RAI processes for handling work effectively
X-BeenThere: rai@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <rai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rai>, <mailto:rai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rai>
List-Post: <mailto:rai@ietf.org>
List-Help: <mailto:rai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jun 2013 16:54:57 -0000

BTW, if you want a real live example as to the extent of the current
problem, just listen to the first 25 minutes of the MMUSIC virtual
interim held this past Monday.

Mary.

On Wed, Jun 19, 2013 at 11:53 AM, Mary Barnes
<mary.ietf.barnes@gmail.com> wrote:
> I'm not Brian but I'll go ahead and respond with my perspective [MB].
>
> Mary.
>
> On Wed, Jun 19, 2013 at 10:54 AM, Ben Campbell <ben@nostrum.com> wrote:
>> 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?
> [MB] I believe the "higher-level constructions" (which are
> "applications" in my mind) are the responsibility of the group
> chartered to create that solution based on existing protocols as well
> as any new protocols the specific WG deems necessary.  The new mini-WG
> is intended to deal with the solution requirements that may need to
> change existing protocols. [/MB]
>>
>> What keeps the min-wg from becoming the union of all interested parties from all the existing wgs? (Or was that what you intended?)
> [MB] The new mini-WG would be the union of all the parties that are
> interested in reusing and changing existing protocols. This doesn't
> impact the existing WGs chartered to define the solution for the
> "higher-level constructions" - this does impact some of the existing
> protocol building blocks that they may need to reuse and extend.
> While we have WGs that are explicitly chartered to define new
> extensions (e.g., MMUSIC for SDP), it's impossible to isolate the
> solution aspects (from the "higher-level construct" WGs) and
> requirements from the extensions that might be needed in the other WG.
>  This gets to be particularly problematic in the case where you have
> two WGs defining new "applications".  The big issue is figuring out
> who is responsible for guiding the work in the existing WG where
> extensions need to be defined.  Again, it's impossible to do the work
> and have sensible discussions without understanding some aspects
> required by the solution (and why they are required). While it's
> tempting for the chairs of the WG where extensions need to be defined
> to suggest that "application" discussions are out of scope, that just
> doesn't work.  By having chairs from all the WGs involved represented
> in the new mini-WG, everyone has "equal stakes" so to speak in
> ensuring that a solution is reached.  Setting a specific deadline is
> extremely helpful as it helps deal with deadlock situations and the
> reality that the new "applications" may not be able to use the same
> extensions, for example.
> [/MB]
>>
>> Thanks!
>>
>> Ben.
>>
>> On Jun 19, 2013, at 8:05 AM, Brian Rosen <br@brianrosen.net> 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 <Gonzalo.Camarillo@ericsson.com> 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@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rai
>>>
>>> _______________________________________________
>>> RAI mailing list
>>> RAI@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rai
>>
>> _______________________________________________
>> RAI mailing list
>> RAI@ietf.org
>> https://www.ietf.org/mailman/listinfo/rai