From problem-statement-bounces@alvestrand.no Sun Nov 2 16:34: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 QAA26178 for ; Sun, 2 Nov 2003 16:34:16 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9AB0361BDF; Sun, 2 Nov 2003 22:33:55 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by eikenes.alvestrand.no (Postfix) with ESMTP id 16AFE61B9A; Sun, 2 Nov 2003 22:33:53 +0100 (CET) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA2LXqF12859; Sun, 2 Nov 2003 23:33:52 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 2 Nov 2003 23:33:52 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 2 Nov 2003 15:33:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 2 Nov 2003 16:33:47 -0500 Message-ID: Thread-Topic: Proposed statement quotes wrong numbers Thread-Index: AcOcTAjU4nRN2fz/QF2A/BNNGoUZ4AAiStEgASzQMGA= From: To: , , , X-OriginalArrivalTime: 02 Nov 2003 21:33:48.0843 (UTC) FILETIME=[008E67B0:01C3A189] Subject: RE: Proposed statement quotes wrong numbers X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 > In fact, if you go back to the archives of the 1992=20 > discussions, it was perceived then that the previous=20 > structure did not scale. For example, the IAB was in=20 > charge of reviewing every RFC before it could be > published, and as the number of WG increased that=20 > became a bottleneck. A lot of the 1992 effort was about=20 > designing a structure that would scale better -- i.e.=20 > scale for much more than the 600-700 participants at the > time. In what way is the current structure substantially different from this? Instead of the IAB, the IESG now reviews every IETF-produced RFC before it is=20 published, and we also manage the WGs. My understanding is that the primary effect of the 1992 change was to unite document review (which had been done by the IAB) and WG/process management (which had been done by the IESG) in a single group (the IESG). How would that improve scaling? Margaret =20 From problem-statement-bounces@alvestrand.no Mon Nov 3 08:23: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 IAA00942 for ; Mon, 3 Nov 2003 08:23:05 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4055961BAE; Mon, 3 Nov 2003 14:22:42 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by eikenes.alvestrand.no (Postfix) with ESMTP id C02D161B9D; Mon, 3 Nov 2003 14:22:39 +0100 (CET) Received: from tsg (33.sanjose-08-09rs16rt.ca.dial-access.att.net[12.81.3.33]) by worldnet.att.net (mtiwmhc13) with SMTP id <200311031322341130086dp2e>; Mon, 3 Nov 2003 13:22:36 +0000 Message-ID: <011c01c3a20c$e6edd780$010aff0a@tsg> From: "todd glassey" To: , , , , References: Date: Mon, 3 Nov 2003 05:17:56 -0800 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 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Subject: Re: Proposed statement quotes wrong numbers X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 One thing that would surely help would be the merging of the IESG and the IETF into as seamless entity. This magic handwaving distance between the two entities is an issue these days. Todd ----- Original Message ----- From: To: ; ; ; Sent: Sunday, November 02, 2003 1:33 PM Subject: RE: Proposed statement quotes wrong numbers > In fact, if you go back to the archives of the 1992 > discussions, it was perceived then that the previous > structure did not scale. For example, the IAB was in > charge of reviewing every RFC before it could be > published, and as the number of WG increased that > became a bottleneck. A lot of the 1992 effort was about > designing a structure that would scale better -- i.e. > scale for much more than the 600-700 participants at the > time. In what way is the current structure substantially different from this? Instead of the IAB, the IESG now reviews every IETF-produced RFC before it is published, and we also manage the WGs. My understanding is that the primary effect of the 1992 change was to unite document review (which had been done by the IAB) and WG/process management (which had been done by the IESG) in a single group (the IESG). How would that improve scaling? Margaret From problem-statement-bounces@alvestrand.no Mon Nov 3 09:45: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 JAA04014 for ; Mon, 3 Nov 2003 09:45:45 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B845C61B9D; Mon, 3 Nov 2003 15:45:23 +0100 (CET) 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 BB1DD61B8D for ; Mon, 3 Nov 2003 15:45:17 +0100 (CET) Received: from znsgs01r.nortelnetworks.com (znsgs01r.europe.nortel.com [47.166.48.91] (may be forged)) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hA3EjFX05765 for ; Mon, 3 Nov 2003 15:45:15 +0100 (MET) 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 hA3EjEM14886 for ; Mon, 3 Nov 2003 14:45:14 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Nov 2003 14:45:14 -0000 Message-ID: <4103264BC8D3D51180B7002048400C45043ABB6D@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "IETF problem (problem-statement@alvestrand.no)" Date: Mon, 3 Nov 2003 14:45:12 -0000 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: New versions of issues and process drafts X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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. New versions of the two problem drafts have been sent to the I-D editor but they haven't made it to the IETF server yet. They are: draft-ietf-problem-issue-summary-05.txt draft-ietf-problem-process-03.txt In the meantime they can be accessed here: http://www.alvestrand.no/ietf/gen/ FYI, the changes are: [issue summary] 1.8 Major Changes between Versions 04 and 05 o Added a bullet in Section 2.2 indicating lack of documentation of potential protocol interactions. o Two bullet points have been merged in Section 2.2 relating to the need for metrics and 'post mortem' reviews to improve processes. o In Section 2.3 Pointed out the probable connection between inadequate external review and late detection of interactions. o The last paragraphs of Section 2.6.4 and Section 2.6.5 have been toned down. o The lack of a process to nominate a stand-in for a temporarily incapacitated AD has been noted in Section 2.6.2. o Various spelling and grammatical errors have been fixed and some phraseology cleaned up. [process] 1.3 Major Changes between Versions 02 and 03 The draft now lists the various suggestions that have been floated as ways forward for the structural changes problems, documents the inability of the community to achieve consensus around any of these proposals and suggests that the problem is remitted to the control of the IESG. Regards, Elwyn ---------------------------------------------------------------------------- ------ 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. ============================================================================ ====== From problem-statement-bounces@alvestrand.no Mon Nov 3 12:19: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 MAA11205 for ; Mon, 3 Nov 2003 12:19:25 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8A16662250; Mon, 3 Nov 2003 18:19:04 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from i2kc05-ukbr.domain1.systemhost.net (unknown [217.32.164.139]) by eikenes.alvestrand.no (Postfix) with ESMTP id 49EC76224D; Mon, 3 Nov 2003 18:19:02 +0100 (CET) Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by i2kc05-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 3 Nov 2003 17:19:01 +0000 Received: from i2km02-ukbr.domain1.systemhost.net ([193.113.197.79]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 3 Nov 2003 17:19:01 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Nov 2003 17:19:01 -0000 Message-ID: <3D67CCA7D63E714B980D21A038EEA08E045A2B5D@i2km02-ukbr.domain1.systemhost.net> Thread-Topic: IESG proposed statement on the IETF mission Thread-Index: AcOeNvBq4xaWo3ffR+mLJh3CNUZKHwD94S0A From: To: X-OriginalArrivalTime: 03 Nov 2003 17:19:01.0592 (UTC) FILETIME=[930EC580:01C3A22E] Cc: problem-statement@alvestrand.no, harald@alvestrand.no Subject: RE: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 Scott, How are you interpreting "has to" ? Are you implying that IP can't run = without MPLS (for example) ? 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. =20 =20 -----Original Message----- From: Scott W Brim [mailto:swb@employees.org] Sent: 29 October 2003 16:09 To: Brian E Carpenter Cc: Harald Tveit Alvestrand; problem-statement@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission On Wed, Oct 29, 2003 04:13:20PM +0100, Brian E Carpenter allegedly = wrote: > The IETF covers a wide range of technical areas and it is impossible > to set fully objective boundaries that allow an algorithmic answer to > the question whether a particular item is within the IETF's technical > scope. However, it can be stated that IETF work items are always > concerned with either the Internet Protocol layer itself (Layer 3 in > the ISO/OSI Reference Model), with its management and routing, with > transport protocols (Layer 4) that may seriously impact the correct > functioning of the IP layer, or with direct uses of the transport > layer that provide generic services. Security mechanisms for all of > the above are also in scope. >=20 > Transmission technologies below Layer 3, and upper layer protocols > that are not generic in nature, are generally out of scope. Also, > tightly integrated suites of generic upper layer protocols (for > example, the Web Services protocols) may be more appropriately > specified by a dedicated standards body. Corollary: Anything that has to run everywhere IP runs. This pulls in protocols which need to establish state at every IP hop, not just waypoints (e.g. application proxies). The one that's on my mind is MPLS. From problem-statement-bounces@alvestrand.no Mon Nov 3 12:32: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 MAA11591 for ; Mon, 3 Nov 2003 12:32:14 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3AF89622FC; Mon, 3 Nov 2003 18:31:53 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by eikenes.alvestrand.no (Postfix) with ESMTP id D36536220A; Mon, 3 Nov 2003 18:31:50 +0100 (CET) Received: from cisco.com (sjc-vpn4-318.cisco.com [10.21.81.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with SMTP id hA3HVknj026057; Mon, 3 Nov 2003 09:31:47 -0800 (PST) Received: by cisco.com (sSMTP sendmail emulation); Mon, 3 Nov 2003 12:31:44 -0500 Date: Mon, 3 Nov 2003 12:31:44 -0500 From: Scott W Brim To: graham.travers@bt.com Message-ID: <20031103173144.GJ2720@sbrim-w2k01> Mail-Followup-To: Scott W Brim , graham.travers@bt.com, problem-statement@alvestrand.no, harald@alvestrand.no References: <3D67CCA7D63E714B980D21A038EEA08E045A2B5D@i2km02-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D67CCA7D63E714B980D21A038EEA08E045A2B5D@i2km02-ukbr.domain1.systemhost.net> User-Agent: Mutt/1.4.1i Cc: problem-statement@alvestrand.no, harald@alvestrand.no Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 On Mon, Nov 03, 2003 05:19:01PM -0000, graham.travers@bt.com allegedly wrote: > Scott, > > How are you interpreting "has to" ? Are you implying that IP can't run without MPLS (for example) ? I see the ambiguity. I meant, if this protocol (suite) is run at all, it needs to be run on all the intervening nodes at the IP layer. It isn't one that just establishes state in edge nodes, or proxies, via a TCP exchange. A protocol like that should be dealt with in the IETF because if it's used at all it needs to be part of the Internet infrastructure just as much as IP is. ..Scott > On Wed, Oct 29, 2003 04:13:20PM +0100, Brian E Carpenter allegedly wrote: > > The IETF covers a wide range of technical areas and it is impossible > > to set fully objective boundaries that allow an algorithmic answer to > > the question whether a particular item is within the IETF's technical > > scope. However, it can be stated that IETF work items are always > > concerned with either the Internet Protocol layer itself (Layer 3 in > > the ISO/OSI Reference Model), with its management and routing, with > > transport protocols (Layer 4) that may seriously impact the correct > > functioning of the IP layer, or with direct uses of the transport > > layer that provide generic services. Security mechanisms for all of > > the above are also in scope. > > > > Transmission technologies below Layer 3, and upper layer protocols > > that are not generic in nature, are generally out of scope. Also, > > tightly integrated suites of generic upper layer protocols (for > > example, the Web Services protocols) may be more appropriately > > specified by a dedicated standards body. > > Corollary: Anything that has to run everywhere IP runs. This pulls in > protocols which need to establish state at every IP hop, not just > waypoints (e.g. application proxies). The one that's on my mind is > MPLS. > From problem-statement-bounces@alvestrand.no Mon Nov 3 15:56: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 PAA20955 for ; Mon, 3 Nov 2003 15:56:38 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1722B62392; Mon, 3 Nov 2003 21:56:17 +0100 (CET) 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 EC76062391 for ; Mon, 3 Nov 2003 21:56:14 +0100 (CET) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20916; Mon, 3 Nov 2003 15:56:04 -0500 (EST) Message-Id: <200311032056.PAA20916@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, 03 Nov 2003 15:56:04 -0500 Subject: I-D ACTION:draft-ietf-problem-process-03.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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-03.txt Pages : 22 Date : 2003-11-3 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-problem-process-03.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-03.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-03.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-11-3161803.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-problem-process-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-problem-process-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-3161803.I-D@ietf.org> --OtherAccess-- --NextPart-- From problem-statement-bounces@alvestrand.no Mon Nov 3 18:12: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 SAA02164 for ; Mon, 3 Nov 2003 18:12:03 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1941461B8D; Tue, 4 Nov 2003 00:11:43 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by eikenes.alvestrand.no (Postfix) with ESMTP id F051161AD5 for ; Tue, 4 Nov 2003 00:11:39 +0100 (CET) Message-ID: <058a01c3a25f$e1ef3910$9f6015ac@dclkempt40> From: "James Kempf" To: Date: Mon, 3 Nov 2003 15:11:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Review Board Draft X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 Don't recall if a notice was posted, but Mark Allman and I wrote a draft about using Review Boards to review WG work. It is meant as a compliment to the SIRS work. The draft is draft-allman-problem-wg-revcomm-00.txt. jak From problem-statement-bounces@alvestrand.no Mon Nov 3 21:18:18 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 VAA09266 for ; Mon, 3 Nov 2003 21:18:18 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D378E61B8D; Tue, 4 Nov 2003 03:17:56 +0100 (CET) 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 424B061AD5 for ; Tue, 4 Nov 2003 03:17:55 +0100 (CET) Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGqlV-000DKi-O0 for problem-statement@alvestrand.no; Tue, 04 Nov 2003 02:17:54 +0000 Date: Tue, 4 Nov 2003 11:17:52 +0900 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Avri Doria To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit In-Reply-To: <058a01c3a25f$e1ef3910$9f6015ac@dclkempt40> Message-Id: <1803657C-0E6D-11D8-A5B8-000393CC2112@acm.org> X-Mailer: Apple Mail (2.552) Subject: Re: Review Board Draft X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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, Wouldn't these both be more for the solutions list? thanks a. On tisdag, nov 4, 2003, at 08:11 Asia/Seoul, James Kempf wrote: > Don't recall if a notice was posted, but Mark Allman and I wrote a > draft > about using Review Boards to review WG work. It is meant as a > compliment to > the SIRS work. The draft is draft-allman-problem-wg-revcomm-00.txt. > > jak > > From problem-statement-bounces@alvestrand.no Thu Nov 6 11:03:04 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 LAA15192 for ; Thu, 6 Nov 2003 11:03:03 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BA21261BDE; Thu, 6 Nov 2003 17:02:43 +0100 (CET) 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 B4A0A61BB5 for ; Thu, 6 Nov 2003 17:02:41 +0100 (CET) Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 Nov 2003 08:07:30 -0800 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 hA6G2dw5023496 for ; Thu, 6 Nov 2003 08:02:39 -0800 (PST) Received: from cisco.com ([10.25.65.178]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANY33383; Thu, 6 Nov 2003 08:02:38 -0800 (PST) Date: Thu, 6 Nov 2003 11:02:35 -0500 Mime-Version: 1.0 (Apple Message framework v552) 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.552) Subject: Process document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 We've been trying to decide how to move forward with the process recommendations document, given the difficulty of having the group come to consensus on a recommendation, etc. What we've decided is probably the best way forward is to produce a document that describes what's been proposed and not agreed to, largely as a matter of historical record but also as a resource for those who work on process changes in the months to come. This is one of the thing we'll be discussing next week in Minneapolis, but obviously it needs a heads-up here, as well. Melinda From problem-statement-bounces@alvestrand.no Thu Nov 6 11:05: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 LAA15319 for ; Thu, 6 Nov 2003 11:05:38 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 262FF61BB5; Thu, 6 Nov 2003 17:05:19 +0100 (CET) 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 7E0A461BB4 for ; Thu, 6 Nov 2003 17:05:15 +0100 (CET) Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 06 Nov 2003 08:06:00 -0800 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 hA6G5CmU008133 for ; Thu, 6 Nov 2003 08:05:13 -0800 (PST) Received: from cisco.com ([10.25.65.178]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANY33665; Thu, 6 Nov 2003 08:05:11 -0800 (PST) Date: Thu, 6 Nov 2003 11:05:08 -0500 Mime-Version: 1.0 (Apple Message framework v552) 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.552) Subject: Fwd: Draft Agenda X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 Many apologies for being remiss about getting out a draft agenda. Here's what's planned so far for the session next week. Please let us know if we've missed something, or if you've got additional agenda items to propose. Melinda > - Review of changes made in draft-ietf-issue-summary-05 > > Discussion of Plans for second LC > > Open Issues? > Structure of document > Choice of language in document > Ordering of issues in the document > > Acceptable mix of problems > Acceptable list of root Causes > > > - Review of changes made in draft-ietf-problem-process-03 > > Discussion of decision to list alternative discussed as opposed > to drive to consensus > > Discussion of plans for LC > > Discussion of plans to ask the group be closed > From problem-statement-bounces@alvestrand.no Thu Nov 6 15:11: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 PAA27212 for ; Thu, 6 Nov 2003 15:11:50 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A4CA661BB5; Thu, 6 Nov 2003 21:11:29 +0100 (CET) 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 152C161BAE for ; Thu, 6 Nov 2003 21:11:28 +0100 (CET) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27150; Thu, 6 Nov 2003 15:11:15 -0500 (EST) Message-Id: <200311062011.PAA27150@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: Thu, 06 Nov 2003 15:11:15 -0500 Subject: I-D ACTION:draft-ietf-problem-issue-statement-05.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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-05.txt Pages : 26 Date : 2003-11-6 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-05.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-05.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-05.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-11-6131147.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-problem-issue-statement-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-problem-issue-statement-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-6131147.I-D@ietf.org> --OtherAccess-- --NextPart-- From problem-statement-bounces@alvestrand.no Mon Nov 10 04:26:34 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 EAA13750 for ; Mon, 10 Nov 2003 04:26:33 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 222B361AD5; Mon, 10 Nov 2003 10:26:14 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from smail.alcatel.fr (gc-na165.alcatel.fr [64.208.49.165]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6592E61AA5 for ; Mon, 10 Nov 2003 10:26:12 +0100 (CET) Received: from frmail31.netfr.alcatel.fr (frmail31.netfr.alcatel.fr [155.132.251.42]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id hAA9Q74I010186; Mon, 10 Nov 2003 10:26:07 +0100 To: Melinda Shore X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Alistair.Urie@alcatel.com Date: Mon, 10 Nov 2003 10:26:05 +0100 X-MIMETrack: Serialize by Router on FRMAIL31/FR/ALCATEL(Release 5.0.11 |July 24, 2002) at 11/10/2003 10:26:07 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new Cc: problem-statement@alvestrand.no Subject: Re: Process document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 Melinda, Good luck with putting this last issue "to bed" and hence to a successful closure of the WG. Unfortunately I can not attend this IETF meeting but I offer an alternative you might want to consider: Why not drop the Process document completely and replace it with a set of web pages? The problem with the problem statement process document is that the "process" to resolve each root clause problem will evolve with time and each issue will become a fairly independent topic. If we want to maintain this process document as a consolidated text then it can never to "closed" since there will alway be one last issue to deal with. The alternative, of using the web to document the current view on decomposition, proposed way forward and status for each topic, would offer everyone a better visibility of progress and allow each issue to be progressed independently. what we would need is a home page providing the root clause list, a set of pages defining the decomposition and then a final set of pages giving status on each topic. The existing process draft could easily become the base text for this set of pages. A "new" process I-D could then simply define that this is the "process" we will use. - Alistair Melinda Shore To: problem-statement@alvestrand.no Sent by: cc: problem-statement-bounces@al Subject: Process document vestrand.no 06/11/2003 17:02 We've been trying to decide how to move forward with the process recommendations document, given the difficulty of having the group come to consensus on a recommendation, etc. What we've decided is probably the best way forward is to produce a document that describes what's been proposed and not agreed to, largely as a matter of historical record but also as a resource for those who work on process changes in the months to come. This is one of the thing we'll be discussing next week in Minneapolis, but obviously it needs a heads-up here, as well. Melinda From problem-statement-bounces@alvestrand.no Tue Nov 11 09:36:21 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 JAA02363 for ; Tue, 11 Nov 2003 09:36:21 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6844F61B9C; Tue, 11 Nov 2003 15:36:00 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 58DB861B95; Tue, 11 Nov 2003 15:35:57 +0100 (CET) Date: Tue, 11 Nov 2003 08:35:56 -0600 From: Harald Tveit Alvestrand To: Alistair.Urie@alcatel.com, Melinda Shore Message-ID: <82337214.1068539756@halvestr-w2k1> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b9 (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: Process document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 Alistar, http://www.ietf.org/u/ietfchair/change-status.html (always in need of updates) Publication of an RFC is suggested for preservation of ideas at this time. --On 10. november 2003 10:26 +0100 Alistair.Urie@alcatel.com wrote: > > Melinda, > Good luck with putting this last issue "to bed" and hence to a successful > closure of the WG. Unfortunately I can not attend this IETF meeting but I > offer an alternative you might want to consider: > > Why not drop the Process document completely and replace it with a set of > web pages? From problem-statement-bounces@alvestrand.no Tue Nov 11 21:35:22 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 VAA04623 for ; Tue, 11 Nov 2003 21:35:22 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EA4AC61B9F; Wed, 12 Nov 2003 03:35:01 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0633861B95; Wed, 12 Nov 2003 03:34:59 +0100 (CET) Date: Tue, 11 Nov 2003 20:34:47 -0600 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no, solutions@alvestrand.no Message-ID: <35671993.1068582887@localhost> X-Mailer: Mulberry/3.1.0b9 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Slides for Wednesday's plenary available (fwd) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 This could be of particular interest to the problem-statement and solutions lists.... ---------- Forwarded Message ---------- Date: 11. november 2003 18:31 -0600 From: Harald Tveit Alvestrand To: ietf@ietf.org Subject: Slides for Wednesday's plenary available A good deal of the slideware material for Wednesday's plenary is now available from the following URL: This includes an overview of the report from the Advisory Committee about IETF organization, and the presentations from the IESG about proposals for changes to the IETF processes to solve some of the problems identified by the problem-statement WG's output. We apologize for publishing this information so late, but can only plead lateness in getting to this point - we've been literally working on this right up to the last minute! Comments are welcome, of course - the Wednesday plenary will be mostly devoted to presenting the proposals, and mostly addressing questions that have to do with clarifying what's being intended - on Thursday, the proposals - and what else we need to do - is, of course, going to be a main topic in the open IESG and IAB sessions. Welcome to the plenaries! Harald Alvestrand _______________________________________________ This message was passed through ietf_censored@carmen.ipv6.cselt.it, which is a sublist of ietf@ietf.org. Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator (ietf_admin@ngnet.it). ---------- End Forwarded Message ---------- From problem-statement-bounces@alvestrand.no Wed Nov 12 10:33: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 KAA22326 for ; Wed, 12 Nov 2003 10:33:52 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 754EA61BAB; Wed, 12 Nov 2003 16:33:32 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from newdev (newdev.eecs.harvard.edu [140.247.60.212]) by eikenes.alvestrand.no (Postfix) with ESMTP id A4D3061BA0; Wed, 12 Nov 2003 16:33:30 +0100 (CET) Received: by newdev (Postfix, from userid 501) id 4692A753DD; Wed, 12 Nov 2003 10:33:24 -0500 (EST) To: problem-statement@alvestrand.no, solutions@alvestrand.no Message-Id: <20031112153324.4692A753DD@newdev> Date: Wed, 12 Nov 2003 10:33:24 -0500 (EST) From: sob@harvard.edu (Scott Bradner) Subject: agenda for newtrk BOF X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 THURSDAY, November 13, 2003 1530-1730 Afternoon Sessions II Salon C GEN newtrk New IETF Standards Track Discussion BOF * ------ CHAIRS: Scott Bradner DESCRIPTION: The consensus in the problem working group is that the current IETF 3- stage standards track described in RFC 2026 [RFC2026] is not working as originally intended. The draft problem statement document says: "The current hierarchy of Proposed, Draft and Full Standard maturity levels for specifications is no longer being used in the way that was envisioned when the stratification was originally proposed. In practice, the IETF currently has a one-step standards process that subverts the IETF's preference for demonstrating effectiveness through running code in multiple interoperable implementations and compresses the process that previously allowed specifications to mature as experience was gained with actual implementations:" The draft document then goes on to list 4 observations: 1/ few documents actually progress after being published as PS 2/ there is a perception that the IESG raised the quality requirement 3/ in spite of the raised quality requirement, running code is not required 4/ there seems to be a reinforcing feedback loop involved: vendors implement and deploy PS documents so the IESG tries to make the PS documents better The draft problem document concludes that the 3-stage process is excessive. This BOF will discuss the observation that the current IETF 3-stage standards track is not working and discuss options for different standards track processes. Expected output of BOF: 1/ criteria for declaring "success" for a new IETF standards track 2/ next steps AGENDA: 1/ description of current IETF Standards Track 2/ observations from problem working group 3/ what other SDOs do 4/ proposals for alternate standards track processes 5/ what would define success in a revised IETF Standards track 6/ open discussion Reading List: draft-ietf-problem-issue-statement-04.txt draft-dawkins-pstmt-twostage-01.txt draft-bradner-ietf-stds-trk-00.txt draft-iesg-hardie-outline-00.txt draft-loughney-what-standards-00.txt --7B8F77539D.1068650916/newdev-- From problem-statement-bounces@alvestrand.no Wed Nov 12 11:42: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 LAA26385 for ; Wed, 12 Nov 2003 11:42:37 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8327961BA0; Wed, 12 Nov 2003 17:42:17 +0100 (CET) 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 43D3161B8F; Wed, 12 Nov 2003 17:42:14 +0100 (CET) Received: from dyn134-101.ietf58.ietf.org (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hACGlVf27259; Wed, 12 Nov 2003 08:47:32 -0800 Date: Wed, 12 Nov 2003 10:43:29 -0600 From: Dave Crocker X-Mailer: The Bat! (v2.00.22) Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <5238316315.20031112104329@brandenburg.com> To: sob@harvard.edu (Scott Bradner) In-Reply-To: <20031112152800.7B8F77539D@newdev> References: <20031112152800.7B8F77539D@newdev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no, solutions@alvestrand.no, ietf@ietf.org Subject: Re: agenda for newtrk BOF X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 Scott, SB> 1/ description of current IETF Standards Track SB> 2/ observations from problem working group SB> 3/ what other SDOs do SB> 4/ proposals for alternate standards track processes SB> 5/ what would define success in a revised IETF Standards track SB> 6/ open discussion Good list. I hope that items 1-3 are will be only very brief reviews, rather than taking time or debating energy. This will leave both time and debating energy for the proposals and the very interesting item #5. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From problem-statement-bounces@alvestrand.no Thu Nov 13 16:55:52 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 QAA22621 for ; Thu, 13 Nov 2003 16:55:51 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BFC8A61B9A; Thu, 13 Nov 2003 22:55:31 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtagate5.de.ibm.com (mtagate5.de.ibm.com [195.212.29.154]) by eikenes.alvestrand.no (Postfix) with ESMTP id EC05661B83 for ; Thu, 13 Nov 2003 22:55:29 +0100 (CET) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id hADLtSXP057284 for ; Thu, 13 Nov 2003 21:55:29 GMT 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 hADLtSw2279216 for ; Thu, 13 Nov 2003 22:55:28 +0100 Received: from zurich.ibm.com ([9.145.244.71]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id WAA51434 for ; Thu, 13 Nov 2003 22:55:26 +0100 Message-ID: <3FB3FDA7.ACC08F4E@zurich.ibm.com> Date: Thu, 13 Nov 2003 22:54:47 +0100 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: <3D67CCA7D63E714B980D21A038EEA08E045A2B5D@i2km02-ukbr.domain1.systemhost.net> <20031103173144.GJ2720@sbrim-w2k01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: IESG proposed statement on the IETF mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 don't think we can write this sort of text without weasel words and leaving some room for interpretation. Therefore, I don't worry too much about it being 100% complete and consistent. Brian Scott W Brim wrote: > > On Mon, Nov 03, 2003 05:19:01PM -0000, graham.travers@bt.com allegedly wrote: > > Scott, > > > > How are you interpreting "has to" ? Are you implying that IP can't run without MPLS (for example) ? > > I see the ambiguity. I meant, if this protocol (suite) is run at all, > it needs to be run on all the intervening nodes at the IP layer. It > isn't one that just establishes state in edge nodes, or proxies, via a > TCP exchange. A protocol like that should be dealt with in the IETF > because if it's used at all it needs to be part of the Internet > infrastructure just as much as IP is. > > ..Scott > > > On Wed, Oct 29, 2003 04:13:20PM +0100, Brian E Carpenter allegedly wrote: > > > The IETF covers a wide range of technical areas and it is impossible > > > to set fully objective boundaries that allow an algorithmic answer to > > > the question whether a particular item is within the IETF's technical > > > scope. However, it can be stated that IETF work items are always > > > concerned with either the Internet Protocol layer itself (Layer 3 in > > > the ISO/OSI Reference Model), with its management and routing, with > > > transport protocols (Layer 4) that may seriously impact the correct > > > functioning of the IP layer, or with direct uses of the transport > > > layer that provide generic services. Security mechanisms for all of > > > the above are also in scope. > > > > > > Transmission technologies below Layer 3, and upper layer protocols > > > that are not generic in nature, are generally out of scope. Also, > > > tightly integrated suites of generic upper layer protocols (for > > > example, the Web Services protocols) may be more appropriately > > > specified by a dedicated standards body. > > > > Corollary: Anything that has to run everywhere IP runs. This pulls in > > protocols which need to establish state at every IP hop, not just > > waypoints (e.g. application proxies). The one that's on my mind is > > MPLS. From problem-statement-bounces@alvestrand.no Mon Nov 17 12:06:52 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 MAA21662 for ; Mon, 17 Nov 2003 12:06:51 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B830A61B97; Mon, 17 Nov 2003 18:06:32 +0100 (CET) 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 6AF0361B92 for ; Mon, 17 Nov 2003 18:06:31 +0100 (CET) Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 17 Nov 2003 09:14:32 -0800 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 hAHH6RAt015441 for ; Mon, 17 Nov 2003 09:06:28 -0800 (PST) Received: from cisco.com ([10.25.65.179]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AOH34955; Mon, 17 Nov 2003 09:06:26 -0800 (PST) Date: Mon, 17 Nov 2003 12:06:25 -0500 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: <60B4EEDF-1920-11D8-976B-000A95E35274@cisco.com> X-Mailer: Apple Mail (2.552) Subject: WG last call - problem description document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 This is to announce the beginning of working group last call for "IETF Problem Statement" (http://www.ietf.org/internet-drafts/draft-ietf-problem-issue- statement-05.txt). Last call closes on Monday, 24 November 2003. Please send comments to the mailing, and note that we're not kidding about the closing date. Melinda From problem-statement-bounces@alvestrand.no Mon Nov 17 12:09:21 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 MAA22098 for ; Mon, 17 Nov 2003 12:09:20 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A7EA061B97; Mon, 17 Nov 2003 18:09:01 +0100 (CET) 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 18BEF61B90 for ; Mon, 17 Nov 2003 18:08:59 +0100 (CET) Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 17 Nov 2003 09:16:59 -0800 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 hAHH8uAt018903 for ; Mon, 17 Nov 2003 09:08:56 -0800 (PST) Received: from cisco.com ([10.25.65.179]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AOH35203; Mon, 17 Nov 2003 09:08:54 -0800 (PST) Date: Mon, 17 Nov 2003 12:08:54 -0500 Mime-Version: 1.0 (Apple Message framework v552) 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.552) Subject: WG last call - process document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 This is to announce the start of working group last call for "IETF Problem Resolution Process" (http://www.ietf.org/internet-drafts/draft-ietf-problem-process-03.txt). Last call closes on Monday, 1 December 2003. Please send any comments to the mailing list before last call closes. Melinda From problem-statement-bounces@alvestrand.no Tue Nov 18 10:12: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 KAA24663 for ; Tue, 18 Nov 2003 10:12:05 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0E2A161B91; Tue, 18 Nov 2003 16:11:45 +0100 (CET) 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 290C761B91 for ; Tue, 18 Nov 2003 16:11:42 +0100 (CET) Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 18 Nov 2003 07:15:16 -0800 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 hAIFBdw5018718 for ; Tue, 18 Nov 2003 07:11:40 -0800 (PST) Received: from cisco.com ([10.25.65.179]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AOI37857; Tue, 18 Nov 2003 07:08:21 -0800 (PST) Date: Tue, 18 Nov 2003 10:08:19 -0500 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Melinda Shore To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit Message-Id: <0B079242-19D9-11D8-976B-000A95E35274@cisco.com> X-Mailer: Apple Mail (2.552) Subject: Fwd: problem minutes X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 Here's a draft of the minutes from last week's meetings. Please post corrections, etc. to the mailing list. Many thanks to Scott Bradner for taking the notes. Melinda > The Problem WG met from 1pm to 3pm on Wednesday November 12th 2003. > > The issues document: > The changes to the issues document between version 4 and version 5 were > reviewed. The proposed fixes to the document based on the issues > raised > during the WG last call were reviewed. No one had any objection to the > proposed fixes. > > The list of open issues were raised and discussed. No one felt that > the > document needed to be changed because of these issues. > > The chair asked if there were any objections to taking version 5 to a > second (one week) WG last call, after which it would be forwarded to > the > General AD for consideration for publication as an Informational RFC. > The > General AD asked if the working group felt that there should be an IETF > Last-Call for this document. The sense of the room was that it should. > > The process document: > The chair asked if the working group felt that it would be OK if the > process document could list alternative paths forward with a note to > say > that the working group was not able to reach consensus on any > particular > path. No one had any problem with closing the document in this way. > Joel > Halprin asked if the document should be published as an RFC at all. > After > discussion the sense of the room was that the process document should > be > published as an informational RFC. > > The future of the working group > The chairs asked if the working group should be closed since its work > was > done when the two documents were sent to the General AD. The sense of > the > room was that it should be closed. > From problem-statement-bounces@alvestrand.no Tue Nov 18 10:24: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 KAA25566 for ; Tue, 18 Nov 2003 10:24:06 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8F6DD61B91; Tue, 18 Nov 2003 16:23:46 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtagate2.de.ibm.com (mtagate2.de.ibm.com [195.212.29.151]) by eikenes.alvestrand.no (Postfix) with ESMTP id A0E1961B89 for ; Tue, 18 Nov 2003 16:23:44 +0100 (CET) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAIFNcHf024110; Tue, 18 Nov 2003 15:23:40 GMT 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 hAIFJf9f127132; Tue, 18 Nov 2003 16:19:41 +0100 Received: from zurich.ibm.com (sig-9-145-225-82.de.ibm.com [9.145.225.82]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA65702; Tue, 18 Nov 2003 16:19:39 +0100 Message-ID: <3FBA3864.1034325D@zurich.ibm.com> Date: Tue, 18 Nov 2003 16:19:00 +0100 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: Melinda Shore References: <60B4EEDF-1920-11D8-976B-000A95E35274@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: WG last call - problem description document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 Just ship it. We could spend 5 years improving it, but the need for action is now and it just isn't worth further tuning. Brian Melinda Shore wrote: > > This is to announce the beginning of working group last call for > "IETF Problem Statement" > (http://www.ietf.org/internet-drafts/draft-ietf-problem-issue- > statement-05.txt). > Last call closes on Monday, 24 November 2003. Please send comments to > the mailing, and note that we're not kidding about the closing date. > > Melinda From problem-statement-bounces@alvestrand.no Tue Nov 18 10:24:22 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 KAA25591 for ; Tue, 18 Nov 2003 10:24:22 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E532861BD7; Tue, 18 Nov 2003 16:24:02 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtagate2.de.ibm.com (mtagate2.de.ibm.com [195.212.29.151]) by eikenes.alvestrand.no (Postfix) with ESMTP id CB6A361BB9 for ; Tue, 18 Nov 2003 16:24:00 +0100 (CET) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAIFNuHf009890; Tue, 18 Nov 2003 15:23:56 GMT 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 hAIFKt9f237428; Tue, 18 Nov 2003 16:20:55 +0100 Received: from zurich.ibm.com (sig-9-145-225-82.de.ibm.com [9.145.225.82]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA65748; Tue, 18 Nov 2003 16:20:54 +0100 Message-ID: <3FBA38AE.E4EF0BAC@zurich.ibm.com> Date: Tue, 18 Nov 2003 16:20:14 +0100 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: Melinda Shore References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: WG last call - process document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 Personally I would abandon the document, but I have no objection to it being published as a record of discussion. Brian Melinda Shore wrote: > > This is to announce the start of working group last call for > "IETF Problem Resolution Process" > (http://www.ietf.org/internet-drafts/draft-ietf-problem-process-03.txt). > Last call closes on Monday, 1 December 2003. Please send any > comments to the mailing list before last call closes. > > Melinda From problem-statement-bounces@alvestrand.no Tue Nov 18 10:56:04 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 KAA27056 for ; Tue, 18 Nov 2003 10:56:03 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 70D0C61BA7; Tue, 18 Nov 2003 16:55:44 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from netcore.fi (netcore.fi [193.94.160.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F2D5361B89 for ; Tue, 18 Nov 2003 16:55:42 +0100 (CET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAIFtga22564 for ; Tue, 18 Nov 2003 17:55:42 +0200 Date: Tue, 18 Nov 2003 17:55:42 +0200 (EET) From: Pekka Savola To: problem-statement@alvestrand.no Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Concrete example of editor/WG inefficiencies X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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, When helping Bert/Randy to review documents at the IESG through ops-dir, Bert stated that we should focus on major issues (while nits etc. would be OK as well, but whether they'd be fixed would be up to the authors etc.). I hope I interpreted that well. The reasons for this stance were (quoting Bert, with permission): - some editors/authors seem to need long turnaround times for even the simplest changes - when you let them make changes, the WG-chairs and ADs need to check that they made them correctly and did not sneak new stuff into the doc that we did not agree on - some people use WORD to produce doc, then do manual editing to remove stupid word-side-effects and so often make stupid errors and so we end up wasting more cycles that needed. .. I can see the problems here, but this really, really seems to be a huge process problem in other fronts: inefficient editors and chairs, the use of wrong tools if fixing a few nits is too difficult etc. For every one of the three points above, you could continue ", but this is really a separate problem on its own, that is, XXXXX." We adjust the work habits and quality to cope for low performance, and expect the editors/WG-chairs/etc. to perform badly. Not sure whether that's a good idea. I think this should already be covered in the problem statement draft, but bringing up as an explicit example of a seemingly failing document improvement process. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From problem-statement-bounces@alvestrand.no Tue Nov 18 12:08: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 MAA01240 for ; Tue, 18 Nov 2003 12:08:32 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A090B61B9F; Tue, 18 Nov 2003 18:08:12 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3BDD861B89 for ; Tue, 18 Nov 2003 18:08:11 +0100 (CET) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hAIH8AGh008125; Tue, 18 Nov 2003 10:08:10 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hAIH8A9S008124; Tue, 18 Nov 2003 10:08:10 -0700 (MST) (envelope-from rousskov) Date: Tue, 18 Nov 2003 10:08:10 -0700 (MST) From: Alex Rousskov To: Pekka Savola In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: problem-statement@alvestrand.no Subject: Re: Concrete example of editor/WG inefficiencies X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 Pekka, Thanks a lot for posting a concrete example! I strongly disagree with your implication (in the subject line and in the text) that the problem is with editors, chairs, and other WG inefficiencies. IMO, your example clearly illustrates a much larger scope of the problems we are facing: - Top reviewers are doing sloppy reviews because they assume that working groups cannot handle tough ones - Some working groups produce sloppy documents because they assume that top reviewers are doing sloppy reviews - Some working groups waste energy and miss deadlines because they assume that top reviewers are doing their job well - Some working groups cannot handle tough reviews because they lack the tools, education, and process - There is no top management that can force both layers to do the right thing and that can order the tools development and education If we just change the top level, the lower levels would complain that they lack the skills and the tools to match new tougher requirements. If we just provide tools and education for the lower level, there will be not enough incentive for them to use the tools and knowledge. Thus, our biggest problem is that our problems are so interrelated that we cannot accurately describe (not to mention solve) one of them in isolation. I agree that lowering expectations to solve these problems is not a good idea, but we should not be talking about solution here... :-) Thank you, Alex. On Tue, 18 Nov 2003, Pekka Savola wrote: > Hi, > > When helping Bert/Randy to review documents at the IESG through > ops-dir, Bert stated that we should focus on major issues (while nits > etc. would be OK as well, but whether they'd be fixed would be up to > the authors etc.). I hope I interpreted that well. > > The reasons for this stance were (quoting Bert, with permission): > > - some editors/authors seem to need long turnaround times for > even the simplest changes > - when you let them make changes, the WG-chairs and ADs need to check > that they made them correctly and did not sneak new stuff into > the doc that we did not agree on > - some people use WORD to produce doc, then do manual editing to > remove stupid word-side-effects and so often make stupid errors > and so we end up wasting more cycles that needed. > > .. I can see the problems here, but this really, really seems to be a > huge process problem in other fronts: inefficient editors and chairs, > the use of wrong tools if fixing a few nits is too difficult etc. > > For every one of the three points above, you could continue ", but > this is really a separate problem on its own, that is, XXXXX." > > We adjust the work habits and quality to cope for low performance, and > expect the editors/WG-chairs/etc. to perform badly. Not sure whether > that's a good idea. > > I think this should already be covered in the problem statement draft, > but bringing up as an explicit example of a seemingly failing document > improvement process. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > From problem-statement-bounces@alvestrand.no Tue Nov 18 16:14: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 QAA16631 for ; Tue, 18 Nov 2003 16:14:37 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2F51261BB5; Tue, 18 Nov 2003 22:14:17 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A92AF61B9F; Tue, 18 Nov 2003 22:14:12 +0100 (CET) Date: Tue, 18 Nov 2003 11:53:13 -0800 From: Harald Tveit Alvestrand To: Melinda Shore , problem-statement@alvestrand.no Message-ID: <72270870.1069156393@localhost> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b9 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: WG last call - process document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 Speaking as participant: I have read the document, and support its publication in its current form. --On 17. november 2003 12:08 -0500 Melinda Shore wrote: > This is to announce the start of working group last call for > "IETF Problem Resolution Process" > (http://www.ietf.org/internet-drafts/draft-ietf-problem-process-03.txt). > Last call closes on Monday, 1 December 2003. Please send any > comments to the mailing list before last call closes. > > Melinda > > > From problem-statement-bounces@alvestrand.no Tue Nov 18 16:14:44 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 QAA16653 for ; Tue, 18 Nov 2003 16:14:43 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0AF0F61BE3; Tue, 18 Nov 2003 22:14:24 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2A2CF61BA7; Tue, 18 Nov 2003 22:14:15 +0100 (CET) Date: Tue, 18 Nov 2003 11:53:37 -0800 From: Harald Tveit Alvestrand To: Melinda Shore , problem-statement@alvestrand.no Message-ID: <72295415.1069156417@localhost> In-Reply-To: <60B4EEDF-1920-11D8-976B-000A95E35274@cisco.com> References: <60B4EEDF-1920-11D8-976B-000A95E35274@cisco.com> X-Mailer: Mulberry/3.1.0b9 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: WG last call - problem description document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 Speaking as participant: I have read the document, and support its publication in its current form. Harald --On 17. november 2003 12:06 -0500 Melinda Shore wrote: > This is to announce the beginning of working group last call for > "IETF Problem Statement" > (http://www.ietf.org/internet-drafts/draft-ietf-problem-issue- > statement-05.txt). > Last call closes on Monday, 24 November 2003. Please send comments to > the mailing, and note that we're not kidding about the closing date. > > Melinda > > > From problem-statement-bounces@alvestrand.no Tue Nov 18 17:01: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 RAA20554 for ; Tue, 18 Nov 2003 17:01:28 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0B86061BA0; Tue, 18 Nov 2003 23:01:09 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from pguin2.txc.com (transfire.transwitch.com [208.5.237.254]) by eikenes.alvestrand.no (Postfix) with ESMTP id AA2F761B91 for ; Tue, 18 Nov 2003 23:01:06 +0100 (CET) Received: from txc.com ([172.17.0.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id hAIM15002138; Tue, 18 Nov 2003 17:01:05 -0500 Message-ID: <3FBA969A.5080900@txc.com> Date: Tue, 18 Nov 2003 17:00:58 -0500 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: problem-statement@alvestrand.no References: <60B4EEDF-1920-11D8-976B-000A95E35274@cisco.com> In-Reply-To: <60B4EEDF-1920-11D8-976B-000A95E35274@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070107010902070708030200" Cc: Melinda Shore Subject: comments - Re: WG last call - problem description document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 is a cryptographically signed message in MIME format. --------------ms070107010902070708030200 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Here are a few comments regarding "draft-ietf-problem-issue-statement-05.txt" document. They are marked "minor" and "major". a. Minor Section titles are too long, too specific in describing a problem, which becomes ennoying when the text in the body of the section does NOT follow the title. For instance, the name "The IETF Management Structure is not Matched to the Current Size and Complexity of the IETF" of Section 2.6 does not reflect adequately the content of all its subsections. For instance "Procedural Blockages" subsection 2.6.3 may have little to do with a mismatch between the size and complexity of the IETF Management structure. A possible solution is shortening the section names, for instance: current: "Participants in the IETF do not have a Common Understanding of the its Mission. change to: "the Understanding of the IETF Mission" current: "The IETF Management Structure is not Matched to the Current Size and Complexity of the IETF" change to: "the IETF Management Structure" b. Major subsection 2.6.3 is addressing "procedural blockage" at the IESG (Area Director) level. This is not the only "procedural blockage". The document should address the same type of problem at WG (WG Chair) level as well. This should be done either in the same subsection, or in a new subsection. The cause of such WG procedural blockage problem can be multiple, but one that may be encountered in IETF, more often than it should, is when a chair, or both chairs have vested interest in directing the work on a certain path. This happens often when a chair or the chairs of a WG are directly involved in writing drafts for that WG. In some WGs, the chairs are authors or co-authors of a large number of drafts or RFCs; in such cases, it is likely that they will favor work or drafts that are not challenging, or are in alignment with their documents. In many Standards Development Organizations, for limiting the cause of such impartiality, a WG chair's role excludes participation or authorship of drafts, and it is rather limited to moderating the WG meetings, and driving the WG process along, according to the organization's rules. Perhaps this is a rule that IETF should adopt. c. Major subsection 2.6.6 "Concentration of Influence in Too Few Hands" mentions the possible negative effect of too long continuity in IESG and IAB memebership. However it does not mention the same negative effect in case of too long continuity in WG chairmanship. Possible fix is virtual, or by statute, term limits for WG chairs. This subsection should address also the perception that the WG chair selection is not an open process, or not as open as it should be. WG members have in general no saying in chair selecting, or in making a choice between several candidates. Regards, Alex Conta Melinda Shore wrote: > This is to announce the beginning of working group last call for > "IETF Problem Statement" > (http://www.ietf.org/internet-drafts/draft-ietf-problem-issue- > statement-05.txt). > Last call closes on Monday, 24 November 2003. Please send comments to > the mailing, and note that we're not kidding about the closing date. > > Melinda > > > --------------ms070107010902070708030200 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINqDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBR0wggSGoAMCAQICEAxYaM16ATcjBamVuftCOMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMxMDA3MDAw MDAwWhcNMDQxMDA2MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKQWxleCBDb250YTEdMBsGCSqGSIb3 DQEJARYOYWNvbnRhQHR4Yy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4 Ft6Hpfel8VTHHZ+/IL7CrN4JZuNiEG0jbHIdZ6p4fIhVYpLiSK57oEE8WooVkMCwJxbd1kja BR8eLKwmMatpnaW661HjOjZaZaWHuj1k+/I7ZKcPKHHk2V++wAz5lIrJEYXm5Swbqq+wz3Xu zBt1K3gRU+5AIeBbxD1H5yOShhuS8KMD3xh7XIpNu8KufVCzWAbLcto/oBAaXH9iXrdZ/fRZ ibQhNldCYSHv8zHt8uYMUs5AlL8TTEsEsx+Zrfhr4/dZWmnCBVLyMxFX3apwUq4onjmAeDmn MOzxlqp5kO/FJlUK5KHPvNYMnkA75zLGfONTZmnsc7nybpMta3YVAgMBAAGjggE4MIIBNDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMAYKYIZIAYb4RQEG BwQiFiAyNTMxNjE3MDc0YTVhNTU3OTNjN2U4NDI2NjEyNTAyNjAzBgNVHR8ELDAqMCigJqAk hiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GB ALIvzgvKUG1MgnjGt+pKACDHwud9y2gSne3lNmmfl9wzLNsSH+32cSUyVgKoQQ0hxKslfgQd xiJQ5PAQPCc2bA6SKJTYiaBE0aWnqGpLTNN4OUKTX3KXEBsxrCP2Tzjj6cm1ghHl12Z8IF1n VRdwTiGeuDVhv0bHVRJkJyFt0tFOMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjAN BgkqhkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZDAeFw0wMzEwMDcwMDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4 IENvbnRhMR0wGwYJKoZIhvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJI rnugQTxaihWQwLAnFt3WSNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77A DPmUiskRheblLBuqr7DPde7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNY Bsty2j+gEBpcf2Jet1n99FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIF UvIzEVfdqnBSriieOYB4Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1r dhUCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEH AQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYB BQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAu IGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQE AwIHgDAwBgpghkgBhvhFAQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2 MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf 7fZxJTJWAqhBDSHEqyV+BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGs I/ZPOOPpybWCEeXXZnwgXWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4xggSqMIIEpgIBATCB4TCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQDFhozXoBNyMF qZW5+0I4wjAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMzExMTgyMjAwNTlaMCMGCSqGSIb3DQEJBDEWBBQMeE3daaSXWvhsh9I8 04IjdQ/h/zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJKwYBBAGCNxAEMYHk MIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ bmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3Mg MSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjN egE3IwWplbn7QjjCMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3 dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFRE KGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3Jp YmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0B AQEFAASCAQCwhRF7BP6DcK9yAehN395bkCUV+FowvboHpT1fARyy9rd7n8ZWRSE0vYmOfuWH QLn9K4Ir2nxl2kAmN1n19nWx9Ayvv7dXiIu1Y666Ae9CwdWEMuKnWIwFvlKduM9ulymjiind Pz3g4+47BvRbPO3oZVFU4k4nBZuGxPBneQBhcfOKfsOXM37o6anhpsPmJWe5jMsPfqnITqfU 3xOBq+4RaWENZKXQ3aEkw1XzajN4n/PYcziPTaP+makRdtYr5VLNVztS+y/SKMxG88yW+6E2 tMXaCWFsI6/iYd9XcGV3m1ahteuwRqVZ1td1Tu7iqndO0NkwbTUydDVrQjUDAkkbAAAAAAAA --------------ms070107010902070708030200-- From problem-statement-bounces@alvestrand.no Tue Nov 18 17:47: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 RAA22714 for ; Tue, 18 Nov 2003 17:47:11 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C365561B9F; Tue, 18 Nov 2003 23:46:51 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from pguin2.txc.com (transfire.txc.com [208.5.237.254]) by eikenes.alvestrand.no (Postfix) with ESMTP id 315D361B91 for ; Tue, 18 Nov 2003 23:46:50 +0100 (CET) Received: from txc.com ([172.17.0.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id hAIMkn002844; Tue, 18 Nov 2003 17:46:49 -0500 Message-ID: <3FBAA159.2060602@txc.com> Date: Tue, 18 Nov 2003 17:46:49 -0500 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: problem-statement@alvestrand.no References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050301040007040003010906" Cc: mshore@cisco.com Subject: comments: - Re: WG last call - process document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 is a cryptographically signed message in MIME format. --------------ms050301040007040003010906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Here are a few comments regarding "draft-ietf-problem-process-03.txt" document. The comments are related to the comments submitted for the "problem description" document. Comments are marked "minor" and "major". a. Major Section 4.6 "Decomposition of the Management Scaling Problem" mentions the possible negative effect of a small pool of people from where IESG and IAB memebers are elected. However it does not mention the same negative effect in case of too few people taking WG chairmanship, or having one person chairing for too long a WG. If it is a problem at AD level, it is also a problem at the lower level as well. Possible fix is virtual, or by statute, term limits. b. Major The same section (4.6) is addressing the procedural blockage caused by ADs, but it is not addressing the procedural blockage problems caused by impartial WG chairs. It should. c. Major In discussing solutions, the same section (4.6) mentions the I-D tracker, but as a tool, this is just a beginning, by far not sufficient in resolving the process management tools shortage. While a lot more can be done in terms of automating the process and the using of tools, there is a lot to do, as well, in timely reaching the people that are interested in the moving forward of a document: the authors should be notified about the progress of a draft - this should be done automatically by the tools, at each step that a draft takes in IESG. d. MAJOR Furthemore, section 4.6, has the suggestion of delegating more work to the WG chairs. This is problematic from start. First, because the WH chairs are not democratically elected. Second, because the IETF rules do not stop them from vesting interest in work performed in the WG - WG chairs may be authors or co-authors of drafts in the WG, which may cause them favor drafts that do not challenge or are aligned with their own drafts. e. Major This section (4.6) should address also the perception that the WG chair selection is not an open process, or not as open as it should be. WG members have in general no saying in chair selecting, or in making a choice between several candidates. f. Major Section 4.7 "Decomposition of the Working Group Practices Problem" does not list the problem caused by the vested interest of WG chairs in promoting or favoring a certain direction in the WG. (this problem was mentioned also above in the context of section 4.6). This happens often when a chair or the chairs of a WG are directly involved in writing drafts for that WG. In some WGs, the chairs are authors or co-authors of a large number of drafts or RFCs; in such cases, it is likely that they will favor work or drafts that are not challenging, or are in alignment with their documents. In many Standards Development Organizations, for limiting the cause of such impartiality, a WG chair's role excludes participation or authorship of drafts, and it is rather limited to moderating the WG meetings, and driving the WG process along, according to the organization's rules. Perhaps this is a rule that IETF should adopt. Regards, Alex Conta Melinda Shore wrote: > This is to announce the start of working group last call for > "IETF Problem Resolution Process" > (http://www.ietf.org/internet-drafts/draft-ietf-problem-process-03.txt). > Last call closes on Monday, 1 December 2003. Please send any > comments to the mailing list before last call closes. > > Melinda > > > --------------ms050301040007040003010906 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTAzMTExODIyNDY0OVowIwYJKoZIhvcNAQkEMRYEFNguMA9dEHxoCUcn ZoXCpBNlLgyOMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBAI6UzoV4/dih9U+qy7qFCaDqgdj8cvH6AUrTaZ8m7mUlpFDJrpAfBvCr8wjB 0TfwJnNzzPh7Kl4No/H53bNNFBr6ig4umj7yzWVgmyLJz19mcx15SALPGxKZChfBWYha6tFV JAMJndPg1lAFbSMAnFJM2Me9BkXJO+xhOlRbpW2YmyXuz4kK9niO3eCCZELafg24YyPEFkih JX28azOIIq5hVxblnBO3Y0Q//bH32aRiiL4cIvfSathCOVUc+zHxYM8NMBb5cMuBt2oteR1u XsQhxrM/cLYA5erEhjoEnPfvuax9fKXXfuIOs/Ksvm2aucXGu/ZZU7Olm60alMA2f4IAAAAA AAA= --------------ms050301040007040003010906-- From problem-statement-bounces@alvestrand.no Wed Nov 19 20:25: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 UAA28247 for ; Wed, 19 Nov 2003 20:25:39 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 34B1E61BA7; Thu, 20 Nov 2003 02:25:20 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from hammer.brocade.com (f070.brocade.com [66.243.153.70]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2F85961B9D for ; Thu, 20 Nov 2003 02:25:13 +0100 (CET) Received: from hq-ex-c2.corp.brocade.com (hq-ex-c2.brocade.com [192.168.126.35]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id hAK1Nqq21176; Wed, 19 Nov 2003 17:23:52 -0800 (PST) Received: by hq-ex-c2.corp.brocade.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Nov 2003 17:23:52 -0800 Message-ID: From: Robert Snively To: "'problem-statement@alvestrand.no'" Date: Wed, 19 Nov 2003 17:23:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AF04.F3676ACB" Cc: "'mshore@cisco.com'" Subject: Response to WG last call, Problem Statement: Thoughts on the IET F problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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_01C3AF04.F3676ACB Content-Type: text/plain; charset="iso-8859-1" In consideration of: draft-ietf-problem-issue-statement-05.txt I'm sorry not to have identified this document earlier, but it was brought to my attention only today by a news publication. INTRODUCTION: First let me briefly introduce myself. I have created and led the creation of national and international standards in the INCITS, IEEE, and IETF environments. I have additionally created defacto standards in industry interest organizations, both commercial and voluntary. As a result, I have a fairly diverse background in the creation of standards and can speak directly to the challenges as seen from the working group and area levels. From my experiences, I believe that I can provide some helpful consideration to the overall IETF process up to the IESG level. BASIC ISSUE IS CULTURE: I believe your IETF draft has correctly identified many problems and issues. However, I believe that there is a more fundamental problem that must be discussed. Perhaps one of the most important issues is raised in clause 2.1. "The IETF creates standards and is therefore necessarily a Standards Development Organization (SDO) but many participants would like to differentiate the IETF and its way of working from the 'conventional' SDOs which emphasize corporate involvement and mandated delegates." This attempt to differentiate and create an "academic" culture is perhaps the biggest flaw in an organization architecting a world-wide commercial infrastructure with very high standards of reliability and security and with immense complexity. From that attempt flow most of the other problems. The obvious solution, following some of the principles of the other large successful SDOs, has consistently slipped from IETF's grasp. PROBLEM STATEMENT: NO MEMBERSHIP REQUIREMENTS Perhaps the most important word qualifying the internet today is "commercial". Companies spend money in their engineering development organizations to develop and implement equipment in compliance with IETF documents. Time to market is a key aspect of such development efforts. Complete, accurate, and timely standards are a requirement. Involving an arbitrary number of standards developers having no commercial stake in the process of creating a standard is perhaps the largest single problem in the IETF. This is touched upon in clause 2.8, but rather than choosing to guide the culture toward a more effective process, it was treated as a failure to properly train the participants. The real issue is that membership should be earned. Membership should be earned in each working group or area by attendance, by activity, by participating in reviews, and by payment of a fee. Membership should be probably be at an organizational level, thus partially identifying the otherwise hidden interests and agendas of representatives. The underlying commercial motivation of most participants must be recognized and brought to light. PROBLEM STATEMENT: OBSOLETE WORKING RULES Tradition is a powerful and helpful guide, but must be supplemented with wisely selected improvements. This is touched on in clause 2.6.5, but its effects are far-reaching. It also appears in various guises in clause 2.2. OBSOLETE WORKING RULES: DOCUMENT FORMAT It took the ips group over a year to gain permission to post drafts in portable document format (pdf). Even then the documents had to be posted in text as well. All other standards organizations have used sophisticated word processing capabilities since the early 1980s, enabling their documents to contain diagrams and relieving the editor of painful document formatting duties. OBSOLETE WORKING RULES: DEFINITIONS OF CONSENSUS As you pointed out in clause 2.7, the definition of consensus is rather vague. In every other standards organization there are formal mechanisms that solicit and measure consensus, usually with a recorded vote by organization or member. That provides a very effective mechanism for managing "consensus by exhaustion" issues. OBSOLETE WORKING RULES: ALL WORK OVER THE INTERNET Face-to-face meetings of sufficient duration to do actual work provide high bandwidth interchange and understanding among those motivated to attend and participate. As one example, the iSCSI activity held two interim face-to-face meetings co-located with the INCITS TC T11 SCSI Committee, bringing together the foremost minds in SCSI and the Internet. In each of those all day meetings, more was accomplished in correcting major flaws in the iSCSI document than had been accomplished in three months of e-mail interchanges. By documenting those meetings in careful minutes, most of the decisions made during that period were not challenged later. The personal understandings achieved by those meetings were also very helpful. The IETF meeting weeks, while sometimes helpful, generally do not have enough time allocated to each project within a working group to achieve helpful technical interchange. At the same time, the number of interested and knowledgeable participants for each project is a small percentage of those attending the working group, making the IETF meetings even less useful for technical interchange. You address this briefly in a number of places, but the real issue is that the working groups should have autonomy within certain limits to hold meetings and teleconferences to accelerate their work. This autonomy issue is partially addressed in several sub-clauses in 2.6. PROBLEM STATEMENT: DICTATORIAL STRUCTURE AND TECHNICAL REVIEW Clause 2.6 and its sub clauses address the following issue, but less brutally than I would suggest. Again, this is a flaw in the IETF culture. In every standards organization I have participated in, except IETF, the administrative hierarchy is concerned with proper completion of the technical process, not with the technical content. The technical content is worked out by organizations roughly at the level of the working group in IETF. As part of the procedure enforced by the administrative hierarchy, liaison with other working groups, other Accredited Standards Developers, and with other industry organizations is established so that architecturally consistent standards are developed. The administrative hierarchy guarantees a fair and open process and the proper scoping of a standards document. It also provides a public review and a public protest mechanism. It does not perform a technical review. The process of sending documents up through the IESG for technical consideration shows a lack of trust in the capabilities of the working group technical participants, a recognition that the process is unsuccessful in achieving consistent technical development, and a certain academic arrogance, akin to grading papers. Without such delegation of the responsibilities for liaison and technical excellence, IETF will not prove scalable. This process is also a major impediment to the timely publication of documents. As an example, we have about $3 billion dollars worth of commercial market value backed up against three IETF documents that are being held up by a security document that most configurations will never use. PROBLEM STATEMENT: LACK OF FORMAL RECOGNITION Clause 2.5.1 suggests that recognition is an important issue. Formal recognition should be given in every document. In systems as complex as the internet, it is absurd to think that there is one person that authors an RFC. All meaningful RFCs are the product of dozens or hundreds of people. However, the academic background of IETF, requires (probably because of the "publish or perish" syndrome) that only one or a few people be listed as authors. If IETF were being honest, it would identify an editor, a chairperson, perhaps a vice-chair and/or secretary, and cite the full list of participating members as authors. I have heard direct and explicit criticisms of this aspect of IETF culture a number of times on several IETF documents. PROBLEM STATEMENT: NIH The previous arrogance of IETF administration has prevented it from looking at very good models for organizational structure and standards development, implemented by such organizations as ANSI and ISO. It is refreshing that IETF has finally realized how severe its problems are and is beginning to cast about for proper solutions. This was pointed to somewhat more politely in several sub clauses of 2.6. This is one part of the culture that needs to be corrected. MY RECOMMENDED PROBLEM RESOLUTION, NOT PART OF THE PROBLEM STATEMENT: My own suggestion would be to review documents like the INCITS RD-2 (available at www.incits.org), the ANSI policy documents (available at www.ansi.org), and the ISO policy documents (www.iso.org) for the many constructive ideas they have. Better yet, IETF should recognize that it now representing a mature industry and become an accredited standards developer under ISO, IEC, or ANSI, adopting the open, efficient, and scalable policies of its new organizational parent. This is not an internet draft, and will not be because of the "obsolete working rules, document format" issue, mentioned above. ------_=_NextPart_001_01C3AF04.F3676ACB Content-Type: text/html; charset="iso-8859-1" Response to WG last call, Problem Statement: Thoughts on the IETF problem statement

In consideration of:

        draft-ietf-problem-issue-statement-05.txt

I'm sorry not to have identified this document earlier, but it was brought
to my attention only today by a news publication.

INTRODUCTION:

First let me briefly introduce myself.  I have created and led the
creation of national and international standards in the INCITS, IEEE,
and IETF environments.  I have additionally created defacto standards
in industry interest organizations, both commercial and voluntary.
As a result, I have a fairly diverse background in the creation of
standards and can speak directly to the challenges as seen from
the working group and area levels.  From my experiences, I believe that
I can provide some helpful consideration to the overall IETF process
up to the IESG level.

BASIC ISSUE IS CULTURE:

I believe your IETF draft has correctly identified many problems
and issues.  However, I believe that there is a more fundamental
problem that must be discussed.

Perhaps one of the most important issues is raised in clause 2.1.

   "The IETF creates standards and is therefore necessarily a Standards
   Development Organization (SDO) but many participants would like to
   differentiate the IETF and its way of working from the 'conventional'
   SDOs which emphasize corporate involvement and mandated delegates."

This attempt to differentiate and create an "academic" culture is perhaps
the biggest flaw in an organization architecting a world-wide commercial
infrastructure with very high standards of reliability and security and
with immense complexity.  From that attempt flow most of the other problems.
The obvious solution, following some of the principles of the other large
successful SDOs, has consistently slipped from IETF's grasp.

PROBLEM STATEMENT: NO MEMBERSHIP REQUIREMENTS

Perhaps the most important word qualifying the internet today is
"commercial".  Companies spend money in their engineering development
organizations to develop and implement equipment in compliance with
IETF documents.  Time to market is a key aspect of such development
efforts.  Complete, accurate, and timely standards are a requirement.
Involving an arbitrary number of standards developers having no commercial
stake in the process of creating a standard is perhaps the largest
single problem in the IETF.

This is touched upon in clause 2.8, but rather than choosing to
guide the culture toward a more effective process, it was treated as
a failure to properly train the participants.  The real issue is that
membership should be earned.

Membership should be earned in each working group or area by attendance,
by activity, by participating in reviews, and by payment of a fee. 

Membership should be probably be at an organizational level, thus partially
identifying the otherwise hidden interests and agendas of representatives.
The underlying commercial motivation of most participants must be
recognized and brought to light.

PROBLEM STATEMENT: OBSOLETE WORKING RULES

Tradition is a powerful and helpful guide, but must be supplemented with
wisely selected improvements. This is touched on in clause 2.6.5, but its
effects are far-reaching.  It also appears in various guises in clause 2.2.

  OBSOLETE WORKING RULES:  DOCUMENT FORMAT

        It took the ips group over a year to gain
        permission to post drafts in portable document format (pdf).  Even then
        the documents had to be posted in text as well.  All other standards
        organizations have used sophisticated word processing capabilities since
        the early 1980s, enabling their documents to contain diagrams
        and relieving the editor of painful document formatting duties.

  OBSOLETE WORKING RULES:  DEFINITIONS OF CONSENSUS

        As you pointed out in clause 2.7, the definition of consensus is
        rather vague.  In every other standards organization there are formal
        mechanisms that solicit and measure consensus, usually with a recorded vote
        by organization or member.  That provides a very effective mechanism
        for managing "consensus by exhaustion" issues.

  OBSOLETE WORKING RULES:  ALL WORK OVER THE INTERNET

        Face-to-face meetings of sufficient duration to do actual work
        provide high bandwidth interchange and understanding among those
        motivated to attend and participate.  As one example, the iSCSI
        activity held two interim face-to-face meetings co-located with the
        INCITS TC T11 SCSI Committee, bringing together the foremost minds
        in SCSI and the Internet.  In each of those all day meetings, more was
        accomplished in correcting major flaws in the iSCSI document than
        had been accomplished in three months of e-mail interchanges.
        By documenting those meetings in careful minutes, most of the
        decisions made during that period were not challenged later.
        The personal understandings achieved by those meetings were also
        very helpful.

        The IETF meeting weeks, while sometimes helpful, generally do not have enough
        time allocated to each project within a working group to achieve helpful technical
        interchange.  At the same time, the number of interested and knowledgeable
        participants for each project is a small percentage of those
        attending the working group, making the IETF meetings even less useful
        for technical interchange.

        You address this briefly in a number of places, but the real issue
        is that the working groups should have autonomy within certain
        limits to hold meetings and teleconferences to accelerate their work.
        This autonomy issue is partially addressed in several sub-clauses in 2.6.

PROBLEM STATEMENT:  DICTATORIAL STRUCTURE AND TECHNICAL REVIEW

Clause 2.6 and its sub clauses address the following issue, but less
brutally than I would suggest.  Again, this is a flaw in the IETF culture.

In every standards organization I have participated in, except IETF,
the administrative hierarchy is concerned with proper completion
of the technical process, not with the technical content.  The technical
content is worked out by organizations roughly at the level of the
working group in IETF.  As part of the procedure enforced by the
administrative hierarchy, liaison with other working groups, other
Accredited Standards Developers, and with other industry organizations
is established so that architecturally consistent standards are
developed.  The administrative hierarchy guarantees a fair and open
process and the proper scoping of a standards document.  It also provides
a public review and a public protest mechanism.  It does not
perform a technical review.

The process of sending documents up through the IESG for technical
consideration shows a lack of trust in the capabilities of the
working group technical participants, a recognition that the process
is unsuccessful in achieving consistent technical development, and
a certain academic arrogance, akin to grading papers.

Without such delegation of the responsibilities for liaison and
technical excellence, IETF will not prove scalable.

This process is also a major impediment to the timely publication
of documents.  As an example, we have about $3 billion dollars worth
of commercial market value backed up against three IETF documents
that are being held up by a security document that most
configurations will never use.

PROBLEM STATEMENT:  LACK OF FORMAL RECOGNITION

Clause 2.5.1 suggests that recognition is an important issue.
Formal recognition should be given in every document.  In systems
as complex as the internet, it is absurd to think that there is
one person that authors an RFC.  All meaningful RFCs are the product
of dozens or hundreds of people.  However, the academic background of
IETF, requires (probably because of the "publish or perish" syndrome)
that only one or a few people be listed as authors.  If
IETF were being honest, it would identify an editor, a chairperson,
perhaps a vice-chair and/or secretary, and cite the full list of
participating members as authors.  I have heard direct and explicit
criticisms of this aspect of IETF culture a number of times on several
IETF documents.

PROBLEM STATEMENT:  NIH

The previous arrogance of IETF administration has prevented it from
looking at very good models for organizational structure and
standards development, implemented
by such organizations as ANSI and ISO.  It is refreshing that IETF has
finally realized how severe its problems are and is beginning to
cast about for proper solutions.  This was pointed to somewhat more
politely in several sub clauses of 2.6.  This is one part of the culture
that needs to be corrected.

MY RECOMMENDED PROBLEM RESOLUTION, NOT PART OF THE PROBLEM STATEMENT:

My own suggestion would be to
review documents like the INCITS RD-2 (available at www.incits.org),
the ANSI policy documents (available at www.ansi.org), and the ISO
policy documents (www.iso.org) for the many constructive ideas they
have.  Better yet, IETF should recognize that it now representing
a mature industry and become an accredited standards
developer under ISO, IEC, or ANSI, adopting the open, efficient, and
scalable policies of its new organizational parent.

This is not an internet draft, and will not be because of the "obsolete
working rules, document format" issue, mentioned above.

------_=_NextPart_001_01C3AF04.F3676ACB-- From problem-statement-bounces@alvestrand.no Wed Nov 19 20:57: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 UAA29161 for ; Wed, 19 Nov 2003 20:57:36 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BE85661BA7; Thu, 20 Nov 2003 02:57:17 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by eikenes.alvestrand.no (Postfix) with ESMTP id AF83961B9D for ; Thu, 20 Nov 2003 02:57:14 +0100 (CET) Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (rwcrmhc11) with SMTP id <2003112001571301300nfqive> (Authid: sdawkins@comcast.net); Thu, 20 Nov 2003 01:57:13 +0000 Message-ID: <072d01c3af09$9e2a3ac0$2c818182@DFNJGL21> From: "Spencer Dawkins" To: References: <60B4EEDF-1920-11D8-976B-000A95E35274@cisco.com> <3FBA3864.1034325D@zurich.ibm.com> Date: Wed, 19 Nov 2003 19:57:13 -0600 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 - problem description document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 Echoing the esteemed Brother Carpenter - just ship it. In addition to everything Brian said, this document was cited by many of the proposals now underway - the discussion has served its purpose. Spencer ----- Original Message ----- From: "Brian E Carpenter" To: "Melinda Shore" Cc: Sent: Tuesday, November 18, 2003 9:19 AM Subject: Re: WG last call - problem description document > Just ship it. We could spend 5 years improving it, but the need for > action is now and it just isn't worth further tuning. > > Brian > > Melinda Shore wrote: > > > > This is to announce the beginning of working group last call for > > "IETF Problem Statement" > > (http://www.ietf.org/internet-drafts/draft-ietf-problem-issue- > > statement-05.txt). > > Last call closes on Monday, 24 November 2003. Please send comments to > > the mailing, and note that we're not kidding about the closing date. > > > > Melinda From problem-statement-bounces@alvestrand.no Wed Nov 19 20:59: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 UAA29239 for ; Wed, 19 Nov 2003 20:59:27 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BA45061BB5; Thu, 20 Nov 2003 02:59:08 +0100 (CET) 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 3506B61BB4 for ; Thu, 20 Nov 2003 02:59:06 +0100 (CET) Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (rwcrmhc13) with SMTP id <2003112001590401500bkov1e> (Authid: sdawkins@comcast.net); Thu, 20 Nov 2003 01:59:04 +0000 Message-ID: <073201c3af09$e02407d0$2c818182@DFNJGL21> From: "Spencer Dawkins" To: References: <3FBA38AE.E4EF0BAC@zurich.ibm.com> Date: Wed, 19 Nov 2003 19:59:03 -0600 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 - process document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 would prefer that this document be published, just so we'll have a (heh, heh) "Working Group Snapshot" to compare incoming proposals against. But it's definitely as complete as it needs to be now. Spencer ----- Original Message ----- From: "Brian E Carpenter" To: "Melinda Shore" Cc: Sent: Tuesday, November 18, 2003 9:20 AM Subject: Re: WG last call - process document > Personally I would abandon the document, but I have no > objection to it being published as a record of discussion. > > Brian > > Melinda Shore wrote: > > > > This is to announce the start of working group last call for > > "IETF Problem Resolution Process" > > (http://www.ietf.org/internet-drafts/draft-ietf-problem-process-03.txt ). > > Last call closes on Monday, 1 December 2003. Please send any > > comments to the mailing list before last call closes. > > > > Melinda From problem-statement-bounces@alvestrand.no Thu Nov 20 02:17:49 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 CAA19974 for ; Thu, 20 Nov 2003 02:17:48 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 914BB61BD7; Thu, 20 Nov 2003 08:17:28 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100]) by eikenes.alvestrand.no (Postfix) with SMTP id 7060961BB5 for ; Thu, 20 Nov 2003 08:17:25 +0100 (CET) Received: (qmail 90634 invoked from network); 20 Nov 2003 07:36:40 -0000 Received: from unknown (HELO pobox.org.sg) (203.208.233.194) by sentosa.post1.com with SMTP; 20 Nov 2003 07:36:40 -0000 Message-ID: <3FBC6A6B.5090102@pobox.org.sg> Date: Thu, 20 Nov 2003 15:16:59 +0800 From: James Seng User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Melinda Shore References: <0B079242-19D9-11D8-976B-000A95E35274@cisco.com> In-Reply-To: <0B079242-19D9-11D8-976B-000A95E35274@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Fwd: problem minutes X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 This may comes a bit early but congralutions for the job well done! -James Seng Melinda Shore wrote: > Here's a draft of the minutes from last week's meetings. Please > post corrections, etc. to the mailing list. > > Many thanks to Scott Bradner for taking the notes. > > Melinda > > >> The Problem WG met from 1pm to 3pm on Wednesday November 12th 2003. >> >> The issues document: >> The changes to the issues document between version 4 and version 5 were >> reviewed. The proposed fixes to the document based on the issues raised >> during the WG last call were reviewed. No one had any objection to the >> proposed fixes. >> >> The list of open issues were raised and discussed. No one felt that the >> document needed to be changed because of these issues. >> >> The chair asked if there were any objections to taking version 5 to a >> second (one week) WG last call, after which it would be forwarded to the >> General AD for consideration for publication as an Informational RFC. >> The >> General AD asked if the working group felt that there should be an IETF >> Last-Call for this document. The sense of the room was that it should. >> >> The process document: >> The chair asked if the working group felt that it would be OK if the >> process document could list alternative paths forward with a note to say >> that the working group was not able to reach consensus on any particular >> path. No one had any problem with closing the document in this way. >> Joel >> Halprin asked if the document should be published as an RFC at all. >> After >> discussion the sense of the room was that the process document should be >> published as an informational RFC. >> >> The future of the working group >> The chairs asked if the working group should be closed since its work was >> done when the two documents were sent to the General AD. The sense of >> the >> room was that it should be closed. >> > > > From problem-statement-bounces@alvestrand.no Thu Nov 20 04:46:34 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 EAA26952 for ; Thu, 20 Nov 2003 04:46:33 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D0BBD61BB5; Thu, 20 Nov 2003 10:46:14 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from netcore.fi (netcore.fi [193.94.160.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7E71161BB5 for ; Thu, 20 Nov 2003 10:46:12 +0100 (CET) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAK9k9W01298; Thu, 20 Nov 2003 11:46:10 +0200 Date: Thu, 20 Nov 2003 11:46:09 +0200 (EET) From: Pekka Savola To: Robert Snively In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "'problem-statement@alvestrand.no'" Subject: Re: Response to WG last call, Problem Statement: Thoughts on the IET F problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 On Wed, 19 Nov 2003, Robert Snively wrote: > First let me briefly introduce myself. I have created and led the > creation of national and international standards in the INCITS, IEEE, > and IETF environments. I have additionally created defacto standards > in industry interest organizations, both commercial and voluntary. > As a result, I have a fairly diverse background in the creation of > standards and can speak directly to the challenges as seen from > the working group and area levels. From my experiences, I believe that > I can provide some helpful consideration to the overall IETF process > up to the IESG level. [...] This clearly shows that different people have different missions and roles in mind for the IETF; some would prefer to have it as an official SDO, in every aspect (with the problems that causes); some others want to avoid it at all costs (with the problems we're aware of). I certainly would not wish to be part of a "full SDO" IETF. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From problem-statement-bounces@alvestrand.no Thu Nov 20 07:18:04 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 HAA01121 for ; Thu, 20 Nov 2003 07:18:03 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8B4B661BAC; Thu, 20 Nov 2003 13:17:43 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3D3F161B9D for ; Thu, 20 Nov 2003 13:17:42 +0100 (CET) Received: by newdev.harvard.edu (Postfix, from userid 501) id B856A80BBD; Thu, 20 Nov 2003 07:17:40 -0500 (EST) To: problem-statement@alvestrand.no Message-Id: <20031120121740.B856A80BBD@newdev.harvard.edu> Date: Thu, 20 Nov 2003 07:17:40 -0500 (EST) From: sob@harvard.edu (Scott Bradner) Subject: Re: WG last call - problem description document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 even though some of Robert Snively's comments might have been good to incorporate a while back I do not think we gain a lot from reopening the document now - its time to say that the current version gets the point across that there is work to do and is a reasonable bases for thinking about that work - i.e., its close enough for IETF standards work - ship it Scott From problem-statement-bounces@alvestrand.no Thu Nov 20 07:19:36 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 HAA01173 for ; Thu, 20 Nov 2003 07:19:35 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 317C761B9D; Thu, 20 Nov 2003 13:19:16 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2D57A61B8D for ; Thu, 20 Nov 2003 13:19:14 +0100 (CET) Received: by newdev.harvard.edu (Postfix, from userid 501) id B61E980BCB; Thu, 20 Nov 2003 07:19:13 -0500 (EST) To: problem-statement@alvestrand.no Message-Id: <20031120121913.B61E980BCB@newdev.harvard.edu> Date: Thu, 20 Nov 2003 07:19:13 -0500 (EST) From: sob@harvard.edu (Scott Bradner) Subject: Re: WG last call - process document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 like (some) historians and think this should be published as an informational RFC as part of the historical record Scott From problem-statement-bounces@alvestrand.no Thu Nov 20 07:28:57 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 HAA01319 for ; Thu, 20 Nov 2003 07:28:57 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A5B2361BDE; Thu, 20 Nov 2003 13:28:37 +0100 (CET) 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 1E5E561B8D for ; Thu, 20 Nov 2003 13:28:35 +0100 (CET) Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (rwcrmhc13) with SMTP id <2003112012283301500b7vkee> (Authid: sdawkins@comcast.net); Thu, 20 Nov 2003 12:28:33 +0000 Message-ID: <094201c3af61$d0f0db00$2c818182@DFNJGL21> From: "Spencer Dawkins" To: References: <20031120121740.B856A80BBD@newdev.harvard.edu> Date: Thu, 20 Nov 2003 06:28:34 -0600 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 - problem description document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 ... and definitely "close enough for IETF process improvement"... ----- Original Message ----- From: "Scott Bradner" To: Sent: Thursday, November 20, 2003 6:17 AM Subject: Re: WG last call - problem description document > > even though some of Robert Snively's comments might have been good > to incorporate a while back I do not think we gain a lot from reopening > the document now - its time to say that the current version gets > the point across that there is work to do and is a reasonable > bases for thinking about that work - i.e., its close enough for > IETF standards work - ship it > > Scott From problem-statement-bounces@alvestrand.no Thu Nov 20 09:05:49 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 JAA04711 for ; Thu, 20 Nov 2003 09:05:48 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1DA1661BE6; Thu, 20 Nov 2003 15:05:29 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtagate7.de.ibm.com (mtagate7.de.ibm.com [195.212.29.156]) by eikenes.alvestrand.no (Postfix) with ESMTP id 51FB361BE3 for ; Thu, 20 Nov 2003 15:05:27 +0100 (CET) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAKE5Lwj122600; Thu, 20 Nov 2003 14:05:23 GMT 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 hAKE21s6224820; Thu, 20 Nov 2003 15:02:01 +0100 Received: from zurich.ibm.com (dyn-9-13-127-147.ge.ch.ibm.com [9.13.127.147]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA66238; Thu, 20 Nov 2003 15:02:00 +0100 Message-ID: <3FBCC92F.75F174F2@zurich.ibm.com> Date: Thu, 20 Nov 2003 15:01:19 +0100 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: Scott Bradner References: <20031120121740.B856A80BBD@newdev.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: WG last call - problem description document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 Scott Bradner wrote: > > even though some of Robert Snively's comments might have been good > to incorporate a while back I do not think we gain a lot from reopening > the document now - its time to say that the current version gets > the point across that there is work to do and is a reasonable > bases for thinking about that work - i.e., its close enough for > IETF standards work - ship it I think we could have a long discussion about those comments, but it's been fairly clear to me that there is no will in the IETF to move in the direction he suggests. There is a will to clean up and professionalize the IETF's way of doing business, under its present constitution as an open-access non-voting organization. That is probably where our efforts should go. Brian From problem-statement-bounces@alvestrand.no Thu Nov 20 13:20: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 NAA16994 for ; Thu, 20 Nov 2003 13:20:04 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5718A61BB9; Thu, 20 Nov 2003 19:19:46 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from hammer.brocade.com (f070.brocade.com [66.243.153.70]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6768161BAB for ; Thu, 20 Nov 2003 19:19:43 +0100 (CET) Received: from hq-ex-c2.corp.brocade.com (hq-ex-c2.brocade.com [192.168.126.35]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id hAKIJft01577; Thu, 20 Nov 2003 10:19:41 -0800 (PST) Received: by hq-ex-c2.corp.brocade.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 10:19:41 -0800 Message-ID: From: Robert Snively To: "'Pekka Savola'" , Robert Snively Date: Thu, 20 Nov 2003 10:19:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AF92.D79EBA09" Cc: "'problem-statement@alvestrand.no'" Subject: RE: Response to WG last call, Problem Statement: Thoughts on the IETF problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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_01C3AF92.D79EBA09 Content-Type: text/plain Dear Mr. Savola, I can understand your concern about working within a carefully structured system that guarantees open and fair access to all interested participants. Such structure may seem confining. However, I am puzzled by what missions and roles you have in mind for the IETF. It is an engineering task force. I have assumed it is intended to promulgate open common solutions for the internet. How is that different from any other SDO, which intends to promulgate open common solutions for its own special area of interest? If there are other roles or missions that would be left out by considering itself as a formal SDO, they do not seem to be included in the problem statement as constraints. Could you please expand upon this? My principal point was that there is a need to more widely delegate technical responsibility to achieve the scalability required by today's internet standardization efforts. While there may be many ways to do that, the present SDOs (including IEEE-Stds, INCITS, and ISO) provide helpful and successful models which are worth our study. I am not sure that the GPL development model of Linux is a helpful model because of the structure of the networking marketplace. And it is clear that the present model of IETF does not meet the requirements. (See for one description of the problem.) I would point out that there are other roles associated with evangelizing a standardized technology, but those roles usually are attached to an industry trade group or interest group without a direct standards development responsibility. Robert Snively rsnively@brocade.com +1 408 333 8135 > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Thursday, November 20, 2003 1:46 AM > To: Robert Snively > Cc: 'problem-statement@alvestrand.no' > Subject: Re: Response to WG last call, Problem Statement: Thoughts on > the IET F problem statement > > > On Wed, 19 Nov 2003, Robert Snively wrote: > > First let me briefly introduce myself. I have created and led the > > creation of national and international standards in the > INCITS, IEEE, > > and IETF environments. I have additionally created defacto > standards > > in industry interest organizations, both commercial and voluntary. > > As a result, I have a fairly diverse background in the creation of > > standards and can speak directly to the challenges as seen from > > the working group and area levels. From my experiences, I > believe that > > I can provide some helpful consideration to the overall IETF process > > up to the IESG level. > [...] > > This clearly shows that different people have different missions and > roles in mind for the IETF; some would prefer to have it as an > official SDO, in every aspect (with the problems that causes); some > others want to avoid it at all costs (with the problems we're aware > of). > > I certainly would not wish to be part of a "full SDO" IETF. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > ------_=_NextPart_001_01C3AF92.D79EBA09 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Response to WG last call, Problem Statement: Thoughts on the = IETF problem statement

Dear Mr. Savola,

I can understand your concern about working within a = carefully
structured system that guarantees open and fair = access to
all interested participants.  Such structure = may seem confining.

However, I am puzzled by what missions and roles you = have in mind for
the IETF.  It is an engineering task = force.  I have assumed it is
intended to promulgate open common solutions for the = internet.
How is that different from any other SDO, which = intends to
promulgate open common solutions for its own special = area of interest?

If there are other roles or missions that would be = left out by
considering itself as a formal SDO, they do not seem = to be included
in the problem statement as constraints.  Could = you please
expand upon this?

My principal point was that there is a need to more = widely delegate
technical responsibility to achieve the scalability = required
by today's internet standardization efforts.  = While there may be
many ways to do that, the present SDOs (including = IEEE-Stds, INCITS,
and ISO) provide helpful and successful models which = are worth
our study.  I am not sure that the GPL = development model of
Linux is a helpful model because of the structure of = the
networking marketplace.  And it is clear that = the present model
of IETF does not meet the requirements. (See  =
<http://www.nwfusion.com/news/2003/1117ietf.html?nl= > for one
description of the problem.)

I would point out that there are other roles = associated with
evangelizing a standardized technology, but those = roles usually
are attached to an industry trade group or interest = group without
a direct standards development = responsibility.

Robert Snively
rsnively@brocade.com
+1 408 333 8135



> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: Thursday, November 20, 2003 1:46 = AM
> To: Robert Snively
> Cc: 'problem-statement@alvestrand.no'
> Subject: Re: Response to WG last call, Problem = Statement: Thoughts on
> the IET F problem statement
>
>
> On Wed, 19 Nov 2003, Robert Snively = wrote:
> > First let me briefly introduce = myself.  I have created and led the
> > creation of national and international = standards in the
> INCITS, IEEE,
> > and IETF environments.  I have = additionally created defacto
> standards
> > in industry interest organizations, both = commercial and voluntary.
> > As a result, I have a fairly diverse = background in the creation of
> > standards and can speak directly to the = challenges as seen from
> > the working group and area levels.  = >From my experiences, I
> believe that
> > I can provide some helpful consideration = to the overall IETF process
> > up to the IESG level.
> [...]
>
> This clearly shows that different people have = different missions and
> roles in mind for the IETF; some would prefer = to have it as an
> official SDO, in every aspect (with the = problems that causes); some
> others want to avoid it at all costs (with the = problems we're aware
> of).
>
> I certainly would not wish to be part of a = "full SDO" IETF.
>
> --
> Pekka = Savola           =       "You each name yourselves king, yet = the
> Netcore = Oy           &nbs= p;        kingdom = bleeds."
> Systems. Networks. Security. -- George R.R. = Martin: A Clash of Kings
>
>

------_=_NextPart_001_01C3AF92.D79EBA09-- From problem-statement-bounces@alvestrand.no Thu Nov 20 13:51: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 NAA18345 for ; Thu, 20 Nov 2003 13:51:30 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9F50261BB5; Thu, 20 Nov 2003 19:51:11 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by eikenes.alvestrand.no (Postfix) with ESMTP id A27C161BAC for ; Thu, 20 Nov 2003 19:51:08 +0100 (CET) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hAKIp6Gh030387; Thu, 20 Nov 2003 11:51:06 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hAKIp6oT030386; Thu, 20 Nov 2003 11:51:06 -0700 (MST) (envelope-from rousskov) Date: Thu, 20 Nov 2003 11:51:06 -0700 (MST) From: Alex Rousskov To: Robert Snively In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "'problem-statement@alvestrand.no'" Subject: RE: Response to WG last call, Problem Statement: Thoughts on the IETF problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 On Thu, 20 Nov 2003, Robert Snively wrote: > I can understand your concern about working within a carefully > structured system that guarantees open and fair access to all > interested participants. Robert, Is there an example of a successful SDO that guarantees open and fair access to all interested participants but does not require membership fees? Or are you implying that those who cannot afford membership fees cannot be interested enough? IETF does not require fees for low-level members that do not want to get elected to IESG positions and such. This is both good (more good engineers can participate) and bad (lack of money and commitments). I do not know of any comparable SDO that does not have fees or similar entry barriers. Do you? IETF membership policies are in the root of many of not most IETF problems. Are there real-world examples where similar policies do not cause the problems we face? Or are we in the unchartered territory here? Thanks, Alex. From problem-statement-bounces@alvestrand.no Thu Nov 20 15:08: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 PAA22055 for ; Thu, 20 Nov 2003 15:08:01 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 567F761BB9; Thu, 20 Nov 2003 21:07:42 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from hammer.brocade.com (f070.brocade.com [66.243.153.70]) by eikenes.alvestrand.no (Postfix) with ESMTP id 08B9A61BAC for ; Thu, 20 Nov 2003 21:07:40 +0100 (CET) Received: from hq-ex-c2.corp.brocade.com (hq-ex-c2.brocade.com [192.168.126.35]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id hAKK7It08844; Thu, 20 Nov 2003 12:07:18 -0800 (PST) Received: by hq-ex-c2.corp.brocade.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 12:07:18 -0800 Message-ID: From: Robert Snively To: "'Alex Rousskov'" , Robert Snively Date: Thu, 20 Nov 2003 12:07:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AFA1.E136C557" Cc: "'problem-statement@alvestrand.no'" Subject: RE: Response to WG last call, Problem Statement: Thoughts on the IETF problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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_01C3AFA1.E136C557 Content-Type: text/plain Alex, No matter how you count it, it costs real money to participate in IETF. At a minimum, it costs $100 for a used computer and $20/month for an internet connection, plus a roof and electricity. In most cases, organizations are also funding the time of their participants, their travels to the IETF meetings, and the meeting fees (which are higher in IETF than for most other SDOs). IETF chooses to pretend that corporate sponsorship is not part of the activity. As an example of a successful standards organization that has sliding fees, one can consider IEEE. To participate in IEEE standards voting, individuals pay $35/yr to join the standards organization and from $25 to $147/yr to join the IEEE, based on location and status. One must also request membership in the balloting pool. INCITS charges $800/yr per member organization for 2 participants and 2 free participants in each subcommittee. Membership also entails periodic meeting attendance and voting in letter ballots. Neither IEEE nor INCITS prohibit non-paying people from participating and contributing, just from voting. None of these fees are prohibitive compared with the other costs of participation, but these fees are sufficient to formalize the separation between those who are members and those who participate as a matter of less serious interest or as a social activity. Having a defined membership and voting pool, together with a formalized and documented voting system, eliminates a significant amount of the technical churn present in IETF activities. Decisions are made, agreed upon, documented, and the organization moves on. That does not prevent hot-blooded flamewars from occurring, but it provides a formal mechanism to resolve them, and if necessary, re-open them. I believe a careful review of the minutes of INCITS and IEEE organizations would not reveal any unexpected problems in the membership and voting process. Robert's Rules of Order have been relatively successful as a guide to fairness and process for both chairs and participants since about 1876. Such formalization also provides for effective liaison and allows the technical excellence of the product (a standard) to be under control of the individual working group. Technical review can then be broadened into the public at large as well as to other interested working groups, reducing the technical review load on the directors of the organization. The IETF model is the one that is really experimental. It can be very successful among a bounded group of like-minded people, but has already shown significant problems in scalability. I hope that I have properly addressed your questions. Bob > Robert, > > Is there an example of a successful SDO that guarantees open > and fair access to all interested participants but does not require > membership fees? Or are you implying that those who cannot afford > membership fees cannot be interested enough? > > IETF does not require fees for low-level members that do not > want to get elected to IESG positions and such. This is both good > (more good engineers can participate) and bad (lack of money and > commitments). I do not know of any comparable SDO that does not have > fees or similar entry barriers. Do you? > > IETF membership policies are in the root of many of not most > IETF problems. Are there real-world examples where similar policies do > not cause the problems we face? Or are we in the unchartered > territory here? > > Thanks, > > Alex. > ------_=_NextPart_001_01C3AFA1.E136C557 Content-Type: text/html RE: Response to WG last call, Problem Statement: Thoughts on the IETF problem statement

Alex,

No matter how you count it, it costs real money to participate
in IETF.  At a minimum, it costs $100 for a used computer and
$20/month for an internet connection, plus a roof and electricity.

In most cases, organizations are also funding the time of
their participants, their travels to the IETF meetings, and
the meeting fees (which are higher in IETF than for most
other SDOs).  IETF chooses to pretend that corporate
sponsorship is not part of the activity.

As an example of a successful standards organization that
has sliding fees, one can consider IEEE.  To participate in
IEEE standards voting, individuals pay $35/yr to join the standards organization
and from $25 to $147/yr to join the IEEE, based on location
and status.  One must also request membership in the balloting
pool.

INCITS charges $800/yr per member organization for
2 participants and 2 free participants in each subcommittee.
Membership also entails periodic meeting attendance and
voting in letter ballots.

Neither IEEE nor INCITS prohibit non-paying people from
participating and contributing, just from voting.
 
None of these fees are prohibitive compared with the other
costs of participation, but these fees are sufficient to
formalize the separation between those who are members
and those who participate as a matter of
less serious interest or as a social activity.

Having a defined membership and voting pool, together with a formalized
and documented voting system, eliminates a significant amount
of the technical churn present in IETF activities.  Decisions are
made, agreed upon, documented, and the organization moves on.
That does not prevent hot-blooded flamewars from occurring, but
it provides a formal mechanism to resolve them, and if necessary,
re-open them.

I believe a careful review of the minutes of INCITS and IEEE
organizations would not reveal any unexpected problems in the membership
and voting process.  Robert's Rules of Order have been relatively
successful as a guide to fairness and process for both chairs and
participants since about 1876.

Such formalization also provides for effective liaison and allows
the technical excellence of the product (a standard) to be under control of
the individual working group.  Technical review can then be
broadened into the public at large as well as to other interested
working groups, reducing the technical review load on the
directors of the organization.

The IETF model is the one that is really experimental.  It can be
very successful among a bounded group of like-minded people, but
has already shown significant problems in scalability. 

I hope that I have properly addressed your questions.

Bob

> Robert,
>
>       Is there an example of a successful SDO that guarantees open
> and fair access to all interested participants but does not require
> membership fees? Or are you implying that those who cannot afford
> membership fees cannot be interested enough?
>
>       IETF does not require fees for low-level members that do not
> want to get elected to IESG positions and such. This is both good
> (more good engineers can participate) and bad (lack of money and
> commitments). I do not know of any comparable SDO that does not have
> fees or similar entry barriers. Do you?
>
>       IETF membership policies are in the root of many of not most
> IETF problems. Are there real-world examples where similar policies do
> not cause the problems we face? Or are we in the unchartered
> territory here?
>
> Thanks,
>
> Alex.
>

------_=_NextPart_001_01C3AFA1.E136C557-- From problem-statement-bounces@alvestrand.no Thu Nov 20 15:26: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 PAA23670 for ; Thu, 20 Nov 2003 15:26:15 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2311161BD6; Thu, 20 Nov 2003 21:25:56 +0100 (CET) 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 85E7961BB9 for ; Thu, 20 Nov 2003 21:25:54 +0100 (CET) Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 9CE75AFB30; Thu, 20 Nov 2003 15:25:53 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12812-01; Thu, 20 Nov 2003 15:25:52 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 51031AFB2D; Thu, 20 Nov 2003 15:25:52 -0500 (EST) Date: Thu, 20 Nov 2003 15:18:34 -0500 From: Keith Moore To: Melinda Shore Message-Id: <20031120151834.1e4d5cb2.moore@cs.utk.edu> In-Reply-To: <60B4EEDF-1920-11D8-976B-000A95E35274@cisco.com> References: <60B4EEDF-1920-11D8-976B-000A95E35274@cisco.com> X-Mailer: Sylpheed version 0.9.7 (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 - problem description document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 1. The document title is misleading; it should be changed to something like "Perceived Problems in IETF" to make clear that while these perceptions are widely held, there's not consensus on the list of problems. 2. Remove the text 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. from the abstract - as it is presumptive. 3. In section 2.2, the following text: 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. could be read as indicating a problem with WG charters. It's more realistic to say that there's a natural gap between the level of detail specified in a WG's charter and the level of detail specified in a WG's first draft protocol specifications, and our WG processes do not currently give much guidance as to how to narrow that gap. IMHO IETF's biggest problem is that its working groups rarely develop specifications by any kind of incremental refinement. Proposals are expected to be fairly complete when they first appear as Internet-Drafts; otherwise they are shot down for lack of completeness. On the other hand, detailed proposals are less likely to get sufficient review because they are lengthy, and sometimes we shoot down entire proposals because they get some of the details wrong - because those details were specified prematurely. (And given that few people can be found to read detailed proposals at early stages, is it any wonder why we consume precious meeting time with boring, detailed presentations?) Working groups should be expected to take problem descriptions at the charter level and iterate them through increasing levels of detail, e.g. - problem definition/statement - goals document (NOT requirements, though there may be a few goals that are non-negotiatble) - functional specification / block diagram that broadly specifies how the functional pieces interact - rough specification which might specify protocol elements and their semantics but not to exact detail of presentation - prototype specification which specifies a subset of the protocol in enough detail that it can be implemented and tested (without being ready for prime time in any sense - for instance, things like authentication might be specified in a trivial fashion at this phase, even though security goals and requirements need to have already been specified) - draft specification which is a fairly complete specification for the protocol as it is intended to be deployed but may have bugs or a few unspecified areas - PS candidate specification which is believed to meet the requirements for Proposed Standard This seems like a lot of documents, but the first several of these documents should be quite short. Cross-area review should happen early, probably by the functional specification phase and certainly by the rough specification phase. Early documents are not carved in stone, they should be revised as it becomes apparent that changes are needed - so that there is always a current problem definition, goals statement, functional spec, etc. Not every WG should have to do each of these - it depends on various factors such as the overall complexity of the group's work, the size of its user community, the amount of interaction with other protocols and other areas, whether there are compatibility issues, etc. The important thing is the pattern of incremental refinement and review, not the specific set of steps. suggested action: reword to something like: o Currently there is no expectation that WGs define their processes or timelines beyond the level of detail specified in the group's charter; however this level of detail is rarely sufficient to direct a WG's activities. Additional documents such as a roadmap or detailed plans are rarely produced. 4. same section o Charters regularly fail to set sufficiently granular milestones at which progress of WGs, individuals and documents can be evaluated. Also WGs often do not make more detailed work plans to refine the charter plans. Again, while true, this seems phrased to put the burden on charters and I don't think it belongs there. I don't think it's reasonable to specify this level of detail in the WG's charter. To be useful, dated milestones need to be expressed in terms of meaningful, measurable results, and "submit an Internet-Draft on topic XXX", while measureable, isn't meaningful. To be meaningful the goal needs to be understood well enough in terms of things that have been done before. IMHO the charter should specify an expectation of the minimum steps that a WG will follow in producing a specification (say, in terms of the list above) and a vague expectation of the timeframe in which the steps will be undertaken - but should not be expected to serve as a detailed schedule. Instead, WG chairs should amplify on the vague outline provided by the charter and produce schedules (separate from the charter outline) for the next few months outlining specific, measurable steps (revise functional spec; decide on issues X, Y, Z; review documents A, B, C) and timeframes that actually have some basis in reality. suggested action: reword to something like: o The timeframes specified in charter milestones are generally not grounded in reality, nor is it reasonable to expect tight adherence to schedules that are specified at the level of detail appropriate for a working group charter. 5. section 2.4 o The three stage hierarchy is, accordingly, seen to be excessive. we really haven't demonstrated that three stages are excessive; what we've seen is that the stages we have are a poor impedance match between our energies to refine our output and the input accepted by our "customers" suggest change to: o The three stage hierarchy thus appears to be a poor match for vendor expectations, market expectations, and/or energy to complete the process. From problem-statement-bounces@alvestrand.no Thu Nov 20 15:34: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 PAA24528 for ; Thu, 20 Nov 2003 15:34:12 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EB46C61BAC; Thu, 20 Nov 2003 21:33:53 +0100 (CET) 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 64B0261BAB for ; Thu, 20 Nov 2003 21:33:52 +0100 (CET) Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id CB084AFB32; Thu, 20 Nov 2003 15:33:51 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13424-11; Thu, 20 Nov 2003 15:33:51 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id D616CAFB2D; Thu, 20 Nov 2003 15:33:50 -0500 (EST) Date: Thu, 20 Nov 2003 15:26:33 -0500 From: Keith Moore To: Melinda Shore Message-Id: <20031120152633.6cfcac7e.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (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 - process document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 do not support this document in its current form. Part of the problem is that it treats the "perceptions" from the Problem Statement document as facts. Another part of the problem is that some of the criteria for choosing process are questionable. Some of the recommendations are dubious, and others don't receive enough emphasis. IMHO there is not enough attention being paid to the way we actually do engineering, nor to the interactions between WGs and IESG and other WGs. Basically this document seems premature at best, and I don't think there is sufficient support (either in the document or in the community) for its recommendations. Keith From problem-statement-bounces@alvestrand.no Thu Nov 20 16: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 QAA26718 for ; Thu, 20 Nov 2003 16:09:47 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1929A61BB9; Thu, 20 Nov 2003 22:09:29 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7E4B861BAC for ; Thu, 20 Nov 2003 22:09:27 +0100 (CET) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hAKL9QGh038001; Thu, 20 Nov 2003 14:09:26 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hAKL9QmQ038000; Thu, 20 Nov 2003 14:09:26 -0700 (MST) (envelope-from rousskov) Date: Thu, 20 Nov 2003 14:09:26 -0700 (MST) From: Alex Rousskov To: Robert Snively In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "'problem-statement@alvestrand.no'" Subject: RE: Response to WG last call, Problem Statement: Thoughts on the IETF problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 On Thu, 20 Nov 2003, Robert Snively wrote: > No matter how you count it, it costs real money to participate in > IETF. At a minimum, it costs $100 for a used computer and $20/month > for an internet connection, plus a roof and electricity. It costs real money (or their equivalent) to live, of course. > None of these fees are prohibitive compared with the other costs of > participation, but these fees are sufficient to formalize the > separation between those who are members and those who participate > as a matter of less serious interest or as a social activity. The above statement sounds like a contradiction to me. If we assume it costs a lot more to participate than the official fee, the official fee becomes irrelevant. In other words, IETF fee structure is already close to the others you mention, without the money-collecting overheads; it already provides the separation you desire. However, let's ignore that contradiction for now. There are two related questions then: - Is formal separation required to achieve quality standards? What makes it an essential feature? - Are official fees the best way to achieve formal separation? Do IETF mailing lists provide enough formal separation? > Having a defined membership and voting pool, together with a > formalized and documented voting system, eliminates a significant > amount of the technical churn present in IETF activities. What mechanism do IEEE and other cheap SDOs have from preventing, say, Cisco or Microsoft from registering thousands of voting members to control a given working group? They certainly have the resources required. What protects minority in a voting-based SDO? Some kind of count-based (rather than portion-based) appeal process? I believe that IETF essentially has formal membership (mailing lists are rosters). What it does not have is formal commitments. I know W3C has commitments, but W3C membership is not affordable and not tailored to individuals. What about IEEE and INCITS? Do they require time/effort commitment from their members? You have mentioned several distinct areas of change: - formal membership - voting procedures - working group control Is it possible for you to indicate the relative importance of those? For example, if we manage to address working group control issues without formal membership and voting, do you think we can get close enough to your ideal? Thank you, Alex. P.S. My questions is an attempt to separate important/essential "ideal" SDO properties from "common" SDO properties so that we can ignore marketing/perception issues and do a focused comparison with IETF. From problem-statement-bounces@alvestrand.no Thu Nov 20 16:16:52 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 QAA27227 for ; Thu, 20 Nov 2003 16:16:52 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ADD2661BD6; Thu, 20 Nov 2003 22:16:33 +0100 (CET) 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 58FAA61BAC for ; Thu, 20 Nov 2003 22:16:31 +0100 (CET) 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 hAKLGOAt000297; Thu, 20 Nov 2003 13:16:25 -0800 (PST) Received: from cisco.com ([10.25.65.179]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AOL07252; Thu, 20 Nov 2003 13:16:23 -0800 (PST) Date: Thu, 20 Nov 2003 16:16:20 -0500 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Alex Rousskov From: Melinda Shore In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: "'problem-statement@alvestrand.no'" Subject: Re: Response to WG last call, Problem Statement: Thoughts on the IETF problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 Please keep in mind that the document under discussion is a problem description only, and that proposed solutions are out of scope for this document in particular and the working group in general. Thanks, Melinda From problem-statement-bounces@alvestrand.no Thu Nov 20 16:50:54 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 QAA00635 for ; Thu, 20 Nov 2003 16:50:53 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7274B61BB9; Thu, 20 Nov 2003 22:50:34 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from linus.bcentralhost.com (linus.bcentralhost.com [205.158.154.16]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2A35661BAC for ; Thu, 20 Nov 2003 22:50:32 +0100 (CET) Received: (root@localhost) by linus.bcentralhost.com id QAA25313; Thu, 20 Nov 2003 16:50:17 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <200311202150.QAA25313@linus.bcentralhost.com> From: mark seery To: Alex Rousskov Date: Thu, 20 Nov 2003 16:50:17 -0500 (EST) In-Reply-To: from Alex Rousskov on Thu, 20 Nov 2003 14:09:26 -0700 (MST) MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: "'problem-statement@alvestrand.no'" Subject: RE: Response to WG last call, Problem Statement: Thoughts on the IETF problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 ---- Alex Rousskov wrote: > > P.S. My questions is an attempt to separate important/essential > "ideal" SDO properties from "common" SDO properties so that we > can ignore marketing/perception issues and do a focused > comparison with IETF. Hi Alex, given Melinda's requests to focus on problems and not solutions, I'll limit my response to the above snip, and perhaps we can discuss the mechanisms of other bodies at another time. So in brief, from some small participation at say 802, I do find the processes add to a sense of fairness and dilligence, and just generally make me feel more comfortable with the procedure. They do not guarantee quality or timeliness though - those are a separate issues. They do not guarantee either that a small set of indivduals will not dominate a group, but at least there is a sense there is a process to deal with that. Typically I feel like standards bodies do really good quality work when they are building standards for a problem domain they know well, and a customer set they know well. In all bodies, when groups deviate from this, you get tension between the way the group would have traditionally solved a problem, and the way the new customer set thinks they want the problem solved; and sometimes it is just a new type of problem that the existing technology architectures do not adapt to. What you see then is the desire to meet the requirements of new customer set, ambiguity about how to solve the problem, luke warm support for the result, and questions of quality arise. That observation leads to the unpleasant discussion of mission, but it could similarly lead to simply a discussion of the problems of scaling an organization to address a growing number of areas. To me there is a strong link between timeliness and scope, and timeliness and reliance on an external body, as in all engineering projects, but that's off into the solution universe. Hope this helps to differentiate between some of purported benefits and realities. From problem-statement-bounces@alvestrand.no Thu Nov 20 17:02:51 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 RAA02101 for ; Thu, 20 Nov 2003 17:02:50 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3A6AB61BD6; Thu, 20 Nov 2003 23:02:32 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by eikenes.alvestrand.no (Postfix) with ESMTP id DEBCB61BAC for ; Thu, 20 Nov 2003 23:02:29 +0100 (CET) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hAKM2SGh041153; Thu, 20 Nov 2003 15:02:28 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hAKM2SSG041152; Thu, 20 Nov 2003 15:02:28 -0700 (MST) (envelope-from rousskov) Date: Thu, 20 Nov 2003 15:02:28 -0700 (MST) From: Alex Rousskov To: Melinda Shore In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "'problem-statement@alvestrand.no'" Subject: Re: Response to WG last call, Problem Statement: Thoughts on the IETF problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 On Thu, 20 Nov 2003, Melinda Shore wrote: > Please keep in mind that the document under discussion is a problem > description only, and that proposed solutions are out of scope for > this document in particular and the working group in general. I do. I do not think I proposed any solution in this context. The bulk of Robert's e-mail was also about problems and comparison with other SDOs, which seems to be in scope. Thanks, Alex. From problem-statement-bounces@alvestrand.no Thu Nov 20 17:12:24 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 RAA02695 for ; Thu, 20 Nov 2003 17:12:24 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 502EA61BAC; Thu, 20 Nov 2003 23:12:05 +0100 (CET) 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 2097761BAB for ; Thu, 20 Nov 2003 23:12:03 +0100 (CET) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 20 Nov 2003 14:12:39 +0000 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 hAKMC0jq023124; Thu, 20 Nov 2003 14:12:00 -0800 (PST) Received: from cisco.com ([10.25.65.179]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AOL15452; Thu, 20 Nov 2003 14:11:58 -0800 (PST) Date: Thu, 20 Nov 2003 17:11:55 -0500 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Alex Rousskov From: Melinda Shore In-Reply-To: Message-Id: <8D627B4D-1BA6-11D8-976B-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: "'problem-statement@alvestrand.no'" Subject: Re: Response to WG last call, Problem Statement: Thoughts on the IETF problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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, November 20, 2003, at 05:02 PM, Alex Rousskov wrote: > I do. I do not think I proposed any solution in this context. The bulk > of Robert's e-mail was also about problems and comparison with other > SDOs, which seems to be in scope. Right you are. I apologize for not being clearer; my note was intended as a general reminder rather than being directed at an individual. Melinda From problem-statement-bounces@alvestrand.no Thu Nov 20 17:33:19 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 RAA03654 for ; Thu, 20 Nov 2003 17:33:18 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A035061BAC; Thu, 20 Nov 2003 23:33:00 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6777161BAB for ; Thu, 20 Nov 2003 23:32:58 +0100 (CET) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAKMWN5m018835 for ; Thu, 20 Nov 2003 17:32:23 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAKMWL5m018765 for ; Thu, 20 Nov 2003 17:32:22 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AFB6.3CA3F726" Date: Fri, 21 Nov 2003 00:32:53 +0200 Message-ID: Thread-Topic: Response to WG last call, Problem Statement: Thoughts on the IETF problem statement Thread-Index: AcOvoflKVChpg8OySv6KaFYX2lrnpAAEk4lw From: "Romascanu, Dan (Dan)" To: "Robert Snively" , "Alex Rousskov" Cc: problem-statement@alvestrand.no Subject: RE: Response to WG last call, Problem Statement: Thoughts on the IETF problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 is a multi-part message in MIME format. ------_=_NextPart_001_01C3AFB6.3CA3F726 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >As an example of a successful standards organization that=20 >has sliding fees, one can consider IEEE. To participate in=20 >IEEE standards voting, individuals pay $35/yr to join the standards = organization=20 >and from $25 to $147/yr to join the IEEE, based on location=20 >and status. One must also request membership in the balloting=20 >pool.=20 I am afraid that this information is not accurate, at least in what = concerns IEEE 802.=20 =20 There is no individual fee 'to join the standards organization' in order = to become a voting member in an IEEE 802 WG. There are some attendance = conditions however (participating in two of the last four meetings). See = http://grouper.ieee.org/groups/802/802%20overview.pdf for details. There = is a registration fee for most of the meetings, usually lower than the = IETF registration fee.=20 =20 =20 >'Neither IEEE nor INCITS prohibit non-paying people from participating = and contributing, just from voting.'. =20 This also not accurate for the IEEE 802 case, as the IEEE documents are = not freely available, unless you participated at at least one meeting. =20 Of course, what is a 'successful standards organization' is also a = relative matter. Personally I think that both the IEEE and the IETF have = each their success stories and their horror stories.=20 =20 Regards, =20 Dan =20 =20 =20 ------_=_NextPart_001_01C3AFB6.3CA3F726 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Response to WG last call, Problem Statement: Thoughts on the = IETF problem statement
>As an example of a = successful standards=20 organization that
>has sliding fees, one can = consider=20 IEEE.  To participate in
>IEEE standards=20 voting, individuals pay $35/yr to join the standards=20 organization
>and from $25 to=20 $147/yr to join the IEEE, based on location =
>and status.  One must also request membership in the=20 balloting=20
>pool.=20
I am afraid that this information = is not=20 accurate, at least in what concerns IEEE 802. =
 
There is no individual fee 'to join the = standards=20 organization' in order to become a voting member in an IEEE = 802 WG.=20 There are some attendance conditions however (participating in two of = the last=20 four meetings). See http://gro= uper.ieee.org/groups/802/802%20overview.pdf for=20 details. There is a registration fee for most of the = meetings, usually=20 lower than the IETF registration fee.
 
 
>'Neither IEEE nor INCITS = prohibit non-paying=20 people from=20 participating and contributing, just from=20 voting.'.  
This also not accurate for the IEEE 802 = case, as=20 the IEEE documents are not freely available, unless you participated at = at least=20 one meeting.
 
Of course, what is = a  'successful standards=20 organization'  is also a relative matter. = Personally I=20 think that both the IEEE and the IETF have each their success stories = and their=20 horror stories.
 
Regards,
 
Dan
 
  
 
------_=_NextPart_001_01C3AFB6.3CA3F726-- From problem-statement-bounces@alvestrand.no Thu Nov 20 17:43:34 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 RAA04174 for ; Thu, 20 Nov 2003 17:43:33 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 22F8D61BD7; Thu, 20 Nov 2003 23:43:15 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6D6FA61BD6 for ; Thu, 20 Nov 2003 23:43:13 +0100 (CET) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAKMef5C001483 for ; Thu, 20 Nov 2003 17:40:41 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAKMec5C001452 for ; Thu, 20 Nov 2003 17:40:39 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Nov 2003 00:43:09 +0200 Message-ID: Thread-Topic: Response to WG last call, Problem Statement: Thoughts on the IETF problem statement Thread-Index: AcOvqpoh3Zl8T0ihRnqSnveeXUavegAC9XAA From: "Romascanu, Dan (Dan)" To: "Alex Rousskov" , "Robert Snively" Cc: problem-statement@alvestrand.no Subject: RE: Response to WG last call, Problem Statement: Thoughts on the IETF problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 > What mechanism do IEEE and other cheap SDOs have from preventing, say, > Cisco or Microsoft from registering thousands of voting members to > control a given working group? They certainly have the resources > required. What protects minority in a voting-based SDO? Some kind of > count-based (rather than portion-based) appeal process? >=20 >=20 Two examples from my IEEE experience: - At the beginning of a standards activity, a Call For Interest (CFI) is = being hold. This is roughly the equivalent of an IETF BOF. Care is being = taken that there is an appropriate balance of participants from the = research/academy, vendors, and customers, counted on organizational = rather than individuals basis before a decision is taken to start a = standards work - Later, in the editing process, comments are classified as critical = (REQUIRED) or not. All critical comments, from any individual need to be = resolved, and have quasi-veto power. Certainly, at the end of the day = there is enough power for the majority to vote down with a 75% majority = repeated comments coming from one single individual, but I am not sure = that this is worse than the IETF process of consensus reaching in a Last = Call. I am not sure that majority votes requiring 75% majority is worse = in this case than the decision taken by one single WG chair (who is also = sponsored by some company, isn't he/she?) Regards, Dan From problem-statement-bounces@alvestrand.no Thu Nov 20 21:53: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 VAA14913 for ; Thu, 20 Nov 2003 21:53:37 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E93A561BDE; Fri, 21 Nov 2003 03:53:18 +0100 (CET) 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 6C27461BD8 for ; Fri, 21 Nov 2003 03:53:17 +0100 (CET) Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id D3B31AFB83; Thu, 20 Nov 2003 21:53:16 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04647-01; Thu, 20 Nov 2003 21:53:15 -0500 (EST) Received: from cs.utk.edu (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 5846CAFB55; Thu, 20 Nov 2003 21:53:15 -0500 (EST) Date: Thu, 20 Nov 2003 21:53:55 -0500 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) To: Robert Snively From: Keith Moore In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Cc: problem-statement@alvestrand.no, Keith Moore Subject: Re: Response to WG last call, Problem Statement: Thoughts on the IETF problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 disagree with most of these problem statements, especially those regarding IETF's "culture" and organizational goals. In particular, It would be a very bad move for IETF to regard the Internet as exclusively or even mostly "commercial" in nature, especially given the extensive history (which continues to this day) of noncommercial efforts producing a significant number of useful innovation, widely-used products, and widely-used protocols. The Internet and IETF both continue to evolve, and even if most of the current participants are "commercial" we should not insist that they shall be so in the future - indeed, I'd argue that to be successful in the future we must find a way to attract more participants who take a long view. Many of these statements are not "problems" but rather assumptions about how IETF should be that are far from universally shared. I do believe that some form of membership should be considered as part of a "solution" to some other problems (at least, it shouldn't be rejected outright), and that our procedures for the operation of working groups in particular are obsolete and need refinement. But these are really topics for another group. One interesting point regarding document format. IETF has a very long history of exchanging and providing standards documents over the network - far more than other SDOs, and this certainly influenced IETF's choice of document format. Nearly 40 years after its initial adoption, ASCII text remains a very versatile and portable format, sufficient for most (not all) of IETF's purposes. Few networking SDOs can claim that several of their 20-year old technical specifications are even accessible and readable, much less usable in other than a historical sense. Specifications that are written to be usable for a long time should be produced in a format that will also continue to be usable into the future, and this argues for simplicity rather than aesthetic appeal. Despite its name, PDF is already becoming somewhat nonportable, and the other popular formats are even worse. From problem-statement-bounces@alvestrand.no Fri Nov 21 11:01: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 LAA19092 for ; Fri, 21 Nov 2003 11:01:06 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ECE8061BD6; Fri, 21 Nov 2003 17:00:47 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from hammer.brocade.com (f070.brocade.com [66.243.153.70]) by eikenes.alvestrand.no (Postfix) with ESMTP id B40DB61BB9 for ; Fri, 21 Nov 2003 17:00:44 +0100 (CET) Received: from hq-ex-c2.corp.brocade.com (hq-ex-c2.brocade.com [192.168.126.35]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id hALG0Wt05140; Fri, 21 Nov 2003 08:00:33 -0800 (PST) Received: by hq-ex-c2.corp.brocade.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Nov 2003 08:00:32 -0800 Message-ID: From: Robert Snively To: "'Romascanu, Dan (Dan)'" , Alex Rousskov , Robert Snively Date: Fri, 21 Nov 2003 08:00:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B048.93F1125F" Cc: problem-statement@alvestrand.no Subject: RE: Response to WG last call, Problem Statement: Thoughts on the IETF problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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_01C3B048.93F1125F Content-Type: text/plain; charset="iso-8859-1" And in agreement with Dan's experience, INCITS specifies membership by organization. IBM gets one vote. Consultants are required to drop their consulting organization from membership while representing another organization. Key votes have a 2/3 rule applied for consensus. The 2/3 rule requires 2/3 of those voting to approve and 1/2 of the total membership to approve. Subsequent public review is by individual. All technical comments must be addressed, and if they are not resolved, they are forwarded with the standard to the administrative review process. Such standards may be returned unapproved to the committee. For this reason, we typically have 100% consensus with the final standard, giving the technical comment the same kind of quasi-veto power seen in IEEE. See www.incits.org, where the policies and procedures are documented as Reference Document 2 (RD-2). INCITS policies and procedures are designed to meet the ANSI standards for accreditation. Note that the IEEE procedures described by Dan are also designed to meet those standards, even though those of IEEE are quite different and much more like IETF's. Bob > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Thursday, November 20, 2003 2:43 PM > To: Alex Rousskov; Robert Snively > Cc: problem-statement@alvestrand.no > Subject: RE: Response to WG last call, Problem Statement: Thoughts on > the IETF problem statement > > > > What mechanism do IEEE and other cheap SDOs have from > preventing, say, > > Cisco or Microsoft from registering thousands of voting members to > > control a given working group? They certainly have the resources > > required. What protects minority in a voting-based SDO? Some kind of > > count-based (rather than portion-based) appeal process? > > > > > > Two examples from my IEEE experience: > > - At the beginning of a standards activity, a Call For > Interest (CFI) is being hold. This is roughly the equivalent > of an IETF BOF. Care is being taken that there is an > appropriate balance of participants from the > research/academy, vendors, and customers, counted on > organizational rather than individuals basis before a > decision is taken to start a standards work > - Later, in the editing process, comments are classified as > critical (REQUIRED) or not. All critical comments, from any > individual need to be resolved, and have quasi-veto power. > Certainly, at the end of the day there is enough power for > the majority to vote down with a 75% majority repeated > comments coming from one single individual, but I am not sure > that this is worse than the IETF process of consensus > reaching in a Last Call. I am not sure that majority votes > requiring 75% majority is worse in this case than the > decision taken by one single WG chair (who is also sponsored > by some company, isn't he/she?) > > Regards, > > Dan > ------_=_NextPart_001_01C3B048.93F1125F Content-Type: text/html; charset="iso-8859-1" RE: Response to WG last call, Problem Statement: Thoughts on the IETF problem statement

And in agreement with Dan's experience, INCITS specifies
membership by organization.  IBM gets one vote.  Consultants
are required to drop their
consulting organization from membership while representing another
organization.  Key votes have a 2/3 rule applied for consensus.
The 2/3 rule requires 2/3 of those voting to approve and 1/2 of the
total membership to approve.  Subsequent public review
is by individual.  All technical comments must be addressed, and
if they are not resolved, they are forwarded with the standard
to the administrative review process.  Such standards may be
returned unapproved to the committee.  For this reason, we typically
have 100% consensus with the final standard, giving the technical
comment the same kind of quasi-veto power seen in IEEE. 
See www.incits.org, where the policies and procedures are documented as
Reference Document 2 (RD-2).

INCITS policies and procedures are designed to meet the ANSI
standards for accreditation.  Note that the IEEE procedures described
by Dan are also designed to meet those standards, even though those of IEEE
are quite different and much more like IETF's.

Bob

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
> Sent: Thursday, November 20, 2003 2:43 PM
> To: Alex Rousskov; Robert Snively
> Cc: problem-statement@alvestrand.no
> Subject: RE: Response to WG last call, Problem Statement: Thoughts on
> the IETF problem statement
>
>
> > What mechanism do IEEE and other cheap SDOs have from
> preventing, say,
> > Cisco or Microsoft from registering thousands of voting members to
> > control a given working group? They certainly have the resources
> > required. What protects minority in a voting-based SDO? Some kind of
> > count-based (rather than portion-based) appeal process?
> >
> >
>
> Two examples from my IEEE experience:
>
> - At the beginning of a standards activity, a Call For
> Interest (CFI) is being hold. This is roughly the equivalent
> of an IETF BOF. Care is being taken that there is an
> appropriate balance of participants from the
> research/academy, vendors, and customers, counted on
> organizational rather than individuals basis before a
> decision is taken to start a standards work
> - Later, in the editing process, comments are classified as
> critical (REQUIRED) or not. All critical comments, from any
> individual need to be resolved, and have quasi-veto power.
> Certainly, at the end of the day there is enough power for
> the majority to vote down with a 75% majority repeated
> comments coming from one single individual, but I am not sure
> that this is worse than the IETF process of consensus
> reaching in a Last Call. I am not sure that majority votes
> requiring 75% majority is worse in this case than the
> decision taken by one single WG chair (who is also sponsored
> by some company, isn't he/she?)
>
> Regards,
>
> Dan
>

------_=_NextPart_001_01C3B048.93F1125F-- From problem-statement-bounces@alvestrand.no Fri Nov 21 11:42:54 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 LAA20666 for ; Fri, 21 Nov 2003 11:42:53 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8D23E61BD6; Fri, 21 Nov 2003 17:42:34 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from hammer.brocade.com (f070.brocade.com [66.243.153.70]) by eikenes.alvestrand.no (Postfix) with ESMTP id E020E61BB9 for ; Fri, 21 Nov 2003 17:42:32 +0100 (CET) Received: from hq-ex-c2.corp.brocade.com (hq-ex-c2.brocade.com [192.168.126.35]) by hammer.brocade.com (8.11.3/8.11.3) with ESMTP id hALGgOt07102; Fri, 21 Nov 2003 08:42:24 -0800 (PST) Received: by hq-ex-c2.corp.brocade.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Nov 2003 08:42:23 -0800 Message-ID: From: Robert Snively To: "'Alex Rousskov'" , Robert Snively Date: Fri, 21 Nov 2003 08:42:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B04E.6AA633B1" Cc: "'problem-statement@alvestrand.no'" Subject: RE: Response to WG last call, Problem Statement: Thoughts on the IETF problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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_01C3B04E.6AA633B1 Content-Type: text/plain Alex, You asked a very difficult question: > > You have mentioned several distinct areas of change: > - formal membership > - voting procedures > - working group control > > Is it possible for you to indicate the relative importance of those? > For example, if we manage to address working group control issues > without formal membership and voting, do you think we can get close > enough to your ideal? I believe that there are multiple interlocking issues here. As you can see below, if you accept goals of scalability, improved responsiveness, and higher productivity, then each of the areas of change contributes in its own way. For scalability: I believe that the centralized technical review process should become a centralized procedural review process. That involves delegation of the technical excellence of a standard to the working group and consistency with other standards to the liaison activities of the working group. After the working group and the formal liaison groups are happy with the technical content, a final widely-announced public review period could pick up any other issues. The meeting schedules and agendas should be modified to reflect such a new organizational grouping. Fewer large plenaries and more multi-day working group level meetings could usefully accelerate the work. For improved responsiveness: Much of the task scheduling, meeting scheduling, choice of teleconferencing techniques and other work procedures should be done principally at or near the working group level. For higher productivity: In addition to the shifting of technical responsibility to the working group and its liaisons, verified by a broader public review, the following actions can improve productivity. Documented minutes of meeting and teleconference discussions with documented records of voting actions taken would help to prevent circular discussion and the reopening of resolved issues. To do this, voting membership and voting procedures have to be defined. Letter ballots using e-mail or web-based systems may also be useful to promote closure of last-calls. Voting membership should be earned by some combination of nominal sliding fees and participation requirements, possibly qualified by organizational affinity. Participation should otherwise be completely open. Voting on key issues should be by some sort of supermajority more meaningful than humming. Resolution of technical comments, including those coming from outside public review, should be granted very high priority in the procedures. These thoughts are not new or magical, but perhaps they can serve as a catalyst for an even better IETF. ------_=_NextPart_001_01C3B04E.6AA633B1 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Response to WG last call, Problem Statement: Thoughts on the = IETF problem statement

Alex,

You asked a very difficult question:

>
> You have mentioned several distinct areas of = change:
>       - formal = membership
>       - voting = procedures
>       - working group = control
>
> Is it possible for you to indicate the relative = importance of those?
> For example, if we manage to address working = group control issues
> without formal membership and voting, do you = think we can get close
> enough to your ideal?

I believe that there are multiple interlocking issues = here.  As you can
see below, if you accept goals of scalability, = improved responsiveness,
and higher productivity, then each of the areas of = change contributes
in its own way.

For scalability:

        I believe = that the centralized technical review process should
        become a = centralized procedural review process.  That involves
        delegation of the technical excellence of a standard to the = working group
        and = consistency with other standards to the liaison activities
        of the = working group.  After the working group and the formal
        liaison = groups are happy with the technical content, a final
        widely-announced public review period could pick up any other = issues.

        The = meeting schedules and agendas should be modified to reflect such = a
        new = organizational grouping. Fewer large plenaries and more
        multi-day = working group level meetings could usefully accelerate the work.

For improved responsiveness:

        Much of = the task scheduling, meeting scheduling, choice of
        teleconferencing techniques and other work procedures = should
        be done = principally at or near the working group level. 

For higher productivity:

        In = addition to the shifting of technical responsibility to
        the = working group and its liaisons, verified by a broader
        public = review, the following actions can improve productivity.

        Documented = minutes of meeting and teleconference discussions
        with = documented records of voting actions taken would help to prevent
        circular = discussion and the reopening of resolved issues.
        To do = this, voting membership and voting procedures have to
        be = defined.  Letter ballots using e-mail or web-based systems
        may also = be useful to promote closure of last-calls.

        Voting = membership should be earned by some combination of
        nominal = sliding fees and participation requirements, possibly qualified
        by = organizational affinity.  Participation should otherwise be
        completely open.  Voting on key issues should be by some = sort
        of = supermajority more meaningful than humming.  Resolution of
        technical = comments, including those
        coming = from outside public review, should be granted
        very high = priority in the procedures.

These thoughts are not new or magical, but perhaps = they can serve
as a catalyst for an even better IETF.

------_=_NextPart_001_01C3B04E.6AA633B1-- From problem-statement-bounces@alvestrand.no Fri Nov 21 11:46: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 LAA20883 for ; Fri, 21 Nov 2003 11:46:47 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 82FFB61BFF; Fri, 21 Nov 2003 17:46:29 +0100 (CET) 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 1B37861BD6 for ; Fri, 21 Nov 2003 17:46:28 +0100 (CET) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Nov 2003 08:47:01 +0000 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 hALGkPjq013834; Fri, 21 Nov 2003 08:46:25 -0800 (PST) Received: from cisco.com ([10.25.65.179]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AOL80806; Fri, 21 Nov 2003 08:46:24 -0800 (PST) Date: Fri, 21 Nov 2003 11:46:22 -0500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Robert Snively From: Melinda Shore In-Reply-To: Message-Id: <3D257EF2-1C42-11D8-8485-000A95E35274@cisco.com> Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) Cc: "'problem-statement@alvestrand.no'" Subject: Re: Response to WG last call, Problem Statement: Thoughts on the IETF problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 Friday, November 21, 2003, at 11:42 AM, Robert Snively wrote: > I believe that there are multiple interlocking issues here.=A0 As you = can > see below, if you accept goals of scalability, improved = responsiveness, > and higher productivity, then each of the areas of change contributes > in its own way. This discussion really does belong on the solutions mailing list. Melinda From problem-statement-bounces@alvestrand.no Fri Nov 21 12:13:52 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 MAA22829 for ; Fri, 21 Nov 2003 12:13:51 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 16B7961BD6; Fri, 21 Nov 2003 18:13:33 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8493061BB9 for ; Fri, 21 Nov 2003 18:13:30 +0100 (CET) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hALHDTGh092333; Fri, 21 Nov 2003 10:13:29 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hALHDTU6092332; Fri, 21 Nov 2003 10:13:29 -0700 (MST) (envelope-from rousskov) Date: Fri, 21 Nov 2003 10:13:29 -0700 (MST) From: Alex Rousskov To: Melinda Shore In-Reply-To: <3D257EF2-1C42-11D8-8485-000A95E35274@cisco.com> Message-ID: References: <3D257EF2-1C42-11D8-8485-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "'problem-statement@alvestrand.no'" Subject: Re: Response to WG last call, Problem Statement: Thoughts on the IETF problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 Fri, 21 Nov 2003, Melinda Shore wrote: > On Friday, November 21, 2003, at 11:42 AM, Robert Snively wrote: > > I believe that there are multiple interlocking issues here.=A0 As you c= an > > see below, if you accept goals of scalability, improved responsiveness, > > and higher productivity, then each of the areas of change contributes > > in its own way. > > This discussion really does belong on the solutions mailing list. Now I agree; we seem to be switching from problem priorities to solution priorities. I should have been even more careful when asking the priority question. Alex. From problem-statement-bounces@alvestrand.no Fri Nov 21 12:37: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 MAA23868 for ; Fri, 21 Nov 2003 12:37:45 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EF15061BE6; Fri, 21 Nov 2003 18:37:27 +0100 (CET) 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 51DCB61BD6 for ; Fri, 21 Nov 2003 18:37:26 +0100 (CET) Received: from frmail31.netfr.alcatel.fr (frmail31.netfr.alcatel.fr [155.132.251.42]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id hALHbMCZ014365; Fri, 21 Nov 2003 18:37:23 +0100 To: Robert Snively X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Alistair.Urie@alcatel.com Date: Fri, 21 Nov 2003 18:37:21 +0100 X-MIMETrack: Serialize by Router on FRMAIL31/FR/ALCATEL(Release 5.0.11 |July 24, 2002) at 11/21/2003 18:37:22 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new Cc: "'problem-statement@alvestrand.no'" , "'Pekka Savola'" Subject: RE: Response to WG last call, Problem Statement: Thoughts on the IETF problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 Robert, I think you are trying to push this debate in the right direction but this is more a "solutions" rather than a "problem" issue. The current draft really is "good enough" so let's ship it and get on with solving the problems rather than talking about them. Adding some more formality, making IETF a bit more SDO-like and improving the scalability of the work of making standards are key issues but they are all already identified in the problem statement. - Alistair URIE Robert Snively To: "'Pekka Savola'" , Robert Snively Sent by: cc: "'problem-statement@alvestrand.no'" problem-statement-bounces@al Subject: RE: Response to WG last call, Problem Statement: Thoughts on the IETF problem vestrand.no statement 20/11/2003 19:19 Dear Mr. Savola, I can understand your concern about working within a carefully structured system that guarantees open and fair access to all interested participants. Such structure may seem confining. However, I am puzzled by what missions and roles you have in mind for the IETF. It is an engineering task force. I have assumed it is intended to promulgate open common solutions for the internet. How is that different from any other SDO, which intends to promulgate open common solutions for its own special area of interest? If there are other roles or missions that would be left out by considering itself as a formal SDO, they do not seem to be included in the problem statement as constraints. Could you please expand upon this? My principal point was that there is a need to more widely delegate technical responsibility to achieve the scalability required by today's internet standardization efforts. While there may be many ways to do that, the present SDOs (including IEEE-Stds, INCITS, and ISO) provide helpful and successful models which are worth our study. I am not sure that the GPL development model of Linux is a helpful model because of the structure of the networking marketplace. And it is clear that the present model of IETF does not meet the requirements. (See for one description of the problem.) I would point out that there are other roles associated with evangelizing a standardized technology, but those roles usually are attached to an industry trade group or interest group without a direct standards development responsibility. Robert Snively rsnively@brocade.com +1 408 333 8135 > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Thursday, November 20, 2003 1:46 AM > To: Robert Snively > Cc: 'problem-statement@alvestrand.no' > Subject: Re: Response to WG last call, Problem Statement: Thoughts on > the IET F problem statement > > > On Wed, 19 Nov 2003, Robert Snively wrote: > > First let me briefly introduce myself. I have created and led the > > creation of national and international standards in the > INCITS, IEEE, > > and IETF environments. I have additionally created defacto > standards > > in industry interest organizations, both commercial and voluntary. > > As a result, I have a fairly diverse background in the creation of > > standards and can speak directly to the challenges as seen from > > the working group and area levels. >From my experiences, I > believe that > > I can provide some helpful consideration to the overall IETF process > > up to the IESG level. > [...] > > This clearly shows that different people have different missions and > roles in mind for the IETF; some would prefer to have it as an > official SDO, in every aspect (with the problems that causes); some > others want to avoid it at all costs (with the problems we're aware > of). > > I certainly would not wish to be part of a "full SDO" IETF. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > From problem-statement-bounces@alvestrand.no Fri Nov 21 12:53:28 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 MAA24518 for ; Fri, 21 Nov 2003 12:53:27 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 79B0F61BF7; Fri, 21 Nov 2003 18:53:09 +0100 (CET) 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 1BF6161BD6 for ; Fri, 21 Nov 2003 18:53:08 +0100 (CET) Received: from tsg (40.san-jose-06-08rs.ca.dial-access.att.net[12.72.194.40]) by worldnet.att.net (mtiwmhc11) with SMTP id <2003112117530011100o5kahe>; Fri, 21 Nov 2003 17:53:04 +0000 Message-ID: <00c201c3b057$b5d2f2d0$010aff0a@tsg> From: "todd glassey" To: "Robert Snively" , References: Date: Fri, 21 Nov 2003 09:48:35 -0800 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 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Cc: problem-statement@alvestrand.no, "'Pekka Savola'" Subject: Re: Response to WG last call, Problem Statement: Thoughts on the IETF problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 Precedence: list Reply-To: todd glassey 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 is that this WG and others will likely take those drafts as the "totality" of the problems and this will impede the rest of the critical issues from being addressed as well. Todd Glassey ----- Original Message ----- From: To: "Robert Snively" Cc: ; "'Pekka Savola'" Sent: Friday, November 21, 2003 9:37 AM Subject: RE: Response to WG last call, Problem Statement: Thoughts on the IETF problem statement > > Robert, > I think you are trying to push this debate in the right direction but this > is more a "solutions" rather than a "problem" issue. The current draft > really is "good enough" so let's ship it and get on with solving the > problems rather than talking about them. > > Adding some more formality, making IETF a bit more SDO-like and improving > the scalability of the work of making standards are key issues but they are > all already identified in the problem statement. > > - Alistair URIE > > > > Robert Snively > To: "'Pekka Savola'" , Robert Snively > Sent by: cc: "'problem-statement@alvestrand.no'" > problem-statement-bounces@al Subject: RE: Response to WG last call, Problem Statement: Thoughts on the IETF problem > vestrand.no statement > > > 20/11/2003 19:19 > > > > > > > Dear Mr. Savola, > > > I can understand your concern about working within a carefully > structured system that guarantees open and fair access to > all interested participants. Such structure may seem confining. > > > However, I am puzzled by what missions and roles you have in mind for > the IETF. It is an engineering task force. I have assumed it is > intended to promulgate open common solutions for the internet. > How is that different from any other SDO, which intends to > promulgate open common solutions for its own special area of interest? > > > If there are other roles or missions that would be left out by > considering itself as a formal SDO, they do not seem to be included > in the problem statement as constraints. Could you please > expand upon this? > > > My principal point was that there is a need to more widely delegate > technical responsibility to achieve the scalability required > by today's internet standardization efforts. While there may be > many ways to do that, the present SDOs (including IEEE-Stds, INCITS, > and ISO) provide helpful and successful models which are worth > our study. I am not sure that the GPL development model of > Linux is a helpful model because of the structure of the > networking marketplace. And it is clear that the present model > of IETF does not meet the requirements. (See > for one > description of the problem.) > > > I would point out that there are other roles associated with > evangelizing a standardized technology, but those roles usually > are attached to an industry trade group or interest group without > a direct standards development responsibility. > > > Robert Snively > rsnively@brocade.com > +1 408 333 8135 > > > > > > > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: Thursday, November 20, 2003 1:46 AM > > To: Robert Snively > > Cc: 'problem-statement@alvestrand.no' > > Subject: Re: Response to WG last call, Problem Statement: Thoughts on > > the IET F problem statement > > > > > > On Wed, 19 Nov 2003, Robert Snively wrote: > > > First let me briefly introduce myself. I have created and led the > > > creation of national and international standards in the > > INCITS, IEEE, > > > and IETF environments. I have additionally created defacto > > standards > > > in industry interest organizations, both commercial and voluntary. > > > As a result, I have a fairly diverse background in the creation of > > > standards and can speak directly to the challenges as seen from > > > the working group and area levels. >From my experiences, I > > believe that > > > I can provide some helpful consideration to the overall IETF process > > > up to the IESG level. > > [...] > > > > This clearly shows that different people have different missions and > > roles in mind for the IETF; some would prefer to have it as an > > official SDO, in every aspect (with the problems that causes); some > > others want to avoid it at all costs (with the problems we're aware > > of). > > > > I certainly would not wish to be part of a "full SDO" IETF. > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > > > > From problem-statement-bounces@alvestrand.no Fri Nov 21 13:45:54 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 NAA26354 for ; Fri, 21 Nov 2003 13:45:53 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BB67F61BE6; Fri, 21 Nov 2003 19:45:33 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3410061BB9; Fri, 21 Nov 2003 19:45:32 +0100 (CET) Date: Fri, 21 Nov 2003 10:45:31 -0800 From: Harald Tveit Alvestrand To: Robert Snively , "'problem-statement@alvestrand.no'" Message-ID: <98373914.1069411530@halvestr-w2k1> In-Reply-To: References: X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: Response to WG last call, Problem Statement: Thoughts on the IET F problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 Robert, let me just say for the record that I disagree with you. I believe the fact that the IETF has technically competent leaders who are expected to use that competence when leading the organization is a central reason why the IETF has been successful in a number of areas where ISO, ANSI, ITU and many others have failed. I also disagree with your comments about the value of corporate membership and the value of doing work (almost) only at face-to-face meetings (while I agree that sometimes more face-to-face meetings are useful). Differentiation is not a goal in itself. But neither is being like others. Harald From problem-statement-bounces@alvestrand.no Fri Nov 21 13: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 NAA26417 for ; Fri, 21 Nov 2003 13:49:03 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8C00E61BFF; Fri, 21 Nov 2003 19:48:43 +0100 (CET) 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 4DA8B61BD6; Fri, 21 Nov 2003 19:48:40 +0100 (CET) Received: from tsg (40.san-jose-06-08rs.ca.dial-access.att.net[12.72.194.40]) by worldnet.att.net (mtiwmhc11) with SMTP id <2003112118483511100o46nie>; Fri, 21 Nov 2003 18:48:38 +0000 Message-ID: <00f501c3b05f$792eae70$010aff0a@tsg> From: "todd glassey" To: "Harald Tveit Alvestrand" , "Robert Snively" , References: <98373914.1069411530@halvestr-w2k1> Date: Fri, 21 Nov 2003 10:44:13 -0800 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 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Subject: Re: Response to WG last call, Problem Statement: Thoughts on the IET F problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 Precedence: list Reply-To: todd glassey 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 So Harald - what are the goals then? To provide this open and fair environment for the creation of Internet Standards? Todd ----- Original Message ----- From: "Harald Tveit Alvestrand" To: "Robert Snively" ; Sent: Friday, November 21, 2003 10:45 AM Subject: Re: Response to WG last call, Problem Statement: Thoughts on the IET F problem statement > Robert, > > let me just say for the record that I disagree with you. > > I believe the fact that the IETF has technically competent leaders who are > expected to use that competence when leading the organization is a central > reason why the IETF has been successful in a number of areas where ISO, > ANSI, ITU and many others have failed. > > I also disagree with your comments about the value of corporate membership > and the value of doing work (almost) only at face-to-face meetings (while I > agree that sometimes more face-to-face meetings are useful). > > Differentiation is not a goal in itself. > But neither is being like others. > > Harald > From problem-statement-bounces@alvestrand.no Fri Nov 21 14:42:21 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 OAA28331 for ; Fri, 21 Nov 2003 14:42:21 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9B7C261BFD; Fri, 21 Nov 2003 20:42:01 +0100 (CET) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from drakken.dbc.mtview.ca.us (unknown [65.125.189.56]) by eikenes.alvestrand.no (Postfix) with ESMTP id A913161BF7; Fri, 21 Nov 2003 20:41:57 +0100 (CET) Received: from drakken.dbc.mtview.ca.us (localhost [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.9/8.12.9) with SMTP id hALJfsvv000843; Fri, 21 Nov 2003 11:41:55 -0800 (PST) Date: Fri, 21 Nov 2003 11:41:54 -0800 From: Marshall Rose To: Harald Tveit Alvestrand Message-Id: <20031121114154.25dfec52.mrose+internet.ietf.problem-statement@dbc.mtview.ca.us> In-Reply-To: <98373914.1069411530@halvestr-w2k1> References: <98373914.1069411530@halvestr-w2k1> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "'problem-statement@alvestrand.no'" Subject: Re: Response to WG last call, Problem Statement: Thoughts on the IET F problem statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 believe the fact that the IETF has technically competent leaders who are > expected to use that competence when leading the organization is a central > reason why the IETF has been successful in a number of areas where ISO, > ANSI, ITU and many others have failed. > > I also disagree with your comments about the value of corporate membership > and the value of doing work (almost) only at face-to-face meetings (while I > agree that sometimes more face-to-face meetings are useful). > > Differentiation is not a goal in itself. > But neither is being like others. i'm going to take this opportunity to agree with, and amplify, what harald is saying. each different style of organization has its own set of advantages, and frankly, none of the styles have succeeded to the point of achieving "one size fits all status" -- it is still the case where the "best tool should be used for the job". i believe now, as i did during the ietf's "post-kobe revolution", that the fundamentals of the ietf remain strong. hence, i'm interested in seeing what can be done in the way of an ietf "point release" (moving from 0.91 to 0.92). /mtr From problem-statement-bounces@alvestrand.no Tue Nov 25 21:37: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 VAA22386 for ; Tue, 25 Nov 2003 21:37:54 -0500 (EST) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0FB6E61BAB; Wed, 26 Nov 2003 03:37:36 +0100 (CET) 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 BAD4D61BAB for ; Wed, 26 Nov 2003 03:37:33 +0100 (CET) Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOpYZ-0007Zt-Vu for problem-statement@alvestrand.no; Wed, 26 Nov 2003 02:37:32 +0000 Date: Wed, 26 Nov 2003 11:37:05 +0900 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed From: Avri Doria To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit Message-Id: <6C140EBA-1FB9-11D8-A38A-000393CC2112@acm.org> X-Mailer: Apple Mail (2.553) Subject: Problem Statement Second Last Call Concluded X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.3 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 As the November 24 has come and gone this second last call on "IETF Problem Statement" (http://www.ietf.org/internet-drafts/draft-ietf-problem-issue- statement-05.txt) has ended. The co-chairs and the editor are currently reviewing the comments to see which ones, if any, reflect a changed consensus on comments made during the first Last Call or reflect on changes made to the document subsequent to the first WG Last Call. Thanks to all who commented. a.