Re: [RAI] Making RAI work better
Henning Schulzrinne <hgs@cs.columbia.edu> Wed, 01 October 2008 01:46 UTC
Return-Path: <rai-bounces@ietf.org>
X-Original-To: rai-archive@optimus.ietf.org
Delivered-To: ietfarch-rai-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C11E13A6828; Tue, 30 Sep 2008 18:46:08 -0700 (PDT)
X-Original-To: rai@core3.amsl.com
Delivered-To: rai@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A37C3A6828 for <rai@core3.amsl.com>; Tue, 30 Sep 2008 18:46:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTdNMOPW3ONQ for <rai@core3.amsl.com>; Tue, 30 Sep 2008 18:46:06 -0700 (PDT)
Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 6B98F3A67EE for <rai@ietf.org>; Tue, 30 Sep 2008 18:46:06 -0700 (PDT)
Received: from [192.168.0.61] (pool-71-250-72-76.nwrknj.east.verizon.net [71.250.72.76]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m911kJNO004783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 30 Sep 2008 21:46:21 -0400 (EDT)
Message-Id: <91451A85-3152-4BEB-A2FF-8798875E2B87@cs.columbia.edu>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
To: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <552C9CF9-94FB-42D4-875F-0D2440951DCB@cisco.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Tue, 30 Sep 2008 21:46:19 -0400
References: <552C9CF9-94FB-42D4-875F-0D2440951DCB@cisco.com>
X-Mailer: Apple Mail (2.929.2)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8
Cc: rai@ietf.org
Subject: Re: [RAI] Making RAI work better
X-BeenThere: rai@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <rai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: rai-bounces@ietf.org
Errors-To: rai-bounces@ietf.org
<rant> Prioritizing drafts by dependency chains may help. To take an example that affects a draft which I'm co-authoring: draft-shacham-sipping-session-mobility in RFC editor queue since 2008-01-02 depends on draft-ietf-sip-gruu in RFC editor queue since 2007-10-15, i.e., almost a year depends on draft-ietf-sip-outbound NOT-RECEIVED Unfortunately, the current area management has not responded to suggestions to remove incidental dependencies as a second-best option when certain documents seem stuck. For example, in our case, the GRUU reference is of no great significance (unless GRUU changes drastically in the RFC editor queue, none of the details could conceivably matter), even more so since the document is informational. The primary document has no dependencies on 'outbound', but is "punished" for whatever sins are holding up "outbound" in purgatory. 3GPP wants to cite the document, but can't, and there's no way for the authors to resolve the issue, particularly since repeated requests have gone unanswered. This is one example, but I suspect others have their own personal horror stories. Is it surprising that energy tends to flag given such interminable delays and non-responsiveness? </rant> Henning On Sep 30, 2008, at 11:37 AM, Cullen Jennings wrote: > > Over the past year or so, Jon and I have heard concerns about the > efficiency and organization of the RAI Area. We have both observed > that > the larger working groups, particularly SIP and SIPPING, continue to > have difficulty tackling some of their more complex projects. The more > critical a document seems to be from a dependency perspective, the > more > late surprises seem to emerge in its development and the longer it > takes > to escape from the working group process. A relatively small number of > the working groups in the RAI Area seem to encompass the lion's > share of > our documents in their scope, which may concentrate too much of our > work > in too few areas and cause distracting parallelization. > > Ultimately, these problems might result from any number of causes. > There > might be structural problems with the manner the RAI Area is divided > into working groups, issues with chartering or focusing of the > efforts, > snarls intrinsic to the technology, personnel problems at any number > of levels, questions of participant energy, or any of a number of > combinations thereof. > > What we'd like to do is kick off a discussion about ways that we can > make RAI work better. As a part of that discussion we are reserving > one > of our precious timeslots for a RAI Area open meeting in Minneapolis > (at > least the Friday afternoon experiment will give us one more slot than > usual). In order to help set an agenda for that meeting, we'd like to > invite any comments and discussion on this list (rai@ietf.org), > or if necessarily in private correspondence to Jon and I. We're > interested to learn to what degree people believe there are problems > that need to be addressed, and what sorts of problems and potential > solutions the community can identify. > > Cullen Jennings > Jon Peterson > RAI Area Directors > _______________________________________________ > 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] Making RAI work better Cullen Jennings
- Re: [RAI] Making RAI work better Dean Willis
- Re: [RAI] Making RAI work better Henning Schulzrinne
- Re: [RAI] Making RAI work better Adam Roach
- Re: [RAI] Making RAI work better Adam Roach
- Re: [RAI] Making RAI work better Peterson, Jon
- Re: [RAI] Making RAI work better Elwell, John
- Re: [RAI] Making RAI work better Lars Eggert
- Re: [RAI] Making RAI work better Markus.Isomaki
- Re: [RAI] Making RAI work better Henning Schulzrinne
- Re: [RAI] Making RAI work better Adam Roach
- Re: [RAI] Making RAI work better Mary Barnes
- Re: [RAI] Making RAI work better Francois Audet
- Re: [RAI] Making RAI work better Ben Campbell
- [RAI] Persistence of Consensus [apologies to Salv… Ben Campbell
- Re: [RAI] Persistence of Consensus [apologies to … Mike Hammer (hmmr)
- Re: [RAI] Persistence of Consensus [apologies to … Ben Campbell
- Re: [RAI] Persistence of Consensus [apologies to … Mary Barnes
- Re: [RAI] Persistence of Consensus [apologies to … Henning Schulzrinne
- Re: [RAI] Persistence of Consensus [apologies to … Vijay K. Gurbani
- Re: [RAI] Persistence of Consensus [apologies to … Dan York
- Re: [RAI] Persistence of Consensus [apologies to … Peterson, Jon
- Re: [RAI] Making RAI work better Peterson, Jon
- Re: [RAI] Making RAI work better Dan York
- Re: [RAI] Making RAI work better Dean Willis
- Re: [RAI] Making RAI work better Dean Willis
- Re: [RAI] Making RAI work better Greg Herlein
- Re: [RAI] Making RAI work better Dean Willis
- Re: [RAI] Making RAI work better Adam Roach
- Re: [RAI] Making RAI work better Dean Willis
- Re: [RAI] Making RAI work better Dean Willis
- Re: [RAI] Making RAI work better Hisham Khartabil
- Re: [RAI] Making RAI work better Dean Willis
- Re: [RAI] Making RAI work better Henning Schulzrinne
- Re: [RAI] Making RAI work better Mary Barnes
- Re: [RAI] Making RAI work better Miguel A. Garcia
- Re: [RAI] Persistence of Consensus [apologies to … Marshall Eubanks
- Re: [RAI] Persistence of Consensus [apologies to … Mary Barnes
- Re: [RAI] Making RAI work better Henry Sinnreich
- Re: [RAI] Making RAI work better Dean Willis
- Re: [RAI] Making RAI work better -- categorizing … Markus.Isomaki
- Re: [RAI] Making RAI work better -- categorizing … Miguel A. Garcia
- Re: [RAI] Making RAI work better -- categorizing … Mary Barnes
- Re: [RAI] Making RAI work better - other SDOs Markus.Isomaki
- Re: [RAI] Making RAI work better Livingood, Jason
- Re: [RAI] Making RAI work better Livingood, Jason
- Re: [RAI] Persistence of Consensus [apologies to … Randall Gellens
- Re: [RAI] Making RAI work better DRAGE, Keith (Keith)
- Re: [RAI] Making RAI work better Henry Sinnreich
- Re: [RAI] Making RAI work better Henning Schulzrinne
- Re: [RAI] Making RAI work better Eric Burger
- Re: [RAI] Making RAI work better DRAGE, Keith (Keith)
- Re: [RAI] Making RAI work better Eric Burger
- Re: [RAI] Making RAI work better- or the SIP liqu… Richard Shockey
- Re: [RAI] Making RAI work better Richard Shockey
- Re: [RAI] Making RAI work better Peterson, Jon
- Re: [RAI] Making RAI work better Dean Willis
- Re: [RAI] Making RAI work better Brian Rosen
- Re: [RAI] Making RAI work better Ben Campbell
- Re: [RAI] Making RAI work better Mary Barnes
- Re: [RAI] Making RAI work better Dan York
- Re: [RAI] Making RAI work better Brian Rosen
- Re: [RAI] Making RAI work better Brian Rosen
- Re: [RAI] Making RAI work better Mary Barnes
- Re: [RAI] Making RAI work better Mary Barnes
- Re: [RAI] Making RAI work better Mike Hammer (hmmr)
- Re: [RAI] Making RAI work better Dan York
- Re: [RAI] Making RAI work better Francois Audet
- Re: [RAI] Making RAI work better Mary Barnes
- Re: [RAI] Making RAI work better Mike Hammer (hmmr)
- Re: [RAI] Making RAI work better Henning Schulzrinne
- Re: [RAI] Making RAI work better Henning Schulzrinne
- Re: [RAI] Making RAI work better Richard Shockey
- Re: [RAI] Making RAI work better Richard Shockey
- Re: [RAI] Making RAI work better Jean-Francois Mule
- Re: [RAI] Making RAI work better Gonzalo Camarillo
- Re: [RAI] Making RAI work better Spencer Dawkins
- Re: [RAI] Making RAI work better Henry Sinnreich
- Re: [RAI] Making RAI work better -- running code Markus.Isomaki
- Re: [RAI] Making RAI work better -- running code Mary Barnes
- Re: [RAI] Making RAI work better -- running code Eric Burger
- Re: [RAI] Making RAI work better -- running code Peter Saint-Andre
- Re: [RAI] Making RAI work better Mary Barnes
- Re: [RAI] Making RAI work better -- running code Marc Petit-Huguenin
- Re: [RAI] Making RAI work better -- running code Peterson, Jon
- Re: [RAI] Making RAI work better -- running code Dan Wing
- Re: [RAI] Making RAI work better Tom Taylor
- Re: [RAI] Making RAI work better -- running code Colin Perkins
- Re: [RAI] Making RAI work better Elwell, John
- Re: [RAI] Making RAI work better -- running code Gonzalo Camarillo
- Re: [RAI] Making RAI work better Gonzalo Camarillo
- Re: [RAI] Making RAI work better -- running code Marc Petit-Huguenin
- Re: [RAI] Making RAI work better -- running code Hannes Tschofenig
- Re: [RAI] Making RAI work better -- running code Henry Sinnreich
- Re: [RAI] Making RAI work better -- running code Gonzalo Camarillo
- Re: [RAI] Making RAI work better -- running code Henning Schulzrinne
- Re: [RAI] Making RAI work better Jonathan Rosenberg
- Re: [RAI] Making RAI work better Markus.Isomaki
- Re: [RAI] Making RAI work better Miguel A. Garcia
- Re: [RAI] Making RAI work better Gonzalo Camarillo
- Re: [RAI] Making RAI work better Hisham Khartabil
- Re: [RAI] Making RAI work better Livingood, Jason
- Re: [RAI] Making RAI work better Livingood, Jason
- Re: [RAI] Making RAI work better Dean Willis
- Re: [RAI] Making RAI work better Elwell, John