Re: [RAI] Making RAI work better

"Peterson, Jon" <jon.peterson@neustar.biz> Wed, 01 October 2008 08:00 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 294643A6A1E; Wed, 1 Oct 2008 01:00:46 -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 8C2403A6A1E for <rai@core3.amsl.com>; Wed, 1 Oct 2008 01:00:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599]
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 jYPwdoBJYqkV for <rai@core3.amsl.com>; Wed, 1 Oct 2008 01:00:43 -0700 (PDT)
Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id E94753A67F1 for <rai@ietf.org>; Wed, 1 Oct 2008 01:00:41 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1222848059; x=1222934459; h=From:Date:Subject:Message-ID:Content-class:Content-Type:Content-Transfer-Encod ing; b=LW09CK1vR5zlQrOwc3QZVBviOf2lJHEMTCTAxJMn2Af/CFMt5R3YJITvLMR/4zHpA8zHu1UTJgrVDN harIxubg==
Received: from ([10.31.13.50]) by chihiron2.nc.neustar.com with ESMTP id 5202415.8461317; Wed, 01 Oct 2008 04:00:34 -0400
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 01 Oct 2008 04:00:05 -0400
Message-ID: <C80ADC57CB3BB64B94A9954A816306C5AA6256@STNTEXCH11.cis.neustar.com>
In-Reply-To: <91451A85-3152-4BEB-A2FF-8798875E2B87@cs.columbia.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [RAI] Making RAI work better
Thread-Index: AckjZ5gp6aoteg5CT9WdmUDbY9y4RgALw+cA
References: <552C9CF9-94FB-42D4-875F-0D2440951DCB@cisco.com> <91451A85-3152-4BEB-A2FF-8798875E2B87@cs.columbia.edu>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: Henning Schulzrinne <hgs@cs.columbia.edu>, Cullen Jennings <fluffy@cisco.com>
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: rai-bounces@ietf.org
Errors-To: rai-bounces@ietf.org

Henning,

Speaking to the portion of this about area management, I do acknowledge
(as the responsible AD for your document) that unresponsive management
is a problem in RAI, and that AD sluggishness helps to perpetuate a
cycle of delay. This is indeed one of the reasons why I'm not seeking
another term as an AD; some fresh blood and energy should definitely
help with that.

At a higher level, I also agree that unnecessary normative dependencies
are a problem. I actually wrote a draft about reducing normative
dependencies not too long ago which, I'd say, was met with about equal
parts of avid support and dismissive hostility. In that document I
questioned what it even meant for Informational documents to hold
normative dependencies, and what it meant for a particular piece of text
in a document to constitute a normative reference. I believe that deep
obscurities in this area cause us many process headaches.

Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of
Henning Schulzrinne
Sent: Tuesday, September 30, 2008 6:46 PM
To: Cullen Jennings
Cc: rai@ietf.org
Subject: Re: [RAI] Making RAI work better

<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 mailing list
RAI@ietf.org
https://www.ietf.org/mailman/listinfo/rai