From problem-statement-bounces@alvestrand.no Tue Sep 2 12:09:43 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11354 for ; Tue, 2 Sep 2003 12:09:42 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 42AE461DEA; Tue, 2 Sep 2003 18:09:16 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by eikenes.alvestrand.no (Postfix) with ESMTP id 28B5461C13 for ; Tue, 2 Sep 2003 18:09:14 +0200 (CEST) Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 Sep 2003 09:09:13 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h82G9BCb021724 for ; Tue, 2 Sep 2003 09:09:11 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-42.cisco.com [10.32.241.42]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ALP17832; Tue, 2 Sep 2003 09:09:10 -0700 (PDT) Date: Tue, 2 Sep 2003 12:09:08 -0400 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Melinda Shore To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.551) Subject: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Unfortunately, we left Vienna in probably greater confusion about how to move forward than we were before we arrived. We need to spend some more time discussing what we want to say about changing the structure and practices of the IETF. There have been several proposals to date but none has been attracted anything resembling consensus. The soon-to-be-posted revision of the process document says this: 5.2 Changing the Structure and Practices of the IETF, contains the following appeal: Given the lack of concensus, this document asks the IETF community to submit and discuss further alternative process (and solution) proposals that might attract better concensus. and so we're soliciting contributions. Melinda & Avri From problem-statement-bounces@alvestrand.no Tue Sep 2 13:00:31 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14996 for ; Tue, 2 Sep 2003 13:00:30 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C26B361DEA; Tue, 2 Sep 2003 19:00:04 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9C9C861C13 for ; Tue, 2 Sep 2003 18:59:58 +0200 (CEST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14864; Tue, 2 Sep 2003 12:59:51 -0400 (EDT) Message-Id: <200309021659.MAA14864@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: problem-statement@alvestrand.no From: Internet-Drafts@ietf.org Date: Tue, 02 Sep 2003 12:59:51 -0400 Subject: I-D ACTION:draft-ietf-problem-process-02.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Internet-Drafts@ietf.org List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Problem Statement Working Group of the IETF. Title : IETF Problem Resolution Process Author(s) : E. Davies, J. Hofmann Filename : draft-ietf-problem-process-02.txt Pages : 21 Date : 2003-9-2 This document suggests processes to address some of the problems identified in the IETF Problem Statement. This document decomposes each of the problems described in the problem statement into a few areas for improvement, categorizes them either as problems affecting the routine processes used to create standards or problems affecting the fundamental structure and practices of the IETF, and suggests ways to address the problems with the routine processes that can be implemented as soon as possible without disrupting other areas of the IETF processes. This version of the draft does not suggest a process for dealing with the structural problems due to the lack of concensus on the way forwards in this area. Instead, the community is asked to offer alternative suggestions for the process and submit them as Internet Drafts for consideration by this WG. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-problem-process-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-problem-process-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-problem-process-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-2100333.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-problem-process-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-problem-process-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-2100333.I-D@ietf.org> --OtherAccess-- --NextPart-- From problem-statement-bounces@alvestrand.no Tue Sep 2 16:34:23 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05147 for ; Tue, 2 Sep 2003 16:34:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2912862201; Tue, 2 Sep 2003 22:33:55 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 73E87621FF; Tue, 2 Sep 2003 22:33:52 +0200 (CEST) Date: Tue, 02 Sep 2003 13:33:51 -0700 From: Harald Tveit Alvestrand To: Melinda Shore , problem-statement@alvestrand.no Message-ID: <630656205.1062509630@HALVESTR-W2K1.cisco.com> In-Reply-To: References: X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Melinda, slightly confused: are you asking for input on how we should structure the process for achieving at a set of changes, or on what the changes should be? These issues are related, but not the same.... Harald --On 2. september 2003 12:09 -0400 Melinda Shore wrote: > Unfortunately, we left Vienna in probably greater confusion about > how to move forward than we were before we arrived. We need to > spend some more time discussing what we want to say about changing > the structure and practices of the IETF. There have been several > proposals to date but none has been attracted anything resembling > consensus. The soon-to-be-posted revision of the process document > says this: > > 5.2 Changing the Structure and Practices of the IETF, contains the > following appeal: Given the lack of concensus, this document asks the > IETF community to submit and discuss further alternative process (and > solution) proposals that might attract better concensus. > > and so we're soliciting contributions. > > Melinda & Avri > > From problem-statement-bounces@alvestrand.no Tue Sep 2 16:44:17 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05710 for ; Tue, 2 Sep 2003 16:44:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D598D62254; Tue, 2 Sep 2003 22:43:48 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by eikenes.alvestrand.no (Postfix) with ESMTP id 36D17621FF; Tue, 2 Sep 2003 22:43:46 +0200 (CEST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h82KhhVT020702; Tue, 2 Sep 2003 13:43:43 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-42.cisco.com [10.32.241.42]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ALP59690; Tue, 2 Sep 2003 13:43:42 -0700 (PDT) Date: Tue, 2 Sep 2003 16:43:39 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) To: Harald Tveit Alvestrand From: Melinda Shore In-Reply-To: <630656205.1062509630@HALVESTR-W2K1.cisco.com> Message-Id: <2233AE7F-DD86-11D7-BA1C-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Cc: problem-statement@alvestrand.no Subject: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On Tuesday, September 2, 2003, at 04:33 PM, Harald Tveit Alvestrand wrote: > are you asking for input on how we should structure the process for > achieving at a set of changes, or on what the changes should be? The latter is, strictly speaking, out of scope. But we do need input on the question of how to tackle the restructuring (if it's agreed that it's necessary) question, whether it's details on how to construct a blue-ribbon panel or to recommend kicking the whole thing over to the IESG. Melinda From problem-statement-bounces@alvestrand.no Tue Sep 2 17:01:48 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07456 for ; Tue, 2 Sep 2003 17:01:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AD32062206; Tue, 2 Sep 2003 23:01:20 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9276B61BDE; Tue, 2 Sep 2003 23:01:17 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h82L62E08373; Tue, 2 Sep 2003 14:06:02 -0700 Date: Tue, 2 Sep 2003 14:01:06 -0700 From: Dave Crocker X-Mailer: The Bat! (v2.00) Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <18724557752.20030902140106@brandenburg.com> To: Melinda Shore In-Reply-To: <2233AE7F-DD86-11D7-BA1C-000A95E35274@cisco.com> References: <630656205.1062509630@HALVESTR-W2K1.cisco.com> <2233AE7F-DD86-11D7-BA1C-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Harald Tveit Alvestrand , problem-statement@alvestrand.no Subject: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Dave Crocker List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Melinda, MS> we do need input on the question of how to tackle the MS> restructuring (if it's agreed that it's necessary) question, MS> whether it's details on how to construct a blue-ribbon panel MS> or to recommend kicking the whole thing over to the IESG. The situation is a bit worse than that. Other than general references to "restructuring" we do not have anything concretely specifying what that means, nevermind whether we have consensus to pursue it. We could probably get community consensus that the world needs peace. But the consensus would have little practical use, in terms of predicting that community's embracing of any particular peace proposal, or even of giving guidance for how to pursue peace. When people explain what they mean by the term restructuring, in terms that have some concrete relationship to the operation of the IETF and some understanding of the intended, concrete outcomes, *then* it might be worth considering how to pursue it. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue Sep 2 17:56:27 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10908 for ; Tue, 2 Sep 2003 17:56:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BB4686225C; Tue, 2 Sep 2003 23:55:59 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D611C62254; Tue, 2 Sep 2003 23:55:55 +0200 (CEST) Date: Tue, 02 Sep 2003 14:52:07 -0700 From: Harald Tveit Alvestrand To: Melinda Shore Message-ID: <635353169.1062514327@localhost> In-Reply-To: <18724557752.20030902140106@brandenburg.com> References: <630656205.1062509630@HALVESTR-W2K1.cisco.com> <2233AE7F-DD86-11D7-BA1C-000A95E35274@cisco.com> <18724557752.20030902140106@brandenburg.com> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: problem-statement@alvestrand.no Subject: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On 2. september 2003 14:01 -0700 Dave Crocker wrote: > Melinda, > > MS> we do need input on the question of how to tackle the > MS> restructuring (if it's agreed that it's necessary) question, > MS> whether it's details on how to construct a blue-ribbon panel > MS> or to recommend kicking the whole thing over to the IESG. > > The situation is a bit worse than that. > > Other than general references to "restructuring" we do not have anything > concretely specifying what that means, nevermind whether we have > consensus to pursue it. I think the WG has the following chartered work item: > As a second work item, the group will also produce a proposal for a > process to develop solutions to the problems identified by this working > group. Since we know what the problems are (modulo objections to -issue-03, which I haven't seen much of), there should be at least some possibility of suggesting the required process for fixing them. This may come in the form of (problem, suggested solution, how-to-get-there) descriptions, or it may come in the form of (problem, needed investigation, range of solutions) descriptions; I personally don't think all of our problems will be solved by a single fell-swoop solution - different problems may require different approaches, so there are probably multiple things that can be suggested, refined and adopted - but I think the proposals need to be anchored into "what problem are we trying to solve". (Yes, I AM working on delivering what I think the IESG was charged with in Vienna - proposing at least some process to deal with at least some of the problems. It's not ready for publication yet.) Harald From problem-statement-bounces@alvestrand.no Tue Sep 2 18:16:37 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13027 for ; Tue, 2 Sep 2003 18:16:37 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E9D7C621FF; Wed, 3 Sep 2003 00:16:10 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3F6A6621B6 for ; Wed, 3 Sep 2003 00:16:09 +0200 (CEST) Received: from dfnjgl21 (adsl-68-90-116-171.dsl.rcsntx.swbell.net[68.90.116.171]) by comcast.net (sccrmhc11) with SMTP id <200309022216070110060v21e> (Authid: sdawkins@comcast.net); Tue, 2 Sep 2003 22:16:07 +0000 Message-ID: <001b01c3719f$cf8b56a0$ab745a44@DFNJGL21> From: "Spencer Dawkins" To: References: <630656205.1062509630@HALVESTR-W2K1.cisco.com><2233AE7F-DD86-11D7-BA1C-000A95E35274@cisco.com><18724557752.20030902140106@brandenburg.com> <635353169.1062514327@localhost> Date: Tue, 2 Sep 2003 17:16:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Dear Dave, I have been confused before, but had assumed that "restructuring" meant at least "fixing 2.6.2 in the current problem statement draft". If it means more than this, that's fine. But I happen to believe that 2.6.2 is a real problem, and that structural changes are likely required to fix them. ("Workload of the IESG", if the draft isn't open in a window on your desktop/palmtop/laptop/etc.) Spencer ----- Original Message ----- From: "Harald Tveit Alvestrand" To: "Melinda Shore" Cc: Sent: Tuesday, September 02, 2003 4:52 PM Subject: Re: Moving the process document forward > > > --On 2. september 2003 14:01 -0700 Dave Crocker wrote: > > > Melinda, > > > > MS> we do need input on the question of how to tackle the > > MS> restructuring (if it's agreed that it's necessary) question, > > MS> whether it's details on how to construct a blue-ribbon panel > > MS> or to recommend kicking the whole thing over to the IESG. > > > > The situation is a bit worse than that. > > > > Other than general references to "restructuring" we do not have anything > > concretely specifying what that means, nevermind whether we have > > consensus to pursue it. > > I think the WG has the following chartered work item: > > > As a second work item, the group will also produce a proposal for a > > process to develop solutions to the problems identified by this working > > group. > > Since we know what the problems are (modulo objections to -issue-03, which > I haven't seen much of), there should be at least some possibility of > suggesting the required process for fixing them. > > This may come in the form of (problem, suggested solution, > how-to-get-there) descriptions, or it may come in the form of (problem, > needed investigation, range of solutions) descriptions; I personally don't > think all of our problems will be solved by a single fell-swoop solution - > different problems may require different approaches, so there are probably > multiple things that can be suggested, refined and adopted - but I think > the proposals need to be anchored into "what problem are we trying to > solve". > > (Yes, I AM working on delivering what I think the IESG was charged with in > Vienna - proposing at least some process to deal with at least some of the > problems. It's not ready for publication yet.) > > Harald > From problem-statement-bounces@alvestrand.no Tue Sep 2 18:40:12 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14341 for ; Tue, 2 Sep 2003 18:40:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 060BE6225D; Wed, 3 Sep 2003 00:39:45 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from athene.wz-berlin.de (athene.wz-berlin.de [193.174.6.3]) by eikenes.alvestrand.no (Postfix) with ESMTP id C8D1162259; Wed, 3 Sep 2003 00:39:43 +0200 (CEST) Received: from medea.wz-berlin.de ([193.174.6.5]) by athene.wz-berlin.de with esmtp (Exim 4.22) id 19uJoM-0004WL-2E; Wed, 03 Sep 2003 00:39:42 +0200 Received: from ERDE/SpoolDir by medea.wz-berlin.de (Mercury 1.48); 3 Sep 03 00:39:43 +0200 Received: from SpoolDir by ERDE (Mercury 1.48); 3 Sep 03 00:39:17 +0200 From: "Jeanette Hofmann" Organization: Wissenschaftszentrum Berlin To: Dave Crocker Date: Wed, 03 Sep 2003 00:39:11 +0200 MIME-Version: 1.0 Message-ID: <3F553831.30377.1109B00@localhost> Priority: normal In-reply-to: <18724557752.20030902140106@brandenburg.com> References: <2233AE7F-DD86-11D7-BA1C-000A95E35274@cisco.com> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Virus-Scanned: by amavisd-new-20030616-p5 (Debian) at wz-berlin.de Cc: Harald Tveit Alvestrand , problem-statement@alvestrand.no Subject: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7BIT On 2 Sep 2003 at 14:01, Dave Crocker wrote: > Melinda, > > MS> we do need input on the question of how to tackle the > MS> restructuring (if it's agreed that it's necessary) question, > MS> whether it's details on how to construct a blue-ribbon panel > MS> or to recommend kicking the whole thing over to the IESG. > > The situation is a bit worse than that. > > Other than general references to "restructuring" we do not have anything > concretely specifying what that means, nevermind whether we have > consensus to pursue it. In the problem resolution process draft we differentiate between near-term improvements and longer-term efforts aiming to adress structures of the IETF. In the structural problems improvement process draft we suggest a list of issues, which are discussed in more detail in Elwyn's problem issue draft: o The Mission Problem (Section 4.1), o the Complex Problems problem (Section 4.3), o the Standards Hierarchy problem (Section 4.4), o the Management Scaling problem (Section 4.6), and o The longer-term portions of the Engagement Problem (Section 4.5) This list is not meant to be exhaustive. It is just the result of the discussion on this list. jeanette > > We could probably get community consensus that the world needs peace. > But the consensus would have little practical use, in terms of > predicting that community's embracing of any particular peace proposal, > or even of giving guidance for how to pursue peace. > > When people explain what they mean by the term restructuring, in terms > that have some concrete relationship to the operation of the IETF and > some understanding of the intended, concrete outcomes, *then* it might > be worth considering how to pursue it. > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > From problem-statement-bounces@alvestrand.no Thu Sep 4 09:05:46 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19181 for ; Thu, 4 Sep 2003 09:05:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5AB2862257; Thu, 4 Sep 2003 15:05:18 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by eikenes.alvestrand.no (Postfix) with ESMTP id CC9BE61C11 for ; Thu, 4 Sep 2003 15:05:16 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h84D5EYG088738 for ; Thu, 4 Sep 2003 15:05:15 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h84D5IMQ279898 for ; Thu, 4 Sep 2003 15:05:19 +0200 Received: from zurich.ibm.com (dhcp22-49.zurich.ibm.com [9.4.22.49]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA34836 for ; Thu, 4 Sep 2003 15:05:09 +0200 Message-ID: <3F57387A.1A5DAB6D@zurich.ibm.com> Date: Thu, 04 Sep 2003 15:04:58 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: problem-statement@alvestrand.no References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: WG Last Call on IETF Problem Statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Ship it. We are way beyond the point of diminishing returns on this. Brian avri wrote: > > This note marks the beginning of the WG Last call for: > > Title : IETF Problem Statement > Author(s) : E. Davies > Filename : draft-ietf-problem-issue-statement-03.txt > Pages : 24 > Date : 2003-8-26 > > The document can be found at: > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-problem-issue-statement-03.txt > > Because of the US holiday on Monday , 1- Sept, the last call will extend from now, 31 August until 16 September (any time zone). > > Please send your comments to the WG mailing list problem-statement@alvestrand.no > > thanks > > a. > > Avri Doria > co-chair From problem-statement-bounces@alvestrand.no Thu Sep 4 09:58:05 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23154 for ; Thu, 4 Sep 2003 09:58:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 75F956225A; Thu, 4 Sep 2003 15:57:35 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by eikenes.alvestrand.no (Postfix) with ESMTP id DC78C62257 for ; Thu, 4 Sep 2003 15:57:33 +0200 (CEST) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h84DvWYG109552 for ; Thu, 4 Sep 2003 15:57:32 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h84DvdNl262666 for ; Thu, 4 Sep 2003 15:57:40 +0200 Received: from zurich.ibm.com (dhcp22-49.zurich.ibm.com [9.4.22.49]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA45034 for ; Thu, 4 Sep 2003 15:57:31 +0200 Message-ID: <3F5744C0.8B8C10B2@zurich.ibm.com> Date: Thu, 04 Sep 2003 15:57:20 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: problem-statement@alvestrand.no References: <2233AE7F-DD86-11D7-BA1C-000A95E35274@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Reading draft-ietf-problem-process-02.txt and draft-davies-structural-rev-process-00.txt, I'm concerned that we are falling into our own trap (i.e. over-engineering). To me things are not so complicated. We have a list of problems ready to publish. We have a measure of agreement that the current leaders (IESG + IAB) ultimately have to show leadership in implementing change to solve those problems, without fixing what isn't broken. So we should basically send the list of problems to the IESG and tell them to set up design teams to fix them. The decomposition in draft-ietf-problem-process-02.txt is certainly useful because it suggests a structure of design teams, but I think this WG would be best advised to stop there. Brian Melinda Shore wrote: > > On Tuesday, September 2, 2003, at 04:33 PM, Harald Tveit Alvestrand > wrote: > > are you asking for input on how we should structure the process for > > achieving at a set of changes, or on what the changes should be? > > The latter is, strictly speaking, out of scope. But > we do need input on the question of how to tackle the > restructuring (if it's agreed that it's necessary) question, > whether it's details on how to construct a blue-ribbon panel > or to recommend kicking the whole thing over to the IESG. > > Melinda From problem-statement-bounces@alvestrand.no Thu Sep 4 18:00:33 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25434 for ; Thu, 4 Sep 2003 18:00:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 67FF961BF4; Fri, 5 Sep 2003 00:00:06 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from athene.wz-berlin.de (athene.wz-berlin.de [193.174.6.3]) by eikenes.alvestrand.no (Postfix) with ESMTP id 00F7861BAD for ; Fri, 5 Sep 2003 00:00:04 +0200 (CEST) Received: from medea.wz-berlin.de ([193.174.6.5]) by athene.wz-berlin.de with esmtp (Exim 4.22) id 19v294-0000Xq-An; Fri, 05 Sep 2003 00:00:02 +0200 Received: from ERDE/SpoolDir by medea.wz-berlin.de (Mercury 1.48); 5 Sep 03 00:00:02 +0200 Received: from SpoolDir by ERDE (Mercury 1.48); 4 Sep 03 23:59:43 +0200 From: "Jeanette Hofmann" Organization: Wissenschaftszentrum Berlin To: problem-statement@alvestrand.no, Brian E Carpenter Date: Thu, 04 Sep 2003 23:59:37 +0200 MIME-Version: 1.0 Message-ID: <3F57D1ED.31068.25AFA01@localhost> Priority: normal In-reply-to: <3F5744C0.8B8C10B2@zurich.ibm.com> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Virus-Scanned: by amavisd-new-20030616-p5 (Debian) at wz-berlin.de Subject: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7BIT On 4 Sep 2003 at 15:57, Brian E Carpenter wrote: > Reading draft-ietf-problem-process-02.txt and > draft-davies-structural-rev-process-00.txt, I'm concerned that we > are falling into our own trap (i.e. over-engineering). > > To me things are not so complicated. We have a list of problems > ready to publish. We have a measure of agreement that the current > leaders (IESG + IAB) ultimately have to show leadership in > implementing change to solve those problems, without fixing what > isn't broken. So we should basically send the list of problems to the > IESG and tell them to set up design teams to fix them. Your proposal touches upon several of the problems documented in the problem issue draft. To list the obvious ones: 2.6.1 Span of authority: Overt authority in the IETF is concentrated in the small number of people sitting on the IESG... 2.6.2 Workload of the IESG: With the current structure of the IETF and IESG, it is clear that the workload imposed on each of the Area Directors (ADs) is well beyond the capabilities.... 2.6.6 Concentration of Influence in Too Few Hands: ... the IETF appeared to have created an affinity group system which tended to re-select the same leaders from a limited pool of people... 2.6.7 Excessive Reliance on Personal Relationships: ...the IETF is built on a particular kind of one-to-one personal trust relationships. This is a very powerful model but it does not scale well... I wonder what we gain if we set up a resolution process which basically repeats or even exacerbates the problems the process is meant to solve. jeanette The > decomposition in draft-ietf-problem-process-02.txt is certainly > useful because it suggests a structure of design teams, > but I think this WG would be best advised to stop there. > > Brian > > Melinda Shore wrote: > > > > On Tuesday, September 2, 2003, at 04:33 PM, Harald Tveit Alvestrand > > wrote: > > > are you asking for input on how we should structure the process for > > > achieving at a set of changes, or on what the changes should be? > > > > The latter is, strictly speaking, out of scope. But > > we do need input on the question of how to tackle the > > restructuring (if it's agreed that it's necessary) question, > > whether it's details on how to construct a blue-ribbon panel > > or to recommend kicking the whole thing over to the IESG. > > > > Melinda From problem-statement-bounces@alvestrand.no Fri Sep 5 08:01:58 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16249 for ; Fri, 5 Sep 2003 08:01:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CA52161B95; Fri, 5 Sep 2003 14:01:21 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by eikenes.alvestrand.no (Postfix) with ESMTP id B9C8A61B91 for ; Fri, 5 Sep 2003 14:01:19 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h85C1HEF202514; Fri, 5 Sep 2003 14:01:17 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h85C1PFU234068; Fri, 5 Sep 2003 14:01:26 +0200 Received: from zurich.ibm.com (dhcp22-49.zurich.ibm.com [9.4.22.49]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA44270; Fri, 5 Sep 2003 14:01:15 +0200 Message-ID: <3F587B00.DDEBEA5A@zurich.ibm.com> Date: Fri, 05 Sep 2003 14:01:04 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Jeanette Hofmann References: <3F57D1ED.31068.25AFA01@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit in line... Jeanette Hofmann wrote: > > On 4 Sep 2003 at 15:57, Brian E Carpenter wrote: > > > Reading draft-ietf-problem-process-02.txt and > > draft-davies-structural-rev-process-00.txt, I'm concerned that we > > are falling into our own trap (i.e. over-engineering). > > > > To me things are not so complicated. We have a list of problems > > ready to publish. We have a measure of agreement that the current > > leaders (IESG + IAB) ultimately have to show leadership in > > implementing change to solve those problems, without fixing what > > isn't broken. So we should basically send the list of problems to the > > IESG and tell them to set up design teams to fix them. > > Your proposal touches upon several of the problems documented in the > problem issue draft. You're missing my point. The only authority that exists *today* is today's leadership. Nobody else but them can change things. So it simply *doesn't matter* that today's leadership is perceived by some people as part of the problem. There is nobody else who actually can initiate change. > To list the obvious ones: > > 2.6.1 Span of authority: Overt authority in the IETF is concentrated in the > small number of people sitting on the IESG... > > 2.6.2 Workload of the IESG: With the current structure of the IETF and IESG, > it is clear that the workload imposed on each of the Area Directors (ADs) is > well beyond the capabilities.... > > 2.6.6 Concentration of Influence in Too Few Hands: ... the IETF appeared to > have created an affinity group system which tended to re-select the same > leaders from a limited pool of people... > > 2.6.7 Excessive Reliance on Personal Relationships: ...the IETF is built on a > particular kind of one-to-one personal trust relationships. This is a very > powerful model but it does not scale well... > > I wonder what we gain if we set up a resolution process which basically > repeats or even exacerbates the problems the process is meant to solve. That is very unfair to the current IESG and IAB and the attitude many of them, and the IETF Chair, have taken to the work here. We are obviously going to set up one or more design teams (whatever name you choose, it's the same thing) and we can do it the easy way (have the IESG do it) or erect a new, complicated, ad hoc mechanism to produce the same result more slowly. I want to see these design teams next week, not next year! Brian > jeanette > > The > > decomposition in draft-ietf-problem-process-02.txt is certainly > > useful because it suggests a structure of design teams, > > but I think this WG would be best advised to stop there. > > > > Brian > > > > Melinda Shore wrote: > > > > > > On Tuesday, September 2, 2003, at 04:33 PM, Harald Tveit Alvestrand > > > wrote: > > > > are you asking for input on how we should structure the process for > > > > achieving at a set of changes, or on what the changes should be? > > > > > > The latter is, strictly speaking, out of scope. But > > > we do need input on the question of how to tackle the > > > restructuring (if it's agreed that it's necessary) question, > > > whether it's details on how to construct a blue-ribbon panel > > > or to recommend kicking the whole thing over to the IESG. > > > > > > Melinda From problem-statement-bounces@alvestrand.no Fri Sep 5 10:25:39 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26220 for ; Fri, 5 Sep 2003 10:25:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 36FA261B95; Fri, 5 Sep 2003 16:25:12 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by eikenes.alvestrand.no (Postfix) with ESMTP id 577F361B91 for ; Fri, 5 Sep 2003 16:25:10 +0200 (CEST) Received: from dfnjgl21 (adsl-68-90-116-171.dsl.rcsntx.swbell.net[68.90.116.171]) by comcast.net (rwcrmhc13) with SMTP id <2003090514250801500cch18e> (Authid: sdawkins@comcast.net); Fri, 5 Sep 2003 14:25:08 +0000 Message-ID: <006b01c373b9$82dad7b0$0400a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <3F57D1ED.31068.25AFA01@localhost> <3F587B00.DDEBEA5A@zurich.ibm.com> Date: Fri, 5 Sep 2003 09:25:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Dear Brian, I hope (or at least "think") we are tripping over a word or two. > > You're missing my point. The only authority that exists *today* is > today's leadership. Nobody else but them can change things. So it simply > *doesn't matter* that today's leadership is perceived by some people > as part of the problem. There is nobody else who actually can initiate change. > I was relatively with you down to the last two words. Do you mean - initiate a proposal for change, or - initiate change based on a proposal? I think Jeanette is talking about the process for initiating a proposal for change. [deleted down to] > I want to see these design teams next week, not next year! That would be lovely... Spencer From problem-statement-bounces@alvestrand.no Fri Sep 5 10:41:07 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27342 for ; Fri, 5 Sep 2003 10:41:06 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EB06C61B95; Fri, 5 Sep 2003 16:40:39 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from athene.wz-berlin.de (athene.wz-berlin.de [193.174.6.3]) by eikenes.alvestrand.no (Postfix) with ESMTP id D853D61B91 for ; Fri, 5 Sep 2003 16:40:38 +0200 (CEST) Received: from medea.wz-berlin.de ([193.174.6.5]) by athene.wz-berlin.de with esmtp (Exim 4.22) id 19vHlK-0004Mn-O2; Fri, 05 Sep 2003 16:40:34 +0200 Received: from ERDE/SpoolDir by medea.wz-berlin.de (Mercury 1.48); 5 Sep 03 16:40:34 +0200 Received: from SpoolDir by ERDE (Mercury 1.48); 5 Sep 03 16:40:28 +0200 From: "Jeanette Hofmann" Organization: Wissenschaftszentrum Berlin To: Brian E Carpenter Date: Fri, 05 Sep 2003 16:40:23 +0200 MIME-Version: 1.0 Message-ID: <3F58BC78.3464.E19E52@localhost> Priority: normal In-reply-to: <3F587B00.DDEBEA5A@zurich.ibm.com> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Virus-Scanned: by amavisd-new-20030616-p5 (Debian) at wz-berlin.de Cc: problem-statement@alvestrand.no Subject: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7BIT On 5 Sep 2003 at 14:01, Brian E Carpenter wrote: > in line... > > Jeanette Hofmann wrote: > > > > On 4 Sep 2003 at 15:57, Brian E Carpenter wrote: > > > > > Reading draft-ietf-problem-process-02.txt and > > > draft-davies-structural-rev-process-00.txt, I'm concerned that we > > > are falling into our own trap (i.e. over-engineering). > > > > > > To me things are not so complicated. We have a list of problems > > > ready to publish. We have a measure of agreement that the current > > > leaders (IESG + IAB) ultimately have to show leadership in > > > implementing change to solve those problems, without fixing what > > > isn't broken. So we should basically send the list of problems to the > > > IESG and tell them to set up design teams to fix them. > > > > Your proposal touches upon several of the problems documented in the > > problem issue draft. > > You're missing my point. Thank you. The only authority that exists *today* is > today's leadership. I didn't deny that. Neither does draft-davies-structural-rev-process-00.txt. According to our model, IESG and IAB nominate people for the SAP panel, the IESG would keep an oversight role and make final decisions. Nobody else but them can change things. So it simply > *doesn't matter* that today's leadership is perceived by some people > as part of the problem. There is nobody else who actually can initiate change. > > > To list the obvious ones: > > > > 2.6.1 Span of authority: Overt authority in the IETF is concentrated in the > > small number of people sitting on the IESG... > > > > 2.6.2 Workload of the IESG: With the current structure of the IETF and IESG, > > it is clear that the workload imposed on each of the Area Directors (ADs) is > > well beyond the capabilities.... > > > > 2.6.6 Concentration of Influence in Too Few Hands: ... the IETF appeared to > > have created an affinity group system which tended to re-select the same > > leaders from a limited pool of people... > > > > 2.6.7 Excessive Reliance on Personal Relationships: ...the IETF is built on a > > particular kind of one-to-one personal trust relationships. This is a very > > powerful model but it does not scale well... > > > > I wonder what we gain if we set up a resolution process which basically > > repeats or even exacerbates the problems the process is meant to solve. > > That is very unfair to the current IESG and IAB and the attitude many > of them, and the IETF Chair, have taken to the work here. I was talking about structural problems not about individual people. I was merely quoting from a list of problems generated on this very list to explain why I don't share your view on what constitutes an easy and quick path forward. Jeanette We are obviously > going to set up one or more design teams (whatever name you choose, it's > the same thing) and we can do it the easy way (have the IESG do it) or > erect a new, complicated, ad hoc mechanism to produce the same result more > slowly. > > I want to see these design teams next week, not next year! > > Brian > > > jeanette > > > > The > > > decomposition in draft-ietf-problem-process-02.txt is certainly > > > useful because it suggests a structure of design teams, > > > but I think this WG would be best advised to stop there. > > > > > > Brian > > > > > > Melinda Shore wrote: > > > > > > > > On Tuesday, September 2, 2003, at 04:33 PM, Harald Tveit Alvestrand > > > > wrote: > > > > > are you asking for input on how we should structure the process for > > > > > achieving at a set of changes, or on what the changes should be? > > > > > > > > The latter is, strictly speaking, out of scope. But > > > > we do need input on the question of how to tackle the > > > > restructuring (if it's agreed that it's necessary) question, > > > > whether it's details on how to construct a blue-ribbon panel > > > > or to recommend kicking the whole thing over to the IESG. > > > > > > > > Melinda From problem-statement-bounces@alvestrand.no Fri Sep 5 11:08:15 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29020 for ; Fri, 5 Sep 2003 11:08:15 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A70EE61B95; Fri, 5 Sep 2003 17:07:48 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2896E61B91 for ; Fri, 5 Sep 2003 17:07:47 +0200 (CEST) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 30F20140DC; Fri, 5 Sep 2003 11:07:46 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30494-07; Fri, 5 Sep 2003 11:07:45 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 8112A13FE2; Fri, 5 Sep 2003 11:07:45 -0400 (EDT) Date: Fri, 5 Sep 2003 11:07:44 -0400 From: Keith Moore To: "Jeanette Hofmann" Message-Id: <20030905110744.2beb2be0.moore@cs.utk.edu> In-Reply-To: <3F57D1ED.31068.25AFA01@localhost> References: <3F5744C0.8B8C10B2@zurich.ibm.com> <3F57D1ED.31068.25AFA01@localhost> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Cc: problem-statement@alvestrand.no, moore@cs.utk.edu Subject: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > Your proposal touches upon several of the problems documented in the > problem issue draft. To list the obvious ones: Since there are problems with every part of the IETF organization (they're certainly not entirely in IESG and IAB) it is impossible to have the problems addressed by a part of the organization that doesn't have problems. IESG and IAB are in the best position to set up design teams to make suggestions as to how to solve these problems. Since design teams have no official status, other people can also form design teams (or act as individuals) and write internet-drafts about how to solve these problems if they want to do so; indeed, some suggestions have already been presented in that form. But the alternative to having IESG and IAB set up design teams is to wait for other people to take the initiative, and this seems unlikely to produce good results in a timely fashion. No matter who makes the suggestions, any changes to the existing BCPs that dictate how we do our work still have to be vetted through the IETF consensus process. From problem-statement-bounces@alvestrand.no Fri Sep 5 11:50:38 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02292 for ; Fri, 5 Sep 2003 11:50:37 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 95CF861BB1; Fri, 5 Sep 2003 17:50:09 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0800A61B95 for ; Fri, 5 Sep 2003 17:50:08 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h85Fo5MD065584; Fri, 5 Sep 2003 17:50:06 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h85FoFFU279812; Fri, 5 Sep 2003 17:50:15 +0200 Received: from zurich.ibm.com (dhcp22-49.zurich.ibm.com [9.4.22.49]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA50890; Fri, 5 Sep 2003 17:50:04 +0200 Message-ID: <3F58B0A1.A5C60352@zurich.ibm.com> Date: Fri, 05 Sep 2003 17:49:53 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Spencer Dawkins References: <3F57D1ED.31068.25AFA01@localhost> <3F587B00.DDEBEA5A@zurich.ibm.com> <006b01c373b9$82dad7b0$0400a8c0@DFNJGL21> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Spencer Dawkins wrote: > > Dear Brian, > > I hope (or at least "think") we are tripping over a word or two. > > > > > You're missing my point. The only authority that exists *today* is > > today's leadership. Nobody else but them can change things. So it > simply > > *doesn't matter* that today's leadership is perceived by some people > > as part of the problem. There is nobody else who actually can > initiate change. > > > > I was relatively with you down to the last two words. Do you mean > > - initiate a proposal for change, or > > - initiate change based on a proposal? > > I think Jeanette is talking about the process for initiating a > proposal for change. I think so to. And I'm pessimistic about that happening quickly except by decisive IESG action. Sorry, but this WG suffers from the same problems that it has identified. Brian > > [deleted down to] > > > I want to see these design teams next week, not next year! > > That would be lovely... > > Spencer -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From problem-statement-bounces@alvestrand.no Fri Sep 5 18:40:08 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24283 for ; Fri, 5 Sep 2003 18:40:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A34DA61BB1; Sat, 6 Sep 2003 00:39:42 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8303E61B95 for ; Sat, 6 Sep 2003 00:39:41 +0200 (CEST) Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.22) id 19vPEx-0000BP-VC for problem-statement@alvestrand.no; Fri, 05 Sep 2003 22:39:40 +0000 Date: Sat, 6 Sep 2003 07:38:59 +0900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Avri Doria To: problem-statement@alvestrand.no Content-Transfer-Encoding: quoted-printable In-Reply-To: <3F58B0A1.A5C60352@zurich.ibm.com> Message-Id: X-Mailer: Apple Mail (2.552) Subject: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable On l=F6rdag, sep 6, 2003, at 00:49 Asia/Seoul, Brian E Carpenter wrote: >> >> >> I think Jeanette is talking about the process for initiating a >> proposal for change. > > I think so to. And I'm pessimistic about that happening quickly > except by decisive IESG action. speaking personally: And if that happens, then perhaps a proposal from this group does=20 become superfluous. but until such time as they do, it is the WG role=20= to try and suggest a process to them. And draft-davies-structural-rev-process-02 itself says, this group can=20= decide that it doesn't want to suggest any process other then asking=20 the IESG to please fix things. and if that turns out to be the rough=20 consensus then fine it gets documented and we are done. My concern is that if we wait for speedy decisive action and that=20 action doesn't come then a year can pass with us being no further along=20= then we are now. the only alternative most of us have since we cannot=20= affect the IESG in any direct manner is to continue working within the=20= context of this WG within the context of its charter. As i see the SAP proposal in draft-davies-structural-rev-process-00 it=20= is a way to create a 'design team', making sure that it gets and=20 considers opinions from all involved. a. From problem-statement-bounces@alvestrand.no Fri Sep 5 20:52:53 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28966 for ; Fri, 5 Sep 2003 20:52:52 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9F14A61BAE; Sat, 6 Sep 2003 02:52:25 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9B59F61B95 for ; Sat, 6 Sep 2003 02:52:24 +0200 (CEST) Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.22) id 19vRJP-000ARk-HN for problem-statement@alvestrand.no; Sat, 06 Sep 2003 00:52:23 +0000 Date: Sat, 6 Sep 2003 09:51:38 +0900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Avri Doria To: problem-statement@alvestrand.no Content-Transfer-Encoding: quoted-printable In-Reply-To: Message-Id: <45A901FB-E004-11D7-853D-000393CC2112@acm.org> X-Mailer: Apple Mail (2.552) Subject: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable I got one of the draft names wrong in this email. Correction below. a. On l=F6rdag, sep 6, 2003, at 07:38 Asia/Seoul, Avri Doria wrote: > > On l=F6rdag, sep 6, 2003, at 00:49 Asia/Seoul, Brian E Carpenter = wrote: >>> >>> >>> I think Jeanette is talking about the process for initiating a >>> proposal for change. >> >> I think so to. And I'm pessimistic about that happening quickly >> except by decisive IESG action. > > speaking personally: > > And if that happens, then perhaps a proposal from this group does=20 > become superfluous. but until such time as they do, it is the WG role=20= > to try and suggest a process to them. > > And draft-davies-structural-rev-process-02 itself says, this group can=20= > decide that it should be draft-ietf-problem-process-02.txt > doesn't want to suggest any process other then asking the IESG to=20 > please fix things. and if that turns out to be the rough consensus=20 > then fine it gets documented and we are done. > > My concern is that if we wait for speedy decisive action and that=20 > action doesn't come then a year can pass with us being no further=20 > along then we are now. the only alternative most of us have since we=20= > cannot affect the IESG in any direct manner is to continue working=20 > within the context of this WG within the context of its charter. > > As i see the SAP proposal in draft-davies-structural-rev-process-00 it=20= > is a way to create a 'design team', making sure that it gets and=20 > considers opinions from all involved. > > a. > > > From problem-statement-bounces@alvestrand.no Fri Sep 5 21:54:53 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01443 for ; Fri, 5 Sep 2003 21:54:52 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2ABBB61BE5; Sat, 6 Sep 2003 03:54:26 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id C602D61BD6 for ; Sat, 6 Sep 2003 03:54:24 +0200 (CEST) Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.22) id 19vSHN-000ElA-I2 for problem-statement@alvestrand.no; Sat, 06 Sep 2003 01:54:21 +0000 Date: Sat, 6 Sep 2003 10:53:35 +0900 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Avri Doria To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Subject: Note regarding reaching consensus on long term process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hi, just wanted to make sure that the WG group knew that since I had joined with Elwyn and Jeanette in proposing a particular process for inclusion in the WG process doc, any final WG chair determination of WG rough consensus on long term process recommendations will belong to Melinda, my co-chair. a. From problem-statement-bounces@alvestrand.no Sat Sep 6 10:19:06 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16858 for ; Sat, 6 Sep 2003 10:19:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3C69061C0A; Sat, 6 Sep 2003 16:17:18 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2AD3761C09 for ; Sat, 6 Sep 2003 16:17:17 +0200 (CEST) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id D075B14050; Sat, 6 Sep 2003 10:17:15 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12497-04; Sat, 6 Sep 2003 10:17:15 -0400 (EDT) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id BD86E14028; Sat, 6 Sep 2003 10:17:14 -0400 (EDT) Date: Sat, 6 Sep 2003 10:14:34 -0400 From: Keith Moore To: Avri Doria Message-Id: <20030906101434.4975a669.moore@cs.utk.edu> In-Reply-To: References: <3F58B0A1.A5C60352@zurich.ibm.com> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Cc: problem-statement@alvestrand.no, moore@cs.utk.edu Subject: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > My concern is that if we wait for speedy decisive action and that > action doesn't come then a year can pass with us being no further along > then we are now. if this WG tries to get consensus on the way forward, it will take even longer. Keith From problem-statement-bounces@alvestrand.no Sat Sep 6 10:54:58 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18765 for ; Sat, 6 Sep 2003 10:54:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6C26D61BF8; Sat, 6 Sep 2003 16:54:32 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4095761BD8 for ; Sat, 6 Sep 2003 16:54:30 +0200 (CEST) Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.22) id 19veSK-000AKF-TF for problem-statement@alvestrand.no; Sat, 06 Sep 2003 14:54:29 +0000 Date: Sat, 6 Sep 2003 23:53:45 +0900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Avri Doria To: problem-statement@alvestrand.no Content-Transfer-Encoding: quoted-printable In-Reply-To: <20030906101434.4975a669.moore@cs.utk.edu> Message-Id: X-Mailer: Apple Mail (2.552) Subject: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable On l=F6rdag, sep 6, 2003, at 23:14 Asia/Seoul, Keith Moore wrote: >> My concern is that if we wait for speedy decisive action and that >> action doesn't come then a year can pass with us being no further=20 >> along >> then we are now. > > if this WG tries to get consensus on the way forward, it will take = even > longer. > > I don't see why that is necessarily so. If people were to start=20 talking about a process and to start making comments on what is wrong=20 with the SAP idea or to start making other process suggestions we might=20= get somewhere. If, on the other hand, all we can talk about is why it would take a=20 long time to get a process to consensus, then we may create a self=20 fulfilling prophecy. As it currently stands this group is close to being on its schedule,=20 and I believe that if we focused on a process for moving forward we=20 would get one with consensus. Personally, I am into trying to find the process that can work and can=20= represent the various interests of IETF participants. It doesn't have=20= to be a perfect process, just one that work work and one that would not=20= leave the community out. While I can't state for certain that the IESG=20= couldn't do it, I personally think it would be very difficult for them=20= to take in the breadth of opinion and synthesis it into something that=20= will satisfy the community and get the job done. All this while doing=20 their normal IESG work. =46rom watching the solutions group, it is obvious there are folks with=20= ideas and I am sure there are many that haven't been aired yet. Now we=20= need a way to find out which ideas are the ones that will serve to fix=20= the problems that need fixing. How do we take the many ideas people=20 have for ways to fix things and come up with some practical workable=20 solutions. What we need is a process that will take the richness we=20 have in the IETF community and bring it together into a workable=20 solution. a. From problem-statement-bounces@alvestrand.no Sat Sep 6 16:54:11 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04479 for ; Sat, 6 Sep 2003 16:54:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 961D661BD8; Sat, 6 Sep 2003 22:53:44 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by eikenes.alvestrand.no (Postfix) with ESMTP id AB41A61BAC for ; Sat, 6 Sep 2003 22:53:42 +0200 (CEST) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id E4BCD1401D; Sat, 6 Sep 2003 16:53:41 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12036-12; Sat, 6 Sep 2003 16:53:41 -0400 (EDT) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id C679114008; Sat, 6 Sep 2003 16:53:40 -0400 (EDT) Date: Sat, 6 Sep 2003 16:50:59 -0400 From: Keith Moore To: Avri Doria Message-Id: <20030906165059.79b707a6.moore@cs.utk.edu> In-Reply-To: References: <20030906101434.4975a669.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Cc: problem-statement@alvestrand.no, moore@cs.utk.edu Subject: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > >> My concern is that if we wait for speedy decisive action and that > >> action doesn't come then a year can pass with us being no further > >> along then we are now. > > > > if this WG tries to get consensus on the way forward, it will take even > > longer. > > > > > I don't see why that is necessarily so. in general, it's harder to get agreeement among a large number of people with widely varying levels of experience (in this case, that means experience leading IETF or a very similar activity) than it is to get agreement among a smaller number of people all of whom have some direct experience. this is especially true when the consequences of being wrong are severe. From problem-statement-bounces@alvestrand.no Mon Sep 8 00:52:07 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07553 for ; Mon, 8 Sep 2003 00:52:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7C54361BB9; Mon, 8 Sep 2003 06:51:41 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2FE8F61BB0 for ; Mon, 8 Sep 2003 06:51:39 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h884uSP22844; Sun, 7 Sep 2003 21:56:28 -0700 Date: Sun, 7 Sep 2003 21:51:24 -0700 From: Dave Crocker X-Mailer: The Bat! (v2.00) Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <159131908794.20030907215124@brandenburg.com> To: Brian E Carpenter In-Reply-To: <3F587B00.DDEBEA5A@zurich.ibm.com> References: <3F57D1ED.31068.25AFA01@localhost> <3F587B00.DDEBEA5A@zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: initiating change X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Brian, BEC> You're missing my point. The only authority that exists *today* is BEC> today's leadership. Nobody else but them can change things. So it simply BEC> *doesn't matter* that today's leadership is perceived by some people BEC> as part of the problem. There is nobody else who actually can initiate change. I think you have correctly summarized a common point of view in the community. What it misses is that the IESG is not really tasked with "initiating" very much and, in fact, has very little history "initiating" much. By design and by long practise, this is a community of self-starters. The job of the IESG is to shepherd *community* initiatives. i.e., community = individuals from the community = us. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From problem-statement-bounces@alvestrand.no Mon Sep 8 01:07:00 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08314 for ; Mon, 8 Sep 2003 01:07:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4354361BF9; Mon, 8 Sep 2003 07:06:33 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id B5F3461BB0; Mon, 8 Sep 2003 07:06:30 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h885BQP23631; Sun, 7 Sep 2003 22:11:26 -0700 Date: Sun, 7 Sep 2003 21:48:47 -0700 From: Dave Crocker X-Mailer: The Bat! (v2.00) Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <16131752059.20030907214847@brandenburg.com> To: Harald Tveit Alvestrand In-Reply-To: <635353169.1062514327@localhost> References: <630656205.1062509630@HALVESTR-W2K1.cisco.com> <2233AE7F-DD86-11D7-BA1C-000A95E35274@cisco.com> <18724557752.20030902140106@brandenburg.com> <635353169.1062514327@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Dave Crocker List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > --On 2. september 2003 14:01 -0700 Dave Crocker wrote: >> Other than general references to "restructuring" we do not have anything >> concretely specifying what that means, nevermind whether we have >> consensus to pursue it. HTA> I think the WG has the following chartered work item: I'm confused by your response, since none of it seems to pertain to my note. Let's be clear: 1. I did not say that anyone or thing in the Problem working group has been done badly or outside of scope 2. The charter text you quote says nothing about "restructuring" being required" 3. Neither the problems draft nor solutions draft says nothing about restructuring being required. So let me state my point again: Some folks are tossing around the term "restructuring" as if a) it is accepted that that will happen, and b) that there is some general understanding of what the term means. I claim that neither is true. However the term tends to imply potentially massive change. Yet there is certainly no basis for claiming that we have community consensus in favor of massive change. If my assessment is incorrect, I would really appreciate hearing how. SD> I have been confused before, but had assumed that "restructuring" SD> meant at least "fixing 2.6.2 in the current problem statement draft". I could make a guess about what the term means, too. It might or might not be the same as your guess. My point is that the term "restructuring" is too serious and implies too much change for us to be guessing. JH> In the structural problems improvement process draft we suggest a list of JH> issues, which are discussed in more detail in Elwyn's problem issue draft: My original -- and continuing -- point is that "improvement" to a structure does not necessarily mean "restructuring". Too much is being taken for granted or is being said without enough precision. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From problem-statement-bounces@alvestrand.no Mon Sep 8 03:43:01 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29192 for ; Mon, 8 Sep 2003 03:43:01 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4A97A61C19; Mon, 8 Sep 2003 09:42:35 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0C16461C13 for ; Mon, 8 Sep 2003 09:42:34 +0200 (CEST) Received: from bs.jck.com ([209.187.148.211] helo=localhost) by bs.jck.com with esmtp (Exim 4.10) id 19wGfP-000BmB-00; Mon, 08 Sep 2003 02:42:32 -0500 Date: Sun, 07 Sep 2003 23:15:53 -0400 From: John C Klensin To: Avri Doria , problem-statement@alvestrand.no Message-ID: <7283042.1062976553@localhost> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On Saturday, September 06, 2003 07:38 +0900 Avri Doria wrote: > My concern is that if we wait for speedy decisive action and > that action doesn't come then a year can pass with us being no > further along then we are now. the only alternative most of > us have since we cannot affect the IESG in any direct manner > is to continue working within the context of this WG within > the context of its charter. > > As i see the SAP proposal in > draft-davies-structural-rev-process-00 it is a way to create a > 'design team', making sure that it gets and considers opinions > from all involved. But, unless I misunderstand parts of that document --which is possible, of course, it isn't going anywhere unless the IESG takes action, if only to start appointing people. That brings us back to Brian's position, and the questions I raised during the Vienna plenary: either the IESG has to take responsibility for moving things forward from this point, or we are stuck. Now, "the IESG takes responsibility" could involve their deciding to create some SAP action, or their deciding to create some other design team mechanism, or their deciding to create some follow-on WG(s) (my least favorite option), or their deciding to actually do or propose something decisive (for community review and/or as an experiment). But, any way you look at it, I think there are only three possibilities: * We continue to discuss issues and possible solutions for a very long time, probably until the proverbial hot place freezes over. * The IESG takes _some_ action. * We conclude that the IESG is sufficiently uninterested in effective change that the appropriate Minneapolis plenary action is to insist that all of them resign, effective as soon as the Nomcom can come up with replacements who are more receptive to change and evolution. Fortunately, my sense is that the odds that the latter is necessary are very, very, low. And that makes the second choice the best one, I think clearly so. john From problem-statement-bounces@alvestrand.no Mon Sep 8 04:05:43 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00249 for ; Mon, 8 Sep 2003 04:05:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A297061C20; Mon, 8 Sep 2003 10:05:17 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id 24C5A61C09 for ; Mon, 8 Sep 2003 10:05:16 +0200 (CEST) Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.22) id 19wH1O-000P1f-WC for problem-statement@alvestrand.no; Mon, 08 Sep 2003 08:05:15 +0000 Date: Mon, 8 Sep 2003 17:04:27 +0900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Avri Doria To: problem-statement@alvestrand.no Content-Transfer-Encoding: quoted-printable In-Reply-To: <7283042.1062976553@localhost> Message-Id: <110A2C22-E1D3-11D7-853D-000393CC2112@acm.org> X-Mailer: Apple Mail (2.552) Subject: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Hi John, You are right at the end of the day, the IESG has to take some action=20 (leaving open the possible view that to take no action is to take=20 action) I think there are two paths: - they can figure it out a process on their own. or - the Problem WG can come up with a suggestion it reaches consensus on=20= and after being reviewed by the IETF in LC it is sent to the IESG. In the first case they can do anything they wish. The community=20 doesn't really get much of a say other then in the context of Nomcom. =20= In the second case, one can hope they would go with the consensus=20 reached by the WG etc. I.e. the community does get to voice an opinion. The IESG gave the community an opportunity to voice its opinion on the=20= process to be taken; i.e. it created this WG with its charter. If this=20= WG doesn't come up with one, I think it is tantamount to inviting the=20= IESG to do as they please. If this group can come to closure on a process (not the solutions to=20 the issues, that is not our task) in short time, we can send that on. =20= If we can't, we fail in meeting our charter and await their pleasure. a. On m=E5ndag, sep 8, 2003, at 12:15 Asia/Seoul, John C Klensin wrote: > > > --On Saturday, September 06, 2003 07:38 +0900 Avri Doria > wrote: > >> My concern is that if we wait for speedy decisive action and >> that action doesn't come then a year can pass with us being no >> further along then we are now. the only alternative most of >> us have since we cannot affect the IESG in any direct manner >> is to continue working within the context of this WG within >> the context of its charter. >> >> As i see the SAP proposal in >> draft-davies-structural-rev-process-00 it is a way to create a >> 'design team', making sure that it gets and considers opinions >> from all involved. > > But, unless I misunderstand parts of that document --which is > possible, of course, it isn't going anywhere unless the IESG > takes action, if only to start appointing people. That brings > us back to Brian's position, and the questions I raised during > the Vienna plenary: either the IESG has to take responsibility > for moving things forward from this point, or we are stuck. > Now, "the IESG takes responsibility" could involve their > deciding to create some SAP action, or their deciding to create > some other design team mechanism, or their deciding to create > some follow-on WG(s) (my least favorite option), or their > deciding to actually do or propose something decisive (for > community review and/or as an experiment). But, any way you > look at it, I think there are only three possibilities: > > * We continue to discuss issues and possible solutions > for a very long time, probably until the proverbial hot > place freezes over. > =09 > * The IESG takes _some_ action. > =09 > * We conclude that the IESG is sufficiently uninterested > in effective change that the appropriate Minneapolis > plenary action is to insist that all of them resign, > effective as soon as the Nomcom can come up with > replacements who are more receptive to change and > evolution. > > Fortunately, my sense is that the odds that the latter is > necessary are very, very, low. And that makes the second choice > the best one, I think clearly so. > > john > > From problem-statement-bounces@alvestrand.no Mon Sep 8 05:30:26 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05024 for ; Mon, 8 Sep 2003 05:30:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F1B1261C09; Mon, 8 Sep 2003 11:29:59 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by eikenes.alvestrand.no (Postfix) with ESMTP id B842261C03 for ; Mon, 8 Sep 2003 11:29:58 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h889TuYG028946; Mon, 8 Sep 2003 11:29:56 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h889TtK9235662; Mon, 8 Sep 2003 11:29:56 +0200 Received: from zurich.ibm.com (dhcp22-49.zurich.ibm.com [9.4.22.49]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA57108; Mon, 8 Sep 2003 11:29:55 +0200 Message-ID: <3F5C4C07.1F42220C@zurich.ibm.com> Date: Mon, 08 Sep 2003 11:29:43 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Dave Crocker References: <3F57D1ED.31068.25AFA01@localhost> <3F587B00.DDEBEA5A@zurich.ibm.com> <159131908794.20030907215124@brandenburg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: initiating change X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Dave Crocker wrote: > > Brian, > > BEC> You're missing my point. The only authority that exists *today* is > BEC> today's leadership. Nobody else but them can change things. So it simply > BEC> *doesn't matter* that today's leadership is perceived by some people > BEC> as part of the problem. There is nobody else who actually can initiate change. > > I think you have correctly summarized a common point of view in the community. > > What it misses is that the IESG is not really tasked with "initiating" very > much and, in fact, has very little history "initiating" much. > > By design and by long practise, this is a community of self-starters. The job > of the IESG is to shepherd *community* initiatives. > > i.e., > > community = individuals from the community = us. Yes, but I think we have done that bit. Turning it into actual actions is the next hurdle. That's where I have trouble seeing any stuckee except the IESG. Brian From problem-statement-bounces@alvestrand.no Mon Sep 8 07:56:27 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13908 for ; Mon, 8 Sep 2003 07:56:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9714D61C10; Mon, 8 Sep 2003 13:55:59 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by eikenes.alvestrand.no (Postfix) with ESMTP id F3BB061C0A for ; Mon, 8 Sep 2003 13:55:57 +0200 (CEST) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 5B50514031; Mon, 8 Sep 2003 07:55:57 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19846-11; Mon, 8 Sep 2003 07:55:56 -0400 (EDT) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 5E800141A4; Mon, 8 Sep 2003 07:55:55 -0400 (EDT) Date: Mon, 8 Sep 2003 07:53:07 -0400 From: Keith Moore To: Avri Doria Message-Id: <20030908075307.67a08c92.moore@cs.utk.edu> In-Reply-To: <110A2C22-E1D3-11D7-853D-000393CC2112@acm.org> References: <7283042.1062976553@localhost> <110A2C22-E1D3-11D7-853D-000393CC2112@acm.org> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Cc: problem-statement@alvestrand.no, moore@cs.utk.edu Subject: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > You are right at the end of the day, the IESG has to take some action > (leaving open the possible view that to take no action is to take > action) > > I think there are two paths: > > - they can figure it out a process on their own. > or > - the Problem WG can come up with a suggestion it reaches consensus on > and after being reviewed by the IETF in LC it is sent to the IESG. let's just say I hope they do the former, because if we wait for this WG to do the latter then it will delay any useful change by probably a year. IMHO. of course, if the IESG waits for this WG to get consensus on whether it should act now or later, it will take even longer. From problem-statement-bounces@alvestrand.no Mon Sep 8 08:35:25 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15794 for ; Mon, 8 Sep 2003 08:35:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1716661C09; Mon, 8 Sep 2003 14:34:59 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4493361BB9 for ; Mon, 8 Sep 2003 14:34:57 +0200 (CEST) Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250]) by comcast.net (rwcrmhc12) with SMTP id <2003090812345501400fd9s0e> (Authid: sdawkins@comcast.net); Mon, 8 Sep 2003 12:34:55 +0000 Message-ID: <064b01c37605$9daf95f0$0400a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <630656205.1062509630@HALVESTR-W2K1.cisco.com><2233AE7F-DD86-11D7-BA1C-000A95E35274@cisco.com><18724557752.20030902140106@brandenburg.com><635353169.1062514327@localhost> <16131752059.20030907214847@brandenburg.com> Date: Mon, 8 Sep 2003 07:34:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: What are we doing when we "restructure"? (was: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Dave Crocker" > > SD> I have been confused before, but had assumed that "restructuring" > SD> meant at least "fixing 2.6.2 in the current problem statement draft". > > I could make a guess about what the term means, too. It might or might not be > the same as your guess. > > My point is that the term "restructuring" is too serious and implies too much > change for us to be guessing. OK, point taken (on the second time round). When I say "restructure", I mean o offload some portion of the IESG review workload, per Problem Statement 2.6.2, with the smallest process and structural changes required to achieve this goal Who means something else when they say "restructure"? If we really mean "offload IESG review workload", saying so would be an improvement. > > Too much is being taken for granted or is being said without enough precision. I agree, and hope we can agree on more precision.. Spencer From problem-statement-bounces@alvestrand.no Mon Sep 8 15:50:23 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17760 for ; Mon, 8 Sep 2003 15:50:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 64B9D61C17; Mon, 8 Sep 2003 21:49:57 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id BBF0761B92 for ; Mon, 8 Sep 2003 21:49:55 +0200 (CEST) Received: from cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 08 Sep 2003 13:02:38 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h88Jnq9F012019; Mon, 8 Sep 2003 12:49:53 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-43.cisco.com [10.32.241.43]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ALV90869; Mon, 8 Sep 2003 12:49:51 -0700 (PDT) Date: Mon, 8 Sep 2003 15:49:50 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Keith Moore From: Melinda Shore In-Reply-To: <20030908075307.67a08c92.moore@cs.utk.edu> Message-Id: <9BF57A68-E235-11D7-A8AC-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Subject: Re: Moving the process document forward X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On Monday, September 8, 2003, at 07:53 AM, Keith Moore wrote: > of course, if the IESG waits for this WG to get consensus on whether > it should > act now or later, it will take even longer. Right now, there's no consensus anywhere on how to go about tackling longer-term change. There was no consensus within the plenary in Vienna, it seemed clear to me at the time, and right now there's no consensus within this working group about how to proceed. We have two proposals in front of us at the moment: 1) kick the whole thing over to the IESG, and 2) form something that looks like a design team using the mechanism described in the current draft of the process document. There have been some posts objecting to the second proposal and I'd like to get a handle on whether or not there's any support for it at all right now. Melinda From problem-statement-bounces@alvestrand.no Mon Sep 15 12:16:55 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10023 for ; Mon, 15 Sep 2003 12:16:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DFCEE61B9B; Mon, 15 Sep 2003 18:16:29 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from smail.alcatel.fr (colt-na165.alcatel.fr [62.23.212.165]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8A06C61B87 for ; Mon, 15 Sep 2003 18:16:27 +0200 (CEST) Received: from frmail31.netfr.alcatel.fr (frmail31.netfr.alcatel.fr [155.132.251.42]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id h8FGGJmY005596; Mon, 15 Sep 2003 18:16:20 +0200 To: avri , Melinda Shore , problem-statement@alvestrand.no X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Alistair.Urie@alcatel.com Date: Mon, 15 Sep 2003 18:16:15 +0200 X-MIMETrack: Serialize by Router on FRMAIL31/FR/ALCATEL(Release 5.0.11 |July 24, 2002) at 09/15/2003 18:16:20 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new Subject: Re: WG Last Call on IETF Problem Statement (small proposal to expand text in sections 2.2 and 2.3) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Although I note that a few people have already said we should "just ship it", may I please make two, small, last minute, proposals to add to this draft covering a pair of issues concerning problems effecting inter-relationships between WGs and between IETF and other bodies? For each issue, I offer some background notes and then specific wording to add to sections 2.2 and 2.3 respectively. 1) Need for IETF to improve communications between WGs and between IETF and outside organisation when working on common issues Background: More and more other standards bodies are now looking to IETF to develop Internet related protocols and/or extensions to existing protocols to help them complete an overall system level solution in their domain. Obvious examples are 3GPP (sip, mobileip, cops, dhcpv6, etc.), ITU-T (megaco, sip, gmpls, etc.), CableLabs (mgcp, cops, radius), etc. In each case we see a clear model of these other bodies defining requirements and an overall architecture and then when they start detailed protocol work they realise that an obvious solution is to start with a protocol developed by IETF. At this point they either choose to simply develop their own extensions (and hence endanger the goal of common protocols and confuse the market with non-compliant versions) or they send experts to IETF to get their requirements included into the ongoing work of improving WG I-D. The second route is obviously better and should be encouraged by the IETF but this will only be successful if we recognise that we now have sister organisations that are effectively our "customers" and hence the WGs should have a means of clearly acknowledging these customers and their dependencies on WG outputs. Such an environment should be based on open collaboration and, sometimes, the IETF must be ready to explain why our "customers" requests are not reasonable and so work with them to develop a more appropriate solution. This same problem also exists between different WGs within IETF and so we could cover both aspects (WG<>WG and WG<>external dependencies) with the same text. To cover this issue I propose we add to section 2.2 a new dot point under problems list and make a corresponding addition later on in the same section. This would complement the existing text in section 2.3 which covers the complex problem handling aspect of this issue. Specific proposed changes are : "2.2 The IETF does not Consistently use Effective Engineering Practices ..... Some of the contributory problems which interfere with effective engineering in WGs include: ..... o Failure to identify and articulate engineering trade-offs that may be needed to meet the deadlines that the WG has set without inappropriately reducing the 'fitness for purpose' for the intended customers. AU - add here>> o Difficulty in identify dependencies and respecting milestones between WG outputs and work planning and the work of other WGs and/or other standards developing bodies outside IETF which are collaborating with WGs on common issues o Continued refinement of the solution beyond the point at which it is adequate to meet the requirements placed on it by the intended purpose. .... In addition, IETF processes, and Working Group processes in particular, suffer because commonly accepted Project Management techniques are not regularly applied to the progress of work in the organization. o Project entry, goal setting, and tracking processes are all either missing or implemented less effectively than the norm for commercial organizations in related activities. AU - replace with>> o Project entry, goal setting, dependency identification and tracking processes are all either missing or implemented less effectively than the norm for commercial organizations in related activities." 2) - Lack of "undated" references covering IETF outputs Background: One of the techniques used by many standards bodies to break up large and complex problems is to make the distinction between "dated" and "undated" references to other standards. "Dated" references are best used when the specification must align with a specific feature covered by a reference while "undated" references are used to simply imply "use the latest version". Within IETF we tend to only use references to nominated RFCs and hence only use "dated" references. This came lead to delays in publishing new RFCs since the RFC editor offer needs to complete a set of inter-linked drafts, assign each a RFC number and finally adjust the references in each prior to final release. A corresponding delay is also occuring when other standards bodies are developing specifications that reference IETF outputs that are currently not yet released as RFC. Obviously, both cases would be improved if IETF could develop some form of "undated" reference to its work which allows other WGs and outside bodies to refer to "the latest RFC that covers subject XXX" (this issue has also been discussed at length on the solutions list) To cover this issue I propose we add a new dot point to the list in section 2.3. Specific proposed text is: "2.3 The IETF has Difficulty Handling Large and/or Complex Problems .... Part of the cause of this difficulty may be that the formal reporting structure of the IETF emphasises communication between the IESG through the ADs and the WGs and does not place much reliance on inter-WG communications: ..... o The IETF does not posess effective formal mechanisms for inter-WG cooperation, coordination or communication, including the handling of dependencies between deliverables and processes specified in in WG charters. AU - add text>>o The IETF does not have an effective means for WGs and outside standards bodies to refer to "work in progress" on new subjects and RFC revisions by means of "undated" references and/or other methods that allow work to progress independently on individual components of a complex problem." yours, Alistair URIE avri Sent by: To: problem-statement@alvestrand.no problem-statement-bounces@al cc: Melinda Shore vestrand.no Subject: WG Last Call on IETF Problem Statement 31/08/2003 04:51 This note marks the beginning of the WG Last call for: > Title : IETF Problem Statement > Author(s) : E. Davies > Filename : draft-ietf-problem-issue-statement-03.txt > Pages : 24 > Date : 2003-8-26 > The document can be found at: A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-problem-issue-statement- 03.txt Because of the US holiday on Monday , 1- Sept, the last call will extend from now, 31 August until 16 September (any time zone). Please send your comments to the WG mailing list problem-statement@alvestrand.no thanks a. Avri Doria co-chair From problem-statement-bounces@alvestrand.no Wed Sep 17 09:48:05 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11082 for ; Wed, 17 Sep 2003 09:48:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 159CF61B9F; Wed, 17 Sep 2003 15:47:36 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6723961B97 for ; Wed, 17 Sep 2003 15:47:34 +0200 (CEST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8HDlWt5001050 for ; Wed, 17 Sep 2003 06:47:32 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-43.cisco.com [10.32.241.43]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AMF51390; Wed, 17 Sep 2003 06:47:30 -0700 (PDT) Date: Wed, 17 Sep 2003 09:47:29 -0400 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed From: Melinda Shore To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit Message-Id: <7A8E1619-E915-11D7-85E2-000A95E35274@cisco.com> X-Mailer: Apple Mail (2.552) Subject: Fwd: WG Last Call on IETF Problem Statement (small proposal to expand text in sections 2.2 and 2.3) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit The problem description document went through wg last call with very little feedback. However, there were some specific suggestions from Alistair Urie and they haven't received any comment. Is there agreement or not with his proposed changes? Begin forwarded message: > [ ... deleted text ... ] > I propose we add to section 2.2 a new dot point under > problems list and make a corresponding addition later on in the same > section. This would complement the existing text in section 2.3 which > covers the complex problem handling aspect of this issue. > > Specific proposed changes are : > "2.2 The IETF does not Consistently use Effective Engineering Practices > > ..... > Some of the contributory problems which interfere with effective > engineering in WGs include: > ..... > o Failure to identify and articulate engineering trade-offs that > may > be needed to meet the deadlines that the WG has set without > inappropriately reducing the 'fitness for purpose' for the > intended customers. > > AU - add here>> o Difficulty in identify dependencies and respecting > milestones between WG outputs and work planning and the work of other > WGs > and/or other standards developing bodies outside IETF which are > collaborating with WGs on common issues > > o Continued refinement of the solution beyond the point at which it > is adequate to meet the requirements placed on it by the intended > purpose. > > .... > > In addition, IETF processes, and Working Group processes in > particular, suffer because commonly accepted Project Management > techniques are not regularly applied to the progress of work in the > organization. > > o Project entry, goal setting, and tracking processes are all > either > missing or implemented less effectively than the norm for > commercial organizations in related activities. > > AU - replace with>> > o Project entry, goal setting, dependency identification and > tracking > processes are all either missing or implemented less effectively > than > the norm for commercial organizations in related activities." > > > 2) - Lack of "undated" references covering IETF outputs [ ... deleted text ... ] > To cover this issue I propose we add a new dot point to the list in > section > 2.3. > > Specific proposed text is: > > "2.3 The IETF has Difficulty Handling Large and/or Complex Problems > .... > Part of the cause of this difficulty may be that the formal > reporting > structure of the IETF emphasises communication between the IESG > through the ADs and the WGs and does not place much reliance on > inter-WG communications: > ..... > > o The IETF does not posess effective formal mechanisms for inter-WG > cooperation, coordination or communication, including the > handling > of dependencies between deliverables and processes specified in > in > WG charters. > > AU - add text>>o The IETF does not have an effective means for WGs and > outside standards bodies to refer to "work in progress" on new > subjects and > RFC revisions by means of "undated" references and/or other methods > that > allow work to progress independently on individual components of a > complex > problem." The full messages is at http://www.alvestrand.no/pipermail/problem-statement/2003-September/ 003039.html From problem-statement-bounces@alvestrand.no Wed Sep 17 10:19:41 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14427 for ; Wed, 17 Sep 2003 10:19:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 09E6D61BA0; Wed, 17 Sep 2003 16:19:16 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by eikenes.alvestrand.no (Postfix) with ESMTP id B3D8F61B97 for ; Wed, 17 Sep 2003 16:19:10 +0200 (CEST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h8HEJ4qk233566 for ; Wed, 17 Sep 2003 10:19:05 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-227-3.mts.ibm.com [9.65.227.3]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8HEJ2MR048628 for ; Wed, 17 Sep 2003 08:19:03 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h8HEFoX05087 for ; Wed, 17 Sep 2003 10:16:27 -0400 Message-Id: <200309171416.h8HEFoX05087@cichlid.adsl.duke.edu> To: problem-statement@alvestrand.no Date: Wed, 17 Sep 2003 10:15:49 -0400 From: Thomas Narten Subject: Missing root cause: Internet has gotten more complex X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Looking at the root causes, they appear to be: > 2. Root Cause Problems . . . . . . . . . . . . . . . . . . . . 8 > 2.1 Participants in the IETF do not have a Common > Understanding of its Mission . . . . . . . . . . . . . . . . 8 > 2.2 The IETF does not Consistently use Effective Engineering > Practices . . . . . . . . . . . . . . . . . . . . . . . . . 9 > 2.3 The IETF has Difficulty Handling Large and/or Complex > Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 12 > 2.4 Three Stage Standards Hierarchy not properly Utilized . . . 13 > 2.5 The IETF's Workload Exceeds the Number of Fully Engaged > Participants . . . . . . . . . . . . . . . . . . . . . . . . 14 > 2.6 The IETF Management Structure is not Matched to the > Current Size and Complexity of the IETF . . . . . . . . . . 15 > 2.7 Working Group Practices can make Issue Closure Difficult . . 20 > 2.8 IETF Participants and Leaders are Inadequately Prepared > for their Roles . . . . . . . . . . . . . . . . . . . . . . 21 But there is at least one root cause that I don't see called out explicitly: The Internet Has Become More Complex and Requirements placed on it by Users have Changed Examples: - increasing complexity of internet/protocols/deployments - awareness that when deployed, protocols _will_ interact with each other and there is a need to understand those interactions in order to decide whether the protocol is reasonably well thought out and that there will be no maor (bad) surpises when it becomes deployed. - desire to not have multiple protocols that do essentially the same thing, thus, need to use other IETF components rather than point solution. (but this view may not be shared by all of the community, which gets back to Section 2.1) - The Internet has changed over the last 15 years, with a different level of expectations (e.g., part of economic infrastructure). Internet is no longer a toy for running half-thought-out experiments on a wide-scale, where the consequences may be very hard to fix after the fact. Another way of stating this. Its one thing to run an experiment of limited scope. It's another to put something into cell phones, where the "experiment" involves millions of devices. note: this point may well also go back to lack of agreement on mission/core values. - The "low hanging fruit" has been picked. The easiest problems to solve have been solved. We're now dealing with the harder ones; it should be no surprise that finding solutions to them is not as easy. Thomas From problem-statement-bounces@alvestrand.no Wed Sep 17 10:23:26 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14769 for ; Wed, 17 Sep 2003 10:23:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 85A8B61BA0; Wed, 17 Sep 2003 16:23:01 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4E72061B97 for ; Wed, 17 Sep 2003 16:22:59 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8HERoP18318; Wed, 17 Sep 2003 07:27:50 -0700 Date: Wed, 17 Sep 2003 07:22:36 -0700 From: Dave Crocker X-Mailer: The Bat! (v2.00) Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <17628754376.20030917072236@brandenburg.com> To: Alistair.Urie@alcatel.com In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Melinda Shore , avri , problem-statement@alvestrand.no Subject: Re: WG Last Call on IETF Problem Statement (small proposal to expand text in sections 2.2 and 2.3) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Dave Crocker List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Alistair, AUac> Although I note that a few people have already said we should "just ship AUac> it", may I please make two, small, last minute, proposals to add to this AUac> draft covering a pair of issues concerning problems effecting I believe both of the points you raise are interesting. I believe neither of them is essential to include. We can never list all of the problems. There are too many. We need to limit the list or we will never complete it. The impetus for this work is to correct major problems with the IETF that are hurting the timeliness and utility of IETF output. While there are many, many things we might do to make improvements, we need to limit the current, formal effort to major problems. I believe the two items you have cited are worthy of discussion and may warrant changes, but I do not believe they warrant further delays to the working group documents. d/ ps. -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From problem-statement-bounces@alvestrand.no Wed Sep 17 11:09:48 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16444 for ; Wed, 17 Sep 2003 11:09:46 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8491661BA0; Wed, 17 Sep 2003 17:09:22 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by eikenes.alvestrand.no (Postfix) with ESMTP id B707261B9E for ; Wed, 17 Sep 2003 17:09:15 +0200 (CEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8HF0u501388; Wed, 17 Sep 2003 17:00:56 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Sep 2003 16:00:56 +0100 Message-ID: <4103264BC8D3D51180B7002048400C45016237B1@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "'Alistair.Urie@alcatel.com'" , avri , Melinda Shore Date: Wed, 17 Sep 2003 16:00:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37D2C.7BB4C686" Cc: problem-statement@alvestrand.no Subject: RE: WG Last Call on IETF Problem Statement (small proposal to exp and text in sections 2.2 and 2.3) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C37D2C.7BB4C686 Content-Type: text/plain Hi. Thanks for the comments. I think the points you make are indeed valid and looking back through the mailing list, I believe that they had mostly been made previously. I also believe that they are essentially covered by the existing text, and so I would concur with Dave Crocker that it would be gilding the lily to make more modifications at this stage. Regards, Elwyn > -----Original Message----- > From: Alistair.Urie@alcatel.com [mailto:Alistair.Urie@alcatel.com] > Sent: 15 September 2003 17:16 > To: avri; Melinda Shore; problem-statement@alvestrand.no > Subject: Re: WG Last Call on IETF Problem Statement (small > proposal to expand text in sections 2.2 and 2.3) > > > > Although I note that a few people have already said we should > "just ship > it", may I please make two, small, last minute, proposals to > add to this > draft covering a pair of issues concerning problems effecting > inter-relationships between WGs and between IETF and other > bodies? <> > 1) Need for IETF to improve communications between WGs and > between IETF and > outside organisation when working on common issues > <> > AU - add here>> o Difficulty in identify dependencies and > respecting > milestones between WG outputs and work planning and the work > of other WGs > and/or other standards developing bodies outside IETF which are > collaborating with WGs on common issues I think the issue for WGs is adequately covered by the equivalent point in 2.4. Communications with SDOs is covered in 2.1. Arguably the equivalent point to the one in 2.4 for WGs could be made for other SDOs. > > o Project entry, goal setting, and tracking processes are > all either > missing or implemented less effectively than the norm for > commercial organizations in related activities. > > AU - replace with>> > o Project entry, goal setting, dependency identification > and tracking > processes are all either missing or implemented less > effectively than > the norm for commercial organizations in related activities." I think this is also covered by the point in 2.4. > > 2) - Lack of "undated" references covering IETF outputs > <> > To cover this issue I propose we add a new dot point to the > list in section > 2.3. > > Specific proposed text is: > <> > AU - add text>>o The IETF does not have an effective means > for WGs and > outside standards bodies to refer to "work in progress" on > new subjects and > RFC revisions by means of "undated" references and/or other > methods that > allow work to progress independently on individual components > of a complex > problem." This is a useful point but I am not sure that it adds significantly to point about complex problems. In terms of solutions this needs to be addressed and various people have already been airing possibilities. Regards, Elwyn. > > yours, > > Alistair URIE > > > > > > > > avri > > > Sent by: > To: problem-statement@alvestrand.no > > problem-statement-bounces@al > cc: Melinda Shore > > vestrand.no > Subject: WG Last Call on IETF Problem Statement > > > > > > > > 31/08/2003 04:51 > > > > > > > > > > > > > > This note marks the beginning of the WG Last call for: > > > > Title : IETF Problem Statement > > Author(s) : E. Davies > > Filename : > draft-ietf-problem-issue-statement-03.txt > > Pages : 24 > > Date : 2003-8-26 > > > > > The document can be found at: > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-problem-issue-s tatement- 03.txt Because of the US holiday on Monday , 1- Sept, the last call will extend from now, 31 August until 16 September (any time zone). Please send your comments to the WG mailing list problem-statement@alvestrand.no thanks a. Avri Doria co-chair ------_=_NextPart_001_01C37D2C.7BB4C686 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: WG Last Call on IETF Problem Statement (small proposal to = expand text in sections 2.2 and 2.3)

Hi.

Thanks for the comments.  I think the points you = make are indeed valid and looking back through the mailing list, I = believe that they had mostly been made previously.  I also believe = that they are essentially covered by the existing text, and so I would = concur with Dave Crocker that it would be gilding the lily to make more = modifications at this stage.

Regards,
Elwyn

> -----Original Message-----
> From: Alistair.Urie@alcatel.com [mailto:Alistair.Urie@alcatel.c= om]
> Sent: 15 September 2003 17:16
> To: avri; Melinda Shore; = problem-statement@alvestrand.no
> Subject: Re: WG Last Call on IETF Problem = Statement (small
> proposal to expand text in sections 2.2 and = 2.3)
>
>
>
> Although I note that a few people have already = said we should
> "just ship
> it", may I please make two, small, last = minute, proposals to
> add to this
> draft covering a pair of issues concerning = problems effecting
> inter-relationships between WGs and between = IETF and other
> bodies?

<<snip>>

> 1) Need for IETF to improve communications = between WGs and
> between IETF and
> outside organisation when working on common = issues
>
<<snip>>

> AU - add here>>   o  = Difficulty in identify dependencies and
> respecting
> milestones between WG outputs and work planning = and the work
> of other WGs
> and/or other standards developing bodies = outside IETF which are
> collaborating with WGs on common issues

I think the issue for WGs is adequately covered by = the equivalent point in 2.4.
Communications with SDOs is covered in 2.1.  = Arguably the equivalent point to the one in 2.4 for WGs could be made = for other SDOs.

>
>    o  Project entry, goal = setting, and tracking processes are
> all either
>       missing or = implemented less effectively than the norm for
>       commercial = organizations in related activities.
>
> AU - replace with>>
>    o  Project entry, goal = setting, dependency identification
> and tracking
>       processes = are all either missing or implemented less
> effectively than
>       the norm = for commercial organizations in related activities."

I think this is also covered by the point in = 2.4.
 
>
> 2) - Lack of "undated" references = covering IETF outputs
>
<<snip>>

> To cover this issue I propose we add a new dot = point to the
> list in section
> 2.3.
>
> Specific proposed text is:
>
<<snip>>
> AU - add text>>o  The IETF does not = have an effective means
> for WGs and
> outside standards bodies to refer to "work = in progress" on
> new subjects and
> RFC revisions by means of "undated" = references and/or other
> methods that
> allow work to progress independently on = individual components
> of a complex
> problem."

This is a useful point but I am not sure that it adds = significantly to point about complex problems.
In terms of solutions this needs to be addressed and = various people have already been airing possibilities.

Regards,
Elwyn.

>
> yours,
>
> Alistair URIE
>
>
>
>
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ; 
>          = ;            = ; avri = <avri@psg.com>        &nbs= p;            =
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ; 
>          = ;            = ; Sent by:          &n= bsp;           &n= bsp;     
> To:      = problem-statement@alvestrand.no       = ;            = ;  
>          = ;            = ;    
>          = ;            = ; = problem-statement-bounces@al       &n= bsp;
> cc:      Melinda Shore = <mshore@cisco.com>        =             =
>          = ;            = ;    
>          = ;            = ; = vestrand.no          &= nbsp;           &= nbsp;  
> Subject: WG Last Call on IETF Problem = Statement          &nb= sp;   
>          = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ; 
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ; 
>          = ;            = ; 31/08/2003 04:51         =             =   
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ; 
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ; 
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ; 
>
>
>
>
>
> This note marks the beginning of the WG Last = call for:
>
>
> = >            = Title           &= nbsp;           &= nbsp; : IETF Problem Statement
> = >            = Author(s)         : E. = Davies
> = >            = Filename          : =
> = draft-ietf-problem-issue-statement-03.txt
> = >            = Pages           &= nbsp;           &= nbsp; : 24
> = >            = Date           &n= bsp;        : 2003-8-26
> >
>
>
> The document can be found at:
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-problem= -issue-s
tatement-
03.txt

Because of the US holiday on Monday ,  1- Sept, = the last call will
extend from now, 31 August until 16 September (any = time zone).

Please send your comments to the WG mailing = list
problem-statement@alvestrand.no

thanks

a.

Avri Doria
co-chair






------_=_NextPart_001_01C37D2C.7BB4C686-- From problem-statement-bounces@alvestrand.no Wed Sep 17 11:41:58 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18120 for ; Wed, 17 Sep 2003 11:41:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AB38D61BA0; Wed, 17 Sep 2003 17:41:33 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by eikenes.alvestrand.no (Postfix) with ESMTP id 75A8A61B9E for ; Wed, 17 Sep 2003 17:41:30 +0200 (CEST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h8HFfQkk495558 for ; Wed, 17 Sep 2003 11:41:26 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-227-3.mts.ibm.com [9.65.227.3]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8HFfOMR065890 for ; Wed, 17 Sep 2003 09:41:25 -0600 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id h8HFci606254 for ; Wed, 17 Sep 2003 11:38:44 -0400 Message-Id: <200309171538.h8HFci606254@cichlid.raleigh.ibm.com> To: problem-statement@alvestrand.no Date: Wed, 17 Sep 2003 11:38:43 -0400 From: Thomas Narten Subject: problem statement: Engineering practice vs. management practices X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > 2.2 The IETF does not Consistently use Effective Engineering Practices > > For an organization with 'engineering' in its title and participants > who are likely to trot out the statement "Trust me, I'm an engineer!" > when confronted with the need to find a solution to a particularly > knotty problem, the IETF has, at least in some cases, extremely > ineffective Engineering Practices. > 2.7 Working Group Practices can make Issue Closure Difficult > I have a hard time understanding the difference between 2.2 and 2.7 and parts of 2.6. I _think_ section 2.2 is trying to say something about how we don't actually use more rigorous and formal internal processes that would help us avoid the problem of documents taking too long, etc. But one could argue that a lot of that is related to basic project management issues (or from Section 2.7 "Working Group Practices can make Issue Closure Difficult"), and its not always clear whether a cited issue is the lack of a tool (or lack of its use) or just lack of use of basic project management techniques, or just bad WG practice, for which there might be several ways to try and improve the situation. Meta issue: Is the "root cause" issue the lack of use of management/engineering techniques, or would using better techniques be a _solution_ to existing poor practices (or to _some_ poor practices, but not others)? This document seems to not make this distinction very well, because it lists one underlying poor practice (e.g., section 2.7), but calls out a number of others in section 2.2. where they aren't listed as poor practices, but as consequences of not using appropriate tools. Regarding Section 2.7: > 2.7 Working Group Practices can make Issue Closure Difficult IMO, Section 2.7 is a bit too narrowly scoped, and there are more examples that should be added here. Existing WG practices are also a root cause issue. In that case, though, the section heading would be better made more general, e.g.: > 2.7 Working Group Practices Contribute to Delays Some additional examples for section 2.7: - too many WGs have a adopated a cycle where the bulk of the activity is centered around the face-to-face meetings. E.g., Many IDs are revised only once per cycle, immediately before a meeting, with too little active work going on in the months immediately after a meeting. - despite IETF mantra that the WG is the mailing list, mailing lists are become increasingly ineffective at resolving issues, e.g., too many postings for many to keep up with, too many off-topic posts (i.e, those not directly related to getting wording changed in a WG document), folk being driven away because small number of vocal posters, etc. - Document authors are often not held accountable enough for revising documents in a timely fashion - As a WG document is being developed, reviews of WG documents too often involve only interested WG members and don't include reviews from those outside of the WG, or don't include reviews from subject matter experts of topics that are related to the topic in the WG document, but are not necessarily the focus of the WG document. But when the WG says its done, and those outside reviews come in, they are frequently viewed as being "too late" and the cost of making changes is "too high". Frustration then results. If section 2.2 is really aimed at non-management stuff, like tools, I think it would be useful make 2.2 state that clearly. Or if it is intended to cover both tools and management techniques, make that more clear (especially in the opening paragraph). I think it would also be good to rename/expand section 2.7 to cover more existing bad practices. Thomas From problem-statement-bounces@alvestrand.no Wed Sep 17 13:35:00 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21211 for ; Wed, 17 Sep 2003 13:34:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E66B161B9E; Wed, 17 Sep 2003 19:34:33 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by eikenes.alvestrand.no (Postfix) with ESMTP id EECCC61B97 for ; Wed, 17 Sep 2003 19:34:22 +0200 (CEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8HHWa506009; Wed, 17 Sep 2003 19:32:36 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Sep 2003 18:32:36 +0100 Message-ID: <4103264BC8D3D51180B7002048400C45016237B3@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "'Thomas Narten'" , problem-statement@alvestrand.no Date: Wed, 17 Sep 2003 18:32:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37D41.AF52E03A" Subject: RE: problem statement: Engineering practice vs. management practi ces X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C37D41.AF52E03A Content-Type: text/plain Hi. The intention was: 2.2 covers areas that are apparently down to failure to apply well-known, essentially mechanical processes of Engineering as it should be practiced, such as process improvement techniques, reviewing, setting of and keeping to milestones, formal mangement techniques, etc. 2.7 covers areas which are apparently down to social engineering and human interactions in the operation of WGs. 2.6 covers the structural and overall process issues. So, yes, section 2.2 covers all the aspects of engineering process - significant parts of management practice are engineering management practice, and you are just as ineffective if you don't do the management part as if you fail to use some appropriate configuration management tool or bug database. We are not saying that that any particular issue is down to lack of a tool (that is solution space) but rather that we don't use tools as well as we might and, yes, they exist. We knew from the outset that not everybody was going to agree with what the actual root causes are. The question, at this stage, is do we need to do a serious reworking of the document? Several points in line below... Regards, Elwyn > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: 17 September 2003 16:39 > To: problem-statement@alvestrand.no > Subject: problem statement: Engineering practice vs. > management practices > > > > 2.2 The IETF does not Consistently use Effective > Engineering Practices > > > > For an organization with 'engineering' in its title and > participants > > who are likely to trot out the statement "Trust me, I'm > an engineer!" > > when confronted with the need to find a solution to a > particularly > > knotty problem, the IETF has, at least in some cases, extremely > > ineffective Engineering Practices. > > > > 2.7 Working Group Practices can make Issue Closure Difficult > > > > I have a hard time understanding the difference between 2.2 and 2.7 > and parts of 2.6. I _think_ section 2.2 is trying to say something > about how we don't actually use more rigorous and formal internal > processes that would help us avoid the problem of documents taking too > long, etc. But one could argue that a lot of that is related to basic > project management issues (or from Section 2.7 "Working Group > Practices can make Issue Closure Difficult"), and its not always clear > whether a cited issue is the lack of a tool (or lack of its use) or > just lack of use of basic project management techniques, or just bad > WG practice, for which there might be several ways to try and improve > the situation. > > Meta issue: Is the "root cause" issue the lack of use of > management/engineering techniques, or would using better techniques be > a _solution_ to existing poor practices (or to _some_ poor practices, > but not others)? This document seems to not make this distinction very > well, because it lists one underlying poor practice (e.g., section > 2.7), but calls out a number of others in section 2.2. where they > aren't listed as poor practices, but as consequences of not using > appropriate tools. Working backwards through this last paragraph: - I don't know whether you mean that you think that we are implying that all the items in 2.2 are consequences of the bullet point 'Tools to support the engineering process...' or are you using tools in the more abstract sense of well-known ways to structure the way we go about doing engineering, including managing it. If you mean the former then I don't agree with your point. If the latter, then certainly - that is just what is meant by the whole section. - The matter of whether having better engineering practices is a cause or a solution has been aired before. I believe that it is correct as it stands: We clearly don't do some Engineering practices very well - we claim (through our title and pronouncements) that we do Engineering and do it well. In that sense the IETF implicitly believes that Engineering IS the solution - the problem is that we aren't doing it according to the accepted best practice. - The problems in Section 2.7 will not go away just because we do Engineering better - they are issues of human diveersity and corporate influence. Normal corporations deal with these sorts of problems through hierarchies, paychecks and hire & fire. The IETF does not have these sanctions and hence the problems cannot be made to go away in the same way that they would in a 'non-volunteer' organisation. They are not poor practice in the sense of something done deliberately by the organisation or exacerbated by failure to implement some well-known process. They are certainly poor practice by the culprits (but they wouldn't see themselves in that way). How to sort them out is likely to need social engineering. > > Regarding Section 2.7: > > > 2.7 Working Group Practices can make Issue Closure Difficult > > IMO, Section 2.7 is a bit too narrowly scoped, and there are more > examples that should be added here. Existing WG practices are also a > root cause issue. In that case, though, the section heading would be > better made more general, e.g.: > > > 2.7 Working Group Practices Contribute to Delays > > Some additional examples for section 2.7: 2.2 does indeed cover the mechanical parts of the delay - I would like to keep this to the social engineering issue of driving concensus and issue closure. > > - too many WGs have a adopated a cycle where the bulk of the activity > is centered around the face-to-face meetings. E.g., Many IDs are > revised only once per cycle, immediately before a meeting, with too > little active work going on in the months immediately after a > meeting. I think this is covered by the need to have more granular milestones in 2.2. > > - despite IETF mantra that the WG is the mailing list, mailing lists > are become increasingly ineffective at resolving issues, e.g., too > many postings for many to keep up with, too many off-topic posts > (i.e, those not directly related to getting wording changed in a WG > document), folk being driven away because small number of vocal > posters, etc. The point about concensus by exhaustion could perhaps be somewhat extended to cover this. > > - Document authors are often not held accountable enough for > revising documents in a timely fashion The problem is that guilt is the only tool you have. We already talk about this in 2.5. > > - As a WG document is being developed, reviews of WG documents too > often involve only interested WG members and don't include reviews > from those outside of the WG, or don't include reviews from subject > matter experts of topics that are related to the topic in the WG > document, but are not necessarily the focus of the WG document. > But when the WG says its done, and those outside reviews come in, > they are frequently viewed as being "too late" and the cost of > making changes is "too high". Frustration then results. This *should* be covered by the 'Lack of auditing against explicit criteria' item in 2.2, but it has probably become too abstract to remind us what the problem actually is. > > If section 2.2 is really aimed at non-management stuff, like tools, I > think it would be useful make 2.2 state that clearly. Or if it is > intended to cover both tools and management techniques, make that more > clear (especially in the opening paragraph). I think it would also be > good to rename/expand section 2.7 to cover more existing bad > practices. > > Thomas > ------_=_NextPart_001_01C37D41.AF52E03A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: problem statement: Engineering practice vs. management = practices

Hi.

The intention was:
2.2 covers areas that are apparently down to failure = to apply well-known, essentially mechanical processes of Engineering as = it should be practiced, such as process improvement techniques, = reviewing, setting of and keeping to milestones, formal mangement = techniques, etc.

2.7 covers areas which are apparently down to social = engineering and human interactions in the operation of WGs.

2.6 covers the structural and overall process = issues.

So, yes, section 2.2 covers all the aspects of = engineering process - significant parts of management practice are = engineering management practice, and you are just as ineffective if you = don't do the management part as if you fail to use some appropriate = configuration management tool or bug database.  We are not saying = that that any particular issue is down to lack of a tool (that is = solution space) but rather that we don't use tools as well as we might = and, yes, they exist.

We knew from the outset that not everybody was going = to agree with what the actual root causes are.  The question, at = this stage, is do we need to do a serious reworking of the document? =

Several points in line below...

Regards,
Elwyn

> -----Original Message-----
> From: Thomas Narten [mailto:narten@us.ibm.com]
> Sent: 17 September 2003 16:39
> To: problem-statement@alvestrand.no
> Subject: problem statement: Engineering = practice vs.
> management practices
>
>
> > 2.2 The IETF does not Consistently use = Effective
> Engineering Practices
> >
> >    For an organization with = 'engineering' in its title and
> participants
> >    who are likely to trot = out the statement "Trust me, I'm
> an engineer!"
> >    when confronted with the = need to find a solution to a
> particularly
> >    knotty problem, the IETF = has, at least in some cases, extremely
> >    ineffective Engineering = Practices.
>
>
> > 2.7 Working Group Practices can make Issue = Closure Difficult
> >
>
> I have a hard time understanding the difference = between 2.2 and 2.7
> and parts of 2.6. I _think_ section 2.2 is = trying to say something
> about how we don't actually use more rigorous = and formal internal
> processes that would help us avoid the problem = of documents taking too
> long, etc. But one could argue that a lot of = that is related to basic
> project management issues (or from Section 2.7 = "Working Group
> Practices can make Issue Closure = Difficult"), and its not always clear
> whether a cited issue is the lack of a tool (or = lack of its use) or
> just lack of use of basic project management = techniques, or just bad
> WG practice, for which there might be several = ways to try and improve
> the situation.
>
> Meta issue: Is the "root cause" issue = the lack of use of
> management/engineering techniques, or would = using better techniques be
> a _solution_ to existing poor practices (or to = _some_ poor practices,
> but not others)? This document seems to not = make this distinction very
> well, because it lists one underlying poor = practice (e.g., section
> 2.7), but calls out a number of others in = section 2.2. where they
> aren't listed as poor practices, but as = consequences of not using
> appropriate tools.

Working backwards through this last paragraph:
- I don't know whether you mean that you think that = we are implying that all the items in 2.2 are consequences of the = bullet point 'Tools to support the engineering process...' or are you = using tools in the more abstract sense of well-known ways to structure = the way we go about doing engineering, including managing it.  If = you mean the former then I don't agree with your point.  If the = latter, then certainly - that is just what is meant by the whole = section.

- The matter of whether having better engineering = practices is a cause or a solution has been aired before.  I = believe that it is correct as it stands: We clearly don't do some = Engineering practices very well - we claim (through our title and = pronouncements) that we do Engineering and do it well.  In that = sense the IETF implicitly believes that Engineering IS the solution - = the problem is that we aren't doing it according to the accepted best = practice.

- The problems in Section 2.7 will not go away just = because we do Engineering better - they are issues of human diveersity = and corporate influence.  Normal corporations deal with these = sorts of problems through hierarchies, paychecks and hire & = fire.  The IETF does not have these sanctions and hence the = problems cannot be made to go away in the same way that they would in a = 'non-volunteer' organisation.  They are not poor practice in the = sense of something done deliberately by the organisation or exacerbated = by failure to implement some well-known process.  They are = certainly poor practice by the culprits (but they wouldn't see = themselves in that way).  How to sort them out is likely to need = social engineering.

>
> Regarding Section 2.7:
>
> >    2.7   Working = Group Practices can make Issue Closure Difficult
>
> IMO, Section 2.7 is a bit too narrowly scoped, = and there are more
> examples that should be added here.  = Existing WG practices are also a
> root cause issue. In that case, though, the = section heading would be
> better made more general, e.g.:
>
> >    2.7   Working = Group Practices Contribute to Delays
>
> Some additional examples for section 2.7:=

2.2 does indeed cover the mechanical parts of the = delay  - I would like to keep this to the social engineering issue = of driving concensus and issue closure.

>
>  - too many WGs have a adopated a cycle = where the bulk of the activity
>    is centered around the = face-to-face meetings. E.g., Many IDs are
>    revised only once per cycle, = immediately before a meeting, with too
>    little active work going on = in the months immediately after a
>    meeting.

I think this is covered by the need to have more = granular milestones in 2.2.

>
>  - despite IETF mantra that the WG is the = mailing list, mailing lists
>    are become increasingly = ineffective at resolving issues, e.g., too
>    many postings for many to = keep up with, too many off-topic posts
>    (i.e, those not directly = related to getting wording changed in a WG
>    document), folk being driven = away because small number of vocal
>    posters, etc.

The point about concensus by exhaustion could perhaps = be somewhat extended to cover this.
>
>  - Document authors are often not held = accountable enough for
>    revising documents in a = timely fashion

The problem is that guilt is the only tool you = have.  We already talk about this in 2.5.

>
>  - As a WG document is being developed, = reviews of WG documents too
>    often involve only interested = WG members and don't include reviews
>    from those outside of the WG, = or don't include reviews from subject
>    matter experts of topics that = are related to the topic in the WG
>    document, but are not = necessarily the focus of the WG document.
>    But when the WG says its = done, and those outside reviews come in,
>    they are frequently viewed as = being "too late" and the cost of
>    making changes is "too = high". Frustration then results.

This *should* be covered by the 'Lack of auditing = against explicit criteria' item in 2.2, but it has probably become too = abstract to remind us what the problem actually is.

>
> If section 2.2 is really aimed at = non-management stuff, like tools, I
> think it would be useful make 2.2 state that = clearly. Or if it is
> intended to cover both tools and management = techniques, make that more
> clear (especially in the opening paragraph). I = think it would also be
> good to rename/expand section 2.7 to cover more = existing bad
> practices.
>
> Thomas
>

------_=_NextPart_001_01C37D41.AF52E03A-- From problem-statement-bounces@alvestrand.no Wed Sep 17 16:48:39 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28768 for ; Wed, 17 Sep 2003 16:48:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6E1D661B9E; Wed, 17 Sep 2003 22:48:15 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8B19361B97 for ; Wed, 17 Sep 2003 22:48:13 +0200 (CEST) Received: from desktop (103.sanjose-06-07rs16rt.ca.dial-access.att.net[12.81.2.103]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003091720474611100mqu79e>; Wed, 17 Sep 2003 20:48:02 +0000 Message-ID: <000a01c37d5d$97700f80$020aff0a@home.glassey.com> From: "todd glassey" To: , "Thomas Narten" References: <200309171416.h8HEFoX05087@cichlid.adsl.duke.edu> Date: Wed, 17 Sep 2003 13:42:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Subject: Re: Missing root cause: Internet has gotten more complex X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Thomas - ----- Original Message ----- From: "Thomas Narten" To: Sent: Wednesday, September 17, 2003 7:15 AM Subject: Missing root cause: Internet has gotten more complex > Looking at the root causes, they appear to be: > > > 2. Root Cause Problems . . . . . . . . . . . . . . . . . . . . 8 > > 2.1 Participants in the IETF do not have a Common > > Understanding of its Mission . . . . . . . . . . . . . . . . 8 > > 2.2 The IETF does not Consistently use Effective Engineering > > Practices . . . . . . . . . . . . . . . . . . . . . . . . . 9 > > 2.3 The IETF has Difficulty Handling Large and/or Complex > > Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 12 > > 2.4 Three Stage Standards Hierarchy not properly Utilized . . . 13 > > 2.5 The IETF's Workload Exceeds the Number of Fully Engaged > > Participants . . . . . . . . . . . . . . . . . . . . . . . . 14 > > 2.6 The IETF Management Structure is not Matched to the > > Current Size and Complexity of the IETF . . . . . . . . . . 15 > > 2.7 Working Group Practices can make Issue Closure Difficult . . 20 > > 2.8 IETF Participants and Leaders are Inadequately Prepared > > for their Roles . . . . . . . . . . . . . . . . . . . . . . 21 > > > But there is at least one root cause that I don't see called out > explicitly: > > The Internet Has Become More Complex and Requirements placed on > it by Users have Changed > > Examples: > > - increasing complexity of internet/protocols/deployments and legal issues as well. For instance, building a protocol that has no real purpose but to allow the subversion of a local law in some country is another problem. Not that we should use this as a metric, but the Napster protocol is exactly this, and especially with how it was erected. Seeing the results, at some point some Judge or group of lawyers is going to realize that the IETF is a real target for vengence for the protocols of the world that they cant control, and this is the last thing the IETF would need. > > - awareness that when deployed, protocols _will_ interact with each > other and there is a need to understand those interactions in order > to decide whether the protocol is reasonably well thought out and > that there will be no maor (bad) surpises when it becomes deployed. This has both political and technical inplications... > > - desire to not have multiple protocols that do essentially the same > thing, thus, need to use other IETF components rather than point > solution. (but this view may not be shared by all of the community, > which gets back to Section 2.1) Which then means that the IETF produces one and only one of each protocol??? - My take is that doing thins makes the IETF of limited use to businesses that want to compete with existing protocols. Which brings us to another problem, and that there is no real way for any new protocol to challenge and unseat the incumbant protocol if the incumbant protocol doesnt want it... > > - The Internet has changed over the last 15 years, with a different > level of expectations (e.g., part of economic infrastructure). Amen > Internet is no longer a toy for running half-thought-out experiments > on a wide-scale, where the consequences may be very hard to fix > after the fact. Good point - so maybe a standard's process based on secret votes is a bit passed its time as well too, Eh? > Another way of stating this. Its one thing to run an > experiment of limited scope. It's another to put something into cell > phones, where the "experiment" involves millions of devices. > > note: this point may well also go back to lack of agreement on > mission/core values. > > - The "low hanging fruit" has been picked. The easiest problems to > solve have been solved. We're now dealing with the harder ones; it > should be no surprise that finding solutions to them is not as easy. > > Thomas From problem-statement-bounces@alvestrand.no Wed Sep 17 16:49:13 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28820 for ; Wed, 17 Sep 2003 16:49:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5D7A661BAC; Wed, 17 Sep 2003 22:48:50 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by eikenes.alvestrand.no (Postfix) with ESMTP id 11DAD61B97 for ; Wed, 17 Sep 2003 22:48:48 +0200 (CEST) Received: from desktop (103.sanjose-06-07rs16rt.ca.dial-access.att.net[12.81.2.103]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003091720481511100mqu7ae>; Wed, 17 Sep 2003 20:48:37 +0000 Message-ID: <000b01c37d5d$ac60a030$020aff0a@home.glassey.com> From: "todd glassey" To: "Dave Crocker" , References: <17628754376.20030917072236@brandenburg.com> Date: Wed, 17 Sep 2003 13:48:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Subject: Re: WG Last Call on IETF Problem Statement (small proposal toexpand text in sections 2.2 and 2.3) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Dave ----- Original Message ----- From: "Dave Crocker" To: Cc: "Melinda Shore" ; "avri" ; Sent: Wednesday, September 17, 2003 7:22 AM Subject: Re: WG Last Call on IETF Problem Statement (small proposal toexpand text in sections 2.2 and 2.3) > Alistair, > > AUac> Although I note that a few people have already said we should "just ship > AUac> it", may I please make two, small, last minute, proposals to add to this > AUac> draft covering a pair of issues concerning problems effecting > > > I believe both of the points you raise are interesting. > > I believe neither of them is essential to include. > > We can never list all of the problems. There are too many. We need to limit > the list or we will never complete it. Not true - What we need to break the list into several lists. That is to create listso of associated problems specific to a conceptual area. Like problems with the "Posting Model" and "Participation Models" in the WG's. The problem with the current list is that it is all encompassing and as such it is too large. But if it was broken down into smaller areas of concern the work-product documents would be more manageable and of a more digestable set of goals (at least IMHO). > > The impetus for this work is to correct major problems with the IETF that are > hurting the timeliness and utility of IETF output. While there are many, many > things we might do to make improvements, we need to limit the current, formal > effort to major problems. > > I believe the two items you have cited are worthy of discussion and may > warrant changes, but I do not believe they warrant further delays to the > working group documents. > > d/ > > ps. > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA > > > From problem-statement-bounces@alvestrand.no Wed Sep 17 16:52:56 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29005 for ; Wed, 17 Sep 2003 16:52:52 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1CBDA61B9E; Wed, 17 Sep 2003 22:52:29 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6B0D461B97 for ; Wed, 17 Sep 2003 22:52:27 +0200 (CEST) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 3E39A1407D; Wed, 17 Sep 2003 16:52:26 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07958-03; Wed, 17 Sep 2003 16:52:25 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id F2EA614076; Wed, 17 Sep 2003 16:52:24 -0400 (EDT) Date: Wed, 17 Sep 2003 13:14:49 -0400 From: Keith Moore To: Thomas Narten Message-Id: <20030917131449.63c6ff51.moore@cs.utk.edu> In-Reply-To: <200309171538.h8HFci606254@cichlid.raleigh.ibm.com> References: <200309171538.h8HFci606254@cichlid.raleigh.ibm.com> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Cc: problem-statement@alvestrand.no, moore@cs.utk.edu Subject: Re: problem statement: Engineering practice vs. management practices X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > > 2.2 The IETF does not Consistently use Effective Engineering > > Practices > > > > For an organization with 'engineering' in its title and > > participants who are likely to trot out the statement "Trust me, > > I'm an engineer!" when confronted with the need to find a > > solution to a particularly knotty problem, the IETF has, at least > > in some cases, extremely ineffective Engineering Practices. > > > > 2.7 Working Group Practices can make Issue Closure Difficult > > > > I have a hard time understanding the difference between 2.2 and 2.7 > and parts of 2.6. I _think_ section 2.2 is trying to say something > about how we don't actually use more rigorous and formal internal > processes that would help us avoid the problem of documents taking too > long, etc. But one could argue that a lot of that is related to basic > project management issues (or from Section 2.7 "Working Group > Practices can make Issue Closure Difficult"), and its not always clear > whether a cited issue is the lack of a tool (or lack of its use) or > just lack of use of basic project management techniques, or just bad > WG practice, for which there might be several ways to try and improve > the situation. On rereading these parts of the document I've come to the conclusion that most of 2.2 is really about management practices rather than engineering practices. Nevertheless I strongly agree that IETF does not consistently use effective engineering practices. (Maybe the problem is that many people in IETF are not familiar with the discipline of engineering or do not know how to apply it to protocol design?) So I think section 2.2 needs to be rewritten a bit, and some of the material in 2.2 needs to be moved to 2.7. In other words we need to make sure we understand (and the document is clear about) the difference between engineering of technical solution and management of groups that are chartered to produce technical solutions. I think it's worth doing because we really need to promote a better understanding of the discipline of engineering within IETF. IMHO, these are about engineering, though to some degree they're stated in the language of management more than the language of engineering: > o Failure to ensure that there is a uniform view in the WG of the > scope of the WG activity, especially the intended purpose of the > solution. i.e. failure to define the problem to be solved > > o Failure to identify at an early stage (before the design is > frozen), and/or then to ensure that there is a uniform view in > the WG of the issues that need to be resolved to bring the work > to a satisfactory conclusion. > > o Failure to identify and articulate engineering trade-offs that > may be needed to meet the deadlines that the WG has set without > inappropriately reducing the 'fitness for purpose' for the > intended customers. This is another example where the language is expressed in management rather than engineering terms. From an engineering perspective it's appropriate to think about time-to-specify as one of the many costs of an engineering solution which influence the compromise that must be made. IMHO it is rarely appropriate to treat a "deadline" as a concern that overrrides other costs. And the cost to the net of living with a poor solution for a long time should also be considered. > o Continued refinement of the solution beyond the point at which > it is adequate to meet the requirements placed on it by the > intended purpose. These are mostly management issues rather than engineering issues: > o The charter may not be sufficiently detailed to document the > process and timeline to be followed by the WG. Additional > documents may be needed such as a roadmap or detailed plans. Yes, WGs need to develop their own roadmaps and plans for the work they expect to do. > o Poorly defined success criteria for WGs and individual > documents. This is a management issue. Success criteria for the technical solutions would be an engineering issue. > o Lack of written guidelines or templates for the content of > documents (as opposed to the overall layout) and matching lists > of review criteria designed to achieve appropriate quality in > output. > > o Lack of auditing against explicit criteria throughout the > standards development process. Auditing against technical solution criteria would be an engineering issue, auditing against other criteria (like document quality) would be a management issue. > o Lack of metrics to measure the achievement of the desired > quality and the performance of WGs and the wider IETF.. Again, measurement of WG performance is a management issue; measurement of technical solutions is an engineering issue. > o Lack of an explicit feed forward path to drive the improvement > of the standards development process and success criteria over > time and to avoid repetition of failures that may occur. Anything having to do with the process is not an engineering issue > o Absence of documented debriefing sessions to assess and record > the successes and failures of WGs (and other processes) so that > the positive and negative lessons learned can be used to > facilitate future work and improve the processes. see above. > o Lack of criteria for determining when a piece of work is > overrunning and/or is unlikely to be concluded successfully > either at all or within an acceptable time frame: Lack of > process for either extending the time frame, adjusting the scope > or terminating the work item or the whole Working Group. This conflates process/management and engineering issues. If a piece of work doesn't satisfy its engineering criteria (including time-to-produce criteria) this is an engineering issue. And it would be appropriate to make those criteria explicit. But the lack of process for adjusting time frame or scope of a group's activities is a process or management issue. > o Tools to support the engineering process are minimal. This is very vague - it's hard to know what tools are meant here. > o Despite its commitment to 'running code', the IETF is not > proactive in providing ways for developers to verify their > implementations of IETF standards. FWIW, we've never relied on verification, and this was an explicit decision. We've placed high faith in interoperability testing, which is not the same thing. Of course, we don't do much to facilitate interoperability testing either. But we should probably amend this bullet a bit to say something like "...for developers to test the interoperability of their implementations." > > > 2.7 Working Group Practices Contribute to Delays > > Some additional examples for section 2.7: > > - too many WGs have a adopated a cycle where the bulk of the activity > is centered around the face-to-face meetings. E.g., Many IDs are > revised only once per cycle, immediately before a meeting, with too > little active work going on in the months immediately after a > meeting. Saying that WGs have "adopted" this cycle may be giving WG management more 'credit' than it deserves. F2F meetings with their imposed I-D deadlines are naturally going to encourage a tendency toward periodic releases of drafts, and this is often a good thing. And for early phases of operation of most WGs, one draft per cycle can be quite reasonable. But when the document is nearing completion it becomes important to release drafts more quickly, to avoid having to wait many months to work out small wording changes. Even more important than revising drafts is to identify the devisive issues prior to the f2f meetings so that there is a chance that they can be worked out in person. Sometimes a chair would do better to concentrate on getting the issues on the table (and using the f2f meeting to discuss those issues) rather than by merely insisting that the document be revised before the f2f meeting deadline. > - despite IETF mantra that the WG is the mailing list, mailing lists > are become increasingly ineffective at resolving issues, e.g., too > many postings for many to keep up with, too many off-topic posts > (i.e, those not directly related to getting wording changed in a WG > document) These are not equivalent. maybe you meant e.g. rather than i.e. ? > , folk being driven away because small number of vocal posters, etc. I agree that this is an issue, but it needs more refinement. There's an important difference between a list where a small number of people are exchanging a lot of messages but contributing useful insights while doing so, and a list where the level of traffic is similar but the participants are not making much progress. (either one might drive some people away through mere volume, but that's not entirely a bad thing. a certain level of discussion is necessary to solve any thorny problem, and artifically slowing down the discussion to reduce the bandwidth level is not necessarily helpful.) Part of this problem may be that we're dealing with more difficult issues, and there is more often a need to compromise between very disparate conflicting interests, than there was in the past. A lot of people do get turned off by divisive arguments, but that doesn't mean that those arguments don't need to take place. It might help if the group as a whole could gain a better idea of the needs of the various interests (both inside and outside of the group) early in its process - and maybe if these interests were documented participants might be able to argue more effectively (less heat and more light) by having a better idea of their adversaries' points-of-view. Keith From problem-statement-bounces@alvestrand.no Wed Sep 17 17:06:03 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29843 for ; Wed, 17 Sep 2003 17:06:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0468761B9E; Wed, 17 Sep 2003 23:05:38 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by eikenes.alvestrand.no (Postfix) with ESMTP id AD7CB61B97 for ; Wed, 17 Sep 2003 23:05:35 +0200 (CEST) Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250]) by comcast.net (sccrmhc11) with SMTP id <20030917210530011002nlvve> (Authid: sdawkins@comcast.net); Wed, 17 Sep 2003 21:05:34 +0000 Message-ID: <063d01c37d5f$70ea1520$040010ac@DFNJGL21> From: "Spencer Dawkins" To: References: <17628754376.20030917072236@brandenburg.com> <000b01c37d5d$ac60a030$020aff0a@home.glassey.com> Date: Wed, 17 Sep 2003 16:05:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: WG Last Call on IETF Problem Statement (small proposal toexpandtext in sections 2.2 and 2.3) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit My opinion is not unbiased (I'm on the editor's team), but I would prefer to actually do something about the problems we've identified in the more-than-year since Yokohama. We have added one new root cause since the list was created in March. This doesn't mean "there are no other problems", and it doesn't mean we have wasted time in discussions since then, but it does mean that we have a stable set of root causes as the basis for change. Further massaging of the list is not required for us to start making changes, and (since we're unlikely to make one set of perfect changes anyway, so must keep our eyes open in the future), anything missing probably isn't on the critical path to making changes. If it is, and we've missed it in six months of fairly intense mailing list and face-to-face discussions, I'd be surprised. The level of rigor for a problem statement for process change does not need to be as high as it is for a Proposed Standard protocol spec. IMHO. Spencer > > > > We can never list all of the problems. There are too many. We need to > limit > > the list or we will never complete it. > > Not true - What we need to break the list into several lists. That is to > create listso of associated problems specific to a conceptual area. Like > problems with the "Posting Model" and "Participation Models" in the WG's. > The problem with the current list is that it is all encompassing and as such > it is too large. But if it was broken down into smaller areas of concern the > work-product documents would be more manageable and of a more digestable set > of goals (at least IMHO). From problem-statement-bounces@alvestrand.no Wed Sep 17 21:07:08 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08595 for ; Wed, 17 Sep 2003 21:07:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8100661B9E; Thu, 18 Sep 2003 03:06:43 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3DCE561B97 for ; Thu, 18 Sep 2003 03:06:42 +0200 (CEST) Received: from desktop (103.sanjose-06-07rs16rt.ca.dial-access.att.net[12.81.2.103]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <200309180106371120065oune>; Thu, 18 Sep 2003 01:06:39 +0000 Message-ID: <034401c37d81$b45a3610$020aff0a@home.glassey.com> From: "todd glassey" To: , "Thomas Narten" References: <200309171538.h8HFci606254@cichlid.raleigh.ibm.com> Date: Wed, 17 Sep 2003 18:10:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Subject: Re: problem statement: Engineering practice vs. management practices X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Thomas ----- Original Message ----- From: "Thomas Narten" To: Sent: Wednesday, September 17, 2003 8:38 AM Subject: problem statement: Engineering practice vs. management practices > > 2.2 The IETF does not Consistently use Effective Engineering Practices > > > > For an organization with 'engineering' in its title and participants > > who are likely to trot out the statement "Trust me, I'm an engineer!" > > when confronted with the need to find a solution to a particularly > > knotty problem, the IETF has, at least in some cases, extremely > > ineffective Engineering Practices. > > > > 2.7 Working Group Practices can make Issue Closure Difficult > > > > I have a hard time understanding the difference between 2.2 and 2.7 -- SNIP-- ss 2.2. is about a uniform Vetting Model for creating a Standard, and 2.7 is about the management of the WG's; They address related but separate issues. BTW - The real problem with this issue is not that the IETF does not use effective engineering practices, its that the IETF refuses to use uniform ones so that everyone gets the same bite at the apple. Todd From problem-statement-bounces@alvestrand.no Thu Sep 18 05:23:37 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03301 for ; Thu, 18 Sep 2003 05:23:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 90AE761BE5; Thu, 18 Sep 2003 11:23:11 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from smail.alcatel.fr (colt-na165.alcatel.fr [62.23.212.165]) by eikenes.alvestrand.no (Postfix) with ESMTP id B222261BDC for ; Thu, 18 Sep 2003 11:23:09 +0200 (CEST) Received: from frmail31.netfr.alcatel.fr (frmail31.netfr.alcatel.fr [155.132.251.42]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id h8I9N8mY028186; Thu, 18 Sep 2003 11:23:08 +0200 To: "Elwyn Davies" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Alistair.Urie@alcatel.com Date: Thu, 18 Sep 2003 11:23:06 +0200 X-MIMETrack: Serialize by Router on FRMAIL31/FR/ALCATEL(Release 5.0.11 |July 24, 2002) at 09/18/2003 11:23:07 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new Cc: Melinda Shore , avri , problem-statement@alvestrand.no Subject: RE: WG Last Call on IETF Problem Statement (small proposal to exp and text in sections 2.2 and 2.3) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Elwyn, For the dependency issue I am sorry but I carn't find any mention of this issue in section 2.4 (which is more about the "post-WG approval process" while I was more concerned about new work still ongoing within a WG) but agree that this paragraph of 2.1 could be read to cover this issue proved we agree that recognising this important issue of dependencies between WG and between IETF and other SDOs is consideration when looking at the problem of IETF's core mission. This is more than I was looking for (I was only considering this to be a process issue and hence for 2.2) I still think the minor change I propose to 2.2 would both better cover this issue and send a clear signal to other SDOs that IETF is going to work to improve its processes handling this dependency issue For the undated reference issue I note that a similar idea is under discussion in the solution list (the SSS idea) and I think you will be surprised to find out how simple changes like this could help us break big complex issues into smaller pieces. Many other SDOs use this and it works. Once again. Why not add this small change proposal? See also my comments below marked AUnew>> - Alistair P.S. Maybe the fact that small, targetted, change proposals like this can not easily be included at this stage in the process is also a problem worth looking at ;-) "Elwyn Davies" , Melinda Shore tworks.com> cc: problem-statement@alvestrand.no 17/09/2003 17:00 Subject: RE: WG Last Call on IETF Problem Statement (small proposal to exp and text in sections 2.2 and 2.3) Hi. Thanks for the comments. I think the points you make are indeed valid and looking back through the mailing list, I believe that they had mostly been made previously. I also believe that they are essentially covered by the existing text, and so I would concur with Dave Crocker that it would be gilding the lily to make more modifications at this stage. Regards, Elwyn > -----Original Message----- > From: Alistair.Urie@alcatel.com [mailto:Alistair.Urie@alcatel.com] > Sent: 15 September 2003 17:16 > To: avri; Melinda Shore; problem-statement@alvestrand.no > Subject: Re: WG Last Call on IETF Problem Statement (small > proposal to expand text in sections 2.2 and 2.3) > > > > Although I note that a few people have already said we should > "just ship > it", may I please make two, small, last minute, proposals to > add to this > draft covering a pair of issues concerning problems effecting > inter-relationships between WGs and between IETF and other > bodies? <> > 1) Need for IETF to improve communications between WGs and > between IETF and > outside organisation when working on common issues > <> > AU - add here>> o Difficulty in identify dependencies and > respecting > milestones between WG outputs and work planning and the work > of other WGs > and/or other standards developing bodies outside IETF which are > collaborating with WGs on common issues I think the issue for WGs is adequately covered by the equivalent point in 2.4. AUnew>>> Sorry but carn't see anything under 2.4 on collaborations. Communications with SDOs is covered in 2.1. Arguably the equivalent point to the one in 2.4 for WGs could be made for other SDOs. AUnew>> But I am not discussing "communications" I am concerned about mutual agreements that IETF leads on certain topics and that we will deliver on our promises > > o Project entry, goal setting, and tracking processes are > all either > missing or implemented less effectively than the norm for > commercial organizations in related activities. > > AU - replace with>> > o Project entry, goal setting, dependency identification > and tracking > processes are all either missing or implemented less > effectively than > the norm for commercial organizations in related activities." I think this is also covered by the point in 2.4. > > 2) - Lack of "undated" references covering IETF outputs > <> > To cover this issue I propose we add a new dot point to the > list in section > 2.3. > > Specific proposed text is: > <> > AU - add text>>o The IETF does not have an effective means > for WGs and > outside standards bodies to refer to "work in progress" on > new subjects and > RFC revisions by means of "undated" references and/or other > methods that > allow work to progress independently on individual components > of a complex > problem." This is a useful point but I am not sure that it adds significantly to point about complex problems. In terms of solutions this needs to be addressed and various people have already been airing possibilities. Regards, Elwyn. > > yours, > > Alistair URIE > > > > > > > > avri > > > Sent by: > To: problem-statement@alvestrand.no > > problem-statement-bounces@al > cc: Melinda Shore > > vestrand.no > Subject: WG Last Call on IETF Problem Statement > > > > > > > > 31/08/2003 04:51 > > > > > > > > > > > > > > This note marks the beginning of the WG Last call for: > > > > Title : IETF Problem Statement > > Author(s) : E. Davies > > Filename : > draft-ietf-problem-issue-statement-03.txt > > Pages : 24 > > Date : 2003-8-26 > > > > > The document can be found at: > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-problem-issue-s tatement- 03.txt Because of the US holiday on Monday , 1- Sept, the last call will extend from now, 31 August until 16 September (any time zone). Please send your comments to the WG mailing list problem-statement@alvestrand.no thanks a. Avri Doria co-chair From problem-statement-bounces@alvestrand.no Thu Sep 18 05:49:03 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04688 for ; Thu, 18 Sep 2003 05:49:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2DA8861BE5; Thu, 18 Sep 2003 11:48:38 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id 67D2A61BB5 for ; Thu, 18 Sep 2003 11:48:36 +0200 (CEST) Received: from psg.com ([147.28.0.62]) by psg.com with esmtp (Exim 4.22) id 19zvOt-000OgN-0q for problem-statement@alvestrand.no; Thu, 18 Sep 2003 09:48:35 +0000 Date: Thu, 18 Sep 2003 18:47:32 +0900 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: avri To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <1FD35450-E9BD-11D7-A1FA-000393CC2112@psg.com> X-Mailer: Apple Mail (2.552) Subject: Re: WG Last Call on IETF Problem Statement (small proposal to exp and text in sections 2.2 and 2.3) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On torsdag, sep 18, 2003, at 18:23 Asia/Seoul, Alistair.Urie@alcatel.com wrote: > Once again. Why not add this small change proposal? > > > - Alistair > > P.S. Maybe the fact that small, targetted, change proposals like this > can > not easily be included at this stage in the process is also a problem > worth > looking at ;-) > > > I think the only problem with including it is determining whether there is WG consensus for including it. Documents can, of course, be changed as a result of Last Call comments, but only when there is consensus from the WG to do so. That is indeed what we are trying to determine at this point. Thanks a. From problem-statement-bounces@alvestrand.no Thu Sep 18 10:03:02 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12154 for ; Thu, 18 Sep 2003 10:03:01 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9AA9E61BB5; Thu, 18 Sep 2003 16:02:35 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3AC4361B97 for ; Thu, 18 Sep 2003 16:02:34 +0200 (CEST) Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250]) by comcast.net (sccrmhc11) with SMTP id <20030918140232011000oo0ie> (Authid: sdawkins@comcast.net); Thu, 18 Sep 2003 14:02:32 +0000 Message-ID: <06f001c37ded$839dbda0$040010ac@DFNJGL21> From: "Spencer Dawkins" To: References: <1FD35450-E9BD-11D7-A1FA-000393CC2112@psg.com> Date: Thu, 18 Sep 2003 09:02:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: WG Last Call on IETF Problem Statement (small proposal toexp and text in sections 2.2 and 2.3) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit I'm probably not being entirely clear in my postings. Avri may have said it better. I happen to agree that the problem Alistair raises is a real problem, and should be fixed. The question is, is it worth discussing the text, updating the document, and issuing another WG last call? I don't think that it is, because - the text cannot include a solution (out of scope for the document and for the WG), so nothing will change immediately as a result of adding the new problem, and - a problem doesn't have to be documented in this draft in order to be fixed! We're talking about the Problem Statement draft as if it was a work plan for solutions. It's not. It's an attempt to get clarity on a few serious problems. Nobody is going to oppose a smart process improvement because the problem wasn't named in the Problem Statement draft. So, my suggestion is, - ship the document, - discuss the problem on this list, if anyone has feedback - nobody has said the problem doesn't exist, so I wouldn't expect too much feedback here - , and - propose a solution - and I would suggest a brief ID as the format for the proposal, and solutions@alvestrand.no as the venue for discussing the proposal. IMH,B,BSCO :-} But we really can start proposing solutions. We really don't have to serialize the first fix behind the final problem identification, but if we have to have a perfect Problem Statement before we ship it, we're going to. Spencer > On torsdag, sep 18, 2003, at 18:23 Asia/Seoul, > Alistair.Urie@alcatel.com wrote: > > > Once again. Why not add this small change proposal? > > > > I think the only problem with including it is determining whether there > is WG consensus for including it. Documents can, of course, be changed > as a result of Last Call comments, but only when there is consensus > from the WG to do so. That is indeed what we are trying to determine > at this point. > > Thanks > > a. > From problem-statement-bounces@alvestrand.no Thu Sep 18 10:27:25 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15031 for ; Thu, 18 Sep 2003 10:27:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C79BE61B9E; Thu, 18 Sep 2003 16:26:59 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2BA0861B97 for ; Thu, 18 Sep 2003 16:26:58 +0200 (CEST) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 9092314038; Thu, 18 Sep 2003 10:26:57 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07228-13; Thu, 18 Sep 2003 10:26:57 -0400 (EDT) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 8187A14057; Thu, 18 Sep 2003 10:26:56 -0400 (EDT) Date: Thu, 18 Sep 2003 10:23:29 -0400 From: Keith Moore To: Spencer Dawkins Message-Id: <20030918102329.409f84ab.moore@cs.utk.edu> In-Reply-To: <06f001c37ded$839dbda0$040010ac@DFNJGL21> References: <1FD35450-E9BD-11D7-A1FA-000393CC2112@psg.com> <06f001c37ded$839dbda0$040010ac@DFNJGL21> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Cc: problem-statement@alvestrand.no, moore@cs.utk.edu Subject: Re: WG Last Call on IETF Problem Statement (small proposal toexp and text in sections 2.2 and 2.3) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit I'm in sympathy with this view. We can't expect to nail down every problem and get agreement on every problem before we submit a list of problems. We have a good enough list for the IESG and IAB to start working on solutions, we should not give them an excuse to delay doing so by delaying this document any more than necessary. So my suggestion is that we change the document to state up front a very clearly that the list is not comprehensive and never will be, and that we recognize that our descriptions of these problems may be imperfect, and that any group considering how to solve these problems will certainly need to consider other input and/or subsequent clarifications, whether from the problem statement WG or other interested/affected parties. That, and change the abstract to remove the assumption that this group is going to dictate the process by which problems are to be addressed. and ship it. Those who have comments/clarifications that they wish to submit can do so as separate internet drafts. Or if the group would like to set up a web page where we can keep track of such notes it would be easy to collect them all into a single draft and/or revise the problem statement document at a later date, should that be found to be desirable. From problem-statement-bounces@alvestrand.no Thu Sep 18 10:31:10 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15225 for ; Thu, 18 Sep 2003 10:31:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6C62661BAD; Thu, 18 Sep 2003 16:30:43 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from znsgs01r.nortelnetworks.com (h1s128a211n47.user.nortelnetworks.com [47.211.128.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0EBAB61B97 for ; Thu, 18 Sep 2003 16:30:42 +0200 (CEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8IEUVk29043; Thu, 18 Sep 2003 15:30:31 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Sep 2003 15:30:31 +0100 Message-ID: <4103264BC8D3D51180B7002048400C45016237B9@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "'Thomas Narten'" Date: Thu, 18 Sep 2003 15:30:28 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Cc: problem-statement@alvestrand.no Subject: RE: Missing root cause: Internet has gotten more complex X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Hi. I think all right thinking IETF persons would have agree with your statement: "The Internet Has Become More Complex and Requirements placed on it by Users have Changed". But, is this a root cause? I would say it is a statement of the environment in which the IETF has to work. To me the IETF has problems due to - not recognising what has happened because it was no longer clear about its mission and as a result not changing what its mission is (or at least making sure that its mission was still appropriate) - not being well equipped to cope with the more complex problems that result from the changed environment These areas are, I believe, covered. That being said I think it would be useful to be more explicit about the changed environment both in the introduction and in 2.1. Section 2.3 already mentions the more complex interactions, etc, but maybe the wording could be improved. There are a few more comments about each of the examples below. In general, I don't think this is another root cause problem, but as we said at the outset there are lots of ways to crumble the cookie - the question is are you happy with adding some text to the Intro, 2.1 and 2.3 - and is everybody else happy? Regards, Elwyn > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: 17 September 2003 15:16 > To: problem-statement@alvestrand.no > Subject: Missing root cause: Internet has gotten more complex > > > Looking at the root causes, they appear to be: > > > 2. Root Cause Problems . . . . . . . . . . . . . . . > . . . . . 8 > > 2.1 Participants in the IETF do not have a Common > > Understanding of its Mission . . . . . . . . . . . > . . . . . 8 > > 2.2 The IETF does not Consistently use Effective Engineering > > Practices . . . . . . . . . . . . . . . . . . . . > . . . . . 9 > > 2.3 The IETF has Difficulty Handling Large and/or Complex > > Problems . . . . . . . . . . . . . . . . . . . . . > . . . . . 12 > > 2.4 Three Stage Standards Hierarchy not properly > Utilized . . . 13 > > 2.5 The IETF's Workload Exceeds the Number of Fully Engaged > > Participants . . . . . . . . . . . . . . . . . . . > . . . . . 14 > > 2.6 The IETF Management Structure is not Matched to the > > Current Size and Complexity of the IETF . . . . . > . . . . . 15 > > 2.7 Working Group Practices can make Issue Closure > Difficult . . 20 > > 2.8 IETF Participants and Leaders are Inadequately Prepared > > for their Roles . . . . . . . . . . . . . . . . . > . . . . . 21 > > > But there is at least one root cause that I don't see called out > explicitly: > > The Internet Has Become More Complex and Requirements placed on > it by Users have Changed > > Examples: > > - increasing complexity of internet/protocols/deployments > > - awareness that when deployed, protocols _will_ interact with each > other and there is a need to understand those interactions in order > to decide whether the protocol is reasonably well thought out and > that there will be no maor (bad) surpises when it becomes deployed. The third para in 2.3 is intended to cover just these issues. It might be good to add in some words which make it clear that the Interent has developed in just such a way as to make the interactions something that MUST be dealt with all the time. > > - desire to not have multiple protocols that do essentially the same > thing, thus, need to use other IETF components rather than point > solution. (but this view may not be shared by all of the community, > which gets back to Section 2.1) I think the parenthesised comment is right - this is more about what the philosophy/mission of the IETF ought to be, rather than being a manifestion of any other problem. Once upon a time, I thought WGs were supposed to consider multiple options to the point of running code and then compare the results - now we have only thought experiments and, in many case, prejudice. > > - The Internet has changed over the last 15 years, with a different > level of expectations (e.g., part of economic infrastructure). > Internet is no longer a toy for running half-thought-out experiments > on a wide-scale, where the consequences may be very hard to fix > after the fact. Another way of stating this. Its one thing to run an > experiment of limited scope. It's another to put something into cell > phones, where the "experiment" involves millions of devices. > > note: this point may well also go back to lack of agreement on > mission/core values. Right - see at the top. > > - The "low hanging fruit" has been picked. The easiest problems to > solve have been solved. We're now dealing with the harder ones; it > should be no surprise that finding solutions to them is not as easy. Indeed - but the problem seems to be we aren't good at solving the more complex problems. > > Thomas > From problem-statement-bounces@alvestrand.no Thu Sep 18 10:36:40 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15533 for ; Thu, 18 Sep 2003 10:36:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2F77461B9E; Thu, 18 Sep 2003 16:36:14 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from znsgs01r.nortelnetworks.com (h1s128a211n47.user.nortelnetworks.com [47.211.128.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 394AD61B9E for ; Thu, 18 Sep 2003 16:36:12 +0200 (CEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8IEa7k29795; Thu, 18 Sep 2003 15:36:07 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Sep 2003 15:36:07 +0100 Message-ID: <4103264BC8D3D51180B7002048400C45016237BA@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "'Keith Moore'" , Spencer Dawkins Date: Thu, 18 Sep 2003 15:36:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37DF2.2EC728AC" Cc: problem-statement@alvestrand.no Subject: RE: WG Last Call on IETF Problem Statement (small proposal toexp and text in sections 2.2 and 2.3) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C37DF2.2EC728AC Content-Type: text/plain I'm also in sympathy with this view - we can add a few words to the document but it is basically fiddling at the edges. I haven't seen anything that really deserves wholesale surgery in the comments so far. As editor, I would be happy to monitor the list, look after a web site and maybe update the document (maybe remove some of the problems as solved!) in due course. The matter of whether the WG is going to produce a process document is rather out of our control at present - I guess we could remove the cross-ref without doing any harm. Regards, Elwyn > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: 18 September 2003 15:23 > To: Spencer Dawkins > Cc: problem-statement@alvestrand.no; moore@cs.utk.edu > Subject: Re: WG Last Call on IETF Problem Statement (small > proposal toexp and text in sections 2.2 and 2.3) > > > I'm in sympathy with this view. We can't expect to nail down > every problem > and get agreement on every problem before we submit a list of > problems. > We have a good enough list for the IESG and IAB to start > working on solutions, > we should not give them an excuse to delay doing so by > delaying this document > any more than necessary. > > So my suggestion is that we change the document to state up > front a very > clearly that the list is not comprehensive and never will be, > and that we > recognize that our descriptions of these problems may be > imperfect, and > that any group considering how to solve these problems will > certainly need to > consider other input and/or subsequent clarifications, > whether from the problem > statement WG or other interested/affected parties. > > That, and change the abstract to remove the assumption that > this group is > going to dictate the process by which problems are to be addressed. > > and ship it. > > Those who have comments/clarifications that they wish to > submit can do so as > separate internet drafts. Or if the group would like to set > up a web page > where we can keep track of such notes it would be easy to > collect them all > into a single draft and/or revise the problem statement > document at a later > date, should that be found to be desirable. > > ------_=_NextPart_001_01C37DF2.2EC728AC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: WG Last Call on IETF Problem Statement (small proposal toexp = and text in sections 2.2 and 2.3)

I'm also in sympathy with this view - we can add a = few words to the document but it is basically fiddling at the = edges.  I haven't seen anything that really deserves wholesale = surgery in the comments so far.

As editor, I would be happy to monitor the list, look = after a web site and maybe update the document (maybe remove some of = the problems as solved!) in due course.

The matter of whether the WG is going to produce a = process document is rather out of our control at present - I guess we = could remove the cross-ref without doing any harm.

Regards,
Elwyn

> -----Original Message-----
> From: Keith Moore [mailto:moore@cs.utk.edu]
> Sent: 18 September 2003 15:23
> To: Spencer Dawkins
> Cc: problem-statement@alvestrand.no; = moore@cs.utk.edu
> Subject: Re: WG Last Call on IETF Problem = Statement (small
> proposal toexp and text in sections 2.2 and = 2.3)
>
>
> I'm in sympathy with this view.  We can't = expect to nail down
> every problem
> and get agreement on every problem before we = submit a list of
> problems.
> We have a good enough list for the IESG and IAB = to start
> working on solutions,
> we should not give them an excuse to delay = doing so by
> delaying this document
> any more than necessary.
>
> So my suggestion is that we change the document = to state up
> front a very
> clearly that the list is not comprehensive and = never will be,
> and that we
> recognize that our descriptions of these = problems may be
> imperfect, and
> that any group considering how to solve these = problems will
> certainly need to
> consider other input and/or subsequent = clarifications,
> whether from the problem
> statement WG or other interested/affected = parties.
>
> That, and change the abstract to remove the = assumption that
> this group is
> going to dictate the process by which problems = are to be addressed.
>
> and ship it.
>
> Those who have comments/clarifications that = they wish to
> submit can do so as
> separate internet drafts.  Or if the group = would like to set
> up a web page
> where we can keep track of such notes it would = be easy to
> collect them all
> into a single draft and/or revise the problem = statement
> document at a later
> date, should that be found to be = desirable.
>
>

------_=_NextPart_001_01C37DF2.2EC728AC-- From problem-statement-bounces@alvestrand.no Thu Sep 18 10:52:58 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16195 for ; Thu, 18 Sep 2003 10:52:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A5AAF61B9E; Thu, 18 Sep 2003 16:52:32 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6DFB461B97 for ; Thu, 18 Sep 2003 16:52:30 +0200 (CEST) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id D15A614038; Thu, 18 Sep 2003 10:52:29 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11656-04; Thu, 18 Sep 2003 10:52:29 -0400 (EDT) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id C34AA14091; Thu, 18 Sep 2003 10:52:28 -0400 (EDT) Date: Thu, 18 Sep 2003 10:49:02 -0400 From: Keith Moore To: "Elwyn Davies" Message-Id: <20030918104902.77e15dc6.moore@cs.utk.edu> In-Reply-To: <4103264BC8D3D51180B7002048400C45016237B9@zhard0jd.europe.nortel.com> References: <4103264BC8D3D51180B7002048400C45016237B9@zhard0jd.europe.nortel.com> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Cc: narten@us.ibm.com, problem-statement@alvestrand.no, moore@cs.utk.edu Subject: Re: Missing root cause: Internet has gotten more complex X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > I think all right thinking IETF persons would have agree with your > statement: > "The Internet Has Become More Complex and Requirements placed on it by Users > have Changed". > > But, is this a root cause? I think it is, and I think it might have implications for IETF's structure. whether we should hold up the document to include it is a different question. From problem-statement-bounces@alvestrand.no Thu Sep 18 11:16:38 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17495 for ; Thu, 18 Sep 2003 11:16:37 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DEE9261BAD; Thu, 18 Sep 2003 17:16:11 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by eikenes.alvestrand.no (Postfix) with ESMTP id AF82B61B97 for ; Thu, 18 Sep 2003 17:16:09 +0200 (CEST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8IFG7x29256 for ; Thu, 18 Sep 2003 08:16:07 -0700 X-mProtect: <200309181516> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.5.66, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdU0agaL; Thu, 18 Sep 2003 08:16:05 PDT Message-ID: <3F69CC26.80905@iprg.nokia.com> Date: Thu, 18 Sep 2003 08:15:50 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: problem-statement@alvestrand.no References: <1FD35450-E9BD-11D7-A1FA-000393CC2112@psg.com> <06f001c37ded$839dbda0$040010ac@DFNJGL21> <20030918102329.409f84ab.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: WG Last Call on IETF Problem Statement (small proposal toexp and text in sections 2.2 and 2.3) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hello folks, Was it decided that the IETF members cannot solve the problems, and we have to hand it over to the IESG? For those who believe that the IESG has too much power and uses it inappropriately, that doesn't sound very hopeful. Furthermore, it seems to me that at least some members of the IESG are _increasing_ their use of that power over the last year. Is there anything about the current direction of this discussion that would encourage them to limit their opportunities? Regards, Charlie P. Keith Moore wrote: >I'm in sympathy with this view. We can't expect to nail down every problem >and get agreement on every problem before we submit a list of problems. >We have a good enough list for the IESG and IAB to start working on solutions, >we should not give them an excuse to delay doing so by delaying this document >any more than necessary. > > > > From problem-statement-bounces@alvestrand.no Thu Sep 18 11:56:05 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19343 for ; Thu, 18 Sep 2003 11:56:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0576661BB5; Thu, 18 Sep 2003 17:55:40 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from znsgs01r.nortelnetworks.com (h1s128a211n47.user.nortelnetworks.com [47.211.128.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E356261B97 for ; Thu, 18 Sep 2003 17:55:38 +0200 (CEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8IFtIk20070; Thu, 18 Sep 2003 16:55:18 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Sep 2003 16:55:19 +0100 Message-ID: <4103264BC8D3D51180B7002048400C45016237BB@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "'Charlie Perkins'" , problem-statement@alvestrand.no Date: Thu, 18 Sep 2003 16:55:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37DFD.3E472A38" Subject: RE: WG Last Call on IETF Problem Statement (small proposal toexp and text in sections 2.2 and 2.3) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C37DFD.3E472A38 Content-Type: text/plain As far as I am aware, there has been no concensus and no firm decision from the WG side on how to go forward on the structural and basic process issues. The WG appears to be happy with recommending independent action, and the members have gone off to execute, on at least some of the 'immediate' problems documented in the process draft. On the other hand a number of voices have been heard saying 'leave it to the IESG', and we note the IAB has set up the 'Advisory Committee on IETF Administration Relationships'. This committee may 'propose IETF management process or structural schanges' but is (currently) not to work on changes to the standards development process (including WG management etc). Jeanette Hofmann, Avri Doria and I published a proposal for the structural and process change area, but there hasn't been much competition or constructive comment (apart from to say this will just slow things down). So if you want a process other than 'leave it the IESG' - start thinking and saying how! Regards, Elwyn > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: 18 September 2003 16:16 > To: problem-statement@alvestrand.no > Subject: Re: WG Last Call on IETF Problem Statement (small > proposal toexp and text in sections 2.2 and 2.3) > > > > Hello folks, > > Was it decided that the IETF members cannot solve the > problems, and we have to hand it over to the IESG? > > For those who believe that the IESG has too much power > and uses it inappropriately, that doesn't sound very hopeful. > Furthermore, it seems to me that at least some members of > the IESG are _increasing_ their use of that power over the > last year. Is there anything about the current direction of this > discussion that would encourage them to limit their opportunities? > > Regards, > Charlie P. > > > > Keith Moore wrote: > > >I'm in sympathy with this view. We can't expect to nail > down every problem > >and get agreement on every problem before we submit a list > of problems. > >We have a good enough list for the IESG and IAB to start > working on solutions, > >we should not give them an excuse to delay doing so by > delaying this document > >any more than necessary. > > > > > > > > > > > ------_=_NextPart_001_01C37DFD.3E472A38 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: WG Last Call on IETF Problem Statement (small proposal toexp = and text in sections 2.2 and 2.3)

As far as I am aware, there has been no concensus and = no firm decision from the WG side on how to go forward on the = structural and basic process issues.  The WG appears to be happy = with recommending independent action, and the members have gone off to = execute, on at least some of the 'immediate' problems documented in the = process draft.

On the other hand a number of voices have been heard = saying 'leave it to the IESG', and we note the IAB has set up the = 'Advisory Committee on IETF Administration Relationships'.  This = committee may 'propose IETF management process or structural schanges' = but is (currently) not to work on changes to the standards development = process (including WG management etc).

Jeanette Hofmann, Avri Doria and I published a = proposal for the structural and process change area, but there hasn't = been much competition or constructive comment (apart from to say this = will just slow things down).

So if you want a process other than 'leave it the = IESG' - start thinking and saying how!

Regards,
Elwyn

> -----Original Message-----
> From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
> Sent: 18 September 2003 16:16
> To: problem-statement@alvestrand.no
> Subject: Re: WG Last Call on IETF Problem = Statement (small
> proposal toexp and text in sections 2.2 and = 2.3)
>
>
>
> Hello folks,
>
> Was it decided that the IETF members cannot = solve the
> problems, and we have to hand it over to the = IESG?
>
> For those who believe that the IESG has too = much power
> and uses it inappropriately, that doesn't sound = very hopeful.
> Furthermore, it seems to me that at least some = members of
> the IESG are _increasing_ their use of that = power over the
> last year.  Is there anything about the = current direction of this
> discussion that would encourage them to limit = their opportunities?
>
> Regards,
> Charlie P.
>
>
>
> Keith Moore wrote:
>
> >I'm in sympathy with this view.  We = can't expect to nail
> down every problem
> >and get agreement on every problem before = we submit a list
> of problems.
> >We have a good enough list for the IESG and = IAB to start
> working on solutions,
> >we should not give them an excuse to delay = doing so by
> delaying this document
> >any more than necessary.
> >
> >
> > 
> >
>
>
>

------_=_NextPart_001_01C37DFD.3E472A38-- From problem-statement-bounces@alvestrand.no Thu Sep 18 13:39:50 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25168 for ; Thu, 18 Sep 2003 13:39:49 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E535861BA7; Thu, 18 Sep 2003 19:39:23 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4C2E161B97 for ; Thu, 18 Sep 2003 19:39:21 +0200 (CEST) Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 18 Sep 2003 10:36:17 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h8IHdIwn017218; Thu, 18 Sep 2003 10:39:18 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-43.cisco.com [10.32.241.43]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AMG93569; Thu, 18 Sep 2003 10:39:17 -0700 (PDT) Date: Thu, 18 Sep 2003 13:39:16 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Charlie Perkins From: Melinda Shore In-Reply-To: <3F69CC26.80905@iprg.nokia.com> Message-Id: <062D5C1E-E9FF-11D7-85E2-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Subject: Re: WG Last Call on IETF Problem Statement (small proposal toexp and text in sections 2.2 and 2.3) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On Thursday, September 18, 2003, at 11:15 AM, Charlie Perkins wrote: > Was it decided that the IETF members cannot solve the > problems, and we have to hand it over to the IESG? Not really. There were the straw polls taken at the plenary (that is to say, *not* in this working group) which showed that a slim majority of people in the room at the favored sending it to the IESG. Within this working group while there was agreement that we'd recommend moving ahead immediately with the recommended short-term solutions, the few concrete process suggestions that have been made have been shot down and nobody's been able to come up with something acceptable to the group. We need to come to grips with that somehow, but in the meantime the problem statement document is not gated on the process document. Melinda From problem-statement-bounces@alvestrand.no Thu Sep 18 14:02:53 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26255 for ; Thu, 18 Sep 2003 14:02:52 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3FBDD61BA7; Thu, 18 Sep 2003 20:02:27 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by eikenes.alvestrand.no (Postfix) with ESMTP id E973461B97 for ; Thu, 18 Sep 2003 20:02:24 +0200 (CEST) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id E40FA14050; Thu, 18 Sep 2003 14:02:23 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02942-14; Thu, 18 Sep 2003 14:02:23 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 750681400A; Thu, 18 Sep 2003 14:02:23 -0400 (EDT) Date: Thu, 18 Sep 2003 14:02:23 -0400 From: Keith Moore To: Charlie Perkins Message-Id: <20030918140223.541b2e08.moore@cs.utk.edu> In-Reply-To: <3F69CC26.80905@iprg.nokia.com> References: <1FD35450-E9BD-11D7-A1FA-000393CC2112@psg.com> <06f001c37ded$839dbda0$040010ac@DFNJGL21> <20030918102329.409f84ab.moore@cs.utk.edu> <3F69CC26.80905@iprg.nokia.com> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Cc: problem-statement@alvestrand.no, moore@cs.utk.edu Subject: Re: WG Last Call on IETF Problem Statement (small proposal toexp and text in sections 2.2 and 2.3) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > Was it decided that the IETF members cannot solve the > problems, and we have to hand it over to the IESG? we have to start somewhere. IESG is not less brain-damaged than the rest of IETF (they quite possibly may be saner), and they're in a better position to initiate change than this WG. of course if you want to form your own design team, you're free to do so. best of luck! Keith From problem-statement-bounces@alvestrand.no Fri Sep 19 11:57:09 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01619 for ; Fri, 19 Sep 2003 11:57:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7527B61BD9; Fri, 19 Sep 2003 11:42:50 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from cbibipnt08.hc.bt.com (saturn.bt.com [193.113.57.20]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1769E61B83; Fri, 19 Sep 2003 11:42:48 +0200 (CEST) Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Fri, 19 Sep 2003 10:42:56 +0100 Message-ID: <3D67CCA7D63E714B980D21A038EEA08E045A2A5A@i2km02-ukbr.domain1.systemhost.net> From: graham.travers@bt.com To: harald@alvestrand.no, mshore@cisco.com Date: Fri, 19 Sep 2003 10:42:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Cc: problem-statement@alvestrand.no Subject: RE: WG Last Call on IETF Problem Statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no All, My two cents worth... I drafted this a few weeks ago, and then sat on it, because it seemed superfluous. However, since we are now discussing how to move the Process Document forward again... I agree pretty much with what Harald wrote recently. We should propose different processes, where they are needed to progress. Let's move forward quickly where we can, as supported by the Vienna IESG Plenary. On the other hand, I think some problems may require a new and slower process, e.g. the type of problem which can't just be handed over to the IESG to resolve ( too much IESG power, etc. ). Practically, this means examining each problem, and proposing a suitable process to deal with it. This could take the form of a simple table/matrix. Regards, Graham Travers International Standards Manager BT Exact e-mail: graham.travers@bt.com tel: +44(0) 1359 235086 mobile: +44(0) 7808 502536 fax: +44(0) 1359 235087 HWB279, PO Box 200,London, N18 1ZF, UK BTexact Technologies is a trademark of British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. -----Original Message----- From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] Sent: 02 September 2003 22:52 To: Melinda Shore Cc: problem-statement@alvestrand.no Subject: Re: Moving the process document forward --On 2. september 2003 14:01 -0700 Dave Crocker wrote: > Melinda, > > MS> we do need input on the question of how to tackle the > MS> restructuring (if it's agreed that it's necessary) question, > MS> whether it's details on how to construct a blue-ribbon panel > MS> or to recommend kicking the whole thing over to the IESG. > > The situation is a bit worse than that. > > Other than general references to "restructuring" we do not have anything > concretely specifying what that means, nevermind whether we have > consensus to pursue it. I think the WG has the following chartered work item: > As a second work item, the group will also produce a proposal for a > process to develop solutions to the problems identified by this working > group. Since we know what the problems are (modulo objections to -issue-03, which I haven't seen much of), there should be at least some possibility of suggesting the required process for fixing them. This may come in the form of (problem, suggested solution, how-to-get-there) descriptions, or it may come in the form of (problem, needed investigation, range of solutions) descriptions; I personally don't think all of our problems will be solved by a single fell-swoop solution - different problems may require different approaches, so there are probably multiple things that can be suggested, refined and adopted - but I think the proposals need to be anchored into "what problem are we trying to solve". (Yes, I AM working on delivering what I think the IESG was charged with in Vienna - proposing at least some process to deal with at least some of the problems. It's not ready for publication yet.) Harald From problem-statement-bounces@alvestrand.no Tue Sep 23 14:20:30 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28720 for ; Tue, 23 Sep 2003 14:20:29 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3393561C11; Tue, 23 Sep 2003 20:20:03 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4DD9A61C0E for ; Tue, 23 Sep 2003 20:20:00 +0200 (CEST) Date: Tue, 23 Sep 2003 09:57:24 -0700 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <9919483.1064311044@localhost> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Minutes from plenary et al in Vienna X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit For those who want to review the events in Vienna: has links to the presentations and minutes (thanks Spencer!) from the IESG plenary, as well as the minutes from the PROBLEM WG. People may find those interesting. Harald From problem-statement-bounces@alvestrand.no Sun Sep 28 10:16:53 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19548 for ; Sun, 28 Sep 2003 10:16:52 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 39D2161BB3; Sun, 28 Sep 2003 16:16:28 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B4FF661BA7 for ; Sun, 28 Sep 2003 16:16:25 +0200 (CEST) Date: Sun, 28 Sep 2003 07:12:06 -0700 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <336146483.1064733126@localhost> X-Mailer: Mulberry/3.1.0b7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: An overview of where the IETF change process is currently at X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Since Vienna, there have been a number of efforts started or continued to address some of the issues identified by the problem-statement working group. A number of these are at stages where they do not yet have visible output that we can review; however, it seems important to make sure the community knows about these efforts and can offer feedback and suggestions where helpful. To facilitate this interaction, I've put up an overview Web page at that attempts to give a broad overview of things going on. I intend to keep this page updated as we get more specific proposals and community engagement in the remaining months leading to our Minneapolis IETF meeting. This is the current snapshot. Enjoy! Harald Tveit Alvestrand From problem-statement-bounces@alvestrand.no Sun Sep 28 11:47:17 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22162 for ; Sun, 28 Sep 2003 11:47:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 706CA61BB3; Sun, 28 Sep 2003 17:46:53 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2FE4E61BA7; Sun, 28 Sep 2003 17:46:51 +0200 (CEST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h8SFklJs020593; Sun, 28 Sep 2003 08:46:48 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-43.cisco.com [10.32.241.43]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AMP21467; Sun, 28 Sep 2003 08:46:46 -0700 (PDT) Date: Sun, 28 Sep 2003 11:46:44 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Harald Tveit Alvestrand From: Melinda Shore In-Reply-To: <336146483.1064733126@localhost> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Subject: Re: An overview of where the IETF change process is currently at X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On Sunday, September 28, 2003, at 10:12 AM, Harald Tveit Alvestrand wrote: > To facilitate this interaction, I've put up an overview Web page at > that attempts to give > a broad overview of things going on. Thanks! It's very helpful. The working group is currently stymied on the question of how to proceed with longer-term organizational and process changes, and that's obviously not good. Avri and I need to talk some more about how to break the logjam but one thing that concerns me a great deal is how we're going to be able to come to consensus when there's strong opposition to pretty much every option that's been put forward. One thing we have discussed is that it may be useful to identify the characteristics that the process itself needs to have. While this may sound too process-heavy or too therapy-cultureish, I do think that it may help take some of the heat out of the discussion and provide some more objective criteria for discussing options moving forward (not to mention provide some operating parameters for whatever process is identified). If it appears that the discussion is unproductive or circular it will be stopped. Some of the characteristics that might be considered include things like whether or not it should be consensus-based, how transparent it should be, how the community should be able to provide input, and so on. What's important? What's not? Melinda From problem-statement-bounces@alvestrand.no Sun Sep 28 12:46:23 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23598 for ; Sun, 28 Sep 2003 12:46:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6FC1661BB3; Sun, 28 Sep 2003 18:45:59 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 33CD261BA7; Sun, 28 Sep 2003 18:45:56 +0200 (CEST) Date: Sun, 28 Sep 2003 09:44:59 -0700 From: Harald Tveit Alvestrand To: Melinda Shore Message-ID: <345317660.1064742299@localhost> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: problem-statement@alvestrand.no Subject: Re: An overview of where the IETF change process is currently at X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On 28. september 2003 11:46 -0400 Melinda Shore wrote: > On Sunday, September 28, 2003, at 10:12 AM, Harald Tveit Alvestrand wrote: >> To facilitate this interaction, I've put up an overview Web page at >> that attempts to give >> a broad overview of things going on. > > Thanks! It's very helpful. > > The working group is currently stymied on the question of how to > proceed with longer-term organizational and process changes, and > that's obviously not good. Avri and I need to talk some more > about how to break the logjam but one thing that concerns me a > great deal is how we're going to be able to come to consensus > when there's strong opposition to pretty much every option that's > been put forward. One thing we have discussed is that it may > be useful to identify the characteristics that the process itself > needs to have. While this may sound too process-heavy or too > therapy-cultureish, I do think that it may help take some of > the heat out of the discussion and provide some more objective > criteria for discussing options moving forward (not to mention > provide some operating parameters for whatever process is > identified). If it appears that the discussion is unproductive > or circular it will be stopped. this makes sense to me. For one thing, it is important for people to say WHY they object, not just that they object - and this approach seems able to capture some of that. There's always some reason for their objection - some property they want the process to have - and getting that formulated is important. > Some of the characteristics that might be considered include > things like whether or not it should be consensus-based, how > transparent it should be, how the community should be able to > provide input, and so on. What's important? What's not? I think we all agree that the process needs to come to the best conclusions for the Internet - that is, it needs to propose "high quality, timely process changes to facilitate making high quality, timely standards". Or something like that. The question is what properties it needs to have in order to achieve that. Harald From problem-statement-bounces@alvestrand.no Mon Sep 29 10:29:12 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17899 for ; Mon, 29 Sep 2003 10:29:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 309E161BDC; Mon, 29 Sep 2003 16:28:46 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from smail.alcatel.fr (colt-na165.alcatel.fr [62.23.212.165]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2D23761BB3; Mon, 29 Sep 2003 16:28:44 +0200 (CEST) Received: from frmail31.netfr.alcatel.fr (frmail31.netfr.alcatel.fr [155.132.251.42]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id h8TESg4W021396; Mon, 29 Sep 2003 16:28:43 +0200 To: Harald Tveit Alvestrand X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Alistair.Urie@alcatel.com Date: Mon, 29 Sep 2003 16:28:41 +0200 X-MIMETrack: Serialize by Router on FRMAIL31/FR/ALCATEL(Release 5.0.11 |July 24, 2002) at 09/29/2003 16:28:42 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new Cc: problem-statement@alvestrand.no, problem-statement-bounces@alvestrand.no Subject: Re: An overview of where the IETF change process is currently at X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Harlad, This is a good starting point. May I suggest that as soon as the problem-statement I-D passes last call (looks like my comments were the only ones made) then we cut the document into bits and then this chair/change-status page could become a set of pages, one per issue, each with: 1) Problem statement (as per last call text) 2) Approach 3) Status (no progress, in action, blocked, abandoned, completed) 4) Open issues or something like that. The change-status home page could then list the issues and give the status. Eventually everything would be listed as either Completed or abandoned.. - alistair Harald Tveit Alvestrand To: problem-statement@alvestrand.no Sent by: cc: problem-statement-bounces@al Subject: An overview of where the IETF change process is currently at vestrand.no 28/09/2003 16:12 Since Vienna, there have been a number of efforts started or continued to address some of the issues identified by the problem-statement working group. A number of these are at stages where they do not yet have visible output that we can review; however, it seems important to make sure the community knows about these efforts and can offer feedback and suggestions where helpful. To facilitate this interaction, I've put up an overview Web page at that attempts to give a broad overview of things going on. I intend to keep this page updated as we get more specific proposals and community engagement in the remaining months leading to our Minneapolis IETF meeting. This is the current snapshot. Enjoy! Harald Tveit Alvestrand From problem-statement-bounces@alvestrand.no Mon Sep 29 15:39:00 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06692 for ; Mon, 29 Sep 2003 15:39:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A113C61B8A; Mon, 29 Sep 2003 21:38:34 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0C71461B83 for ; Mon, 29 Sep 2003 21:38:30 +0200 (CEST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06624; Mon, 29 Sep 2003 15:38:18 -0400 (EDT) Message-Id: <200309291938.PAA06624@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: problem-statement@alvestrand.no From: Internet-Drafts@ietf.org Date: Mon, 29 Sep 2003 15:38:18 -0400 Subject: I-D ACTION:draft-ietf-problem-issue-statement-04.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Internet-Drafts@ietf.org List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Problem Statement Working Group of the IETF. Title : IETF Problem Statement Author(s) : E. Davies Filename : draft-ietf-problem-issue-statement-04.txt Pages : 26 Date : 2003-9-29 This memo summarizes perceived problems in the structure, function and processes of the Internet Engineering Task Force (IETF). We are attempting to identify these problems, so that they can be addressed and corrected by the IETF community. The problems have been digested and categorized from an extensive discussion which took place on the 'problem-statement' mailing list from November 2002 to September 2003. The problem list has been further analyzed to try and determine the root causes, that are at the heart of the perceived problems: The result will be used to guide the next stage of the process in the Problem Statement working group which is to recommend the structures and processes that will carry out the corrections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-problem-issue-statement-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-problem-issue-statement-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-problem-issue-statement-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-29153102.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-problem-issue-statement-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-problem-issue-statement-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-29153102.I-D@ietf.org> --OtherAccess-- --NextPart-- From problem-statement-bounces@alvestrand.no Tue Sep 30 06:52:14 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15850 for ; Tue, 30 Sep 2003 06:52:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D4EC161B93; Tue, 30 Sep 2003 12:51:49 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from znsgs01r.nortelnetworks.com (h12s128a211n47.user.nortelnetworks.com [47.211.128.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4F84061B8C for ; Tue, 30 Sep 2003 12:51:48 +0200 (CEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8UApk905346 for ; Tue, 30 Sep 2003 11:51:47 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Sep 2003 11:51:47 +0100 Message-ID: <4103264BC8D3D51180B7002048400C4501623805@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "IETF problem (problem-statement@alvestrand.no)" Date: Tue, 30 Sep 2003 11:51:44 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: New version (04) of Problem Issue Document on its way X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no I sent a new version (04) of the Problem Issue draft to the I-D editor yesterday. The changes deal with some issues raised during Last Call, especially by Andrew Urie and Thomas Narten. The major changes between versions 03 and 04 are: o Some text has been added to the second paragraph of the Introduction pointing out the increased complexity of the Internet and changed requirements of users. o The increased scope and complexity of the Internet are also mentioned to emphasise the context for a new mission for the IETF in Section 2.1. o Clarification added to Section 2.2 that it covers both technical and management techniques that are commonly accepted as helping the engineering process. o Bullet added to Section 2.2 noting lack of independent reviewers and lack of related topic review, especially early in the process. o Dependency Identification and Coordination processes added to list of project management techniques in Section 2.2 that are not well applied. Noted that these should apply both to other WGs and external SDOs. o Lack of awareness of interactions in today's more complex Internet emphasised in Section 2.3. o Problems with liaisons with other SDOs and the effect on ability to identify interactions added to Section 2.3. o 'Practices' replaced by 'Dynamics' in title of Section 2.7. o Connection of problems in Section 2.7 made to non-hierarchical and volunteer nature of IETF organisation. Solutions therefore cannot be achieved by simple process changes. o Additional point added to 'concensus by exhaustion' paragraph in Section 2.7: Mailing lists are at heart of WG process but are becoming increasingly ineffective at issue resolution. Regards, Elwyn Davies ---------------------------------------------------------------------------- ------ Elwyn B Davies Routing and Addressing Strategy Prime & IPv6 Core Team Leader CTO Office, Portfolio Integration Solutions Ready Nortel Networks plc Email: elwynd@nortelnetworks.com Harlow Laboratories ESN 6-742-5498 London Road, Harlow, Direct Line +44-1279-405498 Essex, CM17 9NA, UK Fax +44-1279-402047 Registered Office: Maidenhead Office Park, Westacott Way, Company No. 3937799 Maidenhead, Berkshire, SSL6 3QH ---------------------------------------------------------------------------- This message may contain information proprietary to Nortel Networks plc so any unauthorised disclosure, copying or distribution of its contents is strictly prohibited. ---------------------------------------------------------------------------- "The Folly is mostly mine" and the opinions are mine and not those of my employer. ============================================================================ ======