Re: [RAI] RAI processes for handling work effectively
Ben Campbell <ben@nostrum.com> Wed, 19 June 2013 15:54 UTC
Return-Path: <ben@nostrum.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 F3AB921F9D73 for <rai@ietfa.amsl.com>; Wed, 19 Jun 2013 08:54:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5sf4totI88q for <rai@ietfa.amsl.com>; Wed, 19 Jun 2013 08:54:47 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD4C21F9D3E for <rai@ietf.org>; Wed, 19 Jun 2013 08:54:47 -0700 (PDT)
Received: from [172.20.10.2] (mobile-166-147-069-103.mycingular.net [166.147.69.103]) (authenticated bits=0) by shaman.nostrum.com (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 ben@nostrum.com)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <53BDCCA9-CBC5-4992-BE2D-7A96250202F7@brianrosen.net>
Date: Wed, 19 Jun 2013 10:54:34 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <6B7CBDE1-7472-4312-935C-6B7D2284A90F@nostrum.com>
References: <51C157BA.70509@ericsson.com> <53BDCCA9-CBC5-4992-BE2D-7A96250202F7@brianrosen.net>
To: Brian Rosen <br@brianrosen.net>
X-Mailer: Apple Mail (2.1508)
Received-SPF: pass (shaman.nostrum.com: 166.147.69.103 is authenticated by a trusted mechanism)
Cc: 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 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?) 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] RAI processes for handling work effectively Gonzalo Camarillo
- Re: [RAI] RAI processes for handling work effecti… Brian Rosen
- Re: [RAI] RAI processes for handling work effecti… Mary Barnes
- Re: [RAI] RAI processes for handling work effecti… John Leslie
- Re: [RAI] RAI processes for handling work effecti… Ben Campbell
- Re: [RAI] RAI processes for handling work effecti… Mary Barnes
- Re: [RAI] RAI processes for handling work effecti… Mary Barnes
- Re: [RAI] RAI processes for handling work effecti… Michael Hammer
- Re: [RAI] RAI processes for handling work effecti… Mary Barnes
- Re: [RAI] RAI processes for handling work effecti… Harald Alvestrand
- Re: [RAI] RAI processes for handling work effecti… Paul Kyzivat
- Re: [RAI] RAI processes for handling work effecti… Spencer Dawkins
- Re: [RAI] RAI processes for handling work effecti… Hadriel Kaplan
- Re: [RAI] RAI processes for handling work effecti… DRAGE, Keith (Keith)
- Re: [RAI] RAI processes for handling work effecti… SM
- Re: [RAI] RAI processes for handling work effecti… Cullen Jennings (fluffy)
- Re: [RAI] RAI processes for handling work effecti… Harald Alvestrand
- Re: [RAI] RAI processes for handling work effecti… Martin Thomson
- Re: [RAI] RAI processes for handling work effecti… Harald Alvestrand
- Re: [RAI] RAI processes for handling work effecti… Martin Thomson
- Re: [RAI] RAI processes for handling work effecti… Dale R. Worley
- Re: [RAI] RAI processes for handling work effecti… Harald Alvestrand
- Re: [RAI] RAI processes for handling work effecti… Dale R. Worley
- Re: [RAI] RAI processes for handling work effecti… Harald Alvestrand
- Re: [RAI] RAI processes for handling work effecti… Hadriel Kaplan
- Re: [RAI] RAI processes for handling work effecti… Harald Alvestrand