Re: [RAI] RAI processes for handling work effectively

Spencer Dawkins <spencerdawkins.ietf@gmail.com> Thu, 18 July 2013 14:47 UTC

Return-Path: <spencerdawkins.ietf@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 0E26221F8E2D for <rai@ietfa.amsl.com>; Thu, 18 Jul 2013 07:47:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 h1eROIBhqfUE for <rai@ietfa.amsl.com>; Thu, 18 Jul 2013 07:47:54 -0700 (PDT)
Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id D5C4D21E8105 for <rai@ietf.org>; Thu, 18 Jul 2013 07:47:48 -0700 (PDT)
Received: by mail-pd0-f178.google.com with SMTP id w11so3168941pde.9 for <rai@ietf.org>; Thu, 18 Jul 2013 07:47:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=gstEMd4wBVqTuaTCjn8RwD+JayJYGcX6ASE/m2LNB8I=; b=OXLtdUFC3HOW83bGhIAoX1zalzx5GBHlgGXyoXPo9O+OY4F6710tpgTaB/qLU/jMsh NZgip7b/30x2BhcApkAzCvxLoMnTvV4Z1yQJuWdEPGeLWz0LHbIBs3MK/xi8+Cpcchl7 tK5W6G89Pe3rbtA0xSMAOLN8MpkWbicjkOE9ZWWOftE67XjNnxfnoC0NL7Frk2cNaTe5 9VpwhP7yIvVm7pIaB+h0HNmOJvAunooxNghQqtcmpnvowJgxVNQ+yWPvkgrpAayeiFhW wV0brWdoLzQAVHwHCOSCrQHWQAQjAqFuakEGQXYeOozyUl2vFaz91+2pzVDb/DvCjgKz PiZA==
X-Received: by 10.68.179.101 with SMTP id df5mr12701680pbc.33.1374158868587; Thu, 18 Jul 2013 07:47:48 -0700 (PDT)
Received: from [192.168.1.74] (99-108-174-213.lightspeed.rcsntx.sbcglobal.net. [99.108.174.213]) by mx.google.com with ESMTPSA id il4sm14144102pbb.36.2013.07.18.07.47.46 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jul 2013 07:47:47 -0700 (PDT)
Message-ID: <51E8000C.9040304@gmail.com>
Date: Thu, 18 Jul 2013 09:47:40 -0500
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
References: <51C157BA.70509@ericsson.com> <51E7D81A.5000008@alvestrand.no> <51E7F3E6.7030308@alum.mit.edu>
In-Reply-To: <51E7F3E6.7030308@alum.mit.edu>
Content-Type: multipart/alternative; boundary="------------040903030105050403080507"
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: Thu, 18 Jul 2013 14:47:55 -0000

On 7/18/2013 8:55 AM, Paul Kyzivat wrote:
> Harald,
>
> What you say makes some sense to me.
>
> But if we were to act on it then I think we need to replace some WGs 
> with review panels. (We have an SDP directorate, but I don't think 
> that is a sufficient replacement for mmusic.) And so we will need some 
> clear processes for review panels. How would we process drafts that 
> would otherwise have been handled through the standanding wg? Would 
> they be AD sponsored? And we may need to schedule meeting sessions for 
> review panels too.
>
> This seems like it would need to be an ietf-wide change, not just RAI. 
> (But maybe we could pilot it in RAI.)

I could be in the rough on this, but if RAI wants to head in that 
direction, I'd suggest doing so in RAI alone as an 
http://tools.ietf.org/html/rfc3933 process experiment. That would bypass 
two frequent sources of failure:

  * Getting everyone in the entire IETF to agree (at least roughly) to
    that this is where we all want to go, and
  * Getting everyone in the entire IETF to agree (at least roughly) to
    change BCP text for the entire IETF, with no operational experience.

 From RFC 3933:

    The IESG is explicitly authorized to use this mechanism (based on
    Experimental RFCs) to gain experience with proposed changes to BCP
    specifications.  There is no requirement to approve a BCP
    specification for the experiment until the experiment is found to
    have value.

and

    In each case, the IESG's decision to go forward (or not) with a
    procedural experiment, or the steps leading up to one, is expected to
    reflect their judgment of the existence of rough consensus in the
    community.  That judgment may be appealed using the usual procedures,
    but the IESG and the community are reminded that an experimental
    attempt to try something for a fixed period is typically a better
    engineering approach than extended philosophical discussion without
    any experience to back it up.

No one understands the last sentence better than Harald, of course ...

Spencer