From problem-statement-bounces@alvestrand.no Sun Jun 1 06:27:10 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04007 for ; Sun, 1 Jun 2003 06:27:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BB06F6257A; Sun, 1 Jun 2003 12:26:40 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3C9CB62577 for ; Sun, 1 Jun 2003 12:26:38 +0200 (CEST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])ESMTP id h51AQYA07387 for ; Sun, 1 Jun 2003 05:26:35 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10MXFN>; Sun, 1 Jun 2003 12:26:33 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501AA02E2@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: problem-statement@alvestrand.no Date: Sun, 1 Jun 2003 12:26:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Query: adding additional AD X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > > At Fri, 30 May 2003 09:32:52 -0400, Melinda Shore wrote: > Should we add an additional AD to deal with process issues? > No. Bert From problem-statement-bounces@alvestrand.no Sun Jun 1 08:59:14 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06088 for ; Sun, 1 Jun 2003 08:59:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 587E56225B; Sun, 1 Jun 2003 14:58:45 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mx-out.daemonmail.net (mx-out.daemonmail.net [216.104.160.39]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8048E621FA for ; Sun, 1 Jun 2003 14:58:37 +0200 (CEST) Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.9.3p2/8.9.3) with SMTP id FAA52443 for ; Sun, 1 Jun 2003 05:58:35 -0700 (PDT) (envelope-from spencer@mcsr-labs.org) Received: from (12.237.229.250 [12.237.229.250]) by mail.varaha.com with SMTP id ndD0JiJ2 Sun, 01 Jun 2003 05:58:35 -0700 (PDT) Message-ID: <069c01c3283d$83a21720$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> Date: Sun, 1 Jun 2003 07:58:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: Doing the Right Things? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 agree with Keith's points here - a very valuable contribution to the discussion. I have one addition. Spencer ----- Original Message ----- From: "Keith Moore" To: "Margaret Wasserman" Cc: ; Sent: Saturday, May 31, 2003 10:38 PM Subject: Re: Doing the Right Things? [deleted down to] > 4. We need to reorganize our document series. This is actually a point where it helps to be a relative newbie. The RFC series is just about opaque to newcomers to the IETF. Ask Keith says, we adjusted as we went, but the most reliable way I have to look at "what's out there" in a field I've not worked in previously is to find a working group home page that "tags" relevant RFCs. This is not reliable. "Reviewing the archives" to find out "what's out there" for Internet Mail is not scalable, for instance. The hurdle I see is that there actually is an "editor role" that's missing - not today's draft editors, and not today's "rfc editor", but an editor that takes the output of successful Document Actions and merging them into existing specifications, where this is applicable. That's how other SDOs I've worked with can maintain a numbering scheme - because STD 007 really would tell you how TCP works, as opposed to "STD 007 (RFC 793) plus a bunch of other specifications that are either proposed standards or experimental-track". As Keith points out, none of us are getting any younger, and even if we enforced "decay to Historical", the number of relevant WORDS that describe the way TCP works are increasing (to use my favorite example), and the number of relevant documents that describe the way TCP works are increasing. Just adding another layer of meat is a great way to make sandwiches and a less-great way to maintain specifications long-term... I'm not saying we need to fix this the way other SDOs do, but can others say whether it's a problem for them? Spencer > > (this is a problem that I don't think is touched on in the current draft) > > Lots of people complain that RFCs are too often used to give things the > appearance of standardization even when they have not been approved for that. > That is probably true, but it's not what I mean here. > > The problem I see here is that we now have so many RFCs that it's too easy for > some important bit of information to get lost. Sequential numbering was fine > when there were only a couple of thousand RFCs (and when you could ignore > the first several hundred), and many of us had the important RFC numbers > memorized, but now there are just too many (or maybe I'm getting too old, > but I'm not the only one getting older..) I see useful work getting unnoticed > because it's buried in some obscure RFC number. > > Some SDOs have a numbering scheme that reflects categories, and I think we > might do well to consider such a scheme for IETF documents. This probably > means abandoning the linear RFC numbering scheme entirely, though it doesn't > mean that we have to stop calling them RFCs. From problem-statement-bounces@alvestrand.no Sun Jun 1 12:45:00 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20746 for ; Sun, 1 Jun 2003 12:44:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 54D28622AF; Sun, 1 Jun 2003 18:44:29 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail04.zma.compaq.com (mailout.zma.compaq.com [161.114.64.104]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5EDC0621FA for ; Sun, 1 Jun 2003 18:44:26 +0200 (CEST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id D57DBB9FA; Sun, 1 Jun 2003 12:44:24 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sun, 1 Jun 2003 12:44:24 -0400 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="us-ascii" Date: Sun, 1 Jun 2003 12:44:24 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04284740@tayexc13.americas.cpqcorp.net> Thread-Topic: Query: adding additional AD Thread-Index: AcMnND76stOyfuNyQKaUIOPthGZ8RgBKMm5g From: "Bound, Jim" To: "Randy Bush" , "Margaret Wasserman" X-OriginalArrivalTime: 01 Jun 2003 16:44:24.0781 (UTC) FILETIME=[0F274FD0:01C3285D] Cc: problem-statement@alvestrand.no Subject: RE: Query: adding additional AD X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA20746 I agree to. No. /jim > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Saturday, May 31, 2003 1:19 AM > To: Margaret Wasserman > Cc: problem-statement@alvestrand.no > Subject: Re: Query: adding additional AD > > > > No, I'd prefer that the IESG didn't add a new AD. > > agree > > From problem-statement-bounces@alvestrand.no Sun Jun 1 12:47:36 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20928 for ; Sun, 1 Jun 2003 12:47:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4F400622AF; Sun, 1 Jun 2003 18:47:07 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by eikenes.alvestrand.no (Postfix) with ESMTP id 66816621FA for ; Sun, 1 Jun 2003 18:47:00 +0200 (CEST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 8D13B8A40; Sun, 1 Jun 2003 12:46:59 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sun, 1 Jun 2003 12:46:59 -0400 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="us-ascii" Date: Sun, 1 Jun 2003 12:46:59 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04284741@tayexc13.americas.cpqcorp.net> Thread-Topic: Doing the Right Things? Thread-Index: AcMn4TrUPhjRnnu/QDeErkACAapbOQAe+Jlg From: "Bound, Jim" To: "Margaret Wasserman" , X-OriginalArrivalTime: 01 Jun 2003 16:46:59.0515 (UTC) FILETIME=[6B61D8B0:01C3285D] Subject: RE: Doing the Right Things? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA20928 I need more time to think about this. I think Keith raised good issues. I think we are missing something but I am not sure right now how to put it. But I agree we need to do soemthing. Are we in that mode now? I think the bar for PS is to HIGH as one input that keeps going thru my mind, but that might be fixed with what Keith suggested. I need most of this week before I can respond with real thought and contemplation. I assume that is ok with the chairs. Lets not rush this one, but get it done in timely manner too. /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Saturday, May 31, 2003 9:53 PM > To: problem-statement@alvestrand.no > Subject: Doing the Right Things? > > > > Hi All, > > I have a concern about the type of discussions that we've > been having regarding the process document, so far... > > The discussion has focused quite heavily on who should > manage the improvement processes and very little on what > those improvement processes should be. > > The process document currently recommends four separate, > parallel near-term efforts and a longer-term effort, as > follows: > > Near-Term: > (1) Form a WG intended to improve the quality, > timeliness and predictability of IETF > WG output, by improving our quality and > review processes. > > (2) Continue and expand our ongoing educational > efforts for WG chairs and participants, > including the addition of education for > editors. A BOF request for Vienna has > already been circulated regarding this > work. > > (3) Encourage grass-roots efforts to deploy > tools for voluntary use by WGs and > IETF participants, particularly for > issue tracking and document sharing. > > (4) Continue efforts to promote communication > between WG chairs. This section is very > weak, and additional suggestions would > be appreciated. > > Longer-Term: > > (5) Form an IETF Improvement WG that will > undertake a two phase process: > > - Understand the mission, values and > goals of the IETF, and develop metrics > to measure and evaluate our current > performance. > - Make changes the organizational > structure of the IETF and/or our > standards-track processes to > improve the efficiency and > scalability of the IETF. > > So, regardless of exactly _how_ we organize to do these > things and/or _who_ does them... Do people think that > these are the right things to do? > > Margaret > > > > > From problem-statement-bounces@alvestrand.no Sun Jun 1 14:27:27 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27547 for ; Sun, 1 Jun 2003 14:27:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8312B6256C; Sun, 1 Jun 2003 20:26:56 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9C868622AF; Sun, 1 Jun 2003 20:26:53 +0200 (CEST) Date: Sun, 01 Jun 2003 20:26:53 +0200 From: Harald Tveit Alvestrand To: Keith Moore Message-ID: <9690000.1054492013@askvoll.hjemme.alvestrand.no> In-Reply-To: <20030531233816.40e5dbf9.moore@cs.utk.edu> References: <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Cc: problem-statement@alvestrand.no Subject: New ways to do things (Re: Doing the Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA27547 --On lørdag, mai 31, 2003 23:38:16 -0400 Keith Moore wrote: > 3. We need to see if there are specific kinds of areas or activities that > we need to engage in, for which our WG processes don't work well. > > WGs are the IETF version of Maslow's hammer. Any time we have a problem > we want to form a working group to look at it. But working groups (and > the assumptions about WG operation that go with them) are not always a > good way to look at a problem. Sometimes a different mode of > conversation, or different procedures, or different management > structures, are appropriate. > > We need to understand the limitations of the WG process and determine > whether there should be exceptions to that process for activities that > are not chartered to develop technical protocol standards. I have thought this too. There are working groups that function in a number of different modes: - SIMPLE expects to produce a document set, then shut down - the "classical working group" model. - LDAPBIS is trying to pick up an old document set, and do the work required to get it to Draft; it's not trying to invent (much) new technology. - IPv6 is chartered to complete a document set, but has in the past been regarded as "the group responsible for everything to do with the IPv6 technology area" - MBONED is "a forum for coordinating the deployment, engineering, and operation of multicast routing protocols and procedures in the global Internet......This is not meant to be a protocol development Working Group." - IDR seems to be the permanent guardian of the BGP specification - TSVWG is a forum for developing proposals that do not merit their own working groups. Yet the rules for working groups, and the ideals we sometimes tout for how to manage working groups, are strongly biased towards the "classical" model. We also have directorates. And we have many (probably hundreds) of mailing lists that have been IETF WGs, or do IETF things, but with no way anyone could find them from the IETF's "official" information. Would we be better off if we developed a few terms different from "working group" that we could use to name classes of entity that do functions in the IETF, but do not behave like "classical" working groups? Harald From problem-statement-bounces@alvestrand.no Mon Jun 2 04:05:29 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27325 for ; Mon, 2 Jun 2003 04:05:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 59DBE623CD; Mon, 2 Jun 2003 10:04:57 +0200 (CEST) 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 274DC621B8 for ; Mon, 2 Jun 2003 10:04:54 +0200 (CEST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])h5284rD23830 for ; Mon, 2 Jun 2003 11:04:53 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com ; Mon, 2 Jun 2003 11:04:52 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 2 Jun 2003 11:04:52 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 2 Jun 2003 11:03:33 +0300 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" Date: Mon, 2 Jun 2003 11:03:32 +0300 Message-ID: Thread-Topic: Doing the Right Things? Thread-Index: AcMn74xvozROsnSmTguen3/S0VwzZQA7KFbQ From: To: X-OriginalArrivalTime: 02 Jun 2003 08:03:33.0479 (UTC) FILETIME=[7656CF70:01C328DD] Cc: problem-statement@alvestrand.no Subject: RE: Doing the Right Things? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA27325 Hi Keith, > 1. We need to define the discipline of Internet Protocol Engineering. > > By that, I mean we need to enumerate a series of steps that should > normally be followed, more or less in order, when developing or modifying a > protocol for use on the Internet. It doesn't have to be a long or > complicated set of steps, and it doesn't have to be rigid. The main thing > is to establish that (for instance) you really do need to understand your > threat model and choose a security technology *before* you design your > protocol - or (for instance) the time to identify other parties that > your protocol might effect and work out compromises about how to minimize > adverse impact is *before* you do detailed protocol design or tweaking. > And maybe it would include 'prototyping' as one of the steps to occur > before standardizing. (though this doesn't mean that the prototype has > to implement all features of the standard) I agree with you on this. This almost seems like a roadmap. I think in the past, charters have served this function, in an informal way, but I think having a loose, but more formal roadmap (for lack of a better term) for the work we undertake in the IETF would be a good thing. > 2. We need to change the methods by which working groups > conduct discussions. > > a. Mailing list discussions are often so chaotic and unstructured that > it's impossible to keep track of what is going on, the volume can be > overwhelming, it's hard to get a "sense of the room" about where the > group stands with respect to an issue, and people get so frustrated that they > resort to personal attacks (or they take the bait when offered...) > > Some groups have imposed some structure on their mailing list discussions, > with varying degrees of success in raising the signal-to-noise ratio, > improving efficiency, and maintaining opennness and high technical quality. > one thing that might be useful is to survey various groups and see what > they've done, and get an assessment of how well it worked. > > Maybe we need a "rules of order" for mailing list discussions. We might also > consider using other tools - e.g. having meetings via instant messaging, "web > voting", etc. > > Different working groups might need slightly different mechanisms depending > on size, diversity of interests, and the variety of levels of > expertise. Agreed. Also, I think it is the WG chairs' job to be list moderators as well. That means interveaning before the attacks get personal; summarizing the discussions; etc. When the mailing list becomes free-form & unstructured, I doubt much can come from it. > b. It's been repeatedly observed for several years that face-to-face meeting > time isn't used effectively - it's often taken up almost entirely by > presentations of material that could have been read in advance, leaving very > little time for activities that really do need face-to-face interaction - > like resolving tricky technical disagreements. Persistent instructions from > various ADs to WGs have had little effect. > > Powerpoint-style presentations (not that it really matters which tool is used) > tend to lull people into passivity, if not sleep. Video projectors can be > great for high quality drawings, or very occasionally, animations to > illustrate how something works - but using them to put up words (with fancy > backgrounds) that are just repeated by the speaker is to make a really > ineffective use of high-bandwidth meeting time. > > We need to understand why we are stuck in these ineffective modes, identify > changes that could get us out of this mode, and implement them for all > working groups. Even the way the room is arranged can make a difference in > the effectiveness of a discussion, but right now it's impossible to get the > room set up in anything other than theatre style seating which puts people > to sleep. Having lots of people in the room who aren't participating or even > listening also has an undesirable effect. > > Maybe we need to ban laptops in the rooms. Maybe we need to have separate > orientation sessions for newcomers to the WG so that they don't use the > normal meeting time getting up to speed. Maybe we need to require > participants to pass a basic competency test before entering the meeting room. > Maybe we need to get rid of video projectors and put up whiteboards. How about better time management; better meeting management, etc? Stronger leadership is needed & perhaps a stronger requirement for getting a WG slot at an IETF meeting is needed. The transport area is fairly strict about IETF meeting time, by the way. One real-life problem that I have in my working group is that we are coming to the point where we need to start some protocol work. I know there will be a land-grab, where many people try to bring forward proposals. In past IETFs, I've noticed having 5 presentations on the same topic (but different individual drafts) tend to be mind-numbing. I've been toying with the idea of having a group discussing (almost a roundtable) where the different parties interested in the protocol work get together and have a common discussion time at the IETF up front - highlighting similarities & differences between the proposals & general open issues. > I suggest that the WG identify what kinds of things need to take place in > face-to-face meetings; that these things be given priority on meeting > agendas, that ADs check the agendas to ensure that the WG is planning > to use meeting time appropriately. Also we should not assume that > face-to-face meetings have to be narrowly focused on the WG; face-to-face > meetings can also be good times to resolve differences with other WGs or other > interests that aren't represented by WGs. I definately agree. John From problem-statement-bounces@alvestrand.no Mon Jun 2 08:28:04 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04525 for ; Mon, 2 Jun 2003 08:28:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 066CD6256C; Mon, 2 Jun 2003 14:27:31 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from athene.wz-berlin.de (athene.wz-berlin.de [193.174.6.3]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6880F623CD for ; Mon, 2 Jun 2003 14:27:24 +0200 (CEST) Received: from medea.wz-berlin.de ([193.174.6.5]) by athene.wz-berlin.de with esmtp (Exim 4.20) id 19MoPK-0005Ak-1H; Mon, 02 Jun 2003 14:27:22 +0200 Received: from ERDE/SpoolDir by medea.wz-berlin.de (Mercury 1.48); 2 Jun 03 14:27:21 +0200 Received: from SpoolDir by ERDE (Mercury 1.48); 2 Jun 03 14:27:17 +0200 From: "Jeanette Hofmann" Organization: Wissenschaftszentrum Berlin To: Date: Mon, 02 Jun 2003 14:27:14 +0200 MIME-Version: 1.0 Message-ID: <3EDB5EC4.22960.8ABC91@localhost> Priority: normal In-reply-to: X-mailer: Pegasus Mail for Windows (v4.11) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at wz-berlin.de Cc: problem-statement@alvestrand.no Subject: RE: Doing the Right Things? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7BIT On 2 Jun 2003 at 11:03, john.loughney@nokia.com wrote: > > Different working groups might need slightly different mechanisms depending > > on size, diversity of interests, and the variety of levels of > > expertise. > > Agreed. Also, I think it is the WG chairs' job to be list moderators as well. > That means interveaning before the attacks get personal; summarizing the > discussions; etc. When the mailing list becomes free-form & unstructured, > I doubt much can come from it. Do you think that all working groups should appoint a moderator? > > > b. It's been repeatedly observed for several years that face-to-face meeting > > time isn't used effectively - it's often taken up almost entirely by > > presentations of material that could have been read in advance, leaving very > > little time for activities that really do need face-to-face interaction - > > like resolving tricky technical disagreements. Persistent instructions from > > various ADs to WGs have had little effect. > > > > Powerpoint-style presentations (not that it really matters which tool is used) > > tend to lull people into passivity, if not sleep. Video projectors can be > > great for high quality drawings, or very occasionally, animations to > > illustrate how something works - but using them to put up words (with fancy > > backgrounds) that are just repeated by the speaker is to make a really > > ineffective use of high-bandwidth meeting time. > > > > We need to understand why we are stuck in these ineffective modes, Judging from the improvements you and Keith suggest, the answer seems to be simple: making effective use of face-to-face meeting time means more preparatory work. Jeanette identify > > changes that could get us out of this mode, and implement them for all > > working groups. Even the way the room is arranged can make a difference in > > the effectiveness of a discussion, but right now it's impossible to get the > > room set up in anything other than theatre style seating which puts people > > to sleep. Having lots of people in the room who aren't participating or even > > listening also has an undesirable effect. > > > > Maybe we need to ban laptops in the rooms. Maybe we need to have separate > > orientation sessions for newcomers to the WG so that they don't use the > > normal meeting time getting up to speed. Maybe we need to require > > participants to pass a basic competency test before entering the meeting room. > > Maybe we need to get rid of video projectors and put up whiteboards. > > How about better time management; better meeting management, etc? Stronger > leadership is needed & perhaps a stronger requirement for getting a WG > slot at an IETF meeting is needed. The transport area is fairly strict > about IETF meeting time, by the way. > > One real-life problem that I have in my working group is that we are coming > to the point where we need to start some protocol work. I know there will > be a land-grab, where many people try to bring forward proposals. In past > IETFs, I've noticed having 5 presentations on the same topic (but different > individual drafts) tend to be mind-numbing. I've been toying with the idea > of having a group discussing (almost a roundtable) where the different > parties interested in the protocol work get together and have a common > discussion time at the IETF up front - highlighting similarities & differences > between the proposals & general open issues. > > > I suggest that the WG identify what kinds of things need to take place in > > face-to-face meetings; that these things be given priority on meeting > > agendas, that ADs check the agendas to ensure that the WG is planning > > to use meeting time appropriately. Also we should not assume that > > face-to-face meetings have to be narrowly focused on the WG; face-to-face > > meetings can also be good times to resolve differences with other WGs or other > > interests that aren't represented by WGs. > > I definately agree. > > > John From problem-statement-bounces@alvestrand.no Mon Jun 2 08:31:54 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04648 for ; Mon, 2 Jun 2003 08:31:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4E0EB6256C; Mon, 2 Jun 2003 14:31:23 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2F9C8623CD for ; Mon, 2 Jun 2003 14:31:12 +0200 (CEST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])h52CVAW01638 for ; Mon, 2 Jun 2003 15:31:10 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com ; Mon, 2 Jun 2003 15:31:10 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 2 Jun 2003 15:31:10 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 2 Jun 2003 15:31:09 +0300 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" Date: Mon, 2 Jun 2003 15:31:08 +0300 Message-ID: Thread-Topic: Doing the Right Things? Thread-Index: AcMpAl8B7T1Y5LLYRRWJNKlx3PZBiQAABVLA From: To: X-OriginalArrivalTime: 02 Jun 2003 12:31:09.0846 (UTC) FILETIME=[D8ADFB60:01C32902] Cc: problem-statement@alvestrand.no Subject: RE: Doing the Right Things? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA04648 Hi Jeanette, > > Agreed. Also, I think it is the WG chairs' job to be list > moderators as well. > > That means interveaning before the attacks get personal; > summarizing the > > discussions; etc. When the mailing list becomes free-form > & unstructured, > > I doubt much can come from it. > > Do you think that all working groups should appoint a moderator? Well, perhaps I've naively assumed that the WG chairs were the moderator. In fact, I think the moderator MUST be the chair(s), as the chair needs to work out the consensus. Part of moderating is calling consensus. > > > b. It's been repeatedly observed for several years that > face-to-face meeting > > > time isn't used effectively - it's often taken up almost > entirely by > > > presentations of material that could have been read in > advance, leaving very > > > little time for activities that really do need > face-to-face interaction - > > > like resolving tricky technical disagreements. > Persistent instructions from > > > various ADs to WGs have had little effect. > > > > > > Powerpoint-style presentations (not that it really > matters which tool is used) > > > tend to lull people into passivity, if not sleep. Video > projectors can be > > > great for high quality drawings, or very occasionally, > animations to > > > illustrate how something works - but using them to put up > words (with fancy > > > backgrounds) that are just repeated by the speaker is to > make a really > > > ineffective use of high-bandwidth meeting time. > > > > > > We need to understand why we are stuck in these ineffective modes, > > Judging from the improvements you and Keith suggest, the answer seems to > be simple: making effective use of face-to-face meeting time means more > preparatory work. One would assume (or at least hope) that would be self-evident... John From problem-statement-bounces@alvestrand.no Mon Jun 2 08:40:41 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04828 for ; Mon, 2 Jun 2003 08:40:41 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AD6C06257A; Mon, 2 Jun 2003 14:40:10 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4F8296256C for ; Mon, 2 Jun 2003 14:40:00 +0200 (CEST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])h52CdxW11195 for ; Mon, 2 Jun 2003 15:39:59 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com ; Mon, 2 Jun 2003 15:39:59 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 2 Jun 2003 15:39:58 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 2 Jun 2003 15:39:57 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 2 Jun 2003 15:39:57 +0300 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" Date: Mon, 2 Jun 2003 15:39:20 +0300 Message-ID: Thread-Topic: Doing the Right Things? Thread-Index: AcMn4TeomEA8l5+9T5mPhcaJ0MVi+wBIaVSQ From: To: , X-OriginalArrivalTime: 02 Jun 2003 12:39:57.0230 (UTC) FILETIME=[130664E0:01C32904] Subject: RE: Doing the Right Things? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA04828 Hi Margaret, I generally agree with your points below, but I would like to add one to the near-term: 0) Improving the quality of communications in the IETF. In following this list, and getting reading for the IETF, I realised that the only time I have 'quality' discussions with my ADs / the IESG / the IAB tends to be at the IETF meetings (3 times a year) - but even then, it is haphazard because everyone is serious overload during the meeting. My AD is overloaded currently (and has been for a number of years) so it is very difficult to get input / thoughts on the technical direction of my WG. My sent an updated charter for approval & I secretely hoped that the IESG / IAB would engage me on the direction of WG .. but that didn't really happen. So, this makes me think your points below will not have much of an impact if we don't address some other things as well. It seems to me that the current way of working in the IETF was designed many years ago, for a much smaller IETF & the process is showing its age. I am not sure about solutions, but I do have some ideas. However, before offering them, I wonder what others think about communications within the IETF, in general? thanks, John > I have a concern about the type of discussions that we've > been having regarding the process document, so far... > > The discussion has focused quite heavily on who should > manage the improvement processes and very little on what > those improvement processes should be. > > The process document currently recommends four separate, > parallel near-term efforts and a longer-term effort, as > follows: > > Near-Term: > (1) Form a WG intended to improve the quality, > timeliness and predictability of IETF > WG output, by improving our quality and > review processes. > > (2) Continue and expand our ongoing educational > efforts for WG chairs and participants, > including the addition of education for > editors. A BOF request for Vienna has > already been circulated regarding this > work. > > (3) Encourage grass-roots efforts to deploy > tools for voluntary use by WGs and > IETF participants, particularly for > issue tracking and document sharing. > > (4) Continue efforts to promote communication > between WG chairs. This section is very > weak, and additional suggestions would > be appreciated. > > Longer-Term: > > (5) Form an IETF Improvement WG that will > undertake a two phase process: > > - Understand the mission, values and > goals of the IETF, and develop metrics > to measure and evaluate our current > performance. > - Make changes the organizational > structure of the IETF and/or our > standards-track processes to > improve the efficiency and > scalability of the IETF. > > So, regardless of exactly _how_ we organize to do these > things and/or _who_ does them... Do people think that > these are the right things to do? > > Margaret > > > > > From problem-statement-bounces@alvestrand.no Mon Jun 2 08:46:22 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04955 for ; Mon, 2 Jun 2003 08:46:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E44986257A; Mon, 2 Jun 2003 14:45:51 +0200 (CEST) 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 E0BB36256C for ; Mon, 2 Jun 2003 14:45:49 +0200 (CEST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])h52CjjD23118 for ; Mon, 2 Jun 2003 15:45:45 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com ; Mon, 2 Jun 2003 15:45:44 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 2 Jun 2003 15:45:43 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 2 Jun 2003 15:45:39 +0300 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" Date: Mon, 2 Jun 2003 15:45:38 +0300 Message-ID: Thread-Topic: WG Quality Processes WG Thread-Index: AcMn4v5Ho3TZsbZ5TPqmAQaIncpnkABIRnkQ From: To: , X-OriginalArrivalTime: 02 Jun 2003 12:45:39.0274 (UTC) FILETIME=[DEE62AA0:01C32904] Subject: RE: WG Quality Processes WG X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA04955 Margaret, > So, do people think we need a WG like this? If so, does > it make sense to hold a BOF in Vienna? I'm happy to do > some leg work (write up the indicated process in more > detail, and propose a couple of improvements to consider) > if people think that this is a reasonable way to proceed. I think we should have a BOF. > > 5.1.1 Suggestions to Improve WG Quality Processes > > A working group should be formed in the General Area of the IETF to > oversee improvements to the quality processes used in IETF WGs, and > to increase the effectiveness of IETF reviews at all levels. This > group should take an experimental, iterative approach to these > improvements: > > - Identify and prioritize a set of promising proposals for > improvement. > - Figure out what each proposal is trying to improve (in > measurable terms) and define a metric to measure > performance in that area. > - Determine the current level of performance against the > defined metric. > - Institute each change in a few representative WGs (on a > volunteer basis). > - Measure the results to determine if each change was > successful. > - Make successful changes available IETF-wide, by publishing > them in BCP RFCs. > - As necessary, train WG chairs and other participants on the > how to implement the successful improvements in their WGs. > - Repeat as necessary. > > A great deal of efficiency and synergy can be achieved by adopting > common processes and tools throughout an organization. However, it > is a strength of the IETF that WG chairs are given a great deal of > latitude to choose their own processes and tools, based on the size > and nature of their WGs. So, in general, processes and tools > should be made available to WGs and WG chairs, not forced upon > them. I think the above sound good, but I would not simply keep everything at the WG level, some should be IETF-wide. It would be great, for example, if a) WGs that were more than 6 months late on one of their deliverables where sent montly reminders of the fact until either the deliverable was completed or charter was updated. b) If the Draft-tracker had a time out, so that any document sitting in a certain state for too long (say 4 months) generated a mail to the mailing list, document editor(s)/author(s), sheparding AD about the status. c) if the draft-tracker would send mail to a WG, author(s)/editor(s) everytime a document changed state and so forth. John From problem-statement-bounces@alvestrand.no Mon Jun 2 08:48:13 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05009 for ; Mon, 2 Jun 2003 08:48:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E43046257A; Mon, 2 Jun 2003 14:47:42 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3001B6256C for ; Mon, 2 Jun 2003 14:47:40 +0200 (CEST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h52Clb9N004593; Mon, 2 Jun 2003 05:47:37 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHW47479; Mon, 2 Jun 2003 05:47:35 -0700 (PDT) Message-Id: <200306021247.AHW47479@mira-sjc5-c.cisco.com> To: john.loughney@nokia.com From: Melinda Shore In-Reply-To: Message from john.loughney@nokia.com Date: Mon, 02 Jun 2003 08:47:34 -0400 Cc: mrw@windriver.com Cc: problem-statement@alvestrand.no Subject: Re: Doing the Right Things? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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'm concerned that we may be wandering a bit far into solutions. Part of the problem reflects a broader IETF problem with getting things done in a timely way; that spinning off a new effort to identify short-term changes may simply take too long. It may be worth talking specifically about how a short-term effort can be initiated without all the overhead associated with wg creation, etc. Melinda From problem-statement-bounces@alvestrand.no Mon Jun 2 09:04:12 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05505 for ; Mon, 2 Jun 2003 09:04:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 27F6D62577; Mon, 2 Jun 2003 15:03:42 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id EF0BD6256C; Mon, 2 Jun 2003 15:03:35 +0200 (CEST) Date: Mon, 02 Jun 2003 15:03:35 +0200 From: Harald Tveit Alvestrand To: john.loughney@nokia.com, problem-statement@alvestrand.no Message-ID: <71130000.1054559015@askvoll.hjemme.alvestrand.no> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: RE: WG Quality Processes WG X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 John, the mechanical things can be done, with just a Small Matter of Programming... the trick is to figure out which ones actually help.... --On mandag, juni 02, 2003 15:45:38 +0300 john.loughney@nokia.com wrote: > It would be great, for example, if > > a) WGs that were more than 6 months late on one of their deliverables > where sent montly reminders of the fact until either the deliverable > was completed or charter was updated. currently we're going for bimonthly reminders to chairs on all overdue milestones... I'm not sure how much that helps in the long run, but it's a start... > b) If the Draft-tracker had a time out, so that any document sitting in > a certain state for too long (say 4 months) generated a mail to the > mailing list, document editor(s)/author(s), sheparding AD about the > status. well.... state "RFC Published" and "dead" are quite OK for a document to stay in, of course; "AD is watching" is doubtful (could change if/when the system is extended to do WG tracking) - otherwise, it would seem to make sense. > c) if the draft-tracker would send mail to a WG, author(s)/editor(s) > everytime a document changed state > Already on the wishlist. I don't think the whole WG wants *all* the state changes, so the WG chairs could act as a filter..... From problem-statement-bounces@alvestrand.no Mon Jun 2 09:11:49 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05730 for ; Mon, 2 Jun 2003 09:11:49 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C554962590; Mon, 2 Jun 2003 15:11:18 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 981916256C; Mon, 2 Jun 2003 15:11:16 +0200 (CEST) Date: Mon, 02 Jun 2003 15:11:16 +0200 From: Harald Tveit Alvestrand To: Melinda Shore , john.loughney@nokia.com Message-ID: <71910000.1054559476@askvoll.hjemme.alvestrand.no> In-Reply-To: <200306021247.AHW47479@mira-sjc5-c.cisco.com> References: <200306021247.AHW47479@mira-sjc5-c.cisco.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: mrw@windriver.com Cc: problem-statement@alvestrand.no Subject: Re: Doing the Right Things? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 mandag, juni 02, 2003 08:47:34 -0400 Melinda Shore wrote: > I'm concerned that we may be wandering a bit far into > solutions. Part of the problem reflects a broader IETF > problem with getting things done in a timely way; that > spinning off a new effort to identify short-term changes may > simply take too long. It may be worth talking specifically > about how a short-term effort can be initiated without all > the overhead associated with wg creation, etc. speaking strictly as a participant.... I think that for each solution path to be pursued, a core team with competence and energy to drive the process is needed, no matter what - and that once we have that, it almost doesn't matter how long the formal process to start the thing is; they can go to work right away, and do course corrections as part of the chartering process, rather than waiting for the "formalities" to complete before starting work. Of course, that depends on there actually being some common understanding that this is the right path to take..... Harald From problem-statement-bounces@alvestrand.no Mon Jun 2 09:24:58 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06250 for ; Mon, 2 Jun 2003 09:24:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C41286257D; Mon, 2 Jun 2003 15:24:27 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.wrs.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id AA42A6257D for ; Mon, 2 Jun 2003 15:24:20 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.22]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA19684 for ; Mon, 2 Jun 2003 06:23:59 -0700 (PDT) Message-Id: <5.1.0.14.2.20030602085717.0436b790@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 02 Jun 2003 09:12:00 -0400 To: problem-statement@alvestrand.no From: Margaret Wasserman In-Reply-To: <5.1.0.14.2.20030531215652.04333d20@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: WG Quality Processes WG X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 was hoping that someone else would say this, so that I wouldn't have to argue with myself in public again, but here goes... At 10:05 PM 5/31/2003 -0400, Margaret Wasserman wrote: >In particular, the process document currently indicates >that we should start a WG to improve WG Quality Processes, >as described below. > >So, do people think we need a WG like this? If so, does >it make sense to hold a BOF in Vienna? I do think that we should hold a BOF in Vienna, but I _don't_ agree with my own WG description anymore... IMO, the description delves too far into "solutions space". It also makes the assumptions that all of the recommendations for short term improvement to the document production process will be process-oriented changes to how WGs function, and could therefore be deployed on a per-WG basis. Given some of the excellent suggestions made recent (which may also be too much in "solutions space" for this WG), those assumptions are invalid. Instead, I think that we should hold a BOF, with the intention of starting a WG to: Improve the quality, timeliness and predictability of the document production process. And, I think that we should leave it to that WG to determine what process makes sense for the introduction of each proposal that it undertakes. IMO, we should have a single WG for this function, so that the group can consider various proposals, prioritize them, and implement them in the way that is least likely to cause chaos and mutual interference... What do folks think of that? The alternative would be to consider/implement various improvements to the document production process separately -- either through grass-roots efforts or through separate WGs. What do folks think? If we do want a WG, I think it makes sense to push for a BOF in Atlanta. This would let us put together a leadership team and vet a few proposals now, rather than waiting until Minneapolis in November to get this effort off the ground. Would folks like to use the "solutions" mailing list as a rendezvous point to discuss the formation of this group? I'll send a message over there to try to get discussion started. Margaret From problem-statement-bounces@alvestrand.no Mon Jun 2 09:30:14 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06585 for ; Mon, 2 Jun 2003 09:30:14 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EFD5D6257A; Mon, 2 Jun 2003 15:29:43 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id 36D8662581; Mon, 2 Jun 2003 15:29:29 +0200 (CEST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])h52DTSW29538; Mon, 2 Jun 2003 16:29:28 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com ; Mon, 2 Jun 2003 16:29:27 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 2 Jun 2003 16:29:27 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 2 Jun 2003 16:29:26 +0300 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" Date: Mon, 2 Jun 2003 16:29:25 +0300 Message-ID: Thread-Topic: WG Quality Processes WG Thread-Index: AcMpCSuWqt9WTO3VQAGYiwa1qrLW6AAAWQ7g From: To: , X-OriginalArrivalTime: 02 Jun 2003 13:29:26.0573 (UTC) FILETIME=[FCE42DD0:01C3290A] Subject: RE: WG Quality Processes WG X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA06585 Hi Harald, > the mechanical things can be done, with just a Small Matter of > Programming... the trick is to figure out which ones actually help.... Of course, however, I am definately a proponent of the 'more info is better' school. > > It would be great, for example, if > > > > a) WGs that were more than 6 months late on one of their deliverables > > where sent montly reminders of the fact until either the deliverable > > was completed or charter was updated. > > currently we're going for bimonthly reminders to chairs on all overdue > milestones... I'm not sure how much that helps in the long run, but it's a start... A gentle reminder is not a bad thing, speaking as a chair ... > > b) If the Draft-tracker had a time out, so that any document sitting in > > a certain state for too long (say 4 months) generated a mail to the > > mailing list, document editor(s)/author(s), sheparding AD about the > > status. > > well.... state "RFC Published" and "dead" are quite OK for a document to > stay in, of course; "AD is watching" is doubtful (could change if/when the > system is extended to do WG tracking) - otherwise, it would seem to make > sense. OK, OK, I guess I should have added 'relevant' state ... > > c) if the draft-tracker would send mail to a WG, author(s)/editor(s) > > everytime a document changed state > > Already on the wishlist. I don't think the whole WG wants *all* the state > changes, so the WG chairs could act as a filter..... That is fine, as long as it is mentioned that the chair SHOULD forward relevant info to the WG. John From problem-statement-bounces@alvestrand.no Mon Jun 2 09:39:30 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06868 for ; Mon, 2 Jun 2003 09:39:30 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A43F26257D; Mon, 2 Jun 2003 15:38:59 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3C41362572; Mon, 2 Jun 2003 15:38:56 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.22]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA24858; Mon, 2 Jun 2003 06:38:32 -0700 (PDT) Message-Id: <5.1.0.14.2.20030602092926.044074b0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 02 Jun 2003 09:34:38 -0400 To: From: Margaret Wasserman In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: harald@alvestrand.no Cc: problem-statement@alvestrand.no Subject: RE: WG Quality Processes WG X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 At 04:29 PM 6/2/2003 +0300, john.loughney@nokia.com wrote: > > Already on the wishlist. I don't think the whole WG wants *all* the state > > changes, so the WG chairs could act as a filter..... > >That is fine, as long as it is mentioned that the chair SHOULD forward >relevant info to the WG. I respectfully disagree... One of the problems with the IETF, IMO, is how little communication we have, and how much of it has to flow through certain bottlenecks (including IESG members and WG chairs). Also, why would we want to introduce the human error of a WG chair into what should be a fully automated process? There may be a bunch of "noise" transition that the WG doesn't need to know about, but the transitions between meaningful states should just be sent, automatically, directly to the WG. It's not as though state changes happen _all_ that often, and we could include some well-known tag in the subject or from field, so that folks who are irritated by them can filter them... I'd even be happy (not now, but in the lull between Vienna and Minneapolis, perhaps) to help write-up a meaningful description of each state change to include at the bottom of each e-mail message, so that newcomers and lightly engaged participants wouldn't be confused by the messages... Margaret From problem-statement-bounces@alvestrand.no Mon Jun 2 09:41:06 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06957 for ; Mon, 2 Jun 2003 09:41:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 326A06257D; Mon, 2 Jun 2003 15:40:36 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id E3B606257A; Mon, 2 Jun 2003 15:40:28 +0200 (CEST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])h52DeSW10515; Mon, 2 Jun 2003 16:40:28 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com ; Mon, 2 Jun 2003 16:40:28 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 2 Jun 2003 16:40:27 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 2 Jun 2003 16:40:26 +0300 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" Date: Mon, 2 Jun 2003 16:40:24 +0300 Message-ID: Thread-Topic: WG Quality Processes WG Thread-Index: AcMpDFeIpExC5pYXRxOMLRu8NIv7ogAABIdQ From: To: X-OriginalArrivalTime: 02 Jun 2003 13:40:26.0562 (UTC) FILETIME=[86468220:01C3290C] Cc: harald@alvestrand.no Cc: problem-statement@alvestrand.no Subject: RE: WG Quality Processes WG X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA06957 Hi Margaret, > At 04:29 PM 6/2/2003 +0300, john.loughney@nokia.com wrote: > > > Already on the wishlist. I don't think the whole WG wants > *all* the state > > > changes, so the WG chairs could act as a filter..... > > > >That is fine, as long as it is mentioned that the chair > SHOULD forward > >relevant info to the WG. > > I respectfully disagree... Do you mean that it is not a SHOULD, but a MUST 'forward relevant info to the WG? Or something else? John > One of the problems with the IETF, IMO, is how little communication > we have, and how much of it has to flow through certain bottlenecks > (including IESG members and WG chairs). Also, why would we want to > introduce the human error of a WG chair into what should be a fully > automated process? > > There may be a bunch of "noise" transition that the WG doesn't > need to know about, but the transitions between meaningful states > should just be sent, automatically, directly to the WG. It's > not as though state changes happen _all_ that often, and we > could include some well-known tag in the subject or from field, > so that folks who are irritated by them can filter them... > > I'd even be happy (not now, but in the lull between Vienna and > Minneapolis, perhaps) to help write-up a meaningful description > of each state change to include at the bottom of each e-mail > message, so that newcomers and lightly engaged participants > wouldn't be confused by the messages... > > Margaret > > > > > From problem-statement-bounces@alvestrand.no Mon Jun 2 09:45:18 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07074 for ; Mon, 2 Jun 2003 09:45:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5FEC76257D; Mon, 2 Jun 2003 15:44:47 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7C19862572; Mon, 2 Jun 2003 15:44:44 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.22]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA26911; Mon, 2 Jun 2003 06:44:20 -0700 (PDT) Message-Id: <5.1.0.14.2.20030602093734.043f1fa8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 02 Jun 2003 09:40:26 -0400 To: john.loughney@nokia.com From: Margaret Wasserman In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: harald@alvestrand.no Cc: problem-statement@alvestrand.no Subject: RE: WG Quality Processes WG X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 At 04:40 PM 6/2/2003 +0300, john.loughney@nokia.com wrote: > > >That is fine, as long as it is mentioned that the chair > > SHOULD forward > > >relevant info to the WG. > > > > I respectfully disagree... > >Do you mean that it is not a SHOULD, but a MUST 'forward relevant >info to the WG? Or something else? I mean that the chairs shouldn't have to forward the messages at all... They should just be sent to the WG by the I-D tracker, automatically. No WG chair filtering required. Margaret From problem-statement-bounces@alvestrand.no Mon Jun 2 10:29:11 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09820 for ; Mon, 2 Jun 2003 10:29:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E9D3F6257A; Mon, 2 Jun 2003 16:28:39 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mx-out.daemonmail.net (mx-out.daemonmail.net [216.104.160.39]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4657C62572 for ; Mon, 2 Jun 2003 16:28:36 +0200 (CEST) Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.9.3p2/8.9.3) with SMTP id HAA51685 for ; Mon, 2 Jun 2003 07:28:34 -0700 (PDT) (envelope-from spencer@mcsr-labs.org) Received: from (12.237.229.250 [12.237.229.250]) by mail.varaha.com with SMTP id URD00WJ2 Mon, 02 Jun 2003 07:28:33 -0700 (PDT) Message-ID: <07c001c32913$3fd1fe30$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <200306021247.AHW47479@mira-sjc5-c.cisco.com> Date: Mon, 2 Jun 2003 09:28:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: Doing the Right Things? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Dear Melinda, I might suggest backing up one more step, and cataloging the reasons we need to do a small chunk of work in the IETF. My cotribution is - relatively minor updates to an existing protocol I'm a TSV guy, mostly, and there's ongoing TSV work on TCP mechanisms for spurious timeout detection and recovery, for instance. Most of it gets done in TSVWG, which was created specifically as a catch-all for small chunks of work in TSV. What are the "small chunk" needs of other communities? Spencer ----- Original Message ----- From: "Melinda Shore" To: Cc: ; Sent: Monday, June 02, 2003 7:47 AM Subject: Re: Doing the Right Things? > I'm concerned that we may be wandering a bit far into > solutions. Part of the problem reflects a broader IETF > problem with getting things done in a timely way; that > spinning off a new effort to identify short-term changes may > simply take too long. It may be worth talking specifically > about how a short-term effort can be initiated without all > the overhead associated with wg creation, etc. > > Melinda From problem-statement-bounces@alvestrand.no Mon Jun 2 11:10:32 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11099 for ; Mon, 2 Jun 2003 11:10:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EAA9862572; Mon, 2 Jun 2003 17:10:02 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 59DE5623CD for ; Mon, 2 Jun 2003 17:10:00 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h52F9rk13497; Mon, 2 Jun 2003 11:09:55 -0400 (EDT) Date: Mon, 2 Jun 2003 11:09:52 -0400 From: Keith Moore To: Message-Id: <20030602110952.034ee6f5.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Subject: Re: Doing the Right Things? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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. We need to define the discipline of Internet Protocol > > Engineering. > > > > By that, I mean we need to enumerate a series of steps that should > > normally be followed, more or less in order, when developing or > > modifying a protocol for use on the Internet. It doesn't have to be > > a long or complicated set of steps, and it doesn't have to be rigid. > > The main thing > > is to establish that (for instance) you really do need to understand > > your threat model and choose a security technology *before* you > > design your protocol - or (for instance) the time to identify other > > parties that your protocol might effect and work out compromises > > about how to minimize adverse impact is *before* you do detailed > > protocol design or tweaking. And maybe it would include > > 'prototyping' as one of the steps to occur before standardizing. > > (though this doesn't mean that the prototype has to implement all > > features of the standard) > > I agree with you on this. This almost seems like a roadmap. I think > in the past, charters have served this function, in an informal way, > but I think having a loose, but more formal roadmap (for lack of a > better term) for the work we undertake in the IETF would be a good > thing. note also that this 'roadmap' is independent of working group processes - that is, it doesn't matter whether the engineering is being done by a working group or a group of individuals or a single person - these are steps you need to follow regardless. so while the roadmap might end up imposing some guidelines or constraints for WG operation, it shoudn't be thought of strictly in terms of WG operation. From problem-statement-bounces@alvestrand.no Mon Jun 2 12:24:12 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14066 for ; Mon, 2 Jun 2003 12:24:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AD35F62581; Mon, 2 Jun 2003 18:23:40 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5035762572 for ; Mon, 2 Jun 2003 18:23:38 +0200 (CEST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h52GNYjS003725 for ; Mon, 2 Jun 2003 09:23:35 -0700 (PDT) Received: from cisco.com (sjc-vpn1-772.cisco.com [10.21.99.4]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AGU25529; Mon, 2 Jun 2003 09:21:18 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Mon, 2 Jun 2003 12:23:35 -0400 Date: Mon, 2 Jun 2003 12:23:35 -0400 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030602162335.GG2232@sbrim-w2k> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: <5.1.0.14.2.20030531215652.04333d20@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030531215652.04333d20@mail.windriver.com> User-Agent: Mutt/1.4i Subject: Re: WG Quality Processes WG X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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'm just reluctant to make it a WG without an immutable time-to-live, less than a year. I want them to take on just one or two possible changes at a time. A change which is so major that it takes longer should be shepherded by the IESG (at this group's instigation?). It can be recreated (not just rechartered) every time. We have a precedent, the NomCom. I don't want the group to get stuck in its ways. On Sat, May 31, 2003 10:05:24PM -0400, Margaret Wasserman allegedly wrote: > A working group should be formed in the General Area of the IETF to > oversee improvements to the quality processes used in IETF WGs, and > to increase the effectiveness of IETF reviews at all levels. This > group should take an experimental, iterative approach to these > improvements: > > - Identify and prioritize a set of promising proposals for > improvement. > - Figure out what each proposal is trying to improve (in > measurable terms) and define a metric to measure performance > in that area. > - Determine the current level of performance against the > defined metric. > - Institute each change in a few representative WGs (on a > volunteer basis). > - Measure the results to determine if each change was > successful. > - Make successful changes available IETF-wide, by publishing > them in BCP RFCs. > - As necessary, train WG chairs and other participants on the > how to implement the successful improvements in their WGs. > - Repeat as necessary. From problem-statement-bounces@alvestrand.no Mon Jun 2 12:24:19 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14085 for ; Mon, 2 Jun 2003 12:24:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BA1CD6259F; Mon, 2 Jun 2003 18:23:48 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1E18A6259C for ; Mon, 2 Jun 2003 18:23:45 +0200 (CEST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h52GNeU9019856 for ; Mon, 2 Jun 2003 09:23:41 -0700 (PDT) Received: from cisco.com (sjc-vpn1-772.cisco.com [10.21.99.4]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AGU25531; Mon, 2 Jun 2003 09:21:23 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Mon, 2 Jun 2003 12:23:41 -0400 Date: Mon, 2 Jun 2003 12:23:41 -0400 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030602162340.GH2232@sbrim-w2k> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: <5.1.0.14.2.20030602093734.043f1fa8@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030602093734.043f1fa8@mail.windriver.com> User-Agent: Mutt/1.4i Subject: Re: WG Quality Processes WG X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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, Jun 02, 2003 09:40:26AM -0400, Margaret Wasserman allegedly wrote: > At 04:40 PM 6/2/2003 +0300, john.loughney@nokia.com wrote: > >> >That is fine, as long as it is mentioned that the chair > >> SHOULD forward > >> >relevant info to the WG. > >> > >> I respectfully disagree... > > > >Do you mean that it is not a SHOULD, but a MUST 'forward relevant > >info to the WG? Or something else? > > I mean that the chairs shouldn't have to forward the messages > at all... They should just be sent to the WG by the I-D tracker, > automatically. No WG chair filtering required. Agreed. From problem-statement-bounces@alvestrand.no Mon Jun 2 12:24:31 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14100 for ; Mon, 2 Jun 2003 12:24:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D6E0A625A3; Mon, 2 Jun 2003 18:23:51 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by eikenes.alvestrand.no (Postfix) with ESMTP id A24BC625A2 for ; Mon, 2 Jun 2003 18:23:49 +0200 (CEST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h52GNiHr006000 for ; Mon, 2 Jun 2003 09:23:45 -0700 (PDT) Received: from cisco.com (sjc-vpn1-772.cisco.com [10.21.99.4]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AGU25541; Mon, 2 Jun 2003 09:21:28 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Mon, 2 Jun 2003 12:23:45 -0400 Date: Mon, 2 Jun 2003 12:23:45 -0400 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030602162345.GI2232@sbrim-w2k> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <9690000.1054492013@askvoll.hjemme.alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9690000.1054492013@askvoll.hjemme.alvestrand.no> User-Agent: Mutt/1.4i Subject: Re: New ways to do things (Re: Doing the Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit On Sun, Jun 01, 2003 08:26:53PM +0200, Harald Tveit Alvestrand allegedly wrote: > --On lørdag, mai 31, 2003 23:38:16 -0400 Keith Moore > wrote: > > >3. We need to see if there are specific kinds of areas or activities that > >we need to engage in, for which our WG processes don't work well. > > > >WGs are the IETF version of Maslow's hammer. Any time we have a problem > >we want to form a working group to look at it. But working groups (and > >the assumptions about WG operation that go with them) are not always a > >good way to look at a problem. Sometimes a different mode of > >conversation, or different procedures, or different management > >structures, are appropriate. > > > >We need to understand the limitations of the WG process and determine > >whether there should be exceptions to that process for activities that > >are not chartered to develop technical protocol standards. > > I have thought this too. I like this a lot as well. > There are working groups that function in a number of different modes: .. > Yet the rules for working groups, and the ideals we sometimes tout for how > to manage working groups, are strongly biased towards the "classical" model. > > We also have directorates. And we have many (probably hundreds) of mailing > lists that have been IETF WGs, or do IETF things, but with no way anyone > could find them from the IETF's "official" information. > > Would we be better off if we developed a few terms different from "working > group" that we could use to name classes of entity that do functions in the > IETF, but do not behave like "classical" working groups? > > Harald In theory "working group" is pretty generic, so maybe you have "standards working groups", etc. Or: have one or more special areas for special *kinds* of WGs. But first do what Keith said - describe areas/activities for which WG-classic doesn't work well, and then explore alternative ways of approaching them. .swb From problem-statement-bounces@alvestrand.no Mon Jun 2 12:47:52 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14755 for ; Mon, 2 Jun 2003 12:47:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D2BC762577; Mon, 2 Jun 2003 18:47:22 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6497F623CD for ; Mon, 2 Jun 2003 18:47:19 +0200 (CEST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h52GlEaQ009010 for ; Mon, 2 Jun 2003 09:47:17 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHW67605; Mon, 2 Jun 2003 09:47:13 -0700 (PDT) Message-Id: <200306021647.AHW67605@mira-sjc5-c.cisco.com> To: problem-statement@alvestrand.no From: Melinda Shore Date: Mon, 02 Jun 2003 12:47:13 -0400 Subject: Issue tracking tool X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 We've now got an issue tracking tool up and running and available for perusal at https://rt.psg.com. It does require a login, which for IETF participants is user "ietf" with password "ietf". A general introduction is at http://rt.psg.com (note that the protocol is "http", while that for the login is "https"). Our ticket queues are problem-statement, problem-process, and problem-other. This is new to us, too, and so we'll be creating new tickets as we identify new issues. These issues are intended to be narrowly-defined and scoped - resolvable, in other words. In addition to using it to track unresolved issues, we'll also be using the issue tracker as a tool for focusing discussion. Please take a look, and check back regularly. Melinda From problem-statement-bounces@alvestrand.no Mon Jun 2 13:36:48 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16210 for ; Mon, 2 Jun 2003 13:36:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0A01962572; Mon, 2 Jun 2003 19:36:17 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.wrs.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id B99CB623CD for ; Mon, 2 Jun 2003 19:36:07 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA13391; Mon, 2 Jun 2003 10:34:53 -0700 (PDT) Message-Id: <5.1.0.14.2.20030602132439.0430e648@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 02 Jun 2003 13:30:03 -0400 To: Scott W Brim From: Margaret Wasserman In-Reply-To: <20030602162345.GI2232@sbrim-w2k> References: <9690000.1054492013@askvoll.hjemme.alvestrand.no> <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <9690000.1054492013@askvoll.hjemme.alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: New ways to do things (Re: Doing the Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA16210 At 12:23 PM 6/2/2003 -0400, Scott W Brim wrote: >On Sun, Jun 01, 2003 08:26:53PM +0200, Harald Tveit Alvestrand allegedly >wrote: > > --On lørdag, mai 31, 2003 23:38:16 -0400 Keith Moore > > >WGs are the IETF version of Maslow's hammer. Any time we have a problem > > >we want to form a working group to look at it. But working groups (and > > >the assumptions about WG operation that go with them) are not always a > > >good way to look at a problem. Sometimes a different mode of > > >conversation, or different procedures, or different management > > >structures, are appropriate. > > > > > >We need to understand the limitations of the WG process and determine > > >whether there should be exceptions to that process for activities that > > >are not chartered to develop technical protocol standards. > > > > I have thought this too. > >I like this a lot as well. Me, too. >In theory "working group" is pretty generic, so maybe you have >"standards working groups", etc. Or: have one or more special areas for >special *kinds* of WGs. But first do what Keith said - describe >areas/activities for which WG-classic doesn't work well, and then >explore alternative ways of approaching them. I have an example... We've been trying to figure out the *right* way to run a non-standards-oriented function in the IETF -- specifically internal education/training. We want to allow community visibility and input into our education priorities and programs, however there is no intention for our internal education/training efforts to produce RFCs. This is also an ongoing function, not a task-oriented function like producing a document or solving a particular technical problem. The two existing choices for group activities in the IETF are: - Directorates - Working Groups I suppose that we could have an internal education directorate, but that wouldn't help to make our efforts more visible and/or allow for wide community input. So, maybe we need a WG? It would be a weird WG, but a WG seems preferable to continuing to conduct this effort in a back-room effort... Anyway, we'll have a BOF in Vienna, and one of the things that we'll be discussing is how this effort should be organized and run on an ongoing basis. Opinions are welcome. Margaret From problem-statement-bounces@alvestrand.no Mon Jun 2 13:54:15 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17001 for ; Mon, 2 Jun 2003 13:54:14 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 28AC262572; Mon, 2 Jun 2003 19:53:44 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id DBC96623CD for ; Mon, 2 Jun 2003 19:53:37 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA27975; Mon, 2 Jun 2003 10:52:26 -0700 (PDT) Message-Id: <5.1.0.14.2.20030602134341.0438f918@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 02 Jun 2003 13:48:20 -0400 To: Scott W Brim From: Margaret Wasserman In-Reply-To: <20030602162335.GG2232@sbrim-w2k> References: <5.1.0.14.2.20030531215652.04333d20@mail.windriver.com> <5.1.0.14.2.20030531215652.04333d20@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: WG Quality Processes WG X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Scott, At 12:23 PM 6/2/2003 -0400, Scott W Brim wrote: >I'm just reluctant to make it a WG without an immutable time-to-live, >less than a year. I want them to take on just one or two possible >changes at a time. A change which is so major that it takes longer >should be shepherded by the IESG (at this group's instigation?). It can >be recreated (not just rechartered) every time. We have a precedent, >the NomCom. I don't want the group to get stuck in its ways. I understand and share your concerns about establishing an ongoing process bureaucracy... However, I'm not sure what, exactly, you are proposing as an alternative. Everyone seems to believe that there is a serious problem with the quality, timeliness and predictability of WG output. But, how do we initiate an effort to improve in this area? We have the strange gap between the problem-statement group and the efforts to make actual improvements in the IETF... The problem-statement group isn't supposed to talk about specific solutions. So, it is virtually impossible for us to start efforts that are focused on accomplishing particular solutions... Basically, all we can do is to encourage the creation of groups (or efforts of any kind) that _will_ (finally!) focus on solutions. Margaret From problem-statement-bounces@alvestrand.no Mon Jun 2 15:12:21 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20156 for ; Mon, 2 Jun 2003 15:12:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C974F6257A; Mon, 2 Jun 2003 21:10:53 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mx-out.daemonmail.net (mx-out.daemonmail.net [216.104.160.39]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3371D62577 for ; Mon, 2 Jun 2003 21:10:14 +0200 (CEST) Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.9.3p2/8.9.3) with SMTP id MAA93396 for ; Mon, 2 Jun 2003 12:10:13 -0700 (PDT) (envelope-from spencer@mcsr-labs.org) Received: from (12.237.229.250 [12.237.229.250]) by mail.varaha.com with SMTP id GIO0mMU2 Mon, 02 Jun 2003 12:10:12 -0700 (PDT) Message-ID: <086f01c3293a$986f9f80$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <9690000.1054492013@askvoll.hjemme.alvestrand.no> <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <9690000.1054492013@askvoll.hjemme.alvestrand.no> <5.1.0.14.2.20030602132439.0430e648@mail.windriver.com> Date: Mon, 2 Jun 2003 14:10:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: New ways to do things (Re: Doing the Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Apparently this week, I'll be agreeing with Margaret... I'm not sure we're really set up to have official meetings that AREN'T either WGs or BoFs at an IETF. We know how to have official WG meetings and unofficial directorate meetings, so if we're shooting for visibility and wide community input, we either need a BoF or a structural change that allows for "something else"... Spencer ----- Original Message ----- From: "Margaret Wasserman" Sent: Monday, June 02, 2003 12:30 PM Subject: Re: New ways to do things (Re: Doing the Right Things?)\ The two existing choices for group activities in the IETF are: - Directorates - Working Groups I suppose that we could have an internal education directorate, but that wouldn't help to make our efforts more visible and/or allow for wide community input. So, maybe we need a WG? It would be a weird WG, but a WG seems preferable to continuing to conduct this effort in a back-room effort... Anyway, we'll have a BOF in Vienna, and one of the things that we'll be discussing is how this effort should be organized and run on an ongoing basis. Opinions are welcome. Margaret From problem-statement-bounces@alvestrand.no Mon Jun 2 15:16:34 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20546 for ; Mon, 2 Jun 2003 15:16:33 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 82BB862581; Mon, 2 Jun 2003 21:16:02 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id E4481623CD for ; Mon, 2 Jun 2003 21:15:52 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19Mumd-000Lsl-00 for problem-statement@alvestrand.no; Mon, 02 Jun 2003 14:15:51 -0500 Date: Mon, 02 Jun 2003 15:15:51 -0400 From: John C Klensin To: "problem-statement@alvestrand.no" Message-ID: <522141049.1054566951@p3.JCK.COM> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Cutting through the accumulating sludge (was: Re: Doing the Right Things? and/or WG Quality Processes WG) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit For those who don't like reading my long notes -- at least before they know what they have to say -- this note suggests that we bypass WGs and even BOFs for most of this work and adopt a model that uses * proposal-> affirmative decision -> implementation -> subsequent review and write up -> Last Call and BCP if needed and * proposal -> negative decision -> discussion/ debate/ serious write up -> Last Call instead of pretending the tuning suggestions about WG process are technical standards. It explains why I think that is appropriate, probably necessary, and The Right Thing to Do. A more general way to categorize the things WGs do, and the ways in which they should do it, might be an output from this process, or a separate, longer-term, thread, but shouldn't be turned into a blocking prerequisite. -------------- --On Monday, 02 June, 2003 15:11 +0200 Harald Tveit Alvestrand wrote: >> I'm concerned that we may be wandering a bit far into >> solutions. Part of the problem reflects a broader IETF >> problem with getting things done in a timely way; that >> spinning off a new effort to identify short-term changes may >> simply take too long. It may be worth talking specifically >>... > I think that for each solution path to be pursued, a core team > with competence and energy to drive the process is needed, no > matter what - and that once we have that, it almost doesn't > matter how long the formal process to start the thing is; they > can go to work right away, and do course corrections as part > of the chartering process, rather than waiting for the > "formalities" to complete before starting work. >... Harald, I'm concerned about one aspect of this, and, ultimately, about the other subthreads of the discussion recently. We seem to be spending more and more time talking about process, planning process, planning processes for developing process, discussing ways to plan, planning for managing the development of plans,..., etc. As this goes on, we see more and more postings from the same people and less participation from the broader IETF community. We don't know if those who have stopped posting (or never have posted) have dropped off, or returned to lurking and trying to follow parts of the discussion, or have other priorities, or are simply disgusted. I do know that the volume of traffic has been too much for me to follow carefully -- perhaps lots of the community has more spare time on their hands than I do, or read faster. But I think I have also noticed an increase in the number of messages that claim insight into what those who are silent are thinking and feeling and I find that a disturbing sign. It is clear that all of this process and metaprocess isn't getting us to changes --or conclusions that changes are not needed -- very quickly. So I want to suggest a radical extension of your comment above (I agree with the suggestion, I just don't think it goes far enough under the circumstances)... In the perspective of our traditional adage, let's focus on seeing what code can be built and whether it runs, rather than on processes for figuring out which code to write or not write. I note that, unless proposed changes are, really, really, radical -- and I don't think I've seen any concrete suggestions that would fall into that category, or "problem statement" items that would require them-- we can implement first and write down the formal mechanisms later. We've got a long history of that approach (which parallels, for better or worse, commercial implementation of ideas while they are still I-Ds). To take a specific example (sorry, Margaret, but the thread was topmost in my mailbox), the notion of spinning up a WG, or even holding a BOF, to discuss topics like "require that state changes in the tracker be automatically posted to the WG" seems to me to be a huge waste of time and resources. If that looks to the IESG like a good idea, let's just do it and agree to come back after a while and evaluate whether it is worth the effort to continue. If the IESG doesn't believe it is a good idea -- based on their overview/ understanding of the process -- then they should say so and, if others don't agree with the IESG perspective, we should start a discussion from that point, not by trying to micro-tune what gets posted and to whom. Specifically, we've got about five weeks before Vienna. If I look back on the discussions of this WG since San Francisco, it seems clear that we could use up all of that time debating charters for new WGs, etc. Even if we do that, the more WGs we spin up with "process" responsibilities, the more coordination that is going to take, and coordination takes time and energy. And, unless each and every one of those (including any BOFs scheduled as part of that process) is scheduled in clear, no-conflicts, time, it will draw an unrepresentative sample of the community, consisting of the union of those who care more about process than about technology standards development, those with free time on their hands who wouldn't rather spend it in some Vienna cafe or museum, and those who feel reluctantly required to attend to protect against the excesses of the other groups. _That_ is scary. It is also, fwiw, the reason we stopped holding face to face Poisson meetings. So, instead, I suggest that we encourage groups to form out of the problem-statement list, groups who are excited about, focused on, and in general agreement about, some small subset of the particular issues that have been identified. Let them self-identify from collections of people with similar opinions. Encourage them to put the energy that has been going into multiple list postings in very short periods (in many cases, repeating the same themes over and over again) into quickly generating some specific "suggestion" documents. I'd like to see those posted as I-Ds, but let's be relaxed about format since they are unlikely to evolve directly into RFCs. Encourage very short documents with very specific suggestions (which means I'm not doing any of the writing :-)). Set a deadline. Impose a filter on the documents. I don't think it makes a huge difference what it is, but I'm thinking about something along the lines of "if at least five people don't sign up to believing this is a good idea, the IESG shouldn't waste its time". Pick a different number, or a different formula, if you like, but let's not spend weeks debating it. With those documents in hand, let the IESG go through them and classify them as something like: * good (or at least interesting and not harmful) idea, will implement on a trial basis. (A schedule would be good.) * unimplementable, because... * unwise or undesirable, because... * doesn't appear to solve any relevant problem. * sweeping change * needs a lot more thought and consideration. For suggestions in any of the categories other than the first, find out if anyone other than the proposer(s) really care(s). You could ask for comments on the mailing list, or for more endorsements. It probably makes little difference, but, again, it is useful to have a filter to avoid wasting more time on something no one cares about or that won't do any good. If it "passes", put it on the plenary agenda for Vienna. Or, if some of this turns out to require a smaller, "discussion", BOF that won't fit in the bar, schedule a BOF. (Assuming times can be found, the scheduling deadlines are all IESG rules, developed for IESG and Secretariat convenience. The IESG can presumably waive any rule it can make, so, if it is important enough and space can be found, the deadline for scheduling a BOF for the morning of 14 July is probably the afternoon of 13 July). I would hope that the IESG can do this quickly and with expedited review. If any of these suggestions gets tied up in "discuss" votes, rather than having a decision made and moving on, would certainly be taken, by some people and with some justification, as evidence that the IESG is, itself, broken. If the IESG doesn't have time, appoint a blue-ribbon committee to do a preliminary review and write comments for the IESG to review. You ought to be able to draft any existing WG chair in this area, or likely candidate to become one, onto that committee -- it will take less of their time. I note that any, or all, of the above can be done, and implemented, without procedure changes or more process debates. While I've been unhappy with some of it, the IESG has claimed for itself the authorization and right to do far more sweeping things under the "managing the process" umbrella. And it is an approach that, if people really want to get something done --rather than engaging in interminable process debates-- could actually produce some agreement about changes before Vienna and a clear agenda for the plenary there. It seems to me that most of the alternatives that have been suggested are going to leave us spending the rest of this month, if not the next few months, debating structure, charters, methods for selecting chairs, and other nice process-things that do not, themselves, produce forward progress. Now, there are things, most of them in the "long term" category, that this approach won't address or fix. I'll try putting some comments on one category of those things into a separate note. But, if there is anything of that nature that we really need to do, they will almost certainly require spinning up a WG, careful consideration of charters and leadership, etc. I think the odds of something of that nature producing results that are ready for us to even debate intelligently in Vienna are pretty low, and will keep getting lower unless we can do something radical about the current astronomical N/S ratio. Maybe we can at least start that effort in parallel with the above. But let's not bog down practical issues, fine-tuning, and fixes with the same process needed for long-term, major, changes. regards, john From problem-statement-bounces@alvestrand.no Mon Jun 2 15:21:20 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20741 for ; Mon, 2 Jun 2003 15:21:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5128E62572; Mon, 2 Jun 2003 21:20:50 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mgw-dax2.ext.nokia.com (unknown [63.78.179.217]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0CF16623CD for ; Mon, 2 Jun 2003 21:20:37 +0200 (CEST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])h52JKYb22484 for ; Mon, 2 Jun 2003 14:20:35 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com ; Mon, 2 Jun 2003 14:20:41 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 2 Jun 2003 12:20:33 -0700 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" Date: Mon, 2 Jun 2003 14:20:33 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4401753652@daebe007.americas.nokia.com> Thread-Topic: New ways to do things (Re: Doing the Right Things?) Thread-Index: AcMpLYdSrWLxEZUqS5u1wfqd1uN+8gADeT7w From: To: , X-OriginalArrivalTime: 02 Jun 2003 19:20:33.0639 (UTC) FILETIME=[09D75770:01C3293C] Cc: problem-statement@alvestrand.no Subject: RE: New ways to do things (Re: Doing the Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA20741 > The two existing choices for group activities in the IETF > are: > - Directorates > - Working Groups > Directorates have generally been restricted and do not have the same degree of open participation as a WG does. So the directorate mechanism does not work. WGs are a better means for discussion. However it is also possible that an area can have an area wide meeting as is done at IETF meetings. So it is possible to have a general area meetiing with the specific topic of process problems or solution proposal discussions without necessarily having to create a WG. > Opinions are welcome. > Margaret My 0.02C -Basavaraj From problem-statement-bounces@alvestrand.no Mon Jun 2 15:24:21 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20856 for ; Mon, 2 Jun 2003 15:24:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9D4C262572; Mon, 2 Jun 2003 21:23:48 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id 41D34623CD for ; Mon, 2 Jun 2003 21:23:45 +0200 (CEST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])h52JNiW26298 for ; Mon, 2 Jun 2003 22:23:44 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com ; Mon, 2 Jun 2003 22:23:43 +0300 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 2 Jun 2003 22:23:43 +0300 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 2 Jun 2003 12:23:40 -0700 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" Date: Mon, 2 Jun 2003 14:23:40 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4401753653@daebe007.americas.nokia.com> Thread-Topic: Cutting through the accumulating sludge (was: Re: Doing the Right Things? and/or WG Quality Processes WG) Thread-Index: AcMpO4Z0BeNkWQurSM29/dQkjnavxgAAKIhg From: To: , X-OriginalArrivalTime: 02 Jun 2003 19:23:40.0718 (UTC) FILETIME=[795954E0:01C3293C] Subject: RE: Cutting through the accumulating sludge (was: Re: Doing the Right Things? and/or WG Quality Processes WG) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA20856 > > For those who don't like reading my long notes -- at least > before they know what they have to say -- this note suggests > that we bypass WGs and even BOFs for most of this work and adopt > a model that uses > > * proposal-> affirmative decision -> implementation -> > subsequent review and write up -> Last Call and BCP if needed > > and > > * proposal -> negative decision -> discussion/ debate/ > serious write up -> Last Call > > instead of pretending the tuning suggestions about WG process > are technical standards. It explains why I think that is > appropriate, probably necessary, and The Right Thing to Do. > > A more general way to categorize the things WGs do, and the ways > in which they should do it, might be an output from this > process, or a separate, longer-term, thread, but shouldn't be > turned into a blocking prerequisite. > I completely agree. This is (possibly) a much faster route to accomplishing something quickly in the IETF. -Basavaraj From problem-statement-bounces@alvestrand.no Mon Jun 2 15:25:10 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20890 for ; Mon, 2 Jun 2003 15:25:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8204A6257D; Mon, 2 Jun 2003 21:24:40 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mx-out.daemonmail.net (mx-out.daemonmail.net [216.104.160.39]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9591462581 for ; Mon, 2 Jun 2003 21:24:36 +0200 (CEST) Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.9.3p2/8.9.3) with SMTP id MAA98772 for ; Mon, 2 Jun 2003 12:24:35 -0700 (PDT) (envelope-from spencer@mcsr-labs.org) Received: from (12.237.229.250 [12.237.229.250]) by mail.varaha.com with SMTP id ugP0QlV2 Mon, 02 Jun 2003 12:24:34 -0700 (PDT) Message-ID: <087601c3293c$9a172310$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <5.1.0.14.2.20030531215652.04333d20@mail.windriver.com> <5.1.0.14.2.20030531215652.04333d20@mail.windriver.com> <5.1.0.14.2.20030602134341.0438f918@mail.windriver.com> Date: Mon, 2 Jun 2003 14:24:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: WG Quality Processes WG X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Hi, Scott, We had already started a discussion this morning about how we organize to do "small chunks of work". It seems to me that we are headed toward small process changes, as opposed to "feed the IESG to pigs and start over", so the "small chunks of work" discussion seems applicable to process work as well. Margaret told me that she'd gotten approval for a BoF in 15 minutes, on one occasion. My limited experience has been that it takes me longer than that to get approval for a BoF, and about two IETF meeting intervals to charter a working group after a BoF is proposed. I'm also thinking that if the IESG has to choose between considering BoF requests for process work and BoF requests for protocol work, the protocol work will get the nod. If you're really good at sliding WG creation requests through, please stay engaged. If I'm going to be involved, I'm concerned about the inertia I've experienced when spinning WGs up from scratch, and expect that process WGs would take more time, rather than less. Spencer p.s. I'm not complaining about the amount of inertia - I work in TSV, and we tend to NOT "go crazy" and redo TCP every year, for good reasons. I'm just not sure the amount of inertia I've experienced will help us improve our processes before IETF 60 (to pick a date). ----- Original Message ----- From: "Margaret Wasserman" To: "Scott W Brim" Cc: Sent: Monday, June 02, 2003 12:48 PM Subject: Re: WG Quality Processes WG > > Hi Scott, > > At 12:23 PM 6/2/2003 -0400, Scott W Brim wrote: > >I'm just reluctant to make it a WG without an immutable time-to-live, > >less than a year. I want them to take on just one or two possible > >changes at a time. A change which is so major that it takes longer > >should be shepherded by the IESG (at this group's instigation?). It can > >be recreated (not just rechartered) every time. We have a precedent, > >the NomCom. I don't want the group to get stuck in its ways. > > I understand and share your concerns about establishing > an ongoing process bureaucracy... > > However, I'm not sure what, exactly, you are proposing as > an alternative. Everyone seems to believe that there is > a serious problem with the quality, timeliness and predictability > of WG output. But, how do we initiate an effort to improve in > this area? > > We have the strange gap between the problem-statement group > and the efforts to make actual improvements in the IETF... > > The problem-statement group isn't supposed to talk about > specific solutions. So, it is virtually impossible for us > to start efforts that are focused on accomplishing > particular solutions... Basically, all we can do is to > encourage the creation of groups (or efforts of any kind) > that _will_ (finally!) focus on solutions. > > Margaret From problem-statement-bounces@alvestrand.no Mon Jun 2 15:30:18 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21028 for ; Mon, 2 Jun 2003 15:30:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 253A562581; Mon, 2 Jun 2003 21:29:48 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3158162581 for ; Mon, 2 Jun 2003 21:29:45 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19Mv04-000LzO-00 for problem-statement@alvestrand.no; Mon, 02 Jun 2003 14:29:44 -0500 Date: Mon, 02 Jun 2003 15:29:44 -0400 From: John C Klensin To: "problem-statement@alvestrand.no" Message-ID: <522974207.1054567784@p3.JCK.COM> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Trusting the IESG to manage the reform process (was: Re: Doing the Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Summary: If we can't trust the current IESG for reform-process management, we are in deep trouble. If we are in that much trouble, we should be postponing the little issues because we need to be looking at very fundamental change, starting with discarding the nomcom process and starting over on our selection processes. I don't believe that is that case, and don't believe that the view that it is the case is generally held in the community, but it is probably time to face the question. -------------- In writing the note about an accelerated process, I realized I've been making an assumption that needs a bit of explanation. Several of the issues here, and what processes might and might not work, are ultimately about whether or not IESG is completely broken and/or in some "us versus them" mode that implies we can't trust them with much of anything, especially anything involving reform or evolution. There are clearly people in the community who believe that the current IESG has formed a closed circle, developed a "them against us" mentality, and cannot be trusted. I don't know how large that group is (although I suspect "not very" would be a good guess). But, if they are right, we don't need incremental procedural suggestions, we need really radical reform. Why? Because at least two consecutive nomcoms, acting independently, have selected (or reselected) the current IESG members. If they have managed to select people who would engage in that sort of conspiracy of untrustworthy behavior, and to do it so successfully that, not only can the IESG behave in undesirable ways, but that no one on the IESG has been willing to speak up in public and say "I see a problem here, but it is all those other folks, not me", then there is something hopelessly broken about the nomcom model, probably to the point that we need to discard it and start over. No one has suggested that yet, but, if people seriously believe that the IESG can no longer be trusted to manage the standards process, or a reform process, or both, I think it is time to move past "list problems only" and get that on the table. Why can't we, instead, just make up some new rules and procedures to "control" the IESG? Because our enforcement mechanisms are almost non-existent if the IESG is unwilling. The IESG has already demonstrated that, under their general responsibility and authority to manage the process, they can and will make up procedural rules that bend written procedures pretty severely. If we trust them, that process may need to be tuned and constrained (as I believe it does) to make our expectations about the limits of what they can do without consulting the community more clear. But, if the trust isn't there, any effort to make more/different rules and procedures is just to give them additional things that they can ignore. So, whether it be about a final decision on a new AD, or on figuring out which process suggestions can just be accepted and deployed without going through a long and complex process, or on managing the process in other ways, I think we need to trust them to make management-level decisions about how best to move forward and hold them accountable for doing that acceptably well. And, if we can't trust them, or at least their good intentions and willingness to do what the community wants and needs, that far, then we had best stop the process of examining the leaves on the forest floor while the place goes up in flames around us. john From problem-statement-bounces@alvestrand.no Mon Jun 2 15:36:29 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21146 for ; Mon, 2 Jun 2003 15:36:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED3C262581; Mon, 2 Jun 2003 21:35:58 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id BBCF06257D for ; Mon, 2 Jun 2003 21:35:53 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.20]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA22398; Mon, 2 Jun 2003 12:35:20 -0700 (PDT) Message-Id: <5.1.0.14.2.20030602152113.04362bf8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 02 Jun 2003 15:30:34 -0400 To: John C Klensin From: Margaret Wasserman In-Reply-To: <522141049.1054566951@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: Cutting through the accumulating sludge (was: Re: Doing the Right Things? and/or WG Quality Processes WG) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 John, I mostly agree with what you've said here (and feel free to use me as an example, good or bad, any time! :-))... In particular: At 03:15 PM 6/2/2003 -0400, you wrote: >Now, there are things, most of them in the "long term" category, that this >approach won't address or fix. I'll try putting some comments on one >category of those things into a separate note. But, if there is anything >of that nature that we really need to do, they will almost certainly >require spinning up a WG, careful consideration of charters and >leadership, etc. I think the odds of something of that nature producing >results that are ready for us to even debate intelligently in Vienna are >pretty low, and will keep getting lower unless we can do something radical >about the current astronomical N/S ratio. Maybe we can at least start >that effort in parallel with the above. But let's not bog down practical >issues, fine-tuning, and fixes with the same process needed for long-term, >major, changes. This was the point of separating the "near-term" and "longer-term" items in the process document... We should work on fixing the near-term items now, in some loosely coordinated way, in parallel with fixing the longer-term problems (i.e. reorganization and updates to the standards-track). I'm just not sure how you think that we can start the near-term effort that you've explained... I had suggested a WG to vet the various ideas for improvement and prioritize which ones to implement, and you've suggested either having the IESG do it, or having the IESG appoint a panel to do it. A WG provides more opportunity for visibility and community feedback, which is why I prefer a WG to having this done in a closed group. I know that not everyone can attend a WG, but it a WG is certainly more open than the IESG or a closed committee. I agree, though, that a WG could be too high overhead. So, either way is really okay with me, as long as we find a way to start vetting the various ideas for near-term improvements and implementing the most promising ones. Margaret From problem-statement-bounces@alvestrand.no Mon Jun 2 15:49:54 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21414 for ; Mon, 2 Jun 2003 15:49:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B4D5962577; Mon, 2 Jun 2003 21:49:23 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id A863A62206 for ; Mon, 2 Jun 2003 21:49:20 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.20]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA01059; Mon, 2 Jun 2003 12:48:59 -0700 (PDT) Message-Id: <5.1.0.14.2.20030602153650.043e3008@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 02 Jun 2003 15:45:06 -0400 To: Spencer Dawkins From: Margaret Wasserman In-Reply-To: <087601c3293c$9a172310$0200a8c0@DFNJGL21> References: <5.1.0.14.2.20030531215652.04333d20@mail.windriver.com> <5.1.0.14.2.20030531215652.04333d20@mail.windriver.com> <5.1.0.14.2.20030602134341.0438f918@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: WG Quality Processes WG X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 At 02:24 PM 6/2/2003 -0500, Spencer Dawkins wrote: >Margaret told me that she'd gotten approval for a BoF >in 15 minutes, on one occasion. That would be an exaggeration (not saying I didn't say it). I've only proposed two BOFs myself, both of which were approved quite quickly (~6 hours and ~2 days) after the final proposal was submitted. It takes a good deal of time, though, to put together a reasonable BOF request, and compared to that, the time to get the BOF approved by the IESG has been trivial (in my experience). Margaret From problem-statement-bounces@alvestrand.no Mon Jun 2 15:56:37 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21681 for ; Mon, 2 Jun 2003 15:56:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8D78C623CD; Mon, 2 Jun 2003 21:56:06 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 10809623CD for ; Mon, 2 Jun 2003 21:56:04 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19MvPX-000M4c-00; Mon, 02 Jun 2003 14:56:03 -0500 Date: Mon, 02 Jun 2003 15:56:03 -0400 From: John C Klensin To: Margaret Wasserman Message-ID: <524552917.1054569363@p3.JCK.COM> In-Reply-To: <5.1.0.14.2.20030602152113.04362bf8@mail.windriver.com> References: <5.1.0.14.2.20030602152113.04362bf8@mail.windriver.co m> X-Mailer: Mulberry/3.0.3 (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: Cutting through the accumulating sludge (was: Re: Doing the Right Things? and/or WG Quality Processes WG) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On Monday, 02 June, 2003 15:30 -0400 Margaret Wasserman wrote: >>... >> we really need to do, they will almost certainly require >> spinning up a WG, careful consideration of charters and >> leadership, etc. I think the odds of something of that >> nature producing results that are ready for us to even >> debate intelligently in Vienna are pretty low, and will keep >> getting lower unless we can do something radical about the >> current astronomical N/S ratio. Maybe we can at least start >> that effort in parallel with the above. But let's not bog >> down practical issues, fine-tuning, and fixes with the same >> process needed for long-term, major, changes. > > This was the point of separating the "near-term" and > "longer-term" items in the process document... Understood. > We should work on fixing the near-term items now, in some > loosely coordinated way, in parallel with fixing the > longer-term problems (i.e. reorganization and updates to the > standards-track). > > I'm just not sure how you think that we can start the near-term > effort that you've explained... I am suggesting that, if there seems to be general sympathy on the list (or otherwise) for this, that the relevant AD just do it --or delegate it to the WG Chairs or an appointed coordinator-- to do it. The authority is there; nothing in the current procedures requires us to find a tree and dance around it in a circle while chanting "rough consensus and running code", or to create a charter and WG, before doing anything. > I had suggested a WG to vet > the various ideas for improvement and prioritize which ones to > implement, and you've suggested either having the IESG do it, > or having the IESG appoint a panel to do it. If the IESG thinks that a particular idea is a good one, or likely to be a good one, then they should implement it, without more fuss. If they think an idea is a bad one, and the community still thinks otherwise, _then_ we may need a more formal/systematic process. > A WG provides more opportunity for visibility and community > feedback, which is why I prefer a WG to having this done in a > closed group. I know that not everyone can attend a WG, but > it a WG is certainly more open than the IESG or a closed > committee. I agree, though, that a WG could be too high > overhead. Then find the middle ground by using the WG for those things that (a) are controversial, (b) are non-trivial, and (c) still have significant support. Right now, we are headed for using WG-like mechanisms for suggestions that, once understood, are probably obvious and trivial. We are also headed for using those mechanism for proposals that, were the IESG to comment, they would immediately point out reasons why the ideas were infeasible and, probably for a large subset, immediately convince most of the rest of us. So, IMO, we need to move to a "four piles" plan -- clearly yes, clearly no (or no support beyond the author and his two friends), not worth further effort, and really worth serious and extended discussion. For the fourth category, _if_ it actually turns out to be non-null, let's by all means spin up a WG, or attach those topics to the "long-term" WG. But let's not go to that effort unless the fourth category really is non-null. Personally, from looking at the list over the last few months, I'd be a bit surprised. > So, either way is really okay with me, as long as we find a way > to start vetting the various ideas for near-term improvements > and implementing the most promising ones. Ok. Want to wait until August to get started? If the answer is "no", then let's not start planning WGs instead of generating specific suggestions and getting quick and efficient IESG evaluations of them. john From problem-statement-bounces@alvestrand.no Mon Jun 2 15:58:21 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21731 for ; Mon, 2 Jun 2003 15:58:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8C59A623CD; Mon, 2 Jun 2003 21:57:51 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9867062206 for ; Mon, 2 Jun 2003 21:57:45 +0200 (CEST) Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h52JvgkQ021667; Mon, 2 Jun 2003 15:57:42 -0400 (EDT) Message-Id: <200306021957.h52JvgkQ021667@rtp-core-1.cisco.com> To: John C Klensin In-reply-to: Your message of Mon, 02 Jun 2003 15:29:44 -0400. <522974207.1054567784@p3.JCK.COM> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 02 Jun 2003 15:57:41 -0400 From: Eric Rosen Cc: "problem-statement@alvestrand.no" Subject: Re: Trusting the IESG to manage the reform process (was: Re: Doing the Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: erosen@cisco.com 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 John> Several of the issues here, and what processes might and might not John> work, are ultimately about whether or not IESG is completely broken John> and/or in some "us versus them" mode that implies we can't trust them John> with much of anything, especially anything involving reform or John> evolution. Which is what makes it absurd to suggest that the IESG can be left to manage the reform process. All we'd get are a bunch of new hurdles for WGs to jump through, so as to make it even harder to oppose the IESG's political objectives. I.e., things would get worse, rather than better. So I think this is a poor case for the "let's get some code fielded and then get the IETF to rubber stamp it" technique ;-) From problem-statement-bounces@alvestrand.no Mon Jun 2 16:11:52 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22299 for ; Mon, 2 Jun 2003 16:11:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 02DD362572; Mon, 2 Jun 2003 22:11:22 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 41DFD623CD for ; Mon, 2 Jun 2003 22:11:20 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h52KB9k15902; Mon, 2 Jun 2003 16:11:10 -0400 (EDT) Date: Mon, 2 Jun 2003 16:11:09 -0400 From: Keith Moore To: Margaret Wasserman Message-Id: <20030602161109.4f836093.moore@cs.utk.edu> In-Reply-To: <5.1.0.14.2.20030602153650.043e3008@mail.windriver.com> References: <5.1.0.14.2.20030531215652.04333d20@mail.windriver.com> <5.1.0.14.2.20030531215652.04333d20@mail.windriver.com> <5.1.0.14.2.20030602134341.0438f918@mail.windriver.com> <5.1.0.14.2.20030602153650.043e3008@mail.windriver.com> X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Subject: Re: WG Quality Processes WG X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > It takes a good deal of time, though, to put together > a reasonable BOF request, and compared to that, the > time to get the BOF approved by the IESG has been > trivial (in my experience). well of course some BOF requests are no-brainers (yep, that's obviously a good idea, shouldn't be too controversial, make it so) and others aren't (gee, do we really want to open *that* pandora's box?) or (this seems to encompass multiple areas, how do we coordinate?) or (is this even in scope for IETF at all?) or (haven't we had 2 BOFs on this topic already? why do we think we'll get better results this time?) From problem-statement-bounces@alvestrand.no Mon Jun 2 23:10:07 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05179 for ; Mon, 2 Jun 2003 23:10:06 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5A6BB62577; Tue, 3 Jun 2003 05:09:34 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id 60E1E61BA7 for ; Tue, 3 Jun 2003 05:09:32 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19N2B1-000Imu-00; Tue, 03 Jun 2003 03:09:31 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.14) id 19N2Az-000JUv-2A; Mon, 02 Jun 2003 20:09:29 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 2 Jun 2003 20:09:28 -0700 To: John C Klensin References: <5.1.0.14.2.20030602152113.04362bf8@mail.windriver.co m> <524552917.1054569363@p3.JCK.COM> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: Cutting through the accumulating sludge (was: Re: Doing the Right Things? and/or WG Quality Processes WG) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 am suggesting that, if there seems to be general sympathy on > the list (or otherwise) for this, that the relevant AD just do > it --or delegate it to the WG Chairs or an appointed > coordinator-- to do it. The authority is there; nothing in the > current procedures requires us to find a tree and dance around > it in a circle while chanting "rough consensus and running > code", or to create a charter and WG, before doing anything. i think we really do not have a clear vision of what we should be doing, so it is easier to talk about the processes and enemies of doing it. no blame. this is extremely difficult stuff. i keep thinking of the analog to how some engineering companies dealt with the conflicts/tensions of staying nimble while undergoing large growth. digital equipment tried to maintain a dynamic engineering culture while growing massively. it did not work. hp is still trying, but has become more and more stodgy and has not stayed lively and dynamic. intel may be the most successful. one key to this success is not touching anything that does not have at least a 40% margin. i.e., they say "no" to a lot of bright ideas. i do not believe that we have the culture to do that. randy From problem-statement-bounces@alvestrand.no Mon Jun 2 23:12:58 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05210 for ; Mon, 2 Jun 2003 23:12:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 194D06257D; Tue, 3 Jun 2003 05:12:28 +0200 (CEST) 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 9F15462577 for ; Tue, 3 Jun 2003 05:12:20 +0200 (CEST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])h533CKD18928 for ; Tue, 3 Jun 2003 06:12:20 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com ; Tue, 3 Jun 2003 06:12:19 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 06:12:19 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 06:12:19 +0300 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" Date: Tue, 3 Jun 2003 06:12:18 +0300 Message-ID: Thread-Topic: WG Quality Processes WG Thread-Index: AcMpI1hqGSbDLu8kRGemkduvEipRPgAWnqog From: To: , X-OriginalArrivalTime: 03 Jun 2003 03:12:19.0344 (UTC) FILETIME=[F15B2900:01C3297D] Subject: RE: WG Quality Processes WG X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA05210 Scott, > I'm just reluctant to make it a WG without an immutable time-to-live, > less than a year. I want them to take on just one or two possible > changes at a time. A change which is so major that it takes longer > should be shepherded by the IESG (at this group's > instigation?). It can > be recreated (not just rechartered) every time. We have a precedent, > the NomCom. I don't want the group to get stuck in its ways. So, putting it in different terms, if we go forward with such a WG, are you suggesting it should have an extremely tight charter that requires re-chartering to continue? John > On Sat, May 31, 2003 10:05:24PM -0400, Margaret Wasserman > allegedly wrote: > > A working group should be formed in the General Area of > the IETF to > > oversee improvements to the quality processes used in > IETF WGs, and > > to increase the effectiveness of IETF reviews at all > levels. This > > group should take an experimental, iterative approach to these > > improvements: > > > > - Identify and prioritize a set of promising proposals for > > improvement. > > - Figure out what each proposal is trying to improve (in > > measurable terms) and define a metric to measure > performance > > in that area. > > - Determine the current level of performance against the > > defined metric. > > - Institute each change in a few representative WGs (on a > > volunteer basis). > > - Measure the results to determine if each change was > > successful. > > - Make successful changes available IETF-wide, by > publishing > > them in BCP RFCs. > > - As necessary, train WG chairs and other > participants on the > > how to implement the successful improvements in > their WGs. > > - Repeat as necessary. > From problem-statement-bounces@alvestrand.no Mon Jun 2 23:19:24 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05372 for ; Mon, 2 Jun 2003 23:19:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 648B96257D; Tue, 3 Jun 2003 05:18:55 +0200 (CEST) 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 4C4DB62577 for ; Tue, 3 Jun 2003 05:18:52 +0200 (CEST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])h533IpD21553 for ; Tue, 3 Jun 2003 06:18:51 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com ; Tue, 3 Jun 2003 06:18:51 +0300 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 06:18:50 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 06:18:50 +0300 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" Date: Tue, 3 Jun 2003 06:18:48 +0300 Message-ID: Thread-Topic: Cutting through the accumulating sludge (was: Re: Doing the Right Things? and/or WG Quality Processes WG) Thread-Index: AcMpO4K7MiE/IdgRRoy/Ll30f35JTAAQtDZw From: To: , X-OriginalArrivalTime: 03 Jun 2003 03:18:50.0447 (UTC) FILETIME=[DA78BDF0:01C3297E] Subject: RE: Cutting through the accumulating sludge (was: Re: Doing the Right Things? and/or WG Quality Processes WG) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA05372 Hi John, > For those who don't like reading my long notes -- at least > before they know what they have to say -- this note suggests > that we bypass WGs and even BOFs for most of this work and adopt > a model that uses > > * proposal-> affirmative decision -> implementation -> > subsequent review and write up -> Last Call and BCP if needed > > and > > * proposal -> negative decision -> discussion/ debate/ > serious write up -> Last Call > > instead of pretending the tuning suggestions about WG process > are technical standards. It explains why I think that is > appropriate, probably necessary, and The Right Thing to Do. That sounds like a reasonable way forward, but there are the boring details of where to feed the proposals, get the decision, do the review, who should take the lead, etc. I think this is what we need to decide to do in the next week or two. Some detailed comments in following mails. John L. From problem-statement-bounces@alvestrand.no Mon Jun 2 23:23:54 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05487 for ; Mon, 2 Jun 2003 23:23:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6F6446257D; Tue, 3 Jun 2003 05:23:24 +0200 (CEST) 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 3D03162577 for ; Tue, 3 Jun 2003 05:23:23 +0200 (CEST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])h533NMD23495 for ; Tue, 3 Jun 2003 06:23:22 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com ; Tue, 3 Jun 2003 06:23:22 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 06:23:22 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 06:23:22 +0300 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" Date: Tue, 3 Jun 2003 06:23:20 +0300 Message-ID: Thread-Topic: Trusting the IESG to manage the reform process (was: Re: Doing the Right Things?) Thread-Index: AcMpPVrk3s1ZDUrsTLCx/RT4CowKSQAQbu0A From: To: X-OriginalArrivalTime: 03 Jun 2003 03:23:22.0244 (UTC) FILETIME=[7C79AC40:01C3297F] Cc: problem-statement@alvestrand.no Subject: RE: Trusting the IESG to manage the reform process (was: Re: Doing the Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA05487 Hi John, On second thought, no detailed comments, but an overall comment. I agree we should get some people to suggest fixes and more forward on it. There should be some oversight of this work - to help focus it, call early consensus and try to avoid circular email discussions. I think what is needed is some forward momentum, something very much lacking at the moment. br, John L > -----Original Message----- > From: ext John C Klensin [mailto:john-ietf@jck.com] > Sent: 02 June, 2003 22:30 > To: problem-statement@alvestrand.no > Subject: Trusting the IESG to manage the reform process (was: > Re: Doing > the Right Things?) > > > Summary: If we can't trust the current IESG for reform-process > management, we are in deep trouble. If we are in that much > trouble, we should be postponing the little issues because we > need to be looking at very fundamental change, starting with > discarding the nomcom process and starting over on our selection > processes. I don't believe that is that case, and don't > believe that the view that it is the case is generally held in > the community, but it is probably time to face the question. From problem-statement-bounces@alvestrand.no Mon Jun 2 23:40:03 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05801 for ; Mon, 2 Jun 2003 23:40:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8FB0662581; Tue, 3 Jun 2003 05:39:30 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id A7CE062577 for ; Tue, 3 Jun 2003 05:39:24 +0200 (CEST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])h533dNW27362 for ; Tue, 3 Jun 2003 06:39:24 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com ; Tue, 3 Jun 2003 06:39:23 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 06:39:23 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 06:39:23 +0300 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" Date: Tue, 3 Jun 2003 06:39:21 +0300 Message-ID: Thread-Topic: WG Quality Processes WG Thread-Index: AcMpPKOkV5a/uETOTrKd8MDe3ravugARKhfQ From: To: , X-OriginalArrivalTime: 03 Jun 2003 03:39:23.0328 (UTC) FILETIME=[B9537400:01C32981] Subject: RE: WG Quality Processes WG X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA05801 Hi Spencer, > We had already started a discussion this morning about > how we organize to do "small chunks of work". It seems > to me that we are headed toward small process changes, > as opposed to "feed the IESG to pigs and start over", > so the "small chunks of work" discussion seems applicable > to process work as well. In a way, does it matter? Even if we feed the IESG to the pigs, there are still a lot of small things that need to be fixed. What is needed is for people to bite off part of the problem and start working on it. Of course, having some co-ordination so there isn't a mad-stampede to the buffet. John From problem-statement-bounces@alvestrand.no Mon Jun 2 23:42:25 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05926 for ; Mon, 2 Jun 2003 23:42:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D9B7962577; Tue, 3 Jun 2003 05:41:53 +0200 (CEST) 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 C2BE261BA7 for ; Tue, 3 Jun 2003 05:41:42 +0200 (CEST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])h533fgD02077 for ; Tue, 3 Jun 2003 06:41:42 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com ; Tue, 3 Jun 2003 06:41:42 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 06:41:42 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 06:41:41 +0300 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" Date: Tue, 3 Jun 2003 06:41:40 +0300 Message-ID: Thread-Topic: Trusting the IESG to manage the reform process (was: Re: Doing the Right Things?) Thread-Index: AcMpPVrk3s1ZDUrsTLCx/RT4CowKSQAQlz3w From: To: , X-OriginalArrivalTime: 03 Jun 2003 03:41:41.0798 (UTC) FILETIME=[0BDC4C60:01C32982] Subject: RE: Trusting the IESG to manage the reform process (was: Re: Doing the Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA05926 Hi John, > Summary: If we can't trust the current IESG for reform-process > management, we are in deep trouble. If we are in that much > trouble, we should be postponing the little issues because we > need to be looking at very fundamental change, starting with > discarding the nomcom process and starting over on our selection > processes. I don't believe that is that case, and don't > believe that the view that it is the case is generally held in > the community, but it is probably time to face the question. Actually, at the moment, I don't think it matters if there is a massive IESG conspiracy or not. Trusting the IESG is irrelevant, IMO. One feature that has really become apparent to me is that the IESG is facing scaling problems. If mails to ADs don't get answered within a reasonable time because ADs suffer from too much going on, I am not so sure adding to the IESG burden will be a good thing. Without any other better ideas, I think that having several documents (drafts would be nice, but not required) for discussion at Vienna & a forum for that discussion would be the way forward. There needs to be a couple of administrative assistants (or chairs, perhaps) to oversee this work, make sure that everyone plays nicely & keeps everyone working in a forward direction. John From problem-statement-bounces@alvestrand.no Tue Jun 3 00:08:04 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06440 for ; Tue, 3 Jun 2003 00:08:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6BC0862577; Tue, 3 Jun 2003 06:07:35 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by eikenes.alvestrand.no (Postfix) with ESMTP id 83CE261BA7 for ; Tue, 3 Jun 2003 06:07:27 +0200 (CEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 196EB6A904; Tue, 3 Jun 2003 07:07:25 +0300 (EEST) Message-ID: <3EDC1E97.6070103@piuha.net> Date: Tue, 03 Jun 2003 07:05:43 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: WG Quality Processes WG X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jari.arkko@piuha.net 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 john.loughney@nokia.com wrote: > Hi Spencer, > > >>We had already started a discussion this morning about >>how we organize to do "small chunks of work". It seems >>to me that we are headed toward small process changes, >>as opposed to "feed the IESG to pigs and start over", >>so the "small chunks of work" discussion seems applicable >>to process work as well. > > > In a way, does it matter? Even if we feed the IESG to the > pigs, there are still a lot of small things that need to > be fixed. What is needed is for people to bite off part > of the problem and start working on it. I agree with John here. This group seems a bit stuck in its (very IETF-like) approach of trying to understand the whole picture completely and agreeing on everything before being able to take the first step. --Jari P.S. I don't believe we should feed the IESG to the pigs, or anyone else for that matter. From problem-statement-bounces@alvestrand.no Tue Jun 3 03:53:36 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22512 for ; Tue, 3 Jun 2003 03:53:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 673EA62577; Tue, 3 Jun 2003 09:53:04 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 857DC61BA7 for ; Tue, 3 Jun 2003 09:53:02 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19N6bN-000Odr-00; Tue, 03 Jun 2003 02:53:01 -0500 Date: Tue, 03 Jun 2003 03:53:01 -0400 From: John C Klensin To: "john.loughney@nokia.com" , "problem-statement@alvestrand.no" Message-ID: <567570282.1054612381@p3.JCK.COM> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: RE: Trusting the IESG to manage the reform process (was: Re: Doing the Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On Tuesday, 03 June, 2003 06:41 +0300 "john.loughney@nokia.com" wrote: > Actually, at the moment, I don't think it matters if there is > a massive IESG conspiracy or not. Trusting the IESG is > irrelevant, IMO. One feature that has really become apparent > to me is that the IESG is facing scaling problems. If mails > to ADs don't get answered within a reasonable time because ADs > suffer from too much going on, I am not so sure adding to the > IESG burden will be a good thing. John, I've been arguing that the IESG is seriously overloaded and suffering from scaling problems and that we need to do something, or several things, to reduce the load for five years or so. And I've been doing it fairly loudly. So have others. Certainly, there are many signs and symptoms that look, from the outside, like overload -- slow responses to mail to ADs and apparently-unreasonable delays in document handling perhaps heading the list. In that same period, we have gotten the tracking system: it may have taken too long to get in place, it certainly helps with transparency, but I have no idea what the additional reporting requirements actually do to workload and whether they are balanced (in load terms) efficiencies in keeping track of things. But, the tracking system possibly excepted, the IESG has regularly, almost relentlessly, added to its load over that period. In every single case, taken one at a time, there has been a good reason to add to load or to reject or ignore a proposal to reduce the load. E.g., * If I work on, or partially rewrite, that document, rather than just bouncing it back to the WG or author, I can make it better. * This may never go to draft, so let's take the time to get those last 100 technical and editorial nits fixed. * Proposal to enforce benchmarks and give WGs more authority relative to ADs? Really would not work and would eliminate vital cross-area review. * Proposal to reduce the number of WGs, or put a ceiling on them? Too ruthless, not really practical, takes important flexibility out of the system. * We aren't getting enough detail in some areas in documents submitted to us, so let's add another required section or more fixed requirements about how sections are written. * Need a liaison to XXX? An IESG member should take it on, since only they really know what is going on in the work area. * Add a new AD, even temporarily, to deal with problem area YYY? Nope, the IESG is too big already, this would upset the balance of things, it takes too long to bring a new person up to speed, such a position is a bad idea anyway except maybe as a temporary position, and temporary positions are better filled internally. There are more examples, some better and some worse. The thing that is important about the ones I can identify is that every single one of them, examined by itself, is completely rational. All of the paraphrased assertions and conclusions in the list above are reasonable and valid, again, taken one at a time. Maybe SIRS will help and be the exception, but it would be easy to construct arguments against it too -- I can imagine the administrative/ policy burdens of actually maintaining/ administering the list and qualifications as being burdensome. If one is amused by such things, it is possible to construct fanciful conspiracy theories to "explain". I know enough of the IESG members to just not believe them. And Occam's Razor suggests easier explanations. I'm reminded a bit of "80 hours a week and loving it" bumper stickers. My new-this-week working hypothesis is that, whether they appear objectively overloaded or not, we need to stop making decisions based on the assumption that they are. We can't reduce the workload against their desires to take on extra tasks, their inability to refuse new ones, or their inclination to expand the IESG's role on a "this is important, someone needs to do it, and we are the obvious answer" basis. If an AD isn't being responsive, tell it to the Nomcom, possibly with advice that they pick someone who is strongly committed to turning away more work, rather than willing to add it. If you can't wait that long, and _really_ think it is that bad, think about recalls. But, IMO, our saying "we can't think about doing it that way because the IESG is overloaded and/or suffering scaling problems" is pointless until and unless the IESG is demonstrably ready to start making hard decisions to reduce those problems... And we had been be ready to support them, strongly, when they do start making those decisions, because, for any given one of them, _someone_ is going to be really unhappy. john From problem-statement-bounces@alvestrand.no Tue Jun 3 04:34:19 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23260 for ; Tue, 3 Jun 2003 04:34:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C5FB362586; Tue, 3 Jun 2003 10:33:48 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9DF8D62577; Tue, 3 Jun 2003 10:33:46 +0200 (CEST) Date: Tue, 03 Jun 2003 10:33:46 +0200 From: Harald Tveit Alvestrand To: Melinda Shore , problem-statement@alvestrand.no Message-ID: <122110000.1054629226@askvoll.hjemme.alvestrand.no> In-Reply-To: <200306021647.AHW67605@mira-sjc5-c.cisco.com> References: <200306021647.AHW67605@mira-sjc5-c.cisco.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: Issue tracking tool X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Melinda, what protocol do you want to use when participants want to raise issues to be tracked? should we send a message to the mailing list with "NEW ISSUE:" in the subject and have the chairs/editors enter the ticket, should we log in as "ietf" on the tracker and create it ourselves, should we send mail to the tracker to create tickets, should we ask the maintainers for a login to create tickets, or shold we do something different? Any of the above (and probably a dozen other ways) would work for me - but I want this to be as simple as possible for you - your call! Harald --On mandag, juni 02, 2003 12:47:13 -0400 Melinda Shore wrote: > We've now got an issue tracking tool up and running and > available for perusal at https://rt.psg.com. It does > require a login, which for IETF participants is user "ietf" > with password "ietf". A general introduction is at > http://rt.psg.com (note that the protocol is "http", while > that for the login is "https"). Our ticket queues are > problem-statement, problem-process, and problem-other. > > This is new to us, too, and so we'll be creating new tickets > as we identify new issues. These issues are intended to be > narrowly-defined and scoped - resolvable, in other words. > In addition to using it to track unresolved issues, we'll > also be using the issue tracker as a tool for focusing > discussion. Please take a look, and check back regularly. > > Melinda > From problem-statement-bounces@alvestrand.no Tue Jun 3 08:14:11 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28703 for ; Tue, 3 Jun 2003 08:14:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 358F962586; Tue, 3 Jun 2003 14:13:40 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2915662205; Tue, 3 Jun 2003 14:13:37 +0200 (CEST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h53CDZOq012832; Tue, 3 Jun 2003 05:13:37 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHX74314; Tue, 3 Jun 2003 05:13:33 -0700 (PDT) Message-Id: <200306031213.AHX74314@mira-sjc5-c.cisco.com> To: Harald Tveit Alvestrand From: Melinda Shore In-Reply-To: Message from harald@alvestrand.no <122110000.1054629226@askvoll.hjemme.alvestrand.no> Date: Tue, 03 Jun 2003 08:13:32 -0400 Cc: problem-statement@alvestrand.no Subject: Re: Issue tracking tool X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > what protocol do you want to use when participants want to raise issues to > be tracked? The issue should be raised on the mailing list, preferably clearly flagged as something requiring resolution ("ISSUE: " in the subject header is fine). The editors and chairs are maintaining the ticket queues. Thanks for raising the question, Melinda From problem-statement-bounces@alvestrand.no Tue Jun 3 08:22:21 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29412 for ; Tue, 3 Jun 2003 08:22:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 57F8B622B1; Tue, 3 Jun 2003 14:21:49 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mx-out.daemonmail.net (mx-out.daemonmail.net [216.104.160.39]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8CA9E62205 for ; Tue, 3 Jun 2003 14:21:41 +0200 (CEST) Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.9.3p2/8.9.3) with SMTP id FAA52753 for ; Tue, 3 Jun 2003 05:21:39 -0700 (PDT) (envelope-from spencer@mcsr-labs.org) Received: from (12.237.229.250 [12.237.229.250]) by mail.varaha.com with SMTP id diD09nJ2 Tue, 03 Jun 2003 05:21:38 -0700 (PDT) Message-ID: <09b601c329ca$b040b870$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: Date: Tue, 3 Jun 2003 07:21:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: WG Quality Processes WG X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Just so I'm clearer than previously, this was not a suggestion to feed the IESG to the pigs. What I was trying to say was, it looks like the bulk of this work will be small chunks of evolution, not big chunks of revolution, based on input on this list so far, so we need to be organizing to do small chunks of work effectively. Spencer ----- Original Message ----- From: To: ; Sent: Monday, June 02, 2003 10:39 PM Subject: RE: WG Quality Processes WG Hi Spencer, > We had already started a discussion this morning about > how we organize to do "small chunks of work". It seems > to me that we are headed toward small process changes, > as opposed to "feed the IESG to pigs and start over", > so the "small chunks of work" discussion seems applicable > to process work as well. In a way, does it matter? Even if we feed the IESG to the pigs, there are still a lot of small things that need to be fixed. What is needed is for people to bite off part of the problem and start working on it. Of course, having some co-ordination so there isn't a mad-stampede to the buffet. John From problem-statement-bounces@alvestrand.no Tue Jun 3 11:22:49 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09332 for ; Tue, 3 Jun 2003 11:22:49 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 916FC62586; Tue, 3 Jun 2003 17:22:18 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4FB0962278 for ; Tue, 3 Jun 2003 17:22:13 +0200 (CEST) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196])h53FM0DI095086 for ; Tue, 3 Jun 2003 17:22:05 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h53FKe6t147716 for ; Tue, 3 Jun 2003 17:20:41 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA49918 from ; Tue, 3 Jun 2003 17:20:39 +0200 Message-Id: <3EDCBCE0.46914DF7@hursley.ibm.com> Date: Tue, 03 Jun 2003 17:21:04 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: problem-statement@alvestrand.no References: <200305301332.AHU57215@mira-sjc5-c.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Query: adding additional AD X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit I think it isn't necessary - the General AD can do it. But I wouldn't object to an extra AD, if that would avoid continued concern from some people about conflict of interest. Brian Melinda Shore wrote: > > Let's try to come to some closure on this. Question: Should > we add an additional AD to deal with process issues? If > your answer is conditional ("yes, but only if a new area is > created; yes, but only if the person is left-handed") please > say so. We don't need answers explained right now; we're > just trying to see if we've got consensus. Also, we're not > assuming any particular structure for a new AD - if there's > agreement that we need one we'll come back and try to get > that answered afterwards. > > Thanks, > > Melinda -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From problem-statement-bounces@alvestrand.no Tue Jun 3 11:27:23 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09507 for ; Tue, 3 Jun 2003 11:27:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2D67062586; Tue, 3 Jun 2003 17:26:53 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by eikenes.alvestrand.no (Postfix) with ESMTP id 57D5362278 for ; Tue, 3 Jun 2003 17:26:50 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180])h53FQgCi023648; Tue, 3 Jun 2003 17:26:44 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h53FQRo7151308; Tue, 3 Jun 2003 17:26:27 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA52820 from ; Tue, 3 Jun 2003 17:26:24 +0200 Message-Id: <3EDCBE3A.590A924C@hursley.ibm.com> Date: Tue, 03 Jun 2003 17:26:50 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: John C Klensin References: <522974207.1054567784@p3.JCK.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "problem-statement@alvestrand.no" Subject: Re: Trusting the IESG to manage the reform process (was: Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 John C Klensin wrote: > > Summary: If we can't trust the current IESG for reform-process > management, we are in deep trouble. We have no choice except to trust them, because the IESG approving a BCP is the only way (short of anarchy) of effecting change. So, as you were suggesting, let's divide-and-conquer by cutting off bite sized problems, designing solutions, and sending them to the IESG. Er, I'm working on one of those. If everybody here worked on one, we might be done soon. Brian From problem-statement-bounces@alvestrand.no Tue Jun 3 12:06:24 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12148 for ; Tue, 3 Jun 2003 12:06:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 23A3762586; Tue, 3 Jun 2003 18:05:55 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6293A62278 for ; Tue, 3 Jun 2003 18:05:46 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19NEGK-0001pr-00; Tue, 03 Jun 2003 09:03:49 -0700 Date: Tue, 3 Jun 2003 12:01:52 -0400 From: Keith Moore To: Randy Bush Message-Id: <20030603120152.4f770704.moore@cs.utk.edu> In-Reply-To: References: <5.1.0.14.2.20030602152113.04362bf8@mail.windriver.co m> <524552917.1054569363@p3.JCK.COM> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: john-ietf@jck.com Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: Cutting through the accumulating sludge (was: Re: Doing the Right Things? and/or WG Quality Processes WG) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > intel may be the most successful. one key to this success is not > touching anything that does not have at least a 40% margin. i.e., > they say "no" to a lot of bright ideas. i do not believe that we > have the culture to do that. of course IETF doesn't measure success in dollars, but paying explicit attention to risk, need, and resource consumption would be a good idea. seems like we would do well to avoid WGs with high risk and low need, as well as those with high resource consumption and low need. at least when I was an AD there seemed to be a widespread belief that IETF was required to take on any working group for which there was a constituency. people need to understand that this is unreasonable. there are always more bright ideas than can be investigated. From problem-statement-bounces@alvestrand.no Tue Jun 3 12:06:41 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12182 for ; Tue, 3 Jun 2003 12:06:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3CA0D62598; Tue, 3 Jun 2003 18:06:12 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by eikenes.alvestrand.no (Postfix) with ESMTP id C756362598 for ; Tue, 3 Jun 2003 18:05:55 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19NEI8-0003Ug-00; Tue, 03 Jun 2003 09:05:40 -0700 Date: Tue, 3 Jun 2003 12:03:45 -0400 From: Keith Moore To: jari.arkko@piuha.net Message-Id: <20030603120345.3e351e01.moore@cs.utk.edu> In-Reply-To: <3EDC1E97.6070103@piuha.net> References: <3EDC1E97.6070103@piuha.net> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: john.loughney@nokia.com Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: WG Quality Processes WG X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 group seems a bit stuck in > its (very IETF-like) approach of trying to understand > the whole picture completely and agreeing on everything > before being able to take the first step. Funny, to me the IETF-like approach seems to be working on solutions before the problems are understood, and then getting frustrated when people realize late in the process (or even afterward) that the solution doesn't solve the problem and want to change it. From problem-statement-bounces@alvestrand.no Tue Jun 3 14:14:54 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17730 for ; Tue, 3 Jun 2003 14:14:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0EB5E6256F; Tue, 3 Jun 2003 20:14:23 +0200 (CEST) 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 DDE5162278 for ; Tue, 3 Jun 2003 20:14:20 +0200 (CEST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])h53IEKD20351 for ; Tue, 3 Jun 2003 21:14:20 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com ; Tue, 3 Jun 2003 21:14:18 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 21:14:19 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 21:14:19 +0300 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" Date: Tue, 3 Jun 2003 21:14:18 +0300 Message-ID: Thread-Topic: Trusting the IESG to manage the reform process (was: Re:Doingthe Right Things?) Thread-Index: AcMp5JNrWmJu2Qq5RoCZiTMqCTm4WgAFy7dA From: To: , X-OriginalArrivalTime: 03 Jun 2003 18:14:19.0406 (UTC) FILETIME=[F36D42E0:01C329FB] Cc: problem-statement@alvestrand.no Subject: RE: Trusting the IESG to manage the reform process (was: Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA17730 Hi Brian & John, > > Summary: If we can't trust the current IESG for reform-process > > management, we are in deep trouble. > > We have no choice except to trust them, because the IESG approving > a BCP is the only way (short of anarchy) of effecting change. > > So, as you were suggesting, let's divide-and-conquer by cutting off > bite sized problems, designing solutions, and sending them to > the IESG. > > Er, I'm working on one of those. If everybody here worked on one, > we might be done soon. I agree. Making some suggestions and designing solutions may be the way forward. John From problem-statement-bounces@alvestrand.no Tue Jun 3 14:16:54 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17868 for ; Tue, 3 Jun 2003 14:16:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D07CA62586; Tue, 3 Jun 2003 20:16:22 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id A9DC562278; Tue, 3 Jun 2003 20:16:18 +0200 (CEST) Date: Tue, 03 Jun 2003 20:16:18 +0200 From: Harald Tveit Alvestrand To: Brian E Carpenter , John C Klensin Message-ID: <59030000.1054664178@askvoll.hjemme.alvestrand.no> In-Reply-To: <3EDCBE3A.590A924C@hursley.ibm.com> References: <522974207.1054567784@p3.JCK.COM> <3EDCBE3A.590A924C@hursley.ibm.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) 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: Trusting the IESG to manage the reform process (was: Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 tirsdag, juni 03, 2003 17:26:50 +0200 Brian E Carpenter wrote: > John C Klensin wrote: >> >> Summary: If we can't trust the current IESG for reform-process >> management, we are in deep trouble. > > We have no choice except to trust them, because the IESG approving > a BCP is the only way (short of anarchy) of effecting change. > > So, as you were suggesting, let's divide-and-conquer by cutting off > bite sized problems, designing solutions, and sending them to the IESG. > > Er, I'm working on one of those. If everybody here worked on one, > we might be done soon. Brian, while I agree with you on a number of issues..... in side conversations, I've made a number of comments on the difficulty of crossing a chasm in two steps. In particular, I believe that the problem: 2.5.1 Span of Authority Overt authority in the IETF is concentrated in the small number of people sitting on the IESG at that time. Existing IETF processes work to funnel tasks on to this small number of people (primarily the Area Directors (ADs) in the IESG). This concentration slows up the process and puts a very large load of responsibility on to the shoulders of these people who are required to act as the senior management for Working Group (WG) chairs as well as acting as quality backstops for the large number of documents issued by the IETF. cannot be solved by making small changes to the IETF and IESG procedures; we need to change the way we make decisions, which is a BIG change. [yes, I have issues with the wording. But that's not important.] If there is a core problem that must be solved and cannot be solved by biting off small pieces, I think we cannot afford to ignore it. Harald From problem-statement-bounces@alvestrand.no Tue Jun 3 18:28:03 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28012 for ; Tue, 3 Jun 2003 18:28:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 94B2462595; Wed, 4 Jun 2003 00:27:33 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from clint.songbird.com (unknown [208.184.79.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4E83F62594 for ; Wed, 4 Jun 2003 00:27:30 +0200 (CEST) Received: from bbprime (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by clint.songbird.com (8.11.6/8.11.6) with ESMTP id h53MUMx25333; Tue, 3 Jun 2003 15:30:22 -0700 Date: Tue, 3 Jun 2003 15:27:25 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <149189936544.20030603152725@brandenburg.com> To: Keith Moore In-Reply-To: <20030531233816.40e5dbf9.moore@cs.utk.edu> References: <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Discipline of Internet Protocol Engineering X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Keith, Excellent points to raise. Each warrants its own thread, so I'm splitting my response(s). KM> 1. We need to define the discipline of Internet Protocol Engineering. KM> By that, I mean we need to enumerate a series of steps that should KM> normally be followed, more or less in order, when developing or modifying a KM> protocol for use on the Internet. Hmmm. We have "guidelines" for working group process. Perhaps you are suggesting "guidelines" for protocol development? Not a small task, but certainly a useful one. KM> The reason I say this is that several groups have demonstrated the inability KM> to define the problem they are working on, Unfortunately, i think this problem is deeper than we might wish to acknowledge. I tend to be a charter fascist, on the theory that a crystal clear charter will leave no doubt about the problem being solved, and/or the benefit to be derived from the result and the deliverables to be produced. I view charters as real contracts, making clear what is included and obligated and what is excluded and prohibited. However with great regularity, remarkably fuzzy charters are getting approved. since chartering involves lots of experienced people beyond the working group, we can't simply assess the problem on the working group folk. I don't know how to improve this. But, yes, we definitely need to keep trying. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue Jun 3 18:40:45 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28564 for ; Tue, 3 Jun 2003 18:40:44 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 342D962594; Wed, 4 Jun 2003 00:40:16 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from clint.songbird.com (unknown [208.184.79.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id EF62F62586 for ; Wed, 4 Jun 2003 00:40:12 +0200 (CEST) Received: from bbprime (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by clint.songbird.com (8.11.6/8.11.6) with ESMTP id h53Mh3x25982; Tue, 3 Jun 2003 15:43:03 -0700 Date: Tue, 3 Jun 2003 15:40:04 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <179190695205.20030603154004@brandenburg.com> To: Keith Moore In-Reply-To: <20030531233816.40e5dbf9.moore@cs.utk.edu> References: <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Working Group methods X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Keith, continuing with the separate points you made... KM> 2. We need to change the methods by which working groups conduct discussions. I believe you are correctly identifying an issue, but incorrectly characterizing it. I believe we already have the necessary methods available. However we do not reliably use them. The IETF has had an extremely important strength in the flexibility of its group process. When we have a small, focused, homogeneous groups with clear deliverables that are clearly understood, it can operate in a very streamlined way. Hence, for example, the sub-thread about moderators needs to note that a separate moderator is required only when they are required. That is, some groups do better with FEWER people holding positions. Keeping things simple is a Good Thing when things are, in fact, simple. Many groups do quite well on their mailing lists and in their meetings. Let's be careful not to "help" them to add unnecessary structure and become less efficient. I believe our repertoire of group management tools is quite rich. I believe the problem is that we do not USE it properly. In particular, we often do not have working group management invoke particular tools when needed. I would claim, therefore, that our tendency is to fail to notice when things are not simple, and to fail to implement *and enforce* stronger structure and management in those cases. Frankly the reason I originally started working group chair training roughly 10 years ago was not to teach new chairs about IETF formalities. Rather, we had too many chairs who were so careful about being fair and open, that they were not giving enough time to making forward progress. A working group needs to balance these two -- often conflicting -- requirements. So, the real challenge of chairing a group that has a difficult goal and/or a heterogeneous group, is shepherding the cats of diversity. And, yes, this includes mailing list management. It is quite a bit more difficult to manage an unruly list than an unruly meeting, partly for technical reasons and partly for reasons of general experience. But it is possible and it is done. The key in both cases is to impose highly active and structured management. So I am going to claim that the real requirements you are raising are to make sure that 1) working group management understands the group tools (procedures) it has available, and 2) that the working groups are encouraged to support the use of those procedures. ("encouraged" is a euphemism, in case that is not obvious.) KM> b. It's been repeatedly observed for several years that face-to-face meeting KM> time isn't used effectively Oddly, i think the problem is worse than this. Over recent years, we have not only repeatedly noted the problem, we have repeatedly noted the solution and it sure looked to me like we had community rough consensus on the solutions. But still we fail to heed all this guidance. I do not understand why. My best guess is that too few chairs really understand these issues and ADs do not begin to have the time to enforce things at this level. (And, yes, some ADs could, but choose not to.) KM> Powerpoint-style presentations (not that it really matters which KM> tool is used) tend to lull people into passivity, ...that are just KM> repeated by the speaker is to make a really ineffective use of KM> high-bandwidth meeting time. Sorry, but I view this as an excellent example of entirely missing the point. The issue is relevance and conciseness of the content, not the means by which it is presented. If we start forcing meetings to have carefully constructed agendas that are designed to use the limited time appropriately, and we *enforce* that structure, then we will not need to be distracted by the religion of presentation style. My own pet suggestion these days is that meeting agendas need to state their deliverables. What is the purpose of the meeting and how will the group have made progress by the end of the meeting? (And, by the way, displaying that purportedly unnecessary text is *extremely* helpful to non-native english speakers -- as long as the text is not too cryptic or slang-ful. For that matter, the real-time blogging helps such folk also.) KM> I suggest that the WG identify what kinds of things need to take place in KM> face-to-face meetings; A casual thought is to beef up the relevant section of the wg guidelines document. Another is to get more people to read the damn thing. KM> face-to-face meetings have to be narrowly focused on the WG; face-to-face KM> meetings can also be good times to resolve differences with other WGs or other KM> interests that aren't represented by WGs. mumble. I very much like the intent of your suggestion, but seriously doubt that adding anything other than strict working group content to working group meetings is a good idea. WGs are already too easily distracted. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue Jun 3 18:47:01 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28639 for ; Tue, 3 Jun 2003 18:47:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E2F8162595; Wed, 4 Jun 2003 00:46:30 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from clint.songbird.com (unknown [208.184.79.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id 69BDB62586; Wed, 4 Jun 2003 00:46:27 +0200 (CEST) Received: from bbprime (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by clint.songbird.com (8.11.6/8.11.6) with ESMTP id h53MnKx26297; Tue, 3 Jun 2003 15:49:20 -0700 Date: Tue, 3 Jun 2003 15:46:21 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <192191072147.20030603154621@brandenburg.com> To: Harald Tveit Alvestrand In-Reply-To: <9690000.1054492013@askvoll.hjemme.alvestrand.no> References: <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <9690000.1054492013@askvoll.hjemme.alvestrand.no> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: New ways to do things (Re: Doing the Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Keith and Harald, KM> 3. We need to see if there are specific kinds of areas or activities that we KM> need to engage in, for which our WG processes don't work well. 1. We do have some other mechanisms. IAB retreats and individual submissions are two examples. And though we often make humorous, dismissive reference to them, I believe Bar BOFs are a real and very productive part of our repertoire. 2. Absent specific suggestions, the basic claim that we ought to have different formal categories of groups sounds entirely reasonable. However practical alternatives are not obvious, to me at least. That is, I do not understand what functional differences are needed, to produce better results. (The labels are not the issue to me; but the structure and operational style are.) HTA> I think that for each solution path to be pursued, a core team with HTA> competence and energy to drive the process is needed, no matter what - and HTA> that once we have that, it almost doesn't matter how long the formal HTA> process to start the thing is; they can go to work right away, and do HTA> course corrections as part of the chartering process, rather than waiting HTA> for the "formalities" to complete before starting work. I heartily agree with this. When a group is motivated enough to start doing the real work, independent of IESG approval, then the latter is usually assured. The danger, of course, is that those "course corrections" might turn out to be "starting over" and that's not such a good thing. On the other hand, my own experience is that a group that has a strong enough sense of needing to delivery something, so that it does not wait for the IESG, usually has a compelling goal and effort. HTA> There are working groups that function in a number of different modes: ... HTA> Would we be better off if we developed a few terms different from "working HTA> group" This is one of those things that sounds completely reasonable, except for lacking the detail needed to be concrete. Yes, different projects have different goals. Some are cleanup exercises. Some are intended to invent whole new systems. Some are intended to create nicely-modular capabilities. Some involve well-understood problems and possible solutions. Some involve a great deal of fuzziness. But all of them are established to produce one or more documents, usually specifying a protocol. Absent concrete details about the operational differences that are appropriate to these different writing exercises, my own belief continues to be that any group that is sufficiently clear about the problem it is solving, and the benefit of that solution, and further that has a sense of urgency about providing it, will operate just fine as a working group. It is easy to create lots of distinguishing labels. But what will be the real benefit? We need to be careful not to make distinctions that lack essential difference. MW> We've been trying to figure out the *right* way to run a MW> non-standards-oriented function in the IETF -- specifically MW> internal education/training. ... MW> I suppose that we could have an internal education directorate, MW> but that wouldn't help to make our efforts more visible and/or MW> allow for wide community input. MW> So, maybe we need a WG? It would be a weird WG, but a WG MW> seems preferable to continuing to conduct this effort in MW> a back-room effort... I believe the core construct that you are citing is one of an *on-going* effort. Indeed this is something that we have never figured out comfortably. The history of open-ended working groups is quite poor, so this is a case in which we well might want to create a different category. However, we need to be very clear about its nature and obligations. What will it do that is different from a working group? Hmmm. Is it slightly similar to kind of IAB, in the sense of providing a home for a collection of experts so that they can provide strategic guidance about one or more topics, with the intent that other groups then follow through on the work? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue Jun 3 19:13:11 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29309 for ; Tue, 3 Jun 2003 19:13:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ACF8862598; Wed, 4 Jun 2003 01:12:42 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from clint.songbird.com (unknown [208.184.79.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id BEABB62595 for ; Wed, 4 Jun 2003 01:12:39 +0200 (CEST) Received: from bbprime (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by clint.songbird.com (8.11.6/8.11.6) with ESMTP id h53NFWx27787; Tue, 3 Jun 2003 16:15:32 -0700 Date: Tue, 3 Jun 2003 16:12:32 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <39192643596.20030603161232@brandenburg.com> To: Keith Moore In-Reply-To: <20030531233816.40e5dbf9.moore@cs.utk.edu> References: <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Keith, And lastly... KM> 4. We need to reorganize our document series. Again, this is something we have lots of agreement about, at this level of statement. But then we get bogged down in the details. So I suggest that people pursue the topic in terms of what stages of a document are *useful* to the community. That is, where is community motivation for changes in a document or a document's status? If we can figure that out, then we will have stages the community actually uses. Here is my own thought on useful stages: 1. Technical discussion and convergence -- form community consensus 2. Technical refinement -- lock down the details 3. Proof of concept and debugging 4. Stability -- community operational acceptance The first is pure mayhem, and that's good. People explore, suggest, debate. Eventually, they should start to form group preferences and focus on getting the details worked into a specification that provides detail which readers can understand and see as coherent and sufficient for achieving a specific set of useful functions. Then they test the thing, to see whether interoperable implementations can be developed. Then they actually use the thing, eventually achieving some sort of critical mass of deployment. Now, the clever reader will observe that we already have exactly these stages. (Personal I-D, WG ID -> PS, Draft, Full.) Yet the latter 2 are virtually unused. The community does not care about demonstrated ability to operate or demonstrated deployment and use? Or is it that they merely do not need the IETF to tell them (anymore)? As to whether the barrier to PS is too high, I strongly suspect that the more serious problem is that we are not getting scope correct. We are tending to try to deliver specifications that cover too much, and thereby any reasonable requirement for completeness, manageability, security, etc., becomes onerous. Yes, there well may be a problem with requiring perfection in PS. The language "no known defects" can be used as a bludgeon. But I keep thinking that that is better fixed by divide-and-conquor than lack of detail. We might also want to consider whether the effort to attain Draft or Full are too high. Historically, we simply took folks' word that adequate interoperability had been achieved. These days we often required an auditor's accounting that every single feature was tested. We might also want to consider enforcing time-outs. If a document is PS and has not reached Draft after awhile, move it to historic... Oh. We already have that rule: RFC 2026 6.2 Advancing in the Standards Track ... When a standards-track specification has not reached the Internet Standard level but has remained at the same maturity level for twenty-four (24) months, and every twelve (12) months thereafter until the status is changed, the IESG shall review the viability of the standardization effort responsible for that specification and the usefulness of the technology. Following each such review, the IESG shall approve termination or continuation of the development effort, So, once again, it appears the problem is that we are not using the tools we already have. Why is that? Does it really mean that somehow, different rules will work better? Or does it mean that we need to organize our administration of those rules differently? KM> Some SDOs have a numbering scheme that reflects categories, Sounds to me like you are describing what STD numbering was intended for. My guess is that we do not use it because we do not maintain it. Or perhaps there is another reason? KM> and I think we KM> might do well to consider such a scheme for IETF documents. This probably KM> means abandoning the linear RFC numbering scheme entirely, though it doesn't KM> mean that we have to stop calling them RFCs. No. The linear numbering scheme ensures unique reference. We all like unique references. The problem is that we also like stable references. The idea behind the STD series was to provide both stability of reference and aggregation of related specifications. SD> The hurdle I see is that there actually is an "editor role" that's missing SD> - not today's draft editors, and not today's "rfc editor", but an editor SD> that takes the output of successful Document Actions and merging SD> them into existing specifications, where this is applicable. Localized versions of aggregations are the meta-specifications that are mostly a vehicle for citing components. Frankly I like these a lot. But they do not operate well over multi-working group efforts. Again, that's what STDs were intended for. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue Jun 3 19:13:53 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29344 for ; Tue, 3 Jun 2003 19:13:52 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 15B2C625A1; Wed, 4 Jun 2003 01:13:25 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from grouse.mail.pas.earthlink.net (grouse.mail.pas.earthlink.net [207.217.120.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5F6BD625A0 for ; Wed, 4 Jun 2003 01:13:23 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19NKxu-0005pH-00; Tue, 03 Jun 2003 16:13:14 -0700 Date: Tue, 3 Jun 2003 19:11:16 -0400 From: Keith Moore To: Dave Crocker Message-Id: <20030603191116.0cd5730a.moore@cs.utk.edu> In-Reply-To: <149189936544.20030603152725@brandenburg.com> References: <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <149189936544.20030603152725@brandenburg.com> X-Mailer: Sylpheed version 0.8.11 (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 Cc: dhc@dcrocker.net Cc: moore@cs.utk.edu Subject: Re: Discipline of Internet Protocol Engineering X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > KM> 1. We need to define the discipline of Internet Protocol Engineering. > > KM> By that, I mean we need to enumerate a series of steps that should > KM> normally be followed, more or less in order, when developing or > KM> modifying a protocol for use on the Internet. > > Hmmm. We have "guidelines" for working group process. Perhaps you are > suggesting "guidelines" for protocol development? yes, this is approximately what I have in mind - at least as I understand it at present. I liked the term "roadmap" that someone else suggested also. > KM> The reason I say this is that several groups have demonstrated the > KM> inability to define the problem they are working on, > > Unfortunately, i think this problem is deeper than we might wish to > acknowledge. I tend to be a charter fascist, on the theory that a > crystal clear charter will leave no doubt about the problem being > solved, and/or the benefit to be derived from the result and the > deliverables to be produced. ... > However with great regularity, remarkably fuzzy charters are getting > approved. since chartering involves lots of experienced people beyond > the working group, we can't simply assess the problem on the working > group folk. My view is that we often don't have enough understanding of the problem at the time a WG is chartered to insist that the charter be very precise or detailed. And charter refinement is yet another thing that takes up IESG resources. Also, asking groups to write "requirements" documents (or as I would prefer, "design goals" documents) hasn't worked well either as far as I can tell - groups don't seem to understand the purpose behind this task or how to do it. So we need to find a better way to refine WGs' problem definitions. From problem-statement-bounces@alvestrand.no Tue Jun 3 20:04:05 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00836 for ; Tue, 3 Jun 2003 20:04:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7BD3D62595; Wed, 4 Jun 2003 02:03:34 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7050B62594 for ; Wed, 4 Jun 2003 02:03:31 +0200 (CEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA06644; Tue, 3 Jun 2003 17:03:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5403TQ32250; Tue, 3 Jun 2003 17:03:29 -0700 X-mProtect: <200306040003> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.150, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpHHTTU; Tue, 03 Jun 2003 17:03:25 PDT Message-Id: <4.3.2.7.2.20030603162734.02d46240@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 03 Jun 2003 17:03:23 -0700 To: Dave Crocker From: Bob Hinden In-Reply-To: <39192643596.20030603161232@brandenburg.com> References: <20030531233816.40e5dbf9.moore@cs.utk.edu> <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Dave, >Here is my own thought on useful stages: > >1. Technical discussion and convergence -- form community consensus >2. Technical refinement -- lock down the details >3. Proof of concept and debugging >4. Stability -- community operational acceptance > >The first is pure mayhem, and that's good. People explore, suggest, >debate. Eventually, they should start to form group preferences and >focus on getting the details worked into a specification that provides >detail which readers can understand and see as coherent and sufficient >for achieving a specific set of useful functions. Then they test the >thing, to see whether interoperable implementations can be developed. >Then they actually use the thing, eventually achieving some sort of >critical mass of deployment. > >Now, the clever reader will observe that we already have exactly these >stages. (Personal I-D, WG ID -> PS, Draft, Full.) Yet the latter 2 are >virtually unused. As you correctly point out the IETF (and as implemented by the IESG) is not using the standards process we have defined. It has been changed where the initial barrier has been raised very high at Proposed Standard and hardy anything gets to Draft standard, let alone (Full) Standard. I think that many of the problems folks are complaining about stem from this. It causes the IESG to worry about letting a document get to PS that is not perfect. This results in many detailed reviews and documents being blocked for what might seem minor reasons. This in turn creates a work load on the IESG that is close to impossible. The resulting delays cause frustration between authors, chairs, working groups, AD, etc. I think that a lot of this stems from trying to make PS the biggest hurdle. I think that if we implemented the standard process as written (and as intended) that many of these problems would go away. Perfection would only have to be achieved at Standard (and close to perfection at Draft standard). This would mean that problems with specifications could be found by people implementation the protocols and running into problems, and then bringing the issues back into the working groups. Interoperability problems would be found. This would spread the load of improving the quality of the specifications to a much larger community of people than just the IESG members. Running code and interoperability would be the real test for quality. Enforcing the time outs would create incentives to move the specifications through the standards process. I also suspect that some (perhaps many) specifications never really get implemented, so as long as we enforced the time outs as specified, that these would just go away. There is a lot of parallels with the multi-step IETF standards process as with building products. First versions of products always have problem. Most successful product companies learn that trying to make the first product perfect is counter productive because it creates long delays and the real test is getting the product to the costumers. Then the company really learns how well the product works and meets the market need (i.e., requirements). It through creating new versions of the products that problems are fixed and quality is improved. Companies that delay the first release until the product is perfect usually go out of business. I wonder if that is what is happening with the IETF. Bob From problem-statement-bounces@alvestrand.no Tue Jun 3 20:16:08 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00996 for ; Tue, 3 Jun 2003 20:16:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CB50D62595; Wed, 4 Jun 2003 02:15:37 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1C0B662594 for ; Wed, 4 Jun 2003 02:15:35 +0200 (CEST) Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4772934 for problem-statement@alvestrand.no; Tue, 03 Jun 2003 20:15:33 -0400 Message-Id: <5.1.0.14.0.20030603200432.0276ee28@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Jun 2003 20:14:11 -0400 To: problem-statement@alvestrand.no From: "Joel M. Halpern" In-Reply-To: <4.3.2.7.2.20030603162734.02d46240@mailhost.iprg.nokia.com> References: <39192643596.20030603161232@brandenburg.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 think we are each making assumptions about the history that led to this, and it would not surprise me if we are making different assumptions. Note that I do not have data to back my understanding / memory, so I may well be confused. My understanding is that the higher bar to PS arose as a consequence of things being widely deployed at PS and things not advancing to Draft rather than the deployment and non-advancement being a consequence of the high bar. This is important in the sense that if the lack of advancement came first, then simply lowering the bar will not help us get better standards, and in fact could result in our ending up with lower quality documents permanently. Yours, Joel M. Halpern At 05:03 PM 6/3/2003 -0700, Bob Hinden wrote (in response to Dave Crocker): >As you correctly point out the IETF (and as implemented by the IESG) is >not using the standards process we have defined. It has been changed >where the initial barrier has been raised very high at Proposed Standard >and hardy anything gets to Draft standard, let alone (Full) Standard. > >I think that many of the problems folks are complaining about stem from >this. It causes the IESG to worry about letting a document get to PS that >is not perfect. This results in many detailed reviews and documents being >blocked for what might seem minor reasons. This in turn creates a work >load on the IESG that is close to impossible. The resulting delays cause >frustration between authors, chairs, working groups, AD, etc. I think >that a lot of this stems from trying to make PS the biggest hurdle. From problem-statement-bounces@alvestrand.no Tue Jun 3 21:23:28 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03046 for ; Tue, 3 Jun 2003 21:23:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6122A62595; Wed, 4 Jun 2003 03:22:58 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9C94462590 for ; Wed, 4 Jun 2003 03:22:56 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19NMzJ-0005OW-00; Tue, 03 Jun 2003 18:22:49 -0700 Date: Tue, 3 Jun 2003 21:20:52 -0400 From: Keith Moore To: "Joel M. Halpern" Message-Id: <20030603212052.740e009a.moore@cs.utk.edu> In-Reply-To: <5.1.0.14.0.20030603200432.0276ee28@mail.stevecrocker.com> References: <39192643596.20030603161232@brandenburg.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <5.1.0.14.0.20030603200432.0276ee28@mail.stevecrocker.com> X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Subject: Re: Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 O> My understanding is that the higher bar to PS arose as a consequence of > things being widely deployed at PS and things not advancing to Draft rather > than the deployment and non-advancement being a consequence of the high bar. that's my understanding also. > This is important in the sense that if the lack of advancement came first, > then simply lowering the bar will not help us get better standards, and in > fact could result in our ending up with lower quality documents permanently. I'm in strong agreement with this. What we need to do is find a way for standards to at least the level that is currently required for PS more quickly, not to lower the bar for PS. We might even need to raise the bar slightly. From problem-statement-bounces@alvestrand.no Tue Jun 3 22:01:54 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04010 for ; Tue, 3 Jun 2003 22:01:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A344A61BA7; Wed, 4 Jun 2003 04:01:23 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by eikenes.alvestrand.no (Postfix) with ESMTP id 04A3761BA7 for ; Wed, 4 Jun 2003 04:01:14 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19NNaP-0005TJ-00; Tue, 03 Jun 2003 19:01:09 -0700 Date: Tue, 3 Jun 2003 21:59:12 -0400 From: Keith Moore To: Dave Crocker Message-Id: <20030603215912.13f7eb3c.moore@cs.utk.edu> In-Reply-To: <179190695205.20030603154004@brandenburg.com> References: <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <179190695205.20030603154004@brandenburg.com> X-Mailer: Sylpheed version 0.8.11 (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 Cc: dhc@dcrocker.net Cc: moore@cs.utk.edu Subject: Re: Working Group methods X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > KM> 2. We need to change the methods by which working groups conduct > KM> discussions. > > I believe you are correctly identifying an issue, but incorrectly > characterizing it. I believe we already have the necessary methods > available. However we do not reliably use them. I suspect we are mostly in agreement about that. Working groups already have a great deal of latitude as to how they conduct discussions, and different mechanisms are appropriate for different groups with different needs. I am not suggesting that we impose new structures on working groups that don't need them. I am suggesting that most working groups are not now operating effectively, and that overall, the operation of most working groups need to change. That doesn't necessarily require imposition of new structures. However, there are strong expectations in the community that mailing list discussions and meetings will be conducted in certain ways. We need to change these expectations, especially where they are found to do harm. I attempted to list some examples of these expectations in my previous message. We may even need to change some of our cherished mechanisms. Perhaps, for instance, we should abandon the notion that we can obtain a meaningful conseneus on a large mailing list whose active participants vary considerably from one week to the next, and where it's difficult to distinguish silence that indicates a lack of dissent from silence that indicates exhaustion. > So I am going to claim that the real requirements you are raising are to > make sure that > > 1) working group management understands the group tools (procedures) it > has available, and > > 2) that the working groups are encouraged to support the use of those > procedures. ("encouraged" is a euphemism, in case that is not obvious.) I don't disagree with either of the above, but I don't think they're quite equivalent to what I was suggesting. I don't think this is a change that can be effected by working group management alone - I think it will require buyin of the entire community. Ordinary working group participants need to understand that the way we participate in working groups has to change, and we need for the community, not merely the WG leadership, to reinforce this within itself. We need to break our bad habits. > KM> b. It's been repeatedly observed for several years that face-to-face > KM> meeting time isn't used effectively > > Oddly, i think the problem is worse than this. Over recent years, we > have not only repeatedly noted the problem, we have repeatedly noted the > solution and it sure looked to me like we had community rough consensus > on the solutions. > > But still we fail to heed all this guidance. I do not understand why. > My best guess is that too few chairs really understand these issues and > ADs do not begin to have the time to enforce things at this level. (And, > yes, some ADs could, but choose not to.) My best guess is that in most cases neither chairs nor ADs felt like they had sufficient actual political power (as opposed to what our procedures say they have) to make the changes that were necessary, in the face of strong community expectation that the old, familiar procedures be used. > KM> Powerpoint-style presentations (not that it really matters which > KM> tool is used) tend to lull people into passivity, ...that are just > KM> repeated by the speaker is to make a really ineffective use of > KM> high-bandwidth meeting time. > > Sorry, but I view this as an excellent example of entirely missing the > point. The issue is relevance and conciseness of the content, not the > means by which it is presented. The medium really does have an effect. Yes, you can use PowerPoint to present a topic in a concise and relevant manner, but the medium encourages exactly the opposite - it encourages over-use of words and under-use of pictures (because good pictures are hard to draw in PowerPoint); it encourages a highly linear and one-way discussion rather than a multi-way exchange of ideas. If you had to present the same ideas using a white board or chalk board, you'd have much more incentive to be concise and focused. Which is not to say that I want to ban PowerPoint. But as long as we're using tools like this, we need to understand how to use the tools in the best manner, and we need to respect their limitations. > KM> face-to-face meetings have to be narrowly focused on the WG; > KM> face-to-face meetings can also be good times to resolve differences with > KM> other WGs or other interests that aren't represented by WGs. > > mumble. I very much like the intent of your suggestion, but seriously > doubt that adding anything other than strict working group content to > working group meetings is a good idea. WGs are already too easily > distracted. When planning a meeting, every WG chair needs to ask: "what kind of input or discussion to we need to be having that we can't easily have over the net?" If that's purely WG discussion, so be it. If the WG needs external input, then by all means the WG should make use of the opportunity to get those people in the room. And it would probably be a good idea for each WG chair to discuss this with his/her AD before meeting planning gets too far along (assuming, of course, that both the AD and the WG chair can find enough time to actually plan the meeting - I know that when I was AD meeting planning didn't get enough of my cycles.) From problem-statement-bounces@alvestrand.no Tue Jun 3 23:32:10 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05534 for ; Tue, 3 Jun 2003 23:32:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A3D26259F; Wed, 4 Jun 2003 05:31:40 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5BA9662595 for ; Wed, 4 Jun 2003 05:31:38 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19NOzs-00007q-00; Tue, 03 Jun 2003 20:31:32 -0700 Date: Tue, 3 Jun 2003 23:29:35 -0400 From: Keith Moore To: Dave Crocker Message-Id: <20030603232935.5252f567.moore@cs.utk.edu> In-Reply-To: <39192643596.20030603161232@brandenburg.com> References: <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <39192643596.20030603161232@brandenburg.com> X-Mailer: Sylpheed version 0.8.11 (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 Cc: dhc@dcrocker.net Cc: moore@cs.utk.edu Subject: Re: Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > KM> 4. We need to reorganize our document series. > > Again, this is something we have lots of agreement about, at this level > of statement. But then we get bogged down in the details. Well, to the extent I was suggesting details, I intended them merely as examples, not as concrete suggestions. I don't pretend to have worked out enough details to make a credible proposal, and I think that is the job of the follow-on group rather than the problem statement group. > So I suggest that people pursue the topic in terms of what stages of a > document are *useful* to the community. I'm thinking that we need to understand what stages of a document will be used by implementors. i.e. at what point of apparent stability, maturity, and buy-in will implementors start prototyping? At what point will they start interop testing? At what point will they start shipping product? Once we understand implementors' needs and expectations, we will be in a better position to decide what the criteria for acceptance of those stages should be. Of course we also have to reconcile that understanding with WG energies and expectations, and with the engineering roadmap. > As to whether the barrier to PS is too high, I strongly suspect that the > more serious problem is that we are not getting scope correct. We are > tending to try to deliver specifications that cover too much, and > thereby any reasonable requirement for completeness, manageability, > security, etc., becomes onerous. I strongly disagree. If anything, I'm convinced that we are not covering enough bases - we are producing too many protocols that work at cross-purposes with our other efforts. > Yes, there well may be a problem with requiring perfection in PS. The > language "no known defects" can be used as a bludgeon. But I keep > thinking that that is better fixed by divide-and-conquor than lack of > detail. I have serious doubts about that. > We might also want to consider whether the effort to attain Draft or > Full are too high. Historically, we simply took folks' word that > adequate interoperability had been achieved. These days we often > required an auditor's accounting that every single feature was tested. I've never seen an "auditor's accounting" required; only a simple list. When protocols have large feature sets it really does seem worth examining which features are implementable and which ones are used. I'm not sure how much good it does to try to test the interoperability of each feature individually, though - I suspect that this about as useful as doing conformance testing. So yes, I think our testing criteria are worth looking at. But I don't think it's terribly helpful to think in terms of tweaking the existing PS, DS, and FS levels. I think we need to start with a clean white board and figure out what levels we really need, because currently only one of these levels seems very useful, and there are arguments that even PS has a poor impedance match with what implementors need and expect. > KM> Some SDOs have a numbering scheme that reflects categories, > > Sounds to me like you are describing what STD numbering was intended > for. Not really. STD is just another kind of document serial number, except that if you revise a document it can keep the old serial number. But it doesn't serve as any kind of classification scheme; it doesn't help you group related documents together. > My guess is that we do not use it because we do not maintain it. Or > perhaps there is another reason? My guess is that STD is not used because STD numbers are only assigned at FS. Of course, that hardly ever happens, and the practice of citing RFC numbers is too well-entrenched to be displaced by a practice of citing STD numbers that are rarely assigned. We can't solve this problem by merely creating a new numbering scheme alongside RFC numbers. We either need to abandon the "RFC" name entirely or we need to start numbering them differently. > The linear numbering scheme ensures unique reference. We all like > unique references. The problem is that we also like stable references. There are other ways to get unique references. e.g. Dates work well. But again, this isn't the place to try to work out the details - I cited these merely as examples of things we need to look at. Keith From problem-statement-bounces@alvestrand.no Tue Jun 3 23:35:44 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05567 for ; Tue, 3 Jun 2003 23:35:44 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 655E46259F; Wed, 4 Jun 2003 05:35:15 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9279262595; Wed, 4 Jun 2003 05:35:10 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19NP3G-00064w-00; Tue, 03 Jun 2003 20:35:02 -0700 Date: Tue, 3 Jun 2003 23:33:03 -0400 From: Keith Moore To: Dave Crocker Message-Id: <20030603233303.0e198bc9.moore@cs.utk.edu> In-Reply-To: <192191072147.20030603154621@brandenburg.com> References: <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <9690000.1054492013@askvoll.hjemme.alvestrand.no> <192191072147.20030603154621@brandenburg.com> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: harald@alvestrand.no Cc: dhc@dcrocker.net Cc: moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: Re: New ways to do things (Re: Doing the Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > KM> 3. We need to see if there are specific kinds of areas or activities > KM> that we need to engage in, for which our WG processes don't work well. > > 1. We do have some other mechanisms. IAB retreats and individual > submissions are two examples. And though we often make humorous, > dismissive reference to them, I believe Bar BOFs are a real and very > productive part of our repertoire. agreed. > 2. Absent specific suggestions, the basic claim that we ought to have > different formal categories of groups sounds entirely reasonable. > However practical alternatives are not obvious, to me at least. That is, > I do not understand what functional differences are needed, to produce > better results. Nor do I, and I'd have to think about it for several hours before I could even make a strawman proposal. For now I merely wanted to suggest this as a topic for study by the solution WG. From problem-statement-bounces@alvestrand.no Wed Jun 4 02:14:27 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19899 for ; Wed, 4 Jun 2003 02:14:27 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0943A6259F; Wed, 4 Jun 2003 08:13:52 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7053362595 for ; Wed, 4 Jun 2003 08:13:48 +0200 (CEST) Received: from bbprime (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h546GSF04081; Tue, 3 Jun 2003 23:16:28 -0700 Date: Tue, 3 Jun 2003 23:13:29 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <127217900264.20030603231329@brandenburg.com> To: john.loughney@nokia.com In-Reply-To: References: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: john-ietf@jck.com Cc: problem-statement@alvestrand.no Subject: Re: Cutting through the accumulating sludge (was: Re: Doing the Right Things? and/or WG Quality Processes WG) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 john, jlnc> That sounds like a reasonable way forward, but there are the boring jlnc> details of where to feed the proposals, get the decision, do jlnc> the review, who should take the lead, etc. I think this is jlnc> what we need to decide to do in the next week or two. The experience with the SIRS proposal would seem to be instructive here. Brian Carpenter had an idea. He chatted it up. One soul he talked to was particularly taken by the idea and worked with Brian to produce a few paragraphs to describe it. Brian floated the paragraphys on a list that seemed relevant. Comments flowed. Brian and his unlucky cohort then produced a formal specification, iterating on the commentary/revision sequence sequence. A test implementation has just started. Lots of people have said they liked the idea. Some people have volunteered to participate. We'll see whether it is useful. The only "formal" part of this was to coordinate with the IETF Chair, mostly to make sure that that part of the community did not have concerns about this. At some point, it will be appropriate for press this into official form, but it is not essential to the core development or testing of the idea. Many bits of work can be done this way, and frankly I also think they should be. Not all, but many. There are substantial benefits, and few detriments. The core benefits are staying close to a core (good) idea and getting the details delivered relatively quickly. (As far as I know, Brian's idea was first floated only at the last IETF.) Hence there is no risk of design-by-committe bloat or loss of focus, and there is no significant risk of taking forever to produce something. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Wed Jun 4 02:17:42 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22072 for ; Wed, 4 Jun 2003 02:17:41 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E2A5D6259F; Wed, 4 Jun 2003 08:17:08 +0200 (CEST) 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 D073562595 for ; Wed, 4 Jun 2003 08:17:02 +0200 (CEST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])h546H2D15062 for ; Wed, 4 Jun 2003 09:17:02 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com ; Wed, 4 Jun 2003 09:17:01 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 4 Jun 2003 09:17:00 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 4 Jun 2003 09:17:00 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 4 Jun 2003 09:16:59 +0300 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" Date: Wed, 4 Jun 2003 09:16:54 +0300 Message-ID: Thread-Topic: Cutting through the accumulating sludge (was: Re: Doing the Right Things? and/or WG Quality Processes WG) Thread-Index: AcMqYG/qumRbqaECTw+kT3N6dv129AAACcMA From: To: X-OriginalArrivalTime: 04 Jun 2003 06:16:59.0655 (UTC) FILETIME=[E8263170:01C32A60] Cc: john-ietf@jck.com Cc: problem-statement@alvestrand.no Subject: RE: Cutting through the accumulating sludge (was: Re: Doing the Right Things? and/or WG Quality Processes WG) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA22072 Hi Dave, > jlnc> That sounds like a reasonable way forward, but there > are the boring > jlnc> details of where to feed the proposals, get the decision, do > jlnc> the review, who should take the lead, etc. I think this is > jlnc> what we need to decide to do in the next week or two. > > The experience with the SIRS proposal would seem to be > instructive here. Your comments, below, are not too different from what I think should happen. I don't think that we should have design by committe or anything. A venue (mailing list) and potential face-to-face time to discuss it are sufficient starting points, in my mind. br, John > Brian Carpenter had an idea. He chatted it up. One soul he talked to was > particularly taken by the idea and worked with Brian to produce a few > paragraphs to describe it. Brian floated the paragraphys on a > list that seemed relevant. Comments flowed. > > Brian and his unlucky cohort then produced a formal specification, > iterating on the commentary/revision sequence sequence. > > A test implementation has just started. Lots of people have said they > liked the idea. Some people have volunteered to participate. We'll see > whether it is useful. > > The only "formal" part of this was to coordinate with the IETF Chair, > mostly to make sure that that part of the community did not have > concerns about this. > > At some point, it will be appropriate for press this into official form, > but it is not essential to the core development or testing of > the idea. > > Many bits of work can be done this way, and frankly I also think they > should be. Not all, but many. > > There are substantial benefits, and few detriments. The core benefits > are staying close to a core (good) idea and getting the details > delivered relatively quickly. (As far as I know, Brian's idea was first > floated only at the last IETF.) Hence there is no risk of > design-by-committe bloat or loss of focus, and there is no significant > risk of taking forever to produce something. > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > > From problem-statement-bounces@alvestrand.no Wed Jun 4 02:31:51 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04198 for ; Wed, 4 Jun 2003 02:31:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BC3166259F; Wed, 4 Jun 2003 08:31:20 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9C6DA62595 for ; Wed, 4 Jun 2003 08:31:16 +0200 (CEST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])h546VFW04266 for ; Wed, 4 Jun 2003 09:31:15 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com ; Wed, 4 Jun 2003 09:31:14 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 4 Jun 2003 09:31:13 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 4 Jun 2003 09:31:13 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 4 Jun 2003 09:31:13 +0300 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" Date: Wed, 4 Jun 2003 09:31:07 +0300 Message-ID: Thread-Topic: Discipline of Internet Protocol Engineering Thread-Index: AcMqH1ggnTWWzTEaTjGgdR2gquoSWQAQrGIg From: To: , X-OriginalArrivalTime: 04 Jun 2003 06:31:13.0236 (UTC) FILETIME=[E4EC5140:01C32A62] Cc: problem-statement@alvestrand.no Subject: RE: Discipline of Internet Protocol Engineering X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA04198 Hi Dave & Keith, > KM> The reason I say this is that several groups have demonstrated the inability > KM> to define the problem they are working on, > > Unfortunately, i think this problem is deeper than we might wish to > acknowledge. I tend to be a charter fascist, on the theory that a > crystal clear charter will leave no doubt about the problem being > solved, and/or the benefit to be derived from the result and the > deliverables to be produced. > > I view charters as real contracts, making clear what is included and > obligated and what is excluded and prohibited. > > However with great regularity, remarkably fuzzy charters are getting > approved. since chartering involves lots of experienced people beyond > the working group, we can't simply assess the problem on the working > group folk. > > I don't know how to improve this. But, yes, we definitely > need to keep trying. I would say that there is a breakdown in the chartering process. I would think, for example, inviting the proposed WG chairs to the conference call when the charter is discussed could help, for example. As a novice chair, creating a charter is difficult. Better advice & engagement from the IAB/IESG would be helpful. For experienced WG chairs, there can be a tendancy that many of the IAB/IESG seem to be more lenient with their proprosed charters because the experienced chair is a known quantity, so the thought is that they know what they are doing. John From problem-statement-bounces@alvestrand.no Wed Jun 4 02:34:26 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05318 for ; Wed, 4 Jun 2003 02:34:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 28466625A0; Wed, 4 Jun 2003 08:33:55 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9142862595 for ; Wed, 4 Jun 2003 08:33:52 +0200 (CEST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])h546XpW07945 for ; Wed, 4 Jun 2003 09:33:51 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com ; Wed, 4 Jun 2003 09:33:26 +0300 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 4 Jun 2003 09:33:26 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 4 Jun 2003 09:33:25 +0300 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" Date: Wed, 4 Jun 2003 09:33:24 +0300 Message-ID: Thread-Topic: Discipline of Internet Protocol Engineering Thread-Index: AcMqH1ggnTWWzTEaTjGgdR2gquoSWQAQrGIgAAA6eWA= From: To: , X-OriginalArrivalTime: 04 Jun 2003 06:33:25.0845 (UTC) FILETIME=[33F6D850:01C32A63] Cc: problem-statement@alvestrand.no Subject: RE: Discipline of Internet Protocol Engineering X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA05318 Just a short reply to myself - I forgot to add that one of the difficulties of creating a charter is that, often, you think you know what you want to accomplish it, but sometimes it is difficult to seperate from what from the how and the why. Thinking about this a bit more, maybe we need to have more formal guidelines on what a charter should contain. John > -----Original Message----- > From: ext [mailto:john.loughney@nokia.com] > Sent: 04 June, 2003 09:31 > To: dcrocker@brandenburg.com; moore@cs.utk.edu > Cc: problem-statement@alvestrand.no > Subject: RE: Discipline of Internet Protocol Engineering > > > Hi Dave & Keith, > > > KM> The reason I say this is that several groups have > demonstrated the inability > > KM> to define the problem they are working on, > > > > Unfortunately, i think this problem is deeper than we might wish to > > acknowledge. I tend to be a charter fascist, on the theory that a > > crystal clear charter will leave no doubt about the problem being > > solved, and/or the benefit to be derived from the result and the > > deliverables to be produced. > > > > I view charters as real contracts, making clear what is included and > > obligated and what is excluded and prohibited. > > > > However with great regularity, remarkably fuzzy charters are getting > > approved. since chartering involves lots of experienced > people beyond > > the working group, we can't simply assess the problem on the working > > group folk. > > > > I don't know how to improve this. But, yes, we definitely > > need to keep trying. > > I would say that there is a breakdown in the chartering > process. I would > think, for example, inviting the proposed WG chairs to the > conference call > when the charter is discussed could help, for example. As a > novice chair, > creating a charter is difficult. Better advice & engagement > from the IAB/IESG > would be helpful. For experienced WG chairs, there can be a > tendancy that > many of the IAB/IESG seem to be more lenient with their > proprosed charters > because the experienced chair is a known quantity, so the > thought is that > they know what they are doing. > > John > From problem-statement-bounces@alvestrand.no Wed Jun 4 02:38:12 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05406 for ; Wed, 4 Jun 2003 02:38:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 81A796259F; Wed, 4 Jun 2003 08:37:41 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id 620FE62595 for ; Wed, 4 Jun 2003 08:37:36 +0200 (CEST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])h546bZW11388 for ; Wed, 4 Jun 2003 09:37:35 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com ; Wed, 4 Jun 2003 09:37:35 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 4 Jun 2003 09:37:35 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 4 Jun 2003 09:37:34 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 4 Jun 2003 09:37:34 +0300 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" Date: Wed, 4 Jun 2003 09:37:30 +0300 Message-ID: Thread-Topic: Working Group methods Thread-Index: AcMqISMl9bRkt5D8RFWzGFXE8bU9yQAQi+TA From: To: , X-OriginalArrivalTime: 04 Jun 2003 06:37:34.0339 (UTC) FILETIME=[C8140530:01C32A63] Cc: problem-statement@alvestrand.no Subject: RE: Working Group methods X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA05406 Hi Dave, Some short comments: > Many groups do quite well on their mailing lists and in their meetings. > Let's be careful not to "help" them to add unnecessary structure and > become less efficient. > > I believe our repertoire of group management tools is quite rich. I > believe the problem is that we do not USE it properly. In particular, we > often do not have working group management invoke particular > tools when needed. > > I would claim, therefore, that our tendency is to fail to notice when > things are not simple, and to fail to implement *and enforce* stronger > structure and management in those cases. Quickly summarizing, I think what we need is more rigor in WG management / mailing list management. We have the tools & processes, what we need to do is apply them and be more rigorous in enforcing discipline, when needed. More education (esp. to chairs and editors) would help as well. > My own pet suggestion these days is that meeting agendas need to > state their deliverables. What is the purpose of the meeting and how > will the group have made progress by the end of the meeting? I'll buy that. John From problem-statement-bounces@alvestrand.no Wed Jun 4 03:20:02 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06382 for ; Wed, 4 Jun 2003 03:20:01 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1669A625A3; Wed, 4 Jun 2003 09:19:27 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2C793625C2; Wed, 4 Jun 2003 09:18:52 +0200 (CEST) Date: Wed, 04 Jun 2003 09:18:51 +0200 From: Harald Tveit Alvestrand To: Dave Crocker Message-ID: <87100000.1054711117@askvoll.hjemme.alvestrand.no> In-Reply-To: <192191072147.20030603154621@brandenburg.com> References: <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <9690000.1054492013@askvoll.hjemme.alvestrand.no> <192191072147.20030603154621@brandenburg.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) 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: New ways to do things (Re: Doing the Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 tirsdag, juni 03, 2003 15:46:21 -0700 Dave Crocker wrote: > HTA> There are working groups that function in a number of different > modes: ... > HTA> Would we be better off if we developed a few terms different from > "working HTA> group" > > This is one of those things that sounds completely reasonable, except > for lacking the detail needed to be concrete. > > Yes, different projects have different goals. Some are cleanup > exercises. Some are intended to invent whole new systems. Some are > intended to create nicely-modular capabilities. Some involve > well-understood problems and possible solutions. Some involve a great > deal of fuzziness. > > But all of them are established to produce one or more documents, > usually specifying a protocol. > Dave, many of my examples weren't.... As for concrete proposals in order to "try this one on for size", I suggest that we think about creating an object called a "maintenance team": - Responsibility for a specific document or document set (usually one protocol) - A chair - A mailing list, with a public archive - A web page (probably) - Milestones strictly set by the IETF standards process: - 6 months after publication: "Evaluate suitability for grade change" - Every 12 months: "Evaluate whether protocol should be retired" (usually these would be filled by an one-liner note saying "no"). - No termination clause For instance, we could create the "SMTP maintenance team": - Chair: John Klensin :-) - Responsibility: RFC 2821 (SMTP) and RFC 1652 (8BITMIME) - Mailing list: ietf-smtp@imc.org - Web page: "RFC 2821 is ready for Draft if someone has the energy to write the interoperability report. Known claimed-conformant implementations are: ............." "RFC 1652 is at Draft, but refers to MIME, which is still at Draft. Cannot be advanced at this time." "No RFC Editor Errata for either protocol." "The following unclear items are known:......" "The following resources exist:....." The advantage would be that someone who does NOT know who still cares about the development of the SMTP protocol or where to go with questions about it could relatively easily find the (still-active!) mailing list and a contact person for it. (I believe the mailing list has moved around 3 times since it was an active IETF WG mailing list. Only its members know where to find it, I think.) And since it's not chartered to produce anything in order to justify its existence, and indeed can be specifically barred from promoting new specifications, the "noise attraction" effect should be quite a bit smaller than the effect we've seen in WGs that "hang around forever". Once the time came that a new document needs to be written, the maintenance team could either decide that a WG needs to be (re)started, or that the effort is small enough and uncontroversial enough to let it go forward as an individual effort. >From my example list, this might eliminate the need to have LDAPBIS as a working group, and might also give IDR a viable path towards splitting off its pure maintenance activities, so that the "new developments" can be separated from the "maintenance of existing specifications". I'll repost this separately to solutions@alvestrand.no, if people want to comment on the specifics of the idea - its value here is to focus the mind on the idea that not everything needs to be a working group. From problem-statement-bounces@alvestrand.no Wed Jun 4 03:20:13 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06397 for ; Wed, 4 Jun 2003 03:20:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6D964625C2; Wed, 4 Jun 2003 09:19:38 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id C4866625A5; Wed, 4 Jun 2003 09:18:59 +0200 (CEST) Received: from bbprime (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h547LrF06564; Wed, 4 Jun 2003 00:21:53 -0700 Date: Wed, 4 Jun 2003 00:18:54 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <16221825538.20030604001854@brandenburg.com> To: Harald Tveit Alvestrand In-Reply-To: <59030000.1054664178@askvoll.hjemme.alvestrand.no> References: <522974207.1054567784@p3.JCK.COM> <3EDCBE3A.590A924C@hursley.ibm.com> <59030000.1054664178@askvoll.hjemme.alvestrand.no> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: "problem-statement@alvestrand.no" Subject: Re: Trusting the IESG to manage the reform process (was: Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Harald, HTA> 2.5.1 Span of Authority HTA> Overt authority in the IETF is concentrated in the small number of HTA> people sitting on the IESG at that time. Existing IETF processes work HTA> to funnel tasks on to this small number of people (primarily the Area HTA> Directors (ADs) in the IESG). This concentration slows up the HTA> process and puts a very large load of responsibility on to the ... HTA> cannot be solved by making small changes to the IETF and IESG procedures; HTA> we need to change the way we make decisions, which is a BIG change. You have made similar statements a number of times. What do you have in mind? The Kobe change to IETF organization was actually quite small. Strategic. Essential. But small. In fact, for all intents and purposes, it did not change the procedures for working groups at all. It simply moved the final authority over standardization from one existing group to another. (There were some important additional changes, but they were not related to operational decision-making for daily IETF work.) Absent specific proposals, we cannot know whether the cited problem of a bottleneck requires us "to change the way we make decisions" or more simply requires that we do divide-and-conquer with existing tasks and responsibilities. If the latter suffices, then in fact we continue to make decisions in the same way. We simply target different types of decisions to different groups. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Wed Jun 4 04:04:30 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07122 for ; Wed, 4 Jun 2003 04:04:29 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2AB2A625A0; Wed, 4 Jun 2003 10:04:00 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by eikenes.alvestrand.no (Postfix) with ESMTP id BB85862595 for ; Wed, 4 Jun 2003 10:03:49 +0200 (CEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 000506A905; Wed, 4 Jun 2003 11:03:48 +0300 (EEST) Message-ID: <3EDDA77F.8050700@piuha.net> Date: Wed, 04 Jun 2003 11:02:07 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: dcrocker@brandenburg.com Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: Discipline of Internet Protocol Engineering X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jari.arkko@piuha.net 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 Keith Moore wrote: > The reason I say this is that several groups have demonstrated the inability > to define the problem they are working on, Dave Crocker wrote: > Unfortunately, i think this problem is deeper than we might wish to > acknowledge. I tend to be a charter fascist, on the theory that a > crystal clear charter will leave no doubt about the problem being > solved, and/or the benefit to be derived from the result and the > deliverables to be produced. > I view charters as real contracts, making clear what is included and > obligated and what is excluded and prohibited. > However with great regularity, remarkably fuzzy charters are getting > approved. since chartering involves lots of experienced people beyond > the working group, we can't simply assess the problem on the working > group folk. John Loughney wrote: > I would say that there is a breakdown in the chartering process. Hmm... I think that the problem is even deeper than you three wish to acknowledge ;-) I'm sure there are quality differences in charters. And that can be improved upon. However, I believe there's a more fundamental reason why some charters are or may need to be fuzzy. That reason has to do with the timing when the IETF gets involved, or the scope of the problem. Are you doing adding a new algorithm to an existing security protocol? Pretty specific. Are you going to develop a protocol for a specific purpose? Still pretty simple. Are you going to develop a whole set of protocols and extensions to fulfill a function. Starting to get more complex (example: SIP). Are you going to re-architect IPn and develop IPn+2? Pretty tough... And the timing -- have just realized a problem? Or are we at a stage where someone else has realized the problem, and is bringing to the IETF solution proposals, or even proposed protocols that we could standardize? Of course, we could define the IETF as the organization that only takes on very specific work, and only if there's advanced protocol work and deployment experience from vendors with the new work... not sure that would satisfy everyone. --Jari From problem-statement-bounces@alvestrand.no Wed Jun 4 05:16:45 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09089 for ; Wed, 4 Jun 2003 05:16:44 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 05784625A0; Wed, 4 Jun 2003 11:16:15 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 32CCA622A1; Wed, 4 Jun 2003 11:16:13 +0200 (CEST) Date: Wed, 04 Jun 2003 11:16:13 +0200 From: Harald Tveit Alvestrand To: Dave Crocker , Keith Moore Message-ID: <117720000.1054718173@askvoll.hjemme.alvestrand.no> In-Reply-To: <149189936544.20030603152725@brandenburg.com> References: <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <149189936544.20030603152725@brandenburg.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) 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: Discipline of Internet Protocol Engineering X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 tirsdag, juni 03, 2003 15:27:25 -0700 Dave Crocker wrote: > KM> The reason I say this is that several groups have demonstrated the > inability KM> to define the problem they are working on, > > Unfortunately, i think this problem is deeper than we might wish to > acknowledge. I tend to be a charter fascist, on the theory that a > crystal clear charter will leave no doubt about the problem being > solved, and/or the benefit to be derived from the result and the > deliverables to be produced. > > I view charters as real contracts, making clear what is included and > obligated and what is excluded and prohibited. > > However with great regularity, remarkably fuzzy charters are getting > approved. since chartering involves lots of experienced people beyond > the working group, we can't simply assess the problem on the working > group folk. Dave, this is a problem, not only because we have different opinions on what WGs should do, but because we have different opinions on what "fuzzy" means. Take, for instance, the recent LEMONADE charter - which I think is reasonably crisp and states what the WG is intended to do. When it was first floated on the IETF list, it was blasted by at least a couple of people (including you, I think) as being fuzzy, unreadable and an improper tool for evaluating or constraining the work of the group. (Yes, there were improvements. But I think the first version floated wasn't that bad either.... and the intent of the proposers didn't change one whit, as far as I know; it just became expressed more clearly.) Or take the charter of this working group. I simply did not see a way to describe the work to be done by this working group more precisely, without unduly constraining the problem area it was "permitted" to explore - a constraint I felt at the time that it was quite important for the IESG *not* to apply. What's a charter that you view as a "good model"? Harald From problem-statement-bounces@alvestrand.no Wed Jun 4 05:31:56 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09326 for ; Wed, 4 Jun 2003 05:31:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5176E622AC; Wed, 4 Jun 2003 11:31:26 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id E8A76622A1; Wed, 4 Jun 2003 11:31:23 +0200 (CEST) Date: Wed, 04 Jun 2003 11:31:23 +0200 From: Harald Tveit Alvestrand To: john.loughney@nokia.com Message-ID: <120720000.1054719083@askvoll.hjemme.alvestrand.no> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) 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: Discipline of Internet Protocol Engineering X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 onsdag, juni 04, 2003 09:33:24 +0300 john.loughney@nokia.com wrote: > Just a short reply to myself - I forgot to add that one of the > difficulties of creating a charter is that, often, you think you know > what you want to accomplish it, but sometimes it is difficult to seperate > from what from the how and the why. VERY much so. > Thinking about this a bit more, maybe we need to have more formal > guidelines on what a charter should contain. just in case someone hasn't read RFC 2418 yet this week, here's what the current formal guidelines say............ 2.2. Charter The formation of a working group requires a charter which is primarily negotiated between a prospective working group Chair and the relevant Area Director(s), although final approval is made by the IESG with advice from the Internet Architecture Board (IAB). A charter is a contract between a working group and the IETF to perform a set of tasks. A charter: 1. Lists relevant administrative information for the working group; 2. Specifies the direction or objectives of the working group and describes the approach that will be taken to achieve the goals; and 3. Enumerates a set of milestones together with time frames for their completion. When the prospective Chair(s), the Area Director and the IETF Secretariat are satisfied with the charter form and content, it becomes the basis for forming a working group. Note that an Area Director MAY require holding an exploratory Birds of a Feather (BOF) meeting, as described below, to gage the level of support for a working group before submitting the charter to the IESG and IAB for approval. Charters may be renegotiated periodically to reflect the current status, organization or goals of the working group (see section 5). Hence, a charter is a contract between the IETF and the working group which is committing to meet explicit milestones and delivering specific "products". Specifically, each charter consists of the following sections: Working group name A working group name should be reasonably descriptive or identifiable. Additionally, the group shall define an acronym (maximum 8 printable ASCII characters) to reference the group in the IETF directories, mailing lists, and general documents. Chair(s) The working group may have one or more Chairs to perform the administrative functions of the group. The email address(es) of the Chair(s) shall be included. Generally, a working group is limited to two chairs. Area and Area Director(s) The name of the IETF area with which the working group is affiliated and the name and electronic mail address of the associated Area Director(s). Responsible Area Director The Area Director who acts as the primary IESG contact for the working group. Mailing list An IETF working group MUST have a general Internet mailing list. Most of the work of an IETF working group will be conducted on the mailing list. The working group charter MUST include: 1. The address to which a participant sends a subscription request and the procedures to follow when subscribing, 2. The address to which a participant sends submissions and special procedures, if any, and 3. The location of the mailing list archive. A message archive MUST be maintained in a public place which can be accessed via FTP or via the web. As a service to the community, the IETF Secretariat operates a mailing list archive for working group mailing lists. In order to take advantage of this service, working group mailing lists MUST include the address "wg_acronym-archive@lists.ietf.org" (where "wg_acronym" is the working group acronym) in the mailing list in order that a copy of all mailing list messages be recorded in the Secretariat's archive. Those archives are located at ftp://ftp.ietf.org/ietf-mail-archive. For robustness, WGs SHOULD maintain an additional archive separate from that maintained by the Secretariat. Description of working group The focus and intent of the group shall be set forth briefly. By reading this section alone, an individual should be able to decide whether this group is relevant to their own work. The first paragraph must give a brief summary of the problem area, basis, goal(s) and approach(es) planned for the working group. This paragraph can be used as an overview of the working group's effort. To facilitate evaluation of the intended work and to provide on- going guidance to the working group, the charter must describe the problem being solved and should discuss objectives and expected impact with respect to: - Architecture - Operations - Security - Network management - Scaling - Transition (where applicable) Goals and milestones The working group charter MUST establish a timetable for specific work items. While this may be renegotiated over time, the list of milestones and dates facilitates the Area Director's tracking of working group progress and status, and it is indispensable to potential participants identifying the critical moments for input. Milestones shall consist of deliverables that can be qualified as showing specific achievement; e.g., "Internet-Draft finished" is fine, but "discuss via email" is not. It is helpful to specify milestones for every 3-6 months, so that progress can be gauged easily. This milestone list is expected to be updated periodically (see section 5). From problem-statement-bounces@alvestrand.no Wed Jun 4 05:47:04 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09746 for ; Wed, 4 Jun 2003 05:47:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F0D4962595; Wed, 4 Jun 2003 11:46:33 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1EA46622AC; Wed, 4 Jun 2003 11:46:31 +0200 (CEST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])h549kUW28867; Wed, 4 Jun 2003 12:46:30 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com ; Wed, 4 Jun 2003 12:46:30 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 4 Jun 2003 12:46:30 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 4 Jun 2003 12:46:29 +0300 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" Date: Wed, 4 Jun 2003 12:46:28 +0300 Message-ID: Thread-Topic: Discipline of Internet Protocol Engineering Thread-Index: AcMqfBJIfOfN5RM2RnWJkHi0VIPfzwAAbtjw From: To: X-OriginalArrivalTime: 04 Jun 2003 09:46:29.0658 (UTC) FILETIME=[2C746FA0:01C32A7E] Cc: problem-statement@alvestrand.no Subject: RE: Discipline of Internet Protocol Engineering X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA09746 Hi Harald, Thanks for posting 2418 - I have not read it this week. One ommission I see from the text you clipped is that there is no mention of the WG scope. If I understand Keith's complaints, some of them relate to WG scope and that WGs often exceed there scope. Could this be part of the problem, that the definition of a WG Charter (& formal guidelines thereof) are not crisp enough? John > -----Original Message----- > From: ext Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: 04 June, 2003 12:31 > To: Loughney John (NRC/Helsinki) > Cc: problem-statement@alvestrand.no > Subject: RE: Discipline of Internet Protocol Engineering > > > > > --On onsdag, juni 04, 2003 09:33:24 +0300 > john.loughney@nokia.com wrote: > > > Just a short reply to myself - I forgot to add that one of the > > difficulties of creating a charter is that, often, you > think you know > > what you want to accomplish it, but sometimes it is > difficult to seperate > > from what from the how and the why. > > VERY much so. > > > Thinking about this a bit more, maybe we need to have more formal > > guidelines on what a charter should contain. > > just in case someone hasn't read RFC 2418 yet this week, > here's what the > current formal guidelines say............ > > 2.2. Charter > > The formation of a working group requires a charter which is > primarily negotiated between a prospective working group Chair and > the relevant Area Director(s), although final approval is > made by the > IESG with advice from the Internet Architecture Board (IAB). A > charter is a contract between a working group and the IETF > to perform > a set of tasks. A charter: > > 1. Lists relevant administrative information for the working group; > 2. Specifies the direction or objectives of the working group and > describes the approach that will be taken to achieve the goals; > and > 3. Enumerates a set of milestones together with time > frames for their > completion. > > When the prospective Chair(s), the Area Director and the IETF > Secretariat are satisfied with the charter form and content, it > becomes the basis for forming a working group. Note that an Area > Director MAY require holding an exploratory Birds of a > Feather (BOF) > meeting, as described below, to gage the level of support for a > working group before submitting the charter to the IESG and IAB for > approval. > > Charters may be renegotiated periodically to reflect the current > status, organization or goals of the working group (see section 5). > Hence, a charter is a contract between the IETF and the > working group > which is committing to meet explicit milestones and delivering > specific "products". > > Specifically, each charter consists of the following sections: > > Working group name > A working group name should be reasonably descriptive or > identifiable. Additionally, the group shall define an acronym > (maximum 8 printable ASCII characters) to reference the group in > the IETF directories, mailing lists, and general documents. > > > Chair(s) > The working group may have one or more Chairs to perform the > administrative functions of the group. The email address(es) of > the Chair(s) shall be included. Generally, a working group is > limited to two chairs. > > Area and Area Director(s) > The name of the IETF area with which the working group is > affiliated and the name and electronic mail address of the > associated Area Director(s). > > Responsible Area Director > The Area Director who acts as the primary IESG contact for the > working group. > > Mailing list > An IETF working group MUST have a general Internet mailing list. > Most of the work of an IETF working group will be > conducted on the > mailing list. The working group charter MUST include: > > 1. The address to which a participant sends a > subscription request > and the procedures to follow when subscribing, > > 2. The address to which a participant sends submissions and > special procedures, if any, and > > 3. The location of the mailing list archive. A message archive > MUST be maintained in a public place which can be > accessed via > FTP or via the web. > > As a service to the community, the IETF Secretariat > operates a > mailing list archive for working group mailing > lists. In order > to take advantage of this service, working group > mailing lists > MUST include the address "wg_acronym-archive@lists.ietf.org" > (where "wg_acronym" is the working group acronym) in the > mailing list in order that a copy of all mailing > list messages > be recorded in the Secretariat's archive. Those archives are > located at ftp://ftp.ietf.org/ietf-mail-archive. For > robustness, WGs SHOULD maintain an additional > archive separate > from that maintained by the Secretariat. > > Description of working group > The focus and intent of the group shall be set forth briefly. By > reading this section alone, an individual should be > able to decide > whether this group is relevant to their own work. The first > paragraph must give a brief summary of the problem area, basis, > goal(s) and approach(es) planned for the working group. This > paragraph can be used as an overview of the working group's > effort. > > To facilitate evaluation of the intended work and to provide on- > going guidance to the working group, the charter must > describe the > problem being solved and should discuss objectives and expected > impact with respect to: > > - Architecture > - Operations > - Security > - Network management > - Scaling > - Transition (where applicable) > > Goals and milestones > The working group charter MUST establish a timetable > for specific > work items. While this may be renegotiated over time, > the list of > milestones and dates facilitates the Area Director's tracking of > working group progress and status, and it is indispensable to > potential participants identifying the critical moments > for input. > Milestones shall consist of deliverables that can be > qualified as > showing specific achievement; e.g., "Internet-Draft finished" is > fine, but "discuss via email" is not. It is helpful to specify > milestones for every 3-6 months, so that progress can be gauged > easily. This milestone list is expected to be updated > periodically (see section 5). > > From problem-statement-bounces@alvestrand.no Wed Jun 4 08:50:20 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15907 for ; Wed, 4 Jun 2003 08:50:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 99BF06233E; Wed, 4 Jun 2003 14:49:48 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by eikenes.alvestrand.no (Postfix) with ESMTP id 784CB622AC for ; Wed, 4 Jun 2003 14:49:45 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180])h54CnaO0008444 for ; Wed, 4 Jun 2003 14:49:37 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h54CmuKY201710 for ; Wed, 4 Jun 2003 14:48:59 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA53668 from ; Wed, 4 Jun 2003 14:48:54 +0200 Message-Id: <3EDDEAD0.E98C7E44@hursley.ibm.com> Date: Wed, 04 Jun 2003 14:49:20 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "problem-statement@alvestrand.no" References: <522974207.1054567784@p3.JCK.COM> <3EDCBE3A.590A924C@hursley.ibm.com> <16221825538.20030604001854@brandenburg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Dave Crocker wrote: > > Harald, > > HTA> 2.5.1 Span of Authority > HTA> Overt authority in the IETF is concentrated in the small number of > HTA> people sitting on the IESG at that time. Existing IETF processes work > HTA> to funnel tasks on to this small number of people (primarily the Area > HTA> Directors (ADs) in the IESG). This concentration slows up the > HTA> process and puts a very large load of responsibility on to the > ... > HTA> cannot be solved by making small changes to the IETF and IESG procedures; > HTA> we need to change the way we make decisions, which is a BIG change. > > You have made similar statements a number of times. What do you have in > mind? > > The Kobe change to IETF organization was actually quite small. > Strategic. Essential. But small. In fact, for all intents and purposes, > it did not change the procedures for working groups at all. It simply > moved the final authority over standardization from one existing group > to another. I think there was something else. The IETF also put in place mechanisms for renewal and accountability of the decision-taking group. And that, if I'm not mistaken, was to reduce the incidence of hubris. In other words, there was no attempt to solve a scaling problem. What Harald is referring to is a scaling problem, imho. > (There were some important additional changes, but they were > not related to operational decision-making for daily IETF work.) > > Absent specific proposals, we cannot know whether the cited problem of a > bottleneck requires us "to change the way we make decisions" or more > simply requires that we do divide-and-conquer with existing tasks and > responsibilities. > > If the latter suffices, then in fact we continue to make decisions in > the same way. We simply target different types of decisions to > different groups. ...or simply give the existing decision-taking group better input to work with, such as fully reviewed and nit-free documents. Brian From problem-statement-bounces@alvestrand.no Wed Jun 4 08:59:18 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16531 for ; Wed, 4 Jun 2003 08:59:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1142E62595; Wed, 4 Jun 2003 14:58:46 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by eikenes.alvestrand.no (Postfix) with ESMTP id EE2596233E for ; Wed, 4 Jun 2003 14:58:39 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180])h54CwY2h089808 for ; Wed, 4 Jun 2003 14:58:34 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h54CwTKY073914 for ; Wed, 4 Jun 2003 14:58:30 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA16744 from ; Wed, 4 Jun 2003 14:58:28 +0200 Message-Id: <3EDDED0D.ADF91031@hursley.ibm.com> Date: Wed, 04 Jun 2003 14:58:53 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: problem-statement@alvestrand.no References: <39192643596.20030603161232@brandenburg.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <20030603212052.740e009a.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Keith Moore wrote: > > O> My understanding is that the higher bar to PS arose as a consequence of > > things being widely deployed at PS and things not advancing to Draft rather > > than the deployment and non-advancement being a consequence of the high bar. > > that's my understanding also. > > > This is important in the sense that if the lack of advancement came first, > > then simply lowering the bar will not help us get better standards, and in > > fact could result in our ending up with lower quality documents permanently. > > I'm in strong agreement with this. What we need to do is find a way for > standards to at least the level that is currently required for PS more > quickly, not to lower the bar for PS. Fully agree. > We might even need to raise the bar slightly. Do you mean that we are frequently releasing PS documents that contain significant defects? We certainly can't expect PS documents to be perfect. Another problem I see is that the barrier to Standard is so high that nobody is interested, and the barrier to DS is high enough that very few people are interested. That being so, apart from some academic ideals, I question the value of having 3 grades at all. Since we hardly use the top two grades, why have them? Brian From problem-statement-bounces@alvestrand.no Wed Jun 4 09:08:40 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17475 for ; Wed, 4 Jun 2003 09:08:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8509C625A0; Wed, 4 Jun 2003 15:08:05 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6BC8E6233E for ; Wed, 4 Jun 2003 15:08:02 +0200 (CEST) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196])h54D80P6048970 for ; Wed, 4 Jun 2003 15:08:00 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h54D80r6242090 for ; Wed, 4 Jun 2003 15:08:01 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA52746 from ; Wed, 4 Jun 2003 15:07:59 +0200 Message-Id: <3EDDEF48.7ED1CC09@hursley.ibm.com> Date: Wed, 04 Jun 2003 15:08:24 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: problem-statement@alvestrand.no References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Discipline of Internet Protocol Engineering X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Indeed, scope and non-goals need to be in there too. The most useful section of diffserv's charter, from the viewpoint of discussion management, was the part starting: "The group will not work on: " I've always regarded the vetting of WG charters as the most important single thing that the IAB and IESG do. A good charter is the most effective tool an AD or WG Chair can have to maintain forward progress. So, "sloppy charters" needs to be on the problem list. Brian john.loughney@nokia.com wrote: > > Hi Harald, > > Thanks for posting 2418 - I have not read it this week. One ommission > I see from the text you clipped is that there is no mention of > the WG scope. If I understand Keith's complaints, some of them > relate to WG scope and that WGs often exceed there scope. Could > this be part of the problem, that the definition of a WG Charter > (& formal guidelines thereof) are not crisp enough? > > John > > > -----Original Message----- > > From: ext Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > > Sent: 04 June, 2003 12:31 > > To: Loughney John (NRC/Helsinki) > > Cc: problem-statement@alvestrand.no > > Subject: RE: Discipline of Internet Protocol Engineering > > > > > > > > > > --On onsdag, juni 04, 2003 09:33:24 +0300 > > john.loughney@nokia.com wrote: > > > > > Just a short reply to myself - I forgot to add that one of the > > > difficulties of creating a charter is that, often, you > > think you know > > > what you want to accomplish it, but sometimes it is > > difficult to seperate > > > from what from the how and the why. > > > > VERY much so. > > > > > Thinking about this a bit more, maybe we need to have more formal > > > guidelines on what a charter should contain. > > > > just in case someone hasn't read RFC 2418 yet this week, > > here's what the > > current formal guidelines say............ > > > > 2.2. Charter > > > > The formation of a working group requires a charter which is > > primarily negotiated between a prospective working group Chair and > > the relevant Area Director(s), although final approval is > > made by the > > IESG with advice from the Internet Architecture Board (IAB). A > > charter is a contract between a working group and the IETF > > to perform > > a set of tasks. A charter: > > > > 1. Lists relevant administrative information for the working group; > > 2. Specifies the direction or objectives of the working group and > > describes the approach that will be taken to achieve the goals; > > and > > 3. Enumerates a set of milestones together with time > > frames for their > > completion. > > > > When the prospective Chair(s), the Area Director and the IETF > > Secretariat are satisfied with the charter form and content, it > > becomes the basis for forming a working group. Note that an Area > > Director MAY require holding an exploratory Birds of a > > Feather (BOF) > > meeting, as described below, to gage the level of support for a > > working group before submitting the charter to the IESG and IAB for > > approval. > > > > Charters may be renegotiated periodically to reflect the current > > status, organization or goals of the working group (see section 5). > > Hence, a charter is a contract between the IETF and the > > working group > > which is committing to meet explicit milestones and delivering > > specific "products". > > > > Specifically, each charter consists of the following sections: > > > > Working group name > > A working group name should be reasonably descriptive or > > identifiable. Additionally, the group shall define an acronym > > (maximum 8 printable ASCII characters) to reference the group in > > the IETF directories, mailing lists, and general documents. > > > > > > Chair(s) > > The working group may have one or more Chairs to perform the > > administrative functions of the group. The email address(es) of > > the Chair(s) shall be included. Generally, a working group is > > limited to two chairs. > > > > Area and Area Director(s) > > The name of the IETF area with which the working group is > > affiliated and the name and electronic mail address of the > > associated Area Director(s). > > > > Responsible Area Director > > The Area Director who acts as the primary IESG contact for the > > working group. > > > > Mailing list > > An IETF working group MUST have a general Internet mailing list. > > Most of the work of an IETF working group will be > > conducted on the > > mailing list. The working group charter MUST include: > > > > 1. The address to which a participant sends a > > subscription request > > and the procedures to follow when subscribing, > > > > 2. The address to which a participant sends submissions and > > special procedures, if any, and > > > > 3. The location of the mailing list archive. A message archive > > MUST be maintained in a public place which can be > > accessed via > > FTP or via the web. > > > > As a service to the community, the IETF Secretariat > > operates a > > mailing list archive for working group mailing > > lists. In order > > to take advantage of this service, working group > > mailing lists > > MUST include the address "wg_acronym-archive@lists.ietf.org" > > (where "wg_acronym" is the working group acronym) in the > > mailing list in order that a copy of all mailing > > list messages > > be recorded in the Secretariat's archive. Those archives are > > located at ftp://ftp.ietf.org/ietf-mail-archive. For > > robustness, WGs SHOULD maintain an additional > > archive separate > > from that maintained by the Secretariat. > > > > Description of working group > > The focus and intent of the group shall be set forth briefly. By > > reading this section alone, an individual should be > > able to decide > > whether this group is relevant to their own work. The first > > paragraph must give a brief summary of the problem area, basis, > > goal(s) and approach(es) planned for the working group. This > > paragraph can be used as an overview of the working group's > > effort. > > > > To facilitate evaluation of the intended work and to provide on- > > going guidance to the working group, the charter must > > describe the > > problem being solved and should discuss objectives and expected > > impact with respect to: > > > > - Architecture > > - Operations > > - Security > > - Network management > > - Scaling > > - Transition (where applicable) > > > > Goals and milestones > > The working group charter MUST establish a timetable > > for specific > > work items. While this may be renegotiated over time, > > the list of > > milestones and dates facilitates the Area Director's tracking of > > working group progress and status, and it is indispensable to > > potential participants identifying the critical moments > > for input. > > Milestones shall consist of deliverables that can be > > qualified as > > showing specific achievement; e.g., "Internet-Draft finished" is > > fine, but "discuss via email" is not. It is helpful to specify > > milestones for every 3-6 months, so that progress can be gauged > > easily. This milestone list is expected to be updated > > periodically (see section 5). > > > > From problem-statement-bounces@alvestrand.no Wed Jun 4 09:23:32 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18230 for ; Wed, 4 Jun 2003 09:23:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AAA68625A0; Wed, 4 Jun 2003 15:23:01 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id A427B6233E for ; Wed, 4 Jun 2003 15:22:55 +0200 (CEST) Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h54DMq51022596 for ; Wed, 4 Jun 2003 09:22:52 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-51.cisco.com [10.21.96.51]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id JAA25798 for ; Wed, 4 Jun 2003 09:22:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20030604090936.03be0790@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Jun 2003 09:22:45 -0400 To: problem-statement@alvestrand.no From: Ralph Droms In-Reply-To: <3EDDED0D.ADF91031@hursley.ibm.com> References: <39192643596.20030603161232@brandenburg.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <20030603212052.740e009a.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 My experience with DS and full Standard is that no one is interested because of the lack of perceived difference between the requirements between the standards levels and the lack of perceived added value in progressing a spec to DS or full standard. That is, I disagree with Brian's statement about the requirements for DS and full standard being too high - I think the problem is a lack of differentiation among the three standards levels. Here's how I see the standards track: The required correctness for PS is high enough that a PS spec is "good enough" for vendor implementation and deployment. The reward for moving to DS and full standard is not worth the investment of effort. The tension I see is the need for a specification that is sufficiently baked and stable to be used for prototyping, interoperability testing and proof-of-correctness for the spec doc, but that does *not* result in deployment. It's the premature deployment that (a) casts goofs in the spec in stone and (b) eliminates any motivation to move the specification through the standards track. - Ralph At 02:58 PM 6/4/2003 +0200, Brian E Carpenter wrote: >Keith Moore wrote: >> >> O> My understanding is that the higher bar to PS arose as a consequence of >> > things being widely deployed at PS and things not advancing to Draft rather >> > than the deployment and non-advancement being a consequence of the high bar. >> >> that's my understanding also. >> >> > This is important in the sense that if the lack of advancement came first, >> > then simply lowering the bar will not help us get better standards, and in >> > fact could result in our ending up with lower quality documents permanently. >> >> I'm in strong agreement with this. What we need to do is find a way for >> standards to at least the level that is currently required for PS more >> quickly, not to lower the bar for PS. > >Fully agree. > >> We might even need to raise the bar slightly. > >Do you mean that we are frequently releasing PS documents that contain >significant defects? We certainly can't expect PS documents to be perfect. > >Another problem I see is that the barrier to Standard is so high that >nobody is interested, and the barrier to DS is high enough that very >few people are interested. That being so, apart from some academic >ideals, I question the value of having 3 grades at all. Since we hardly >use the top two grades, why have them? > > Brian From problem-statement-bounces@alvestrand.no Wed Jun 4 09:24:23 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18252 for ; Wed, 4 Jun 2003 09:24:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 43194625A0; Wed, 4 Jun 2003 15:23:54 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by eikenes.alvestrand.no (Postfix) with ESMTP id B2CFB6233E for ; Wed, 4 Jun 2003 15:23:51 +0200 (CEST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])ESMTP id h54DNkB19119 for ; Wed, 4 Jun 2003 09:23:46 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R103N3M>; Wed, 4 Jun 2003 15:23:45 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501BC24F7@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Brian E Carpenter , problem-statement@alvestrand.no Date: Wed, 4 Jun 2003 15:23:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Trusting the IESG to manage the reform process (was:Re:Doingt he Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > > > > Absent specific proposals, we cannot know whether the cited problem of a > > bottleneck requires us "to change the way we make decisions" or more > > simply requires that we do divide-and-conquer with existing tasks and > > responsibilities. > > > > If the latter suffices, then in fact we continue to make decisions in > > the same way. We simply target different types of decisions to > > different groups. > > ...or simply give the existing decision-taking group better input to > work with, such as fully reviewed and nit-free documents. > Amen! Bert > Brian > From problem-statement-bounces@alvestrand.no Wed Jun 4 10:10:45 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21302 for ; Wed, 4 Jun 2003 10:10:44 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 212D8625A0; Wed, 4 Jun 2003 16:10:09 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1F9E76233E for ; Wed, 4 Jun 2003 16:09:58 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.22]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA29427; Wed, 4 Jun 2003 07:09:30 -0700 (PDT) Message-Id: <5.1.0.14.2.20030604095705.043c2c60@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 04 Jun 2003 10:05:36 -0400 To: Brian E Carpenter From: Margaret Wasserman In-Reply-To: <3EDDEAD0.E98C7E44@hursley.ibm.com> References: <522974207.1054567784@p3.JCK.COM> <3EDCBE3A.590A924C@hursley.ibm.com> <16221825538.20030604001854@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "problem-statement@alvestrand.no" Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Brian, At 02:49 PM 6/4/2003 +0200, Brian E Carpenter wrote: >I think there was something else. The IETF also put in place mechanisms >for renewal and accountability of the decision-taking group. And that, >if I'm not mistaken, was to reduce the incidence of hubris. > >In other words, there was no attempt to solve a scaling problem. > >What Harald is referring to is a scaling problem, imho. Right. With the growth of the IETF, the increase in complexity and scope of our work, etc. the job of an AD has become so large, time-consuming and complex that there are very few people who can do it. And, there are even fewer people who are willing to do it... We need to figure out some way to solve this problem, and that almost certainly involve some reorganization and re-definition of roles at the top of the IETF. This could be driven by the IESG -- they could create new roles under themselves and delegate work. Or, it could be driven by the community. I actually would have preferred the former, but the IESG seems to have chosen the latter... > > If the latter suffices, then in fact we continue to make decisions in > > the same way. We simply target different types of decisions to > > different groups. > >...or simply give the existing decision-taking group better input to >work with, such as fully reviewed and nit-free documents. I think that we're all in agreement that the quality, timeliness and predictability of WG output is unacceptably low. It might be amusing to watch WG chairs come up with ways to blame the IESG for this -- they didn't charter us properly, they didn't manage us properly, they didn't give us early feedback, etc... But, that's all just whining. It is the responsibility of the WG chair to manage the WG to produce high quality and timely work, to get adequate review for our documents, and to manage our milestones. And, most of us are falling down on the job. As I'm sure you know, high quality, nit-free documents don't happen by accident... And, it doesn't matter how many times we ask for them, or whine about the fact that our editors don't produce them. We need to actually put some quality processes in place during WG creation of these documents to improve the quality of WG output. IMO, though, this won't solve the scaling problems that have lead to the ADs job being so large/complex that there is a limited pool of people that can/will do it... That needs to be solved separately. Margaret From problem-statement-bounces@alvestrand.no Wed Jun 4 10:21:00 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22162 for ; Wed, 4 Jun 2003 10:20:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 09575625A0; Wed, 4 Jun 2003 16:20:30 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id BEB786233E for ; Wed, 4 Jun 2003 16:20:20 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19NZ7j-000DVu-00; Wed, 04 Jun 2003 14:20:19 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.14) id 19NZ7i-000KXn-CB; Wed, 04 Jun 2003 07:20:18 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 4 Jun 2003 07:20:02 -0700 To: Margaret Wasserman References: <522974207.1054567784@p3.JCK.COM> <3EDCBE3A.590A924C@hursley.ibm.com> <16221825538.20030604001854@brandenburg.com> <5.1.0.14.2.20030604095705.043c2c60@mail.windriver.com> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 driven by the IESG -- they could create new roles > under themselves and delegate work. Or, it could be driven by > the community. I actually would have preferred the former, but > the IESG seems to have chosen the latter... not completely true. increasingly, directorates and less formal constructs are being used as document and srchitecture review teams. this is a massive help, at least for me. randy From problem-statement-bounces@alvestrand.no Wed Jun 4 10:27:46 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22469 for ; Wed, 4 Jun 2003 10:27:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B620C625A0; Wed, 4 Jun 2003 16:27:16 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2C6D66233E for ; Wed, 4 Jun 2003 16:27:15 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19NZED-0002mZ-00; Wed, 04 Jun 2003 07:27:01 -0700 Date: Wed, 4 Jun 2003 10:25:00 -0400 From: Keith Moore To: jari.arkko@piuha.net Message-Id: <20030604102500.27eaf7e5.moore@cs.utk.edu> In-Reply-To: <3EDDA77F.8050700@piuha.net> References: <3EDDA77F.8050700@piuha.net> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: john.loughney@nokia.com Cc: dcrocker@brandenburg.com Cc: moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: Re: Discipline of Internet Protocol Engineering X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > However, I believe > there's a more fundamental reason why some charters are or may > need to be fuzzy. That reason has to do with the timing when > the IETF gets involved, or the scope of the problem. Part of the problem may be that we often want the initial charter to map out the entire life cycle of the group. often this is unrealistic, because we really don't understand what the group has to do. I don't think we should try to nail down details more than about eight months (say two IETF meetings) in advance. But if we don't have a good idea about what a WG is going to be doing over the next few months, with fairly concrete, realizable, measurable goals - something's wrong. From problem-statement-bounces@alvestrand.no Wed Jun 4 10:41:00 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23882 for ; Wed, 4 Jun 2003 10:40:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0EACA625A0; Wed, 4 Jun 2003 16:40:30 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by eikenes.alvestrand.no (Postfix) with ESMTP id 756146233E for ; Wed, 4 Jun 2003 16:40:27 +0200 (CEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A815B6A905; Wed, 4 Jun 2003 17:40:26 +0300 (EEST) Message-ID: <3EDE0474.50002@piuha.net> Date: Wed, 04 Jun 2003 17:38:44 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore References: <3EDDA77F.8050700@piuha.net> <20030604102500.27eaf7e5.moore@cs.utk.edu> In-Reply-To: <20030604102500.27eaf7e5.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Discipline of Internet Protocol Engineering X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jari.arkko@piuha.net 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 Keith Moore wrote: >>However, I believe >>there's a more fundamental reason why some charters are or may >>need to be fuzzy. That reason has to do with the timing when >>the IETF gets involved, or the scope of the problem. > > > Part of the problem may be that we often want the initial charter to map > out the entire life cycle of the group. often this is unrealistic, because > we really don't understand what the group has to do. I don't think we > should try to nail down details more than about eight months (say two > IETF meetings) in advance. But if we don't have a good idea about what > a WG is going to be doing over the next few months, with fairly concrete, > realizable, measurable goals - something's wrong. Agreed. We could in addition require that groups produce something concrete (like an approved document) in that 8 months. If we take in account that the full protocol (or whatever) can't be done in this time, this shows a need to produce intermediate deliveries. Often these are requirements documents, though I'm not quite sure useful they are. It might be more useful to produce roadmap or architecture documents. --Jari From problem-statement-bounces@alvestrand.no Wed Jun 4 10:44:38 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24254 for ; Wed, 4 Jun 2003 10:44:37 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9DDAB625A0; Wed, 4 Jun 2003 16:44:07 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 783086233E; Wed, 4 Jun 2003 16:44:04 +0200 (CEST) Date: Wed, 04 Jun 2003 16:44:04 +0200 From: Harald Tveit Alvestrand To: Keith Moore Message-ID: <210400000.1054737844@askvoll.hjemme.alvestrand.no> In-Reply-To: <20030604102500.27eaf7e5.moore@cs.utk.edu> References: <3EDDA77F.8050700@piuha.net> <20030604102500.27eaf7e5.moore@cs.utk.edu> X-Mailer: Mulberry/2.2.1 (Linux/x86) 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: Discipline of Internet Protocol Engineering X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 onsdag, juni 04, 2003 10:25:00 -0400 Keith Moore wrote: >> However, I believe >> there's a more fundamental reason why some charters are or may >> need to be fuzzy. That reason has to do with the timing when >> the IETF gets involved, or the scope of the problem. > > Part of the problem may be that we often want the initial charter to map > out the entire life cycle of the group. often this is unrealistic, > because we really don't understand what the group has to do. I don't > think we should try to nail down details more than about eight months > (say two IETF meetings) in advance. But if we don't have a good idea > about what a WG is going to be doing over the next few months, with > fairly concrete, realizable, measurable goals - something's wrong. > Might part of the problem be that we're lousy at making plans, *apart* from the charter? I don't think I've ever seen a working group chair come up with a document/message/webpage that said something like "OK, in order to achieve this milestone in December, here's what we're planning to do in June, July, August, September and November.... we didn't do what we were supposed to do in May, so that means September's going to have a time crunch....." again, this is something we have no rule against, it's normal practice in other branches of engineering, but we just don't seem to be doing it.... From problem-statement-bounces@alvestrand.no Wed Jun 4 10:47:49 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24391 for ; Wed, 4 Jun 2003 10:47:48 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 62527625A0; Wed, 4 Jun 2003 16:47:17 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5CF5B6233E; Wed, 4 Jun 2003 16:47:08 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19NZXe-0005cP-00; Wed, 04 Jun 2003 07:47:07 -0700 Date: Wed, 4 Jun 2003 10:45:08 -0400 From: Keith Moore To: Harald Tveit Alvestrand Message-Id: <20030604104508.073ef1da.moore@cs.utk.edu> In-Reply-To: <210400000.1054737844@askvoll.hjemme.alvestrand.no> References: <3EDDA77F.8050700@piuha.net> <20030604102500.27eaf7e5.moore@cs.utk.edu> <210400000.1054737844@askvoll.hjemme.alvestrand.no> X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Subject: Re: Discipline of Internet Protocol Engineering X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > Might part of the problem be that we're lousy at making plans, *apart* from > the charter? yup. or that we think that the charter is all the planning we need. From problem-statement-bounces@alvestrand.no Wed Jun 4 10:53:08 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24879 for ; Wed, 4 Jun 2003 10:53:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7C6AC625A3; Wed, 4 Jun 2003 16:52:38 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from turkey.mail.pas.earthlink.net (turkey.mail.pas.earthlink.net [207.217.120.126]) by eikenes.alvestrand.no (Postfix) with ESMTP id EC9566233E; Wed, 4 Jun 2003 16:52:36 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19NZcp-0003gU-00; Wed, 04 Jun 2003 07:52:27 -0700 Date: Wed, 4 Jun 2003 10:50:28 -0400 From: Keith Moore To: Dave Crocker Message-Id: <20030604105028.7448fb1d.moore@cs.utk.edu> In-Reply-To: <16221825538.20030604001854@brandenburg.com> References: <522974207.1054567784@p3.JCK.COM> <3EDCBE3A.590A924C@hursley.ibm.com> <59030000.1054664178@askvoll.hjemme.alvestrand.no> <16221825538.20030604001854@brandenburg.com> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: harald@alvestrand.no Cc: dhc@dcrocker.net Cc: moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: Re: Trusting the IESG to manage the reform process (was: Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > The Kobe change to IETF organization was actually quite small. > Strategic. Essential. and it's caused a lot of harm. From problem-statement-bounces@alvestrand.no Wed Jun 4 10:58:42 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25098 for ; Wed, 4 Jun 2003 10:58:41 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4230D625A0; Wed, 4 Jun 2003 16:58:12 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from athene.wz-berlin.de (athene.wz-berlin.de [193.174.6.3]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6ADD8625A0; Wed, 4 Jun 2003 16:58:04 +0200 (CEST) Received: from medea.wz-berlin.de ([193.174.6.5]) by athene.wz-berlin.de with esmtp (Exim 4.20) id 19NZiF-00059e-2F; Wed, 04 Jun 2003 16:58:03 +0200 Received: from ERDE/SpoolDir by medea.wz-berlin.de (Mercury 1.48); 4 Jun 03 16:58:02 +0200 Received: from SpoolDir by ERDE (Mercury 1.48); 4 Jun 03 16:57:39 +0200 From: "Jeanette Hofmann" Organization: Wissenschaftszentrum Berlin To: Harald Tveit Alvestrand Date: Wed, 04 Jun 2003 16:57:39 +0200 MIME-Version: 1.0 Message-ID: <3EDE2504.7007.FBC394@localhost> Priority: normal In-reply-to: <210400000.1054737844@askvoll.hjemme.alvestrand.no> References: <20030604102500.27eaf7e5.moore@cs.utk.edu> X-mailer: Pegasus Mail for Windows (v4.11) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at wz-berlin.de Cc: problem-statement@alvestrand.no Subject: Re: Discipline of Internet Protocol Engineering X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7BIT On 4 Jun 2003 at 16:44, Harald Tveit Alvestrand wrote: > > > --On onsdag, juni 04, 2003 10:25:00 -0400 Keith Moore > wrote: > > >> However, I believe > >> there's a more fundamental reason why some charters are or may > >> need to be fuzzy. That reason has to do with the timing when > >> the IETF gets involved, or the scope of the problem. > > > > Part of the problem may be that we often want the initial charter to map > > out the entire life cycle of the group. often this is unrealistic, > > because we really don't understand what the group has to do. I don't > > think we should try to nail down details more than about eight months > > (say two IETF meetings) in advance. But if we don't have a good idea > > about what a WG is going to be doing over the next few months, with > > fairly concrete, realizable, measurable goals - something's wrong. > > > > Might part of the problem be that we're lousy at making plans, *apart* from > the charter? I think we are dealing with two more or less unrelated issues here. One has to do with the observation of Dorothy L. Sayers that "facts are like cows. If you look them in the face hard enough they generally run away." Some flexibility regarding both tasks and time is necessary to be prepared for unexpected running cows or facts. The other issue is general time management. The working groups seem not apply what most of their members would do under similar circumstances in their day job. jeanette > > I don't think I've ever seen a working group chair come up with a > document/message/webpage that said something like "OK, in order to achieve > this milestone in December, here's what we're planning to do in June, July, > August, September and November.... we didn't do what we were supposed to do > in May, so that means September's going to have a time crunch....." > > again, this is something we have no rule against, it's normal practice in > other branches of engineering, but we just don't seem to be doing it.... From problem-statement-bounces@alvestrand.no Wed Jun 4 11:03:44 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25309 for ; Wed, 4 Jun 2003 11:03:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A205625A0; Wed, 4 Jun 2003 17:03:14 +0200 (CEST) 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 0CB586233E for ; Wed, 4 Jun 2003 17:03:07 +0200 (CEST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])h54F36D01563 for ; Wed, 4 Jun 2003 18:03:06 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com ; Wed, 4 Jun 2003 18:03:06 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 4 Jun 2003 18:03:06 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 4 Jun 2003 18:03:05 +0300 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" Date: Wed, 4 Jun 2003 18:03:05 +0300 Message-ID: Thread-Topic: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) Thread-Index: AcMqowYwK8YDYoFyR3uhkzNE9wIUuAABw8fA From: To: X-OriginalArrivalTime: 04 Jun 2003 15:03:05.0875 (UTC) FILETIME=[67151E30:01C32AAA] Cc: problem-statement@alvestrand.no Subject: RE: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA25309 Hi all, Just out of curiosity: > Right. With the growth of the IETF, the increase in complexity > and scope of our work, etc. the job of an AD has become so > large, time-consuming and complex that there are very few people > who can do it. And, there are even fewer people who are willing > to do it... Do we have stats to back that up? I have no idea if this is true or not. I guess an examination of the number of people who have accepted an IESG nomination would be a starting point ... John From problem-statement-bounces@alvestrand.no Wed Jun 4 11:38:14 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27322 for ; Wed, 4 Jun 2003 11:38:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9FF8A625A0; Wed, 4 Jun 2003 17:37:44 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from joy.songbird.com (songbird.com [208.184.79.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id EEBBC6233E; Wed, 4 Jun 2003 17:37:36 +0200 (CEST) Received: from bbprime (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h54FeUF31803; Wed, 4 Jun 2003 08:40:30 -0700 Date: Wed, 4 Jun 2003 08:36:15 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <141251662691.20030604083615@brandenburg.com> To: Keith Moore In-Reply-To: <20030604105028.7448fb1d.moore@cs.utk.edu> References: <522974207.1054567784@p3.JCK.COM> <3EDCBE3A.590A924C@hursley.ibm.com> <59030000.1054664178@askvoll.hjemme.alvestrand.no> <16221825538.20030604001854@brandenburg.com> <20030604105028.7448fb1d.moore@cs.utk.edu> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: harald@alvestrand.no Cc: dhc@dcrocker.net Cc: problem-statement@alvestrand.no Subject: Re: Trusting the IESG to manage the reform process (was: Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Keith, >> The Kobe change to IETF organization was actually quite small. >> Strategic. Essential. KM> and it's caused a lot of harm. the problem with criticizing that original design is the tendency to miss the context of the situation and the range of choices that were available. As is true with so many things that are problematic in the very long term, it is often not the original decision that is the problem, but the failure to evaluate and modify it over time. BEC> I think there was something else. The IETF also put in place mechanisms BEC> for renewal and accountability of the decision-taking group. And that, BEC> if I'm not mistaken, was to reduce the incidence of hubris. The original draft of my posting had text to distinguish the standardization-authority change from the AD selection change. The latter has nothing to do with "the style in which we make decisions", which was the focus of Harald's comment that I was responding to. BEC> In other words, there was no attempt to solve a scaling problem. yup. i entirely agree. however, that does not mean the original decision was bad, but that we have not been improving our system design over time. but scaling is not the *only* problem that is of concern to our community. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Wed Jun 4 12:07:28 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29130 for ; Wed, 4 Jun 2003 12:07:27 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 10641625A0; Wed, 4 Jun 2003 18:06:59 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by eikenes.alvestrand.no (Postfix) with ESMTP id 500336233E for ; Wed, 4 Jun 2003 18:06:51 +0200 (CEST) Received: by romeo.rtfm.com (Postfix, from userid 556) id F275AABA9; Wed, 4 Jun 2003 09:12:41 -0700 (PDT) To: "Wijnen, Bert (Bert)" References: <7D5D48D2CAA3D84C813F5B154F43B15501BC24F7@nl0006exch001u.nl.lucent.com> From: Eric Rescorla Date: 04 Jun 2003 09:12:41 -0700 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501BC24F7@nl0006exch001u.nl.lucent.com> Message-ID: Lines: 27 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: problem-statement@alvestrand.no Cc: Brian E Carpenter Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingt he Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: EKR 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 "Wijnen, Bert (Bert)" writes: > > > > > > Absent specific proposals, we cannot know whether the cited problem of a > > > bottleneck requires us "to change the way we make decisions" or more > > > simply requires that we do divide-and-conquer with existing tasks and > > > responsibilities. > > > > > > If the latter suffices, then in fact we continue to make decisions in > > > the same way. We simply target different types of decisions to > > > different groups. > > > > ...or simply give the existing decision-taking group better input to > > work with, such as fully reviewed and nit-free documents. > > > Amen! I'm afraid we're now back to the issue I mentioned before SF. Do WGs get rewarded for producing such documents and punished for not producing them. I'm not sure that's true. To the extent it's not, it's hardly surprising that they don't. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From problem-statement-bounces@alvestrand.no Wed Jun 4 14:34:43 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05316 for ; Wed, 4 Jun 2003 14:34:42 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 534AC625A4; Wed, 4 Jun 2003 20:34:12 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 541106233E; Wed, 4 Jun 2003 20:34:10 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h54IY2k00910; Wed, 4 Jun 2003 14:34:03 -0400 (EDT) Date: Wed, 4 Jun 2003 14:34:01 -0400 From: Keith Moore To: Dave Crocker Message-Id: <20030604143401.1b57f142.moore@cs.utk.edu> In-Reply-To: <141251662691.20030604083615@brandenburg.com> References: <522974207.1054567784@p3.JCK.COM> <3EDCBE3A.590A924C@hursley.ibm.com> <59030000.1054664178@askvoll.hjemme.alvestrand.no> <16221825538.20030604001854@brandenburg.com> <20030604105028.7448fb1d.moore@cs.utk.edu> <141251662691.20030604083615@brandenburg.com> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: harald@alvestrand.no Cc: dhc@dcrocker.net Cc: moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: Re: Trusting the IESG to manage the reform process (was: Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > the problem with criticizing that original design is the tendency to > miss the context of the situation and the range of choices that were > available. > > As is true with so many things that are problematic in the very long > term, it is often not the original decision that is the problem, but > the failure to evaluate and modify it over time. I view these as separate mistakes. Failing to provide architectural oversight was a lousy idea. > BEC> In other words, there was no attempt to solve a scaling problem. > > yup. i entirely agree. > > however, that does not mean the original decision was bad nor does it mean it was good. I see it as example of trying to solve one problem in a way that inadvertently made other problems worse. From problem-statement-bounces@alvestrand.no Wed Jun 4 14:45:32 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05878 for ; Wed, 4 Jun 2003 14:45:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9893C625A3; Wed, 4 Jun 2003 20:45:01 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 36CDC625A3 for ; Wed, 4 Jun 2003 20:44:58 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h54Iiok00926; Wed, 4 Jun 2003 14:44:52 -0400 (EDT) Date: Wed, 4 Jun 2003 14:44:50 -0400 From: Keith Moore To: Brian E Carpenter Message-Id: <20030604144450.595e543c.moore@cs.utk.edu> In-Reply-To: <3EDDED0D.ADF91031@hursley.ibm.com> References: <39192643596.20030603161232@brandenburg.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <20030603212052.740e009a.moore@cs.utk.edu> <3EDDED0D.ADF91031@hursley.ibm.com> X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Subject: Re: Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > > What we need to do is find a way for > > standards to at least the level that is currently required for PS > > more quickly, not to lower the bar for PS. > > Fully agree. > > > We might even need to raise the bar slightly. > > Do you mean that we are frequently releasing PS documents that contain > significant defects? We certainly can't expect PS documents to be > perfect. of course not. what I mean is that if we realize that PS in effect is taken as "ready for deployment" (which seems to be how the industry interprets it), then maybe we really do need to expect some level of implementation and interop testing before we approve something as PS. in general I think earlier implementation would be a good thing - it would help groups be more honest about the difficulty of implementing some of these things. From problem-statement-bounces@alvestrand.no Wed Jun 4 15:45:44 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10063 for ; Wed, 4 Jun 2003 15:45:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 79187625B5; Wed, 4 Jun 2003 21:45:13 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 47033625A3 for ; Wed, 4 Jun 2003 21:45:10 +0200 (CEST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h54Jj9S22735 for ; Wed, 4 Jun 2003 12:45:09 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 4 Jun 2003 12:45:08 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: problem-statement@alvestrand.no In-Reply-To: <20030604144450.595e543c.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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, 4 Jun 2003, Bob Hinden wrote: BH As you correctly point out the IETF (and as implemented by the BH IESG) is not using the standards process we have defined. It BH has been changed where the initial barrier has been raised very BH high at Proposed Standard and hardy anything gets to Draft BH standard, let alone (Full) Standard. Agreed that this is a problem. There seem to be several related reasons for this. >>>>> On Wed, 4 Jun 2003, Brian E Carpenter wrote: BC Keith Moore wrote: BC >[Joel M. Halpern wrote:] BC > > My understanding is that the higher bar to PS arose as a BC > > consequence of things being widely deployed at PS and things BC > > not advancing to Draft rather than the deployment and BC > > non-advancement being a consequence of the high bar. BC > BC > that's my understanding also. In other words the high bar imposed on PS is due to the fact that vendors, operators, and IETF folk fail to treat PS as the standards process intended. There are probably many reasons for that. Here are a couple that I can think of: - Most SDOs don't seem to have anything resembling the three-tier process. Typically an approved standard is considered ready for deployment. It seems that PS has been treated on a par with other SDO's approved standards. Yes, there are well-known problems with deploying standards not backed by implementation experience, but that seems to be what's happening. - In some cases the three-tier process is simply ill-suited to the task. MIB documents are one particularly problematic case, especially those whose purpose is to manage technology developed by other SDOs. The Ethernet MIB modules (currently RFCs 2665 and 2668) have been recycling at PS for quite a while now, because of new objects being added to manage new types of Ethernet media. The one document that did reach full standard (RFC 1643) is obsolete and the WG has asked the IESG to formally retire it by moving it to Historic. (Part of the problem here is that it's not always possible or reasonable to split new MIB features off into separate documents that can be advanced separately. But let's not get sidetracked on the details.) There is probably little that the IETF can do to prevent vendors from deploying stuff that is at PS, short of calling it something other than a standard. The IEEE has something called a trial-use document (http://standards.ieee.org/guides/opman/index.html) that seems to roughly correspond to the IETF's notion of a PS. I don't know how successful that idea has been or how often it is applied, but it does have a maximum lifetime of two years after which it must either be affirmed as a full standard, revised, or withdrawn. BC> > > This is important in the sense that if the lack of BC> > > advancement came first, then simply lowering the bar will BC> > > not help us get better standards, and in fact could result BC> > > in our ending up with lower quality documents permanently. BC> > BC> > I'm in strong agreement with this. What we need to do is find BC> > a way for standards to at least the level that is currently BC> > required for PS more quickly, not to lower the bar for PS. BC> BC> Fully agree. If actual deployment is going to be expected at PS, then it is hard to argue for lowering the bar of "no known defects". BC> > We might even need to raise the bar slightly. BC> BC> Do you mean that we are frequently releasing PS documents that BC> contain significant defects? We certainly can't expect PS BC> documents to be perfect. No, not without implementation experience. BH> I think that if we implemented the standard process as written BH> (and as intended) that many of these problems would go away. BH> Perfection would only have to be achieved at Standard (and close BH> to perfection at Draft standard). It's not clear to me whether it is really possible for the IETF to make PS into what RFC 2026 says it's supposed to be. BH> Enforcing the time outs would create incentives to move the BH> specifications through the standards process. I also suspect BH> that some (perhaps many) specifications never really get BH> implemented, so as long as we enforced the time outs as BH> specified, that these would just go away. That would help, and it would address a problem that we often fail to maintain our specs. However, it would not address something like the Ethernet MIBs ... the technology moves fast enough that the spec is likely to recycle at PS forever (even though large portions of it are stable). >>>>> On Wed, 4 Jun 2003, Ralph Droms wrote: RD> Here's how I see the standards track: The required correctness RD> for PS is high enough that a PS spec is "good enough" for vendor RD> implementation and deployment. The reward for moving to DS and RD> full standard is not worth the investment of effort. RD> RD> The tension I see is the need for a specification that is RD> sufficiently baked and stable to be used for prototyping, RD> interoperability testing and proof-of-correctness for the spec RD> doc, but that does *not* result in deployment. It's the RD> premature deployment that (a) casts goofs in the spec in stone RD> and (b) eliminates any motivation to move the specification RD> through the standards track. It seems to me that Experimental documents would fill that bill. BC> I question the value of having 3 grades at all. Since we BC> hardly use the top two grades, why have them? >>>>> On Wed, 4 Jun 2003, Keith Moore wrote: KM> of course not. what I mean is that if we realize that PS in KM> effect is taken as "ready for deployment" (which seems to be how KM> the industry interprets it), then maybe we really do need to KM> expect some level of implementation and interop testing before KM> we approve something as PS. This suggests to me a two-step process - specs start out in life as Experimental, recycling there are necessary until - there are no known problems and at least two interoperable implementations, at which point they would be eligible for elevation to Standard (and could stay there on subsequent revisions, if the changes were not "too drastic") but this is intruding on solution space, isn't it? //cmh From problem-statement-bounces@alvestrand.no Wed Jun 4 16:09:52 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10558 for ; Wed, 4 Jun 2003 16:09:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E13EE625AB; Wed, 4 Jun 2003 22:09:21 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from episteme-software.com (champdsl-25-66.mcleodusa.net [216.43.25.66]) by eikenes.alvestrand.no (Postfix) with ESMTP id A2EC36233E for ; Wed, 4 Jun 2003 22:09:19 +0200 (CEST) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.2b1); Wed, 4 Jun 2003 15:09:22 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <20030604144450.595e543c.moore@cs.utk.edu> References: <39192643596.20030603161232@brandenburg.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <20030603212052.740e009a.moore@cs.utk.edu> <3EDDED0D.ADF91031@hursley.ibm.com> <20030604144450.595e543c.moore@cs.utk.edu> X-Mailer: Eudora [Macintosh version 6.0a15] Date: Wed, 4 Jun 2003 15:09:46 -0500 To: Keith Moore From: Pete Resnick Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: problem-statement@alvestrand.no Cc: Brian E Carpenter Subject: Re: Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 6/4/03 at 2:44 PM -0400, Keith Moore wrote: >what I mean is that if we realize that PS in effect is taken as >"ready for deployment" (which seems to be how the industry >interprets it), then maybe we really do need to expect some level of >implementation and interop testing before we approve something as PS. So, I read this as saying that industry is interpreting PS as what we meant DS to mean. That is, industry thinks: A [Proposed] Standard [is] well-understood and known to be quite stable, both in its semantics and as a basis for developing an implementation. A [Proposed] Standard may still require additional or more widespread field experience, since it is possible for implementations based on [Proposed] Standard specifications to demonstrate unforeseen behavior when subjected to large-scale use in production environments. A [Proposed] Standard is normally considered to be a final specification, and changes are likely to be made only to solve specific problems encountered. In most circumstances, it is reasonable for vendors to deploy implementations of [Proposed] Standards into a disruption sensitive environment. [2026, section 4.1.2 on Draft Standard, with "industry" edits.] I don't exactly understand why this should mean that we should (as we seem to be on our way to doing unofficially already) raise the bar of PS to be identical to the bar of DS unless we really think that there is no worth in having Proposed Standard as it was originally intended (a vetted, though immature, specification). We could go the route (similar to what CMH suggested) of going Experimental->PS->S, or even Experimental->DS->S, but I assume that the only thing that this will result in is industry thinking that Experimental is ready for prime time. (They already assume that "Informational" is an "IETF-Approved implementable standard".) Wouldn't it make more sense to: - Leave our written processes exactly the way they are; - *Lower* the bar on PS back to what it was intended to be, get PS's out early, and do real interop testing early in the process; - Start putting a boilerplate on PS RFC's which says "OK, now we really mean it; this isn't ready for prime time!" - Ignore all screams of horror when we significantly change a specification that is at PS, publish the changed spec as a new PS and change the old PS to Historic, and say "I told you so". I'm not being facetious. Or at least, I'm not being totally facetious. If the problem we are addressing is really, "Industry expects more out of PS than we intended", the problem can be addressed by either changing our interpretation of PS to meet industry expectations, or by changing industry expectations. The former seems to be what the IESG has been doing for some time now, and the result has been that some industry folks have taken to considering Internet Drafts stable enough to implement. This seems destined for an arms race. I'm more inclined to attempt the latter if we can. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From problem-statement-bounces@alvestrand.no Wed Jun 4 16:30:56 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11357 for ; Wed, 4 Jun 2003 16:30:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6BFEF62571; Wed, 4 Jun 2003 22:30:26 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by eikenes.alvestrand.no (Postfix) with ESMTP id CF67C6233E for ; Wed, 4 Jun 2003 22:30:18 +0200 (CEST) Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4775242 for problem-statement@alvestrand.no; Wed, 04 Jun 2003 16:30:13 -0400 Message-Id: <5.1.0.14.0.20030604162415.01883538@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 04 Jun 2003 16:30:06 -0400 To: problem-statement@alvestrand.no From: "Joel M. Halpern" In-Reply-To: References: <20030604144450.595e543c.moore@cs.utk.edu> <39192643596.20030603161232@brandenburg.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <20030603212052.740e009a.moore@cs.utk.edu> <3EDDED0D.ADF91031@hursley.ibm.com> <20030604144450.595e543c.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 [Somewhere on the border between problems and solutions...] While I like the goal Pete describes, I am afraid that the reality does not match. The last hyphen line suggests ignoring the screams of horror when we change PS. I have currently observed working groups that have been resist to (sometimes unable to) changing working group internet drafts due to complaints about deployment. I therefore tend to be doubtful of our ability in the current structure to ignore those screams. While I am not happy with declaring most of our work experimental, the suggestion on this list would at least make it clear that things can be changed. Yours, Joel M. Halpern At 03:09 PM 6/4/2003 -0500, Pete Resnick wrote: >Wouldn't it make more sense to: > >- Leave our written processes exactly the way they are; >- *Lower* the bar on PS back to what it was intended to be, get PS's out >early, and do real interop testing early in the process; >- Start putting a boilerplate on PS RFC's which says "OK, now we really >mean it; this isn't ready for prime time!" >- Ignore all screams of horror when we significantly change a >specification that is at PS, publish the changed spec as a new PS and >change the old PS to Historic, and say "I told you so". > >I'm not being facetious. Or at least, I'm not being totally facetious. If >the problem we are addressing is really, "Industry expects more out of PS >than we intended", the problem can be addressed by either changing our >interpretation of PS to meet industry expectations, or by changing >industry expectations. From problem-statement-bounces@alvestrand.no Wed Jun 4 16:34:43 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11430 for ; Wed, 4 Jun 2003 16:34:41 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F04A162571; Wed, 4 Jun 2003 22:34:11 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4C8F16233E for ; Wed, 4 Jun 2003 22:34:09 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h54KXwk01115; Wed, 4 Jun 2003 16:34:00 -0400 (EDT) Date: Wed, 4 Jun 2003 16:33:58 -0400 From: Keith Moore To: Pete Resnick Message-Id: <20030604163358.3c4738f1.moore@cs.utk.edu> In-Reply-To: References: <39192643596.20030603161232@brandenburg.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> <20030531233816.40e5dbf9.moore@cs.utk.edu> <20030603212052.740e009a.moore@cs.utk.edu> <3EDDED0D.ADF91031@hursley.ibm.com> <20030604144450.595e543c.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Cc: brian@hursley.ibm.com Subject: Re: Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > Wouldn't it make more sense to: > > - Leave our written processes exactly the way they are; > - *Lower* the bar on PS back to what it was intended to be, get PS's > out early, and do real interop testing early in the process; > - Start putting a boilerplate on PS RFC's which says "OK, now we > really mean it; this isn't ready for prime time!" > - Ignore all screams of horror when we significantly change a > specification that is at PS, publish the changed spec as a new PS and > change the old PS to Historic, and say "I told you so". I don't think so. Part of the reason I don't think so is that I don't think industry pays much attention to what we claim about a document, so even an explicit "not ready for prime time" disclaimer wouldn't be terribly useful. But basically I think our current maturity levels (regardless of what we call them or claim about them) are not a good match either with industry needs or with working group interests/energies/motivations. I assume that a revised set of maturity levels would have some stage more-or-less equivalent to our current PS stage, and that it would not have stages equivalent to DS or FS - but would replace these with applicability statements and/or implementation notes. And I expect that the stage that was closest to the current PS stage would actually be a bit higher bar than PS now, and that there would be some earlier stages as prequesites to that stage (which to discourage deployment would probably not be published as RFCs) But of course it doesn't have to work out that way. For now I'm merely suggesting that we need to re-examine our document maturity stages to see how well they serve our needs and the needs of our customers, and if they don't, to consider changing them. From problem-statement-bounces@alvestrand.no Wed Jun 4 23:54:38 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24661 for ; Wed, 4 Jun 2003 23:54:37 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 48992625A4; Thu, 5 Jun 2003 05:54:08 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id 647016233E for ; Thu, 5 Jun 2003 05:54:00 +0200 (CEST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])h553rxW20520 for ; Thu, 5 Jun 2003 06:53:59 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com for ; Thu, 5 Jun 2003 06:53:59 +0300 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 5 Jun 2003 06:53:58 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 5 Jun 2003 06:53:58 +0300 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" Date: Thu, 5 Jun 2003 06:53:57 +0300 Message-ID: Thread-Topic: Document Series Thread-Index: AcMqyXLalOQhjpayQ/KrRmM+MocngAAS3WSw From: To: X-OriginalArrivalTime: 05 Jun 2003 03:53:58.0570 (UTC) FILETIME=[17D648A0:01C32B16] Subject: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA24661 Hi all, I've always assumed that industry does not use DS or FS simply because the IETF does not produce them in any great number. The IETF doesn't seem to produce them because WGs are, in general, charted to make PSs; after which, they try to shut down. There is very little incentive in the IETF progress documents. Industry, being industry, takes what they get & runs with it. I'm not sure how many of the proposals discussed would impact this situation in any meaningful way. br, John From problem-statement-bounces@alvestrand.no Thu Jun 5 02:14:12 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07900 for ; Thu, 5 Jun 2003 02:14:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8BF23625A2; Thu, 5 Jun 2003 08:13:40 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3D400622A1; Thu, 5 Jun 2003 08:13:39 +0200 (CEST) Date: Thu, 05 Jun 2003 08:13:39 +0200 From: Harald Tveit Alvestrand To: john.loughney@nokia.com, problem-statement@alvestrand.no Message-ID: <245610000.1054793619@askvoll.hjemme.alvestrand.no> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On torsdag, juni 05, 2003 06:53:57 +0300 john.loughney@nokia.com wrote: > Hi all, > > I've always assumed that industry does not use DS or FS simply because > the IETF does not produce them in any great number. The IETF doesn't > seem to produce them because WGs are, in general, charted to make > PSs; after which, they try to shut down. There is very little incentive > in the IETF progress documents. Industry, being industry, takes what > they get & runs with it. > > I'm not sure how many of the proposals discussed would impact this > situation in any meaningful way. at least two try to: Brian's DS/Full merger Maintenance Teams but industry running on PS is not a core problem, I think. The more-core problem is industry running on protocols with design flaws and protocol bugs, which cannot be fixed because of the installed base. If PS was perfect, this would not be a serious problem. But it isn't so. (my favourite example of deployment lock-in is the MIME version number - when the first post-RFC revision of the MIME spec was done, we wanted to increase the version number from 1.0 to 1.1, to celebrate the fixing of many bugs and unclear points in the specification. One vendor had a product in days-before-release state, which would not interoperate with UAs that sent 1.1 in the version number. We decided to freeze the version number at 1.0 forever...... not a big loss to humanity, but it looks stupid.) Harald From problem-statement-bounces@alvestrand.no Thu Jun 5 04:36:48 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11739 for ; Thu, 5 Jun 2003 04:36:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7D31C625A2; Thu, 5 Jun 2003 10:36:16 +0200 (CEST) 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 394426233E; Thu, 5 Jun 2003 10:36:07 +0200 (CEST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])h558a6D28427; Thu, 5 Jun 2003 11:36:06 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com ; Thu, 5 Jun 2003 11:36:05 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 5 Jun 2003 11:36:05 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 5 Jun 2003 11:36:05 +0300 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" Date: Thu, 5 Jun 2003 11:36:04 +0300 Message-ID: Thread-Topic: pausable explanation for the Document Series Thread-Index: AcMrKZ4G4pT9YM80Ryai8CwG+GrxKgAD0tzA From: To: , X-OriginalArrivalTime: 05 Jun 2003 08:36:05.0300 (UTC) FILETIME=[80F44F40:01C32B3D] Subject: RE: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA11739 Hi Harald, > > I've always assumed that industry does not use DS or FS simply because > > the IETF does not produce them in any great number. The IETF doesn't > > seem to produce them because WGs are, in general, charted to make > > PSs; after which, they try to shut down. There is very little incentive > > in the IETF progress documents. Industry, being industry, takes what > > they get & runs with it. > > > > I'm not sure how many of the proposals discussed would impact this > > situation in any meaningful way. > > at least two try to: > > Brian's DS/Full merger Actually, I'm not sure how Brian's proposal fits into the above picture, since PS seems to be the default level for most work done in the IETF. Without internal motiviation to progress the work, I'm not sure it makes a difference. > > Maintenance Teams > I didn't think about your proposal in these terms, but the more I do, the more I like it. It is, basically, the IETF taking care of its own messes, which is a good thing. > but industry running on PS is not a core problem, I think. I agree - mostly because it is outside of our ability to control. > The more-core problem is industry running on protocols with design flaws > and protocol bugs, which cannot be fixed because of the installed base. Depends upon how you look at things. I would say that the more-core problem is that our quality control may be less than ideal. As the IETF is not a protocol enforcement agency, what the industry does with what we make is beyond our control, in my opinion. > If PS was perfect, this would not be a serious problem. But > it isn't so. This touches on the relevant issue. Should PS be perfect? At what level do we raise (or lower) the bar? What can we do about it? One possibility would be that we make sure that PS documents are as perfect as possible (raise the bar). Another could be to require some sort of best practices document for most major PS documents (which would capture operational issues, etc). Another could be your Maintenance Team idea, especially if it is coupled with an object that captures all of the relevant RFCs, drafts in progress, bug reports, etc. I also think that if we go the route of Maintenence Teams, perhaps the object could also preserve any issue lists created during WG / IETF last call. John From problem-statement-bounces@alvestrand.no Thu Jun 5 06:34:29 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14173 for ; Thu, 5 Jun 2003 06:34:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CC183625A2; Thu, 5 Jun 2003 12:33:56 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id ECB87621FB; Thu, 5 Jun 2003 12:33:54 +0200 (CEST) Date: Thu, 05 Jun 2003 12:33:55 +0200 From: Harald Tveit Alvestrand To: john.loughney@nokia.com, problem-statement@alvestrand.no Message-ID: <268630000.1054809235@askvoll.hjemme.alvestrand.no> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On torsdag, juni 05, 2003 11:36:04 +0300 john.loughney@nokia.com wrote: >> The more-core problem is industry running on protocols with design flaws >> and protocol bugs, which cannot be fixed because of the installed base. > > Depends upon how you look at things. I would say that the more-core > problem is that our quality control may be less than ideal. As the IETF > is not a protocol enforcement agency, what the industry does with > what we make is beyond our control, in my opinion. actually this comes back to the IETF mission statement thing.... if the mission of the IETF is to "make the Internet work", with our particular task in pursuit of that mission being to "make high quality, timely standards for the Internet", then flaws in the standards that the industry runs on are signs that we haven't achieved our mission. I don't think we can assert "control", in the sense of "I decide, it happens" - if I asserted that I was in control of the IETF, I'd be as silly as if the IETF claimed that it was in control of the Internet. But I do have influence over what the IETF does (and so do you), and the IETF does have influence over what the industry does. Might be semantic quibbling .... then again, it might actually matter when we decide what to do. > >> If PS was perfect, this would not be a serious problem. But >> it isn't so. > > This touches on the relevant issue. Should PS be perfect? At what > level do we raise (or lower) the bar? What can we do about it? > One possibility would be that we make sure that PS documents are > as perfect as possible (raise the bar). Another could be to > require some sort of best practices document for most major PS > documents (which would capture operational issues, etc). RFC 2026 invented the term "applicability statements" - that's a term that seems to have fallen by the wayside...... > Another > could be your Maintenance Team idea, especially if it is coupled > with an object that captures all of the relevant RFCs, drafts > in progress, bug reports, etc. I also think that if we go the > route of Maintenence Teams, perhaps the object could also > preserve any issue lists created during WG / IETF last call. The "protocol, its current state and history book" site? Seems to make sense to me..... much of ancient history is actually preserved in various archives, but it can be VERY hard to find...... Nice thought! From problem-statement-bounces@alvestrand.no Thu Jun 5 08:01:54 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16985 for ; Thu, 5 Jun 2003 08:01:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A3DC8622A1; Thu, 5 Jun 2003 14:01:21 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8264B6223F; Thu, 5 Jun 2003 14:01:12 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19NtQd-0009pj-00; Thu, 05 Jun 2003 07:01:11 -0500 Date: Thu, 05 Jun 2003 08:01:11 -0400 From: John C Klensin To: Harald Tveit Alvestrand Message-ID: <30507347.1054800071@p3.JCK.COM> In-Reply-To: <268630000.1054809235@askvoll.hjemme.alvestrand.no> References: <268630000.1054809235@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/3.0.3 (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: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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, 05 June, 2003 12:33 +0200 Harald Tveit Alvestrand wrote: >> Depends upon how you look at things. I would say that the >> more-core problem is that our quality control may be less >> than ideal. As the IETF is not a protocol enforcement >> agency, what the industry does with what we make is beyond >> our control, in my opinion. > > actually this comes back to the IETF mission statement > thing.... > > if the mission of the IETF is to "make the Internet work", > with our particular task in pursuit of that mission being to > "make high quality, timely standards for the Internet", then > flaws in the standards that the industry runs on are signs > that we haven't achieved our mission. >... > RFC 2026 invented the term "applicability statements" - that's > a term that seems to have fallen by the wayside...... Actually, unless my memory has gone _very_ bad, we have had applicability statements as tools in the collection for a long time, certainly before 2026. I think they were even called that. We haven't used them very much because it has been extremely difficult to get energy and focus for those efforts -- they are hard to do, and rarely as rewarding as developing a technology standard. Note that RFC 1122 and 1123 are definitely AS documents, as is RFC 1812. If you go through the RFC list looking for the word "requirements", you will find it in several other places as the term is used by an AS in the 2026 sense. The term "applicability statement" appears in RFC 2000 (and probably earlier, I haven't had time to go back through that thread). The fact that these are hard to get done doesn't imply that we should have written them off, which we essentially have done... except by accident, when we call them something else. We have created a lot of confusion by also using the term "requirements" to describe "things we really think this protocol ought to have in it". We also devalued ASs by claiming, of late, that attempts at ASs must be published only as Informational, and then telling anyone who will listen that Informational documents don't count, despite the fact that 2026 explicitly identifies them with standards track maturity levels. That doctrine has been imposed, and dropped, more or less at the convenience (I'm tempted to say "whim") of the IESG. For example, using the definitions of 2026, RFC 3454 meets the criteria for an AS: it is a profile of an external standard that specifies how to use parts of that standard in the Internet and in other IETF protocols. And it is definitely standards-track, but the term AS was never, as far as I know, used during its development or approval process. Speaking of tools we have stopped using, section 3.3 of 2026 describes requirement levels (formerly "status", see below) for documents -- required/ recommended/ elective/ limited use/ not recommended. Those statements, or ones similar to them, should be (or should have been) much more important tools for vendors and others in determining what documents to use than the orthogonal standards-track maturity levels. Before we dropped them --about the same time, if I recall, that we dropped the notion of conformity clauses in standards-track documents -- they appeared regularly and were attached to _every_ protocol-specifying RFC. See 1083 for examples. Incidentally, reading RFC 1083, especially section 2, can be very illuminating with regard to where some of 2026 ultimately came from. Interestingly, it uses "proposed protocol", and not "proposed standard". The term "standard" is introduced only at "draft", as in "draft protocol standard". And it is very clear about what "draft" means in the context of the discussions recently on this list: "[This] draft standard state is essentially a warning to the community that unless an objection is raised or a flaw is found this protocol will become a 'standard'". I wonder whether we might have reduced some confusion had we preserved that particular distinction --not using the term "standard" at all to refer to proposed-level documents --in wording. regards, john From problem-statement-bounces@alvestrand.no Thu Jun 5 08:49:00 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21837 for ; Thu, 5 Jun 2003 08:48:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F00C7625A2; Thu, 5 Jun 2003 14:48:27 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 44116622A1; Thu, 5 Jun 2003 14:48:25 +0200 (CEST) Date: Thu, 05 Jun 2003 14:48:25 +0200 From: Harald Tveit Alvestrand To: John C Klensin Message-ID: <287550000.1054817305@askvoll.hjemme.alvestrand.no> In-Reply-To: <30507347.1054800071@p3.JCK.COM> References: <268630000.1054809235@askvoll.hjemme.alvestrand.no> <30507347.1054800071@p3.JCK.COM> X-Mailer: Mulberry/2.2.1 (Linux/x86) 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: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On torsdag, juni 05, 2003 08:01:11 -0400 John C Klensin wrote: >> RFC 2026 invented the term "applicability statements" - that's >> a term that seems to have fallen by the wayside...... > > Actually, unless my memory has gone _very_ bad, we have had applicability > statements as tools in the collection for a long time, certainly before > 2026. I think they were even called that. I've been duly berated for the fallibility of my institutional memory. The AS concept is far older than 2026. Apologies. Harald From problem-statement-bounces@alvestrand.no Thu Jun 5 11:02:47 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29593 for ; Thu, 5 Jun 2003 11:02:46 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C836D625A4; Thu, 5 Jun 2003 17:02:14 +0200 (CEST) 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 A1DB4625A4 for ; Thu, 5 Jun 2003 17:02:04 +0200 (CEST) Received: from bbprime (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h55F4mF03847; Thu, 5 Jun 2003 08:04:48 -0700 Date: Thu, 5 Jun 2003 07:58:59 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <189335823007.20030605075859@brandenburg.com> To: John C Klensin In-Reply-To: <30507347.1054800071@p3.JCK.COM> References: <268630000.1054809235@askvoll.hjemme.alvestrand.no> <30507347.1054800071@p3.JCK.COM> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: "problem-statement@alvestrand.no" Subject: Re: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 John, JCK> Actually, unless my memory has gone _very_ bad, we have had JCK> applicability statements as tools in the collection for a long JCK> time, certainly before 2026. I think they were even called that It isn't. We have. They were. JCK> that. We haven't used them very much because it has been JCK> extremely difficult to get energy and focus for those efforts -- I believe that we haven't used them because it has always been difficult to figure out what they actually should mean or how they should actually be used. They have not had a sufficiently pragmatic, operational quality to them. JCK> JCK> The fact that these are hard to get done doesn't imply that we JCK> should have written them off, (for this community, your version of a tirade is cute.) Let me suggest that the most significant thing in your commentary, along with some other observations that have been showing up, is that we are all tending to believe that we have to invent all sorts of structures and processes, often ignoring existing ones. We should, at least, consider reviving the ones that have been ignored. (This requires actually becoming familiar with them.) And if we reject them, we should ask why inventing some new bit of cleverness is likely to have any more benefit. Why will this new thing be any more likely to work well? JCK> We have created a lot of confusion by also using the term JCK> "requirements" to describe "things we really think this protocol JCK> ought to have in it". or, worse, the document specifies most of the protocol, except syntax. Perhaps the most serious difficulty with the way we use requirements statements is that they are often written with no concern about practicalities, and sometimes without concern about coherence for an integrated service. And then during protocol specification the requirements are used to reject concerns about practicality and coherence. JCK> Speaking of tools we have stopped using, section 3.3 of 2026 JCK> describes requirement levels (formerly "status", see below) for JCK> documents -- required/ recommended/ elective/ limited use/ not JCK> recommended. Again, I believe this is because we never figured out how to make them be really meaningful. JCK> 'standard'". I wonder whether we might have reduced some JCK> confusion had we preserved that particular distinction --not JCK> using the term "standard" at all to refer to proposed-level JCK> documents --in wording. oh, you optimist, you. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Thu Jun 5 11:09:47 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00675 for ; Thu, 5 Jun 2003 11:09:46 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7EF15625A4; Thu, 5 Jun 2003 17:09:16 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by eikenes.alvestrand.no (Postfix) with ESMTP id ACE04625A2 for ; Thu, 5 Jun 2003 17:09:06 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19NwMN-0007dn-00; Thu, 05 Jun 2003 08:08:59 -0700 Date: Thu, 5 Jun 2003 11:06:55 -0400 From: Keith Moore To: Dave Crocker Message-Id: <20030605110655.0ae706f6.moore@cs.utk.edu> In-Reply-To: <189335823007.20030605075859@brandenburg.com> References: <268630000.1054809235@askvoll.hjemme.alvestrand.no> <30507347.1054800071@p3.JCK.COM> <189335823007.20030605075859@brandenburg.com> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: john-ietf@jck.com Cc: problem-statement@alvestrand.no Cc: dhc@dcrocker.net Cc: moore@cs.utk.edu Subject: Re: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 that we haven't used them because it has always been difficult > to figure out what they actually should mean or how they should actually > be used. perhaps more generally - there isn't such an obvious pattern to them, either for what they look like or how they are created, so they are mostly off people's radar. Keith From problem-statement-bounces@alvestrand.no Thu Jun 5 11:15:03 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00965 for ; Thu, 5 Jun 2003 11:15:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4D2D3625B7; Thu, 5 Jun 2003 17:14:20 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by eikenes.alvestrand.no (Postfix) with ESMTP id 65B5E625B6 for ; Thu, 5 Jun 2003 17:14:02 +0200 (CEST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h55FDpwc016646; Thu, 5 Jun 2003 08:13:52 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIA49488; Thu, 5 Jun 2003 08:13:50 -0700 (PDT) Message-Id: <200306051513.AIA49488@mira-sjc5-c.cisco.com> To: Dave Crocker From: Melinda Shore In-Reply-To: Message from dhc@dcrocker.net <189335823007.20030605075859@brandenburg.com> Date: Thu, 05 Jun 2003 11:13:50 -0400 Cc: John C Klensin Cc: "problem-statement@alvestrand.no" Subject: Re: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > Let me suggest that the most significant thing in your commentary, along > with some other observations that have been showing up, is that we are > all tending to believe that we have to invent all sorts of structures > and processes, often ignoring existing ones. > We should, at least, consider reviving the ones that have been ignored. > (This requires actually becoming familiar with them.) In reading some of the recent messages I think it's become clear, at least to me, that in some cases the "problems" we're having aren't procedural/policy problems but rather problems in how we're implementing established procedure and policy. It may be legitimate to ask if a bad implementation of a policy is because the policy can't be implemented well, though. Melinda From problem-statement-bounces@alvestrand.no Thu Jun 5 11:38:50 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03566 for ; Thu, 5 Jun 2003 11:38:49 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8D94F625B5; Thu, 5 Jun 2003 17:38:19 +0200 (CEST) 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 12A04625A4 for ; Thu, 5 Jun 2003 17:38:08 +0200 (CEST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])h55Fc7D11660 for ; Thu, 5 Jun 2003 18:38:07 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com ; Thu, 5 Jun 2003 18:38:07 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 5 Jun 2003 18:38:06 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 5 Jun 2003 18:38:06 +0300 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" Date: Thu, 5 Jun 2003 18:38:05 +0300 Message-ID: Thread-Topic: IETF mission (RE: pausable explanation for the Document Series) Thread-Index: AcMrd3tCe7Yc+dA0S9yUV4aNeUG8dgAADy/g From: To: , X-OriginalArrivalTime: 05 Jun 2003 15:38:06.0273 (UTC) FILETIME=[756E2B10:01C32B78] Cc: john-ietf@jck.com Cc: problem-statement@alvestrand.no Cc: dhc@dcrocker.net Subject: RE: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA03566 Hi all, > perhaps more generally - there isn't such an obvious pattern to them, either > for what they look like or how they are created, so they are mostly off > people's radar. As a contributor to one: http://www.ietf.org/rfc/rfc3257.txt I don't think that these are really very mysterious beasts. I suggest that ADs should encourage these documents in WGs their charter. John From problem-statement-bounces@alvestrand.no Thu Jun 5 11:58:21 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04476 for ; Thu, 5 Jun 2003 11:58:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D3208625A5; Thu, 5 Jun 2003 17:57:49 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id C19BA625A1 for ; Thu, 5 Jun 2003 17:57:46 +0200 (CEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA17475 for ; Thu, 5 Jun 2003 08:57:45 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h55Fvhd23796; Thu, 5 Jun 2003 08:57:43 -0700 X-mProtect: <200306051557> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpiTjrl; Thu, 05 Jun 2003 08:57:41 PDT Message-ID: <3EDF6875.50B3FAD8@iprg.nokia.com> Date: Thu, 05 Jun 2003 08:57:41 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hello John, I also wholeheartedly support the inclusion of an applicability statement whenever it makes sense. However, I also suggest that the protocol SHOULD (within engineering discretion) not intentionally restrict its applcability to the situations delineated in the applicability statement. I would restate Postel's maxim: Be conservative in the claimed applicability, but generous in the potential applicability. Regards, Charlie P. john.loughney@nokia.com wrote: > > Hi all, > > > perhaps more generally - there isn't such an obvious pattern to them, either > > for what they look like or how they are created, so they are mostly off > > people's radar. > > As a contributor to one: > > http://www.ietf.org/rfc/rfc3257.txt > > I don't think that these are really very mysterious beasts. > > I suggest that ADs should encourage these documents in WGs their charter. > > John From problem-statement-bounces@alvestrand.no Thu Jun 5 12:10:29 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04868 for ; Thu, 5 Jun 2003 12:10:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A79D625B6; Thu, 5 Jun 2003 18:09:51 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2758D625A1; Thu, 5 Jun 2003 18:09:48 +0200 (CEST) Received: from backin5.merit.edu (backin5.merit.edu [198.108.60.28]) by segue.merit.edu (Postfix) with ESMTP id 960BD5DD99; Thu, 5 Jun 2003 12:09:46 -0400 (EDT) Date: Thu, 5 Jun 2003 12:09:46 -0400 (EDT) From: Susan Harris To: Harald Tveit Alvestrand In-Reply-To: <87100000.1054711117@askvoll.hjemme.alvestrand.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: problem-statement@alvestrand.no Subject: Re: New ways to do things (Re: Doing the Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > As for concrete proposals in order to "try this one on for size", I suggest > that we think about creating an object called a "maintenance team": I think this is a *great* idea Harald. From problem-statement-bounces@alvestrand.no Thu Jun 5 13:13:07 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06810 for ; Thu, 5 Jun 2003 13:13:06 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9FA00625B5; Thu, 5 Jun 2003 19:12:36 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mx-out.daemonmail.net (mx-out.daemonmail.net [216.104.160.39]) by eikenes.alvestrand.no (Postfix) with ESMTP id F08A5625A1 for ; Thu, 5 Jun 2003 19:12:32 +0200 (CEST) Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.9.3p2/8.9.3) with SMTP id KAA77559 for ; Thu, 5 Jun 2003 10:12:30 -0700 (PDT) (envelope-from spencer@mcsr-labs.org) Received: from (12.237.229.250 [12.237.229.250]) by mail.varaha.com with SMTP id IAK0oEQ2 Thu, 05 Jun 2003 10:12:28 -0700 (PDT) Message-ID: <010201c32b85$a65997c0$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <268630000.1054809235@askvoll.hjemme.alvestrand.no><30507347.1054800071@p3.JCK.COM><189335823007.20030605075859@brandenburg.com> <20030605110655.0ae706f6.moore@cs.utk.edu> Date: Thu, 5 Jun 2003 12:12:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Ummm... this looks like another self-inflicted wound - in my understanding of the plan, full Standard would be common, and STDs can contain multiple RFCs, so that would be more common, and an AS could easily be attached to a STD, so ASes would be more easily visible. But we run the Internet on PSes, don't use STDs in common conversation, and have no way to tie ASes to PSes in a visible way. I remember, a number of years ago, carefully understanding ASes in 2026 and then deciding that we apparently pay little or no attention to the notion, and forgetting everything I'd read about them. ("what OTHER problems have we already solved once?") Spencer ----- Original Message ----- From: "Keith Moore" To: "Dave Crocker" Cc: ; ; ; Sent: Thursday, June 05, 2003 10:06 AM Subject: Re: IETF mission (RE: pausable explanation for the Document Series) > > I believe that we haven't used them because it has always been difficult > > to figure out what they actually should mean or how they should actually > > be used. > > perhaps more generally - there isn't such an obvious pattern to them, either > for what they look like or how they are created, so they are mostly off > people's radar. > > Keith From problem-statement-bounces@alvestrand.no Thu Jun 5 13:26:17 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07213 for ; Thu, 5 Jun 2003 13:26:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C93BE625B6; Thu, 5 Jun 2003 19:25:47 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 13D8B625B5 for ; Thu, 5 Jun 2003 19:25:46 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h55HPTk22046; Thu, 5 Jun 2003 13:25:31 -0400 (EDT) Date: Thu, 5 Jun 2003 13:25:29 -0400 From: Keith Moore To: "Charles E. Perkins" Message-Id: <20030605132529.555f251a.moore@cs.utk.edu> In-Reply-To: <3EDF6875.50B3FAD8@iprg.nokia.com> References: <3EDF6875.50B3FAD8@iprg.nokia.com> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: john.loughney@nokia.com Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > However, I also suggest that > the protocol SHOULD (within engineering discretion) not intentionally > restrict its applcability to the situations delineated in the > applicability statement. I disagree. A protocol spec should be careful to claim applicability only for that which it's been designed to do, and for which it's been reviewed. This doesn't preclude use of the protocol for other purposes, but it should be clear that such use is not within the scope of the standard. And where it's know that use is inappropriate, this should be clearly stated. (not that this stops people - look how many sites are using HTTP cookies for authentication) From problem-statement-bounces@alvestrand.no Thu Jun 5 13:36:51 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07454 for ; Thu, 5 Jun 2003 13:36:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AD82D625B6; Thu, 5 Jun 2003 19:36:19 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6E92A625B5 for ; Thu, 5 Jun 2003 19:36:11 +0200 (CEST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h55Ha8Oo018842 for ; Thu, 5 Jun 2003 10:36:08 -0700 (PDT) Received: from cisco.com (sjc-vpn1-385.cisco.com [10.21.97.129]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AGX24823; Thu, 5 Jun 2003 10:33:06 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Thu, 5 Jun 2003 13:36:06 -0400 Date: Thu, 5 Jun 2003 13:36:06 -0400 From: Scott W Brim To: "problem-statement@alvestrand.no" Message-ID: <20030605173606.GC1800@sbrim-w2k01> Mail-Followup-To: Scott W Brim , "problem-statement@alvestrand.no" References: <268630000.1054809235@askvoll.hjemme.alvestrand.no> <30507347.1054800071@p3.JCK.COM> <189335823007.20030605075859@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <189335823007.20030605075859@brandenburg.com> User-Agent: Mutt/1.4i Subject: Re: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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, Jun 05, 2003 07:58:59AM -0700, Dave Crocker allegedly wrote: > Perhaps the most serious difficulty with the way we use requirements > statements is that they are often written with no concern about > practicalities, and sometimes without concern about coherence for an > integrated service. And then during protocol specification the > requirements are used to reject concerns about practicality and > coherence. How do you measure practicality of a requirement without assuming the solution? The reason we (occasionally) have requirements documents is to get everyone to agree on what the problem is. If someone says "my customers require this", what are you going to do? The answer is to use requirements docs to define the working group before trying to define the solution. That is, if someone thinks the requirements are impractical or not coherent, you have clear evidence that the WG should be focused or split. From problem-statement-bounces@alvestrand.no Thu Jun 5 18:47:43 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21318 for ; Thu, 5 Jun 2003 18:47:42 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EA498625A5; Fri, 6 Jun 2003 00:47:11 +0200 (CEST) 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 F398861C73 for ; Fri, 6 Jun 2003 00:47:09 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h55Mo5F01954 for ; Thu, 5 Jun 2003 15:50:05 -0700 Date: Thu, 5 Jun 2003 15:47:02 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <144363905408.20030605154702@brandenburg.com> To: problem-statement@alvestrand.no In-Reply-To: <3EDDA77F.8050700@piuha.net> References: <3EDDA77F.8050700@piuha.net> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Subject: Re: Discipline of Internet Protocol Engineering X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Folks, JA> However, I believe there's a more fundamental reason why some JA> charters are or may need to be fuzzy. That reason has to do with the JA> timing when the IETF gets involved, or the scope of the problem. This has been discussed over the years. We sometimes form working groups without really knowing what they are supposed to do. I believe that a working group must formulate its requirements statement before forming or within a few months. Otherwise it is not ready to do standards work. The IETF has a very poor track record with fuzzy goals, and a very good one with very concrete, very near-term and very narrow goals. JA> Are you doing adding a new algorithm to an existing security JA> protocol? Pretty specific. Are you going to develop a protocol for a JA> specific purpose? Still pretty simple. agree. JA> Are you going to develop a whole set of protocols and extensions to JA> fulfill a function. Starting to get more complex (example: SIP). Are JA> you going to re-architect IPn and develop IPn+2? Pretty tough Not just tough but I would say that our track record for such large-scale project is quite poor, unless we have been able to carve off pieces that are useful on their own. That is, if we can do incrementally useful work, then the IETF has a good chance of doing something that is timely and useful. Otherwise, we don't. Our work suffers from technical and schedule bloat. HTA> Take, for instance, the recent LEMONADE charter - which I think is HTA> reasonably crisp and states what the WG is intended to do. HTA> When it was first floated on the IETF list, it was blasted by at least a HTA> couple of people (including you, I think) Yes. However what I found interesting was that the fundamental concerns about concreteness that I was raising did not seem to be that interesting to most folks. Pete Resnick did a stellar job of negotiating a compromise, but that should not have been necessary. All I was seeking was a charter that said concretely what problem/benefit was being attacked, and what the technical scope of work would be, in language that permitted knowing what was *out* of scope as much as what was *in* and knowing what would actually be delivered. HTA> Yes, there were improvements. But I think the first version floated wasn't HTA> that bad either My sense is that looking at the history of that charter could be highly instructive, since my impression is that some iterations of it received "help" that made it considerably more mushy, in the earlier stages. KM> Part of the problem may be that we often want the initial charter to map KM> out the entire life cycle of the group. often this is unrealistic, because KM> we really don't understand what the group has to do. I don't think we KM> should try to nail down details more than about eight months (say two KM> IETF meetings) in advance. But if we don't have a good idea about what KM> a WG is going to be doing over the next few months, with fairly concrete, KM> realizable, measurable goals - something's wrong. Folks -- we need to frame Keith's words and chant them at the beginning of every meeting -- and it just kills me to say something this nice about Keith. JA> We could in addition require that groups produce something concrete JA> (like an approved document) in that 8 months. Note that the PACT suggestion was 18 months, yet folks were quite upset about it. HTA> Might part of the problem be that we're lousy at making plans, *apart* from HTA> the charter? HTA> I don't think I've ever seen a working group chair come up with a HTA> document/message/webpage that said something like "OK, in order to achieve HTA> this milestone in December, here's what we're planning to do in June, July, HTA> August, September and November Properly designed milestones will, at least, set the stage for exactly that kind of thinking. Or perhaps the way to talk about this is that you are calling for the intermediate milestones that will achieve the ones in the charter. Egad. As you note, this starts sounding like classic project management. What a thought. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Thu Jun 5 20:33:19 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23620 for ; Thu, 5 Jun 2003 20:33:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CE00D625A5; Fri, 6 Jun 2003 02:32:46 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id E2D81625A4; Fri, 6 Jun 2003 02:32:42 +0200 (CEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA13129; Thu, 5 Jun 2003 17:32:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h560WeV10859; Thu, 5 Jun 2003 17:32:40 -0700 X-mProtect: <200306060032> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.150, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkpHEkd; Thu, 05 Jun 2003 17:32:37 PDT Message-Id: <4.3.2.7.2.20030605172112.0309fe00@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 05 Jun 2003 17:32:30 -0700 To: Harald Tveit Alvestrand From: Bob Hinden In-Reply-To: <245610000.1054793619@askvoll.hjemme.alvestrand.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: john.loughney@nokia.com Cc: problem-statement@alvestrand.no Subject: Re: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Harald, >The more-core problem is industry running on protocols with design flaws >and protocol bugs, which cannot be fixed because of the installed base. > >If PS was perfect, this would not be a serious problem. But it isn't so. First versions of anything are never perfect. This is true for products and standards. As long as we try to solve the problem by trying to make the first version perfect we will fail. It only delays the first version and causes it to miss the market need. The only solution I know of is to do new versions. This seems to work well in industry. Perfection doesn't work. Shipping products and getting bug reports works. Bob p.s. Bug reports are also a good way to measure real usage. From problem-statement-bounces@alvestrand.no Thu Jun 5 20:38:20 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23720 for ; Thu, 5 Jun 2003 20:38:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 48F7B625A5; Fri, 6 Jun 2003 02:37:49 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 91454625A4 for ; Fri, 6 Jun 2003 02:37:41 +0200 (CEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA13322; Thu, 5 Jun 2003 17:37:39 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h560bcW15265; Thu, 5 Jun 2003 17:37:38 -0700 X-mProtect: <200306060037> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.150, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmW4MC2; Thu, 05 Jun 2003 17:37:36 PDT Message-Id: <4.3.2.7.2.20030605173528.0346cef8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 05 Jun 2003 17:37:30 -0700 To: Dave Crocker From: Bob Hinden In-Reply-To: <144363905408.20030605154702@brandenburg.com> References: <3EDDA77F.8050700@piuha.net> <3EDDA77F.8050700@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: Discipline of Internet Protocol Engineering X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 >Properly designed milestones will, at least, set the stage for exactly >that kind of thinking. Or perhaps the way to talk about this is that >you are calling for the intermediate milestones that will achieve the >ones in the charter. > >Egad. As you note, this starts sounding like classic project management. > >What a thought. Worse still, we might even want people in the IESG with some real management experience. Bob From problem-statement-bounces@alvestrand.no Fri Jun 6 00:57:06 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28697 for ; Fri, 6 Jun 2003 00:57:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 01978625A5; Fri, 6 Jun 2003 06:56:34 +0200 (CEST) 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 EFB816256B for ; Fri, 6 Jun 2003 06:56:31 +0200 (CEST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])h564uUD11933 for ; Fri, 6 Jun 2003 07:56:30 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com for ; Fri, 6 Jun 2003 07:56:30 +0300 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 07:56:30 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 07:56:29 +0300 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" Date: Fri, 6 Jun 2003 07:56:29 +0300 Message-ID: Thread-Topic: IETF mission (RE: pausable explanation for the Document Series) Thread-Index: AcMrezWDZe5bgr6DRC6WgiD2apg7NQAbIDaQ From: To: X-OriginalArrivalTime: 06 Jun 2003 04:56:29.0754 (UTC) FILETIME=[FE2149A0:01C32BE7] Cc: problem-statement@alvestrand.no Subject: RE: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA28697 Hi Charles, > I also wholeheartedly support the inclusion of an applicability > statement whenever it makes sense. However, I also suggest that > the protocol SHOULD (within engineering discretion) not intentionally > restrict its applcability to the situations delineated in the > applicability statement. > > I would restate Postel's maxim: > > Be conservative in the claimed applicability, but generous > in the potential applicability. What I am concerned about is there seems to be a movement to make a super-PS, one which would be the equavalent of a DS & have no bugs. I am not sure of the feasibility of this, but I have noticed that simple protocol documents are getting overloaded with a lot of applicability info, deployment concerns, best practices and implementation guides. Somehow, I think overloading a single document with this info, is not a reciepe for success. John From problem-statement-bounces@alvestrand.no Fri Jun 6 01:15:53 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29022 for ; Fri, 6 Jun 2003 01:15:52 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 012C6625B8; Fri, 6 Jun 2003 07:15:21 +0200 (CEST) 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 61DFF625A5; Fri, 6 Jun 2003 07:15:18 +0200 (CEST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])h565FHD24915; Fri, 6 Jun 2003 08:15:17 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com ; Fri, 6 Jun 2003 08:15:17 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 08:15:17 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 08:15:16 +0300 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" Date: Fri, 6 Jun 2003 08:15:15 +0300 Message-ID: Thread-Topic: pausable explanation for the Document Series Thread-Index: AcMrwyTvX9dwcQqQTKSiBi/uD7M/KwAJvSkQ From: To: , X-OriginalArrivalTime: 06 Jun 2003 05:15:16.0641 (UTC) FILETIME=[9DCE9910:01C32BEA] Cc: problem-statement@alvestrand.no Subject: RE: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA29022 Hi Bob, > >The more-core problem is industry running on protocols with design flaws > >and protocol bugs, which cannot be fixed because of the installed base. > > > >If PS was perfect, this would not be a serious problem. But it isn't so. > > First versions of anything are never perfect. This is true for products > and standards. As long as we try to solve the problem by trying to make > the first version perfect we will fail. It only delays the first version > and causes it to miss the market need. The only solution I know of is to > do new versions. This seems to work well in industry. > > Perfection doesn't work. Shipping products and getting bug > reports works. I agree with you on this point. Until someone writes an ascii to C (or your favorite coding language) to convert I-Ds to running code, it'll be impossible to ensure that a PS does not have bugs. A more sensible way forward, in my opinion, would be to ensure a better way for bug reporting, document updating, etc. I think Harald's maintainence teams is a good potential solution. John From problem-statement-bounces@alvestrand.no Fri Jun 6 02:06:59 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06929 for ; Fri, 6 Jun 2003 02:06:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 62DE8625A5; Fri, 6 Jun 2003 08:06:28 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by eikenes.alvestrand.no (Postfix) with ESMTP id 38A9A62251 for ; Fri, 6 Jun 2003 08:06:26 +0200 (CEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5BE176A903; Fri, 6 Jun 2003 09:06:24 +0300 (EEST) Message-ID: <3EE02A07.1050901@piuha.net> Date: Fri, 06 Jun 2003 08:43:35 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Hinden References: <3EDDA77F.8050700@piuha.net> <3EDDA77F.8050700@piuha.net> <4.3.2.7.2.20030605173528.0346cef8@mailhost.iprg.nokia.com> In-Reply-To: <4.3.2.7.2.20030605173528.0346cef8@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Dave Crocker Cc: problem-statement@alvestrand.no Subject: Re: Discipline of Internet Protocol Engineering X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jari.arkko@piuha.net 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 Bob Hinden wrote: >> Egad. As you note, this starts sounding like classic project management. >> >> What a thought. > > Worse still, we might even want people in the IESG with some real > management experience. And even worse, we might have to start tracking how much "resources" (that means you and me) we have for our projects, and figuring out how "big" the projects are. --Jari From problem-statement-bounces@alvestrand.no Fri Jun 6 02:07:10 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07112 for ; Fri, 6 Jun 2003 02:07:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5DBE5625BE; Fri, 6 Jun 2003 08:06:29 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3FAF4625A5 for ; Fri, 6 Jun 2003 08:06:26 +0200 (CEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 22A686A906; Fri, 6 Jun 2003 09:06:25 +0300 (EEST) Message-ID: <3EE02D2C.9040009@piuha.net> Date: Fri, 06 Jun 2003 08:57:00 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Hinden References: <4.3.2.7.2.20030605172112.0309fe00@mailhost.iprg.nokia.com> In-Reply-To: <4.3.2.7.2.20030605172112.0309fe00@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jari.arkko@piuha.net 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 Bob Hinden wrote: >> The more-core problem is industry running on protocols with design >> flaws and protocol bugs, which cannot be fixed because of the >> installed base. >> >> If PS was perfect, this would not be a serious problem. But it isn't so. > > > First versions of anything are never perfect. This is true for products > and standards. As long as we try to solve the problem by trying to make > the first version perfect we will fail. It only delays the first > version and causes it to miss the market need. The only solution I know > of is to do new versions. This seems to work well in industry. > > Perfection doesn't work. Shipping products and getting bug reports works. Agree 100%. Waterfall development vs. incremental development. Serious debates early on in the project how all possible features "must" be supported. Claims that engineers would not make the mistakes they usually do, if they had just done more "planning" or "design". Introduction of reviews, so that more problems can be caught. Claims that the product we are making is soooo important that we can not possibly have any bugs or missing features in it. In the end, key success factors for the project are missed, because no one bothered to try out how the thing would work out in real usage. Or competition is on its improvement cycle 17 when your first buggy release comes out. Or you run out of money. Finally, the management blames the engineers for bad quality. I've been there in the distant past, but I know better now. But I'm alarmed that the above sounds very much like the discussions we're having here. A few observations on what this might mean for the IETF: - It really is essential to get real usage, not just more reviews or interop tests. So *some* amount of industry adoption early on is required. - Having to "fix" a standard (e.g. deprecate site-locals) is not a sign of bad early specifications, its a sign of being able to learn and adopt. - While we normally don't like to compromise on things like quality, security, scalability, we have to learn to do things in pieces better. And when we are already doing things in small pieces, we need to have a better view of the full architecture/roadmap early on. - This doesn't necessarily mean that we have to put out more PS RFCs with a lower quality. We could keep ahead of the industry's exaggeration of PS status value by introducing a new document level lower in chain. --Jari From problem-statement-bounces@alvestrand.no Fri Jun 6 02:09:00 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09013 for ; Fri, 6 Jun 2003 02:08:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2209C625A5; Fri, 6 Jun 2003 08:08:29 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from netcore.fi (netcore.fi [193.94.160.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8FEA262251; Fri, 6 Jun 2003 08:08:17 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h5668Dg08041; Fri, 6 Jun 2003 09:08:13 +0300 Date: Fri, 6 Jun 2003 09:08:12 +0300 (EEST) From: Pekka Savola To: Bob Hinden In-Reply-To: <4.3.2.7.2.20030605172112.0309fe00@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: john.loughney@nokia.com Cc: Harald Tveit Alvestrand Cc: problem-statement@alvestrand.no Subject: Re: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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, 5 Jun 2003, Bob Hinden wrote: > >The more-core problem is industry running on protocols with design flaws > >and protocol bugs, which cannot be fixed because of the installed base. > > > >If PS was perfect, this would not be a serious problem. But it isn't so. > > First versions of anything are never perfect. This is true for products > and standards. As long as we try to solve the problem by trying to make > the first version perfect we will fail. It only delays the first version > and causes it to miss the market need. The only solution I know of is to > do new versions. This seems to work well in industry. > > Perfection doesn't work. Shipping products and getting bug reports works. I partially disagree. It's often too challenging to later change fundamental design decisions made early on: just shipping a spec with a thought like "we'll fix the issues later" seems like a recipe for disaster. Naturally, when updating the documents some features are ripped off, some clarifications added etc., but this *typically* cannot influence the basic way specs work. And therefore, the core things in specs must be in very good shape. In consequence, "security will be described in other documents" or "deployment will be considered in other documents" doesn't sound like a good idea. These can often hide some very nasty surprises which affect your design decisions on the core spec. -- 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 Jun 6 02:25:25 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11828 for ; Fri, 6 Jun 2003 02:25:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 44B286256B; Fri, 6 Jun 2003 08:24:54 +0200 (CEST) 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 A73BD62251 for ; Fri, 6 Jun 2003 08:24:52 +0200 (CEST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])h566OqD23852 for ; Fri, 6 Jun 2003 09:24:52 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com ; Fri, 6 Jun 2003 09:24:51 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 09:24:51 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 09:24:51 +0300 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" Date: Fri, 6 Jun 2003 09:24:50 +0300 Message-ID: Thread-Topic: pausable explanation for the Document Series Thread-Index: AcMr8hLJnpgq+U6dQxCYpNkDtIr9sAAAfVwA From: To: X-OriginalArrivalTime: 06 Jun 2003 06:24:51.0481 (UTC) FILETIME=[5634A090:01C32BF4] Cc: problem-statement@alvestrand.no Subject: RE: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA11828 Hi Pekka, > I partially disagree. It's often too challenging to later change > fundamental design decisions made early on: just shipping a spec with a > thought like "we'll fix the issues later" seems like a recipe for > disaster. > > Naturally, when updating the documents some features are ripped off, some > clarifications added etc., but this *typically* cannot influence the basic > way specs work. And therefore, the core things in specs must > be in very good shape. > > In consequence, "security will be described in other documents" or > "deployment will be considered in other documents" doesn't sound like a > good idea. These can often hide some very nasty surprises which affect > your design decisions on the core spec. Of course the core of any protocol developed in the IETF should be extremely stable even at the PS level. However, if how can you get deployment concerns for many protocols that are not yet PS? There is a big chicken & egg problem here. For protocol work, we should have a tight scope on what is contained in the draft (& later PS). John From problem-statement-bounces@alvestrand.no Fri Jun 6 02:30:40 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11942 for ; Fri, 6 Jun 2003 02:30:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 63AD86256B; Fri, 6 Jun 2003 08:30:09 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from netcore.fi (netcore.fi [193.94.160.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DBA8E62251 for ; Fri, 6 Jun 2003 08:30:06 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h566U5p08195; Fri, 6 Jun 2003 09:30:05 +0300 Date: Fri, 6 Jun 2003 09:30:05 +0300 (EEST) From: Pekka Savola To: john.loughney@nokia.com In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: problem-statement@alvestrand.no Subject: RE: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Fri, 6 Jun 2003 john.loughney@nokia.com wrote: > > I partially disagree. It's often too challenging to later change > > fundamental design decisions made early on: just shipping a spec with a > > thought like "we'll fix the issues later" seems like a recipe for > > disaster. > > > > Naturally, when updating the documents some features are ripped off, some > > clarifications added etc., but this *typically* cannot influence the basic > > way specs work. And therefore, the core things in specs must > > be in very good shape. > > > > In consequence, "security will be described in other documents" or > > "deployment will be considered in other documents" doesn't sound like a > > good idea. These can often hide some very nasty surprises which affect > > your design decisions on the core spec. > > Of course the core of any protocol developed in the IETF should be > extremely stable even at the PS level. However, if how can you > get deployment concerns for many protocols that are not yet PS? There > is a big chicken & egg problem here. For protocol work, we should > have a tight scope on what is contained in the draft (& later PS). In real world, people implement the protocols for pilot/test purposes in any case. This can be done when the I-D has reached reasonable level of stability. Of course, we could try to add some "experimental" category below PS, to try to document these pilot protocols -- but this is slightly problematic also, as we have to make sure people understand that if protocol is modified for PS, no backward-compatibility must be required.. -- 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 Jun 6 02:48:17 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12210 for ; Fri, 6 Jun 2003 02:48:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 66C026256B; Fri, 6 Jun 2003 08:47:45 +0200 (CEST) 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 5838B62251 for ; Fri, 6 Jun 2003 08:47:42 +0200 (CEST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])h566lfD16369 for ; Fri, 6 Jun 2003 09:47:41 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com ; Fri, 6 Jun 2003 09:47:41 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 09:47:41 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 09:47:40 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 09:47:39 +0300 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" Date: Fri, 6 Jun 2003 09:47:38 +0300 Message-ID: Thread-Topic: pausable explanation for the Document Series Thread-Index: AcMr9RQxElSsWWRDQ1OSwqf96C1cGwAAiTZw From: To: X-OriginalArrivalTime: 06 Jun 2003 06:47:40.0060 (UTC) FILETIME=[85F135C0:01C32BF7] Cc: problem-statement@alvestrand.no Subject: RE: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA12210 Hi Pekka, > In real world, people implement the protocols for pilot/test purposes in > any case. This can be done when the I-D has reached reasonable level of > stability. Except when the IETF is not timely. In a number of cases, people fail to update implementations to protocols that are long lived because they prefer to wait until the protocol is nearly complete. I have this comment from many people (from different organizations) for a number of protocols such as MIPv6 and Diameter, for example. Without making much effort, I could find a bunch of other examples. John From problem-statement-bounces@alvestrand.no Fri Jun 6 03:07:52 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12553 for ; Fri, 6 Jun 2003 03:07:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6E223625A5; Fri, 6 Jun 2003 09:07:19 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0989E62251; Fri, 6 Jun 2003 09:07:16 +0200 (CEST) Date: Fri, 06 Jun 2003 09:07:16 +0200 From: Harald Tveit Alvestrand To: Pekka Savola , john.loughney@nokia.com Message-ID: <27020000.1054883235@askvoll.hjemme.alvestrand.no> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) 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: Documenting pilots (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 fredag, juni 06, 2003 09:30:05 +0300 Pekka Savola wrote: > In real world, people implement the protocols for pilot/test purposes in > any case. This can be done when the I-D has reached reasonable level of > stability. > > Of course, we could try to add some "experimental" category below PS, to > try to document these pilot protocols -- but this is slightly problematic > also, as we have to make sure people understand that if protocol is > modified for PS, no backward-compatibility must be required.. two examples of trying exactly that approach.... RFC 2362 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. June 1998. (Format: TXT=159833 bytes) (Obsoletes RFC2117) (Status: EXPERIMENTAL) RFC 3208 PGM Reliable Transport Protocol Specification. T. Speakman, J. Crowcroft, J. Gemmell, D. Farinacci, S. Lin, D. Leshchiner, M. Luby, T. Montgomery, L. Rizzo, A. Tweedly, N. Bhaskar, R. Edmonstone, R. Sumanasekera, L. Vicisano. December 2001. (Format: TXT=244637 bytes) (Status: EXPERIMENTAL) I think the general idea seems attractive, but Real Life has twisted our expectations at least in the case of PIM-SM, and I have heard rumblings about the same thing wrt PGM - that "the RFC is out there, and works for the 95% case I need" has taken a great deal of interest away from working on other possible solutions - or even pushing the thing onto the standards track at all. It's possible that "permanently archived I-D copy" would do better. Then again, maybe not. Of course, I'm not an expert in either field, so if I have to hurriedly retract my reading of the situation when the real experts chime in, I apologize in advance..... Harald From problem-statement-bounces@alvestrand.no Fri Jun 6 03:08:14 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12581 for ; Fri, 6 Jun 2003 03:08:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 139346256B; Fri, 6 Jun 2003 09:07:44 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from netcore.fi (netcore.fi [193.94.160.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9F1C162251 for ; Fri, 6 Jun 2003 09:07:38 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h5677aM08431; Fri, 6 Jun 2003 10:07:36 +0300 Date: Fri, 6 Jun 2003 10:07:36 +0300 (EEST) From: Pekka Savola To: john.loughney@nokia.com In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: problem-statement@alvestrand.no Subject: RE: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Fri, 6 Jun 2003 john.loughney@nokia.com wrote: > > In real world, people implement the protocols for pilot/test purposes in > > any case. This can be done when the I-D has reached reasonable level of > > stability. > > Except when the IETF is not timely. Uhh.. > In a number of cases, people fail > to update implementations to protocols that are long lived because > they prefer to wait until the protocol is nearly complete. I have this > comment from many people (from different organizations) for a number > of protocols such as MIPv6 and Diameter, for example. Without making much > effort, I could find a bunch of other examples. There are a few issues here: 1) I don't know what you see as a problem here: IETF not finishing the spec quickly, or people failing to test it in a timely fashion? 2) you use the word "update", implying that implementation experience is updated only a couple of times during the spec cycle; IMHO, if people have already -once- tested an implementation and provided feedback, I think that's already a very good success. A problem of course comes when there are major changes in the protocol and you'd want folks to test it again and again provide feedback. IMO, 2) should only be a problem when the document is deemed "ready" prematurely (and implemented), but is later pushed back and completely redesigned (e.g. MIPv6). But this is an issue *already* that needs some serious attention, ie. preventing people from declaring protocol "ready" when it isn't (by e.g. cross-area reviews etc.). -- 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 Jun 6 07:50:49 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18528 for ; Fri, 6 Jun 2003 07:50:48 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 16C836256B; Fri, 6 Jun 2003 13:50:17 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by eikenes.alvestrand.no (Postfix) with ESMTP id EF2BE622BB for ; Fri, 6 Jun 2003 13:50:09 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180])h56BnxbJ020862 for ; Fri, 6 Jun 2003 13:50:01 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h56BnxBP170640 for ; Fri, 6 Jun 2003 13:49:59 +0200 Received: from dhcp22-128.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA38766 from ; Fri, 6 Jun 2003 13:49:57 +0200 Message-Id: <3EE07FFE.32A07F4A@hursley.ibm.com> Date: Fri, 06 Jun 2003 13:50:22 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: problem-statement@alvestrand.no References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 john.loughney@nokia.com wrote: > > Hi Charles, > > > I also wholeheartedly support the inclusion of an applicability > > statement whenever it makes sense. However, I also suggest that > > the protocol SHOULD (within engineering discretion) not intentionally > > restrict its applcability to the situations delineated in the > > applicability statement. > > > > I would restate Postel's maxim: > > > > Be conservative in the claimed applicability, but generous > > in the potential applicability. > > What I am concerned about is there seems to be a movement to > make a super-PS, one which would be the equavalent of a DS > & have no bugs. I am not sure of the feasibility of this, > but I have noticed that simple protocol documents are getting > overloaded with a lot of applicability info, deployment concerns, > best practices and implementation guides. Somehow, I think > overloading a single document with this info, is not a > reciepe for success. In any case, since we don't actually use the complexity we already have (3 grades of standard), the need is clearly to *simplify* the document scheme, not to complicate it. My thinking is getting more radical the longer this discussion continues. Let's think seriously about Problem: the 3 step standards track is largely fictional and possible solutions along the lines of Solution: let's scrap it and have all "standards" RFCs as a single level (with recycling in grade for corrections/updates). Brian From problem-statement-bounces@alvestrand.no Fri Jun 6 08:08:58 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19011 for ; Fri, 6 Jun 2003 08:08:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 344EA625BD; Fri, 6 Jun 2003 14:08:27 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by eikenes.alvestrand.no (Postfix) with ESMTP id F3FE26256B for ; Fri, 6 Jun 2003 14:08:19 +0200 (CEST) Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h56C8Gpi008516 for ; Fri, 6 Jun 2003 08:08:17 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn3-66.cisco.com [10.21.64.66]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id IAA02724 for ; Fri, 6 Jun 2003 08:08:15 -0400 (EDT) Message-Id: <4.3.2.7.2.20030606075416.04354208@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Jun 2003 08:08:09 -0400 To: problem-statement@alvestrand.no From: Ralph Droms In-Reply-To: <3EE07FFE.32A07F4A@hursley.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Regarding Brian's call for radical thinking... Is the problem: the 3 step standards track is largely fictional the root problem or just a symptom? I think it's just a symptom of a mismatch among industry uses for IETF standards, WG processes and IESG goals. The current *usage* of the standards track effectively has a single hurdle at PS. I suggest we need to devise a process and set of hurdles that include some intermediate states that are not well-defined in the current usage of the standards track. One of the important states that is missing today is stable specification used for prototyping My recent experience with specifications in the dhc WG has been that "running (prototype) code" trumps (potentially ad infinitum) speculative discussion about whether the protocol is correct and completely specified. The design problem, of course, is devising the right document classifications and process to strike a balance among nimbleness (getting to a stable specification quickly), correctness and allowing for changes after the prototypes have been developed (avoiding the "we've deployed the prototype and now we can't change the protocol" problem)... - Ralph At 01:50 PM 6/6/2003 +0200, Brian E Carpenter wrote: >john.loughney@nokia.com wrote: >> >> Hi Charles, >> >> > I also wholeheartedly support the inclusion of an applicability >> > statement whenever it makes sense. However, I also suggest that >> > the protocol SHOULD (within engineering discretion) not intentionally >> > restrict its applcability to the situations delineated in the >> > applicability statement. >> > >> > I would restate Postel's maxim: >> > >> > Be conservative in the claimed applicability, but generous >> > in the potential applicability. >> >> What I am concerned about is there seems to be a movement to >> make a super-PS, one which would be the equavalent of a DS >> & have no bugs. I am not sure of the feasibility of this, >> but I have noticed that simple protocol documents are getting >> overloaded with a lot of applicability info, deployment concerns, >> best practices and implementation guides. Somehow, I think >> overloading a single document with this info, is not a >> reciepe for success. > >In any case, since we don't actually use the complexity we >already have (3 grades of standard), the need is clearly to >*simplify* the document scheme, not to complicate it. My thinking >is getting more radical the longer this discussion continues. Let's >think seriously about > > Problem: the 3 step standards track is largely fictional > >and possible solutions along the lines of > > Solution: let's scrap it and have all "standards" RFCs as a single level > (with recycling in grade for corrections/updates). > > Brian From problem-statement-bounces@alvestrand.no Fri Jun 6 08:19:51 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19278 for ; Fri, 6 Jun 2003 08:19:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AEFE06256B; Fri, 6 Jun 2003 14:19:20 +0200 (CEST) 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 54CF0622BB for ; Fri, 6 Jun 2003 14:19:14 +0200 (CEST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])h56CJDD06689 for ; Fri, 6 Jun 2003 15:19:13 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com ; Fri, 6 Jun 2003 15:19:13 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 15:19:12 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 15:19:11 +0300 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" Date: Fri, 6 Jun 2003 15:19:10 +0300 Message-ID: Thread-Topic: IETF mission (RE: pausable explanation for the Document Series) Thread-Index: AcMsIdHkGcdWaocmTNC977LuE2oqMgAA7jLQ From: To: , X-OriginalArrivalTime: 06 Jun 2003 12:19:11.0586 (UTC) FILETIME=[D6373420:01C32C25] Subject: RE: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA19278 Hi Brian, > In any case, since we don't actually use the complexity we > already have (3 grades of standard), the need is clearly to > *simplify* the document scheme, not to complicate it. My thinking > is getting more radical the longer this discussion continues. Let's > think seriously about > > Problem: the 3 step standards track is largely fictional > > and possible solutions along the lines of > > Solution: let's scrap it and have all "standards" RFCs as a single level > (with recycling in grade for corrections/updates). Actually, if we coupled this with Harald's "maintenance team" idea, it may actually work. I think we would need to have some 'object' that tracks bugs in a spec (hmm, issue tracking software might be nice) and the resolution, etc. A nice, simple interface that would pull all of this together could be really useful. John From problem-statement-bounces@alvestrand.no Fri Jun 6 08:33:40 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19815 for ; Fri, 6 Jun 2003 08:33:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2BF256256B; Fri, 6 Jun 2003 14:33:09 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mx-out.daemonmail.net (mx-out.daemonmail.net [216.104.160.39]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3CE0A6256B for ; Fri, 6 Jun 2003 14:32:50 +0200 (CEST) Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.9.3p2/8.9.3) with SMTP id FAA07310 for ; Fri, 6 Jun 2003 05:32:48 -0700 (PDT) (envelope-from spencer@mcsr-labs.org) Received: from (12.237.229.250 [12.237.229.250]) by mail.varaha.com with SMTP id nt10FuE0 Fri, 06 Jun 2003 05:32:48 -0700 (PDT) Message-ID: <03fb01c32c27$bf9d2740$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: Date: Fri, 6 Jun 2003 07:32:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Well, if full STDs were the rule, rather than the exception, we could be using multi-RFC STDs as the objects John is asking for - we know how to group RFCs 791 and 792 as STD 5, for instance. When we have a STD, we have an object that could also hold bug reports, implementation guidance, etc. If Brian's "one-shot standard" proposal plus Harald's maintenance team proposal gave us STDs as the common case, this would be routine. Spencer ----- Original Message ----- From: To: ; Sent: Friday, June 06, 2003 7:19 AM Subject: RE: IETF mission (RE: pausable explanation for the Document Series) Hi Brian, > In any case, since we don't actually use the complexity we > already have (3 grades of standard), the need is clearly to > *simplify* the document scheme, not to complicate it. My thinking > is getting more radical the longer this discussion continues. Let's > think seriously about > > Problem: the 3 step standards track is largely fictional > > and possible solutions along the lines of > > Solution: let's scrap it and have all "standards" RFCs as a single level > (with recycling in grade for corrections/updates). Actually, if we coupled this with Harald's "maintenance team" idea, it may actually work. I think we would need to have some 'object' that tracks bugs in a spec (hmm, issue tracking software might be nice) and the resolution, etc. A nice, simple interface that would pull all of this together could be really useful. John From problem-statement-bounces@alvestrand.no Fri Jun 6 08:52:16 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21456 for ; Fri, 6 Jun 2003 08:52:15 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7478D6256B; Fri, 6 Jun 2003 14:51:44 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.wrs.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0DE90622BB for ; Fri, 6 Jun 2003 14:51:33 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.26]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA06727 for ; Fri, 6 Jun 2003 05:51:06 -0700 (PDT) Message-Id: <5.1.0.14.2.20030606084042.04731d28@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 06 Jun 2003 08:45:48 -0400 To: problem-statement@alvestrand.no From: Margaret Wasserman In-Reply-To: <27020000.1054883235@askvoll.hjemme.alvestrand.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Staying on Track (Re: Documenting pilots (RE: pausable explanation for the Document Series)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 hate to do this, but... Not that I have any official authority to say this, but... At this point, this mailing list is almost exclusively discussing solutions to problems, and refinements to those solutions. I, too, find it more fun and constructive to discuss solutions, but this WG is only chartered to produce: 1 - A problem statement 2 - Recommendations for a process to solve the problems. Are people happy enough with those documents that we're ready to publish them and move on? If so, let's do that. If not, please send feedback on the documents to this list, and keep solutions discussions on the solutions mailing list. Thanks, Margaret From problem-statement-bounces@alvestrand.no Fri Jun 6 09:04:13 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22045 for ; Fri, 6 Jun 2003 09:04:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 48E616256B; Fri, 6 Jun 2003 15:03:42 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 02F12622BB for ; Fri, 6 Jun 2003 15:03:32 +0200 (CEST) Date: Fri, 06 Jun 2003 15:03:32 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <74750000.1054904612@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ISSUE: Goal of problem-statement document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 have (finally!) gotten around to reading through the problem-statement document again in detail, and jotting down my various concerns with it. I think the document is a huge step in a reasonable direction - but I would just not be human if I did not have issues with it :-) I've written up the lot of my current concerns (these may change over time), and put them up on the Web at http://www.alvestrand.no/ietf/problems-01-comments.html (for those who can't wait), but I thought I'd be less brutal to the list than dumping all of them in one big batch would be, and raise only a few issues per day.... also, that way it's easier for the tracking system to track the issues independent of each other; I definitely don't expect the group to come to consensus on my opinion every time! First issue: Goal statement for the document - I think it's wrong. Section 1.3 of the document: We, in line with many contributors to the mailing list, do not believe that the process of problem resolution will be helped by continued rework of the root issues in what would probably be a vain attempt to achieve any sort of consensus. Instead, the general tenor and scope of the problems identified will provide a guide in setting up the processes needed to resolve the problems and provide input to the resolvers. ISSUE: The normal understanding of "understanding problems" says that if you start fixing problems that don't exist, you will not be happy with the result. Going forward with the resolution process of this paragraph thus appears to be either exceedingly dangerous or belittling the purpose of the document - one rational conclusion to take is that the authors do not believe that the problem document will provide significant guidance to the solution process, and therefore it does not matter whether it's right or wrong. SUGGESTED RESOLUTION: Change this section to say that the document attempts to be a basis for consensus on the root causes. The perceptions of problems may be less important in the guidance for resolution, so having multiple views on what symptoms the problems cause is probably less problematic. [Don't worry - there'll be specific input later!] From problem-statement-bounces@alvestrand.no Fri Jun 6 09:25:18 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22534 for ; Fri, 6 Jun 2003 09:25:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4E2CF6256B; Fri, 6 Jun 2003 15:24:47 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6DDBD622BB for ; Fri, 6 Jun 2003 15:24:39 +0200 (CEST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h56DObms012139; Fri, 6 Jun 2003 06:24:37 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIB70919; Fri, 6 Jun 2003 06:24:36 -0700 (PDT) Message-Id: <200306061324.AIB70919@mira-sjc5-c.cisco.com> To: Margaret Wasserman From: Melinda Shore In-Reply-To: Message from mrw@windriver.com <5.1.0.14.2.20030606084042.04731d28@mail.windriver.com> Date: Fri, 06 Jun 2003 09:24:36 -0400 Cc: problem-statement@alvestrand.no Subject: Re: Staying on Track (Re: Documenting pilots (RE: pausable explanation for the Document Series)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > Are people happy enough with those documents that we're > ready to publish them and move on? If so, let's do > that. If not, please send feedback on the documents to > this list, and keep solutions discussions on the solutions > mailing list. I'm also very concerned about keeping the documents moving forward, but I do think that the notion of what we need to do about short-term solution efforts that would be hampered by the overhead associated with working group creation do need to be addressed and I think some interesting ideas have been popping out of the discussion. One of the problems with the discussion, however, is that we still don't have a way to accommodate ad-hoc, short-lived, individual voluntary, or what-have-you efforts, and that does need to be dealt with. Personally (i.e. not as chair) I'm not crazy about things like what's going on with the SIRS proposal (going off and collecting volunteers without real agreement from the cohort that this is a good thing to do) because it feels pre-emptive and unco-operative, but on the other hand given our decision-making structure I'm not sure what the alternatives are if anything is going to happen in real time. If anybody has wisdom about how to do short-term efforts within the IETF, this would be an excellent time to discuss it. Melinda From problem-statement-bounces@alvestrand.no Fri Jun 6 09:47:41 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23396 for ; Fri, 6 Jun 2003 09:47:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3CB236256B; Fri, 6 Jun 2003 15:47:11 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from albatross.mail.pas.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by eikenes.alvestrand.no (Postfix) with ESMTP id 744D2622BB for ; Fri, 6 Jun 2003 15:47:09 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19OHYY-0000km-00; Fri, 06 Jun 2003 06:46:59 -0700 Date: Fri, 6 Jun 2003 09:44:50 -0400 From: Keith Moore To: Message-Id: <20030606094450.458c765f.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Subject: Re: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > What I am concerned about is there seems to be a movement to > make a super-PS, one which would be the equavalent of a DS > & have no bugs. I haven't seen any evidence of such a movement, and that's certainly not what I've proposed. Surely nobody thinks it's feasible to get rid of all bugs. What I've proposed is that we need to figure out what the criteria should be for "ready for deployment", and that these are probably slightly higher than those currently in place for PS (but IMHO lower than those required for DS). "ready for deployment" doesn't mean "bug-free", but it does seem to imply a certain amount of diligence in looking for bugs, and at least minimal implementation and testing. > I have noticed that simple protocol documents are getting overloaded with a > lot of applicability info, deployment concerns, best practices, and > implementation guides. I think you exaggerate when you say "overloaded". But these most certainly do belong in a protocol standard, and there's some experience that says that they're more likely to be ignored if placed in a separate document. (though it might help if our document numbering scheme made it easier to find related documents.) Keith From problem-statement-bounces@alvestrand.no Fri Jun 6 09:51:07 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23507 for ; Fri, 6 Jun 2003 09:51:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DE9D66256B; Fri, 6 Jun 2003 15:50:36 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by eikenes.alvestrand.no (Postfix) with ESMTP id DEF36622BB for ; Fri, 6 Jun 2003 15:50:33 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19OHbu-000796-00; Fri, 06 Jun 2003 06:50:26 -0700 Date: Fri, 6 Jun 2003 09:48:20 -0400 From: Keith Moore To: jari.arkko@piuha.net Message-Id: <20030606094820.59a7f558.moore@cs.utk.edu> In-Reply-To: <3EE02D2C.9040009@piuha.net> References: <4.3.2.7.2.20030605172112.0309fe00@mailhost.iprg.nokia.com> <3EE02D2C.9040009@piuha.net> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: hinden@IPRG.nokia.com Cc: moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: Re: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > > Perfection doesn't work. Shipping products and getting bug reports works. > > Agree 100%. Disagree 100%. It costs much more to fix bugs after shipping product than it does to do so beforehand. Forcing customers to accept the costs of poor protocol design is just irresponsible. From problem-statement-bounces@alvestrand.no Fri Jun 6 09:55:40 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23672 for ; Fri, 6 Jun 2003 09:55:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BA325625C9; Fri, 6 Jun 2003 15:55:08 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1F8D4622BB for ; Fri, 6 Jun 2003 15:55:06 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19OHgO-000FlY-00; Fri, 06 Jun 2003 08:55:04 -0500 Date: Fri, 06 Jun 2003 09:55:03 -0400 From: John C Klensin To: Brian E Carpenter , "problem-statement@alvestrand.no" Message-ID: <123738085.1054893303@p3.JCK.COM> In-Reply-To: <3EDDEF48.7ED1CC09@hursley.ibm.com> References: <3EDDEF48.7ED1CC09@hursley.ibm.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Sloppy Charters (was: Re: Discipline of Internet Protocol Engineering) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Wednesday, 04 June, 2003 15:08 +0200 Brian E Carpenter wrote: > Indeed, scope and non-goals need to be in there too. > > The most useful section of diffserv's charter, from the > viewpoint of discussion management, was the part starting: > "The group will not work on: " > > I've always regarded the vetting of WG charters as the most > important single thing that the IAB and IESG do. A good > charter is the most effective tool an AD or WG Chair can have > to maintain forward progress. > > So, "sloppy charters" needs to be on the problem list. Brian, While I fully agree, I think that, in this area and several others, we've set up the wrong incentive structure. When we have tight charters, they are often, perhaps typically, not enforced. When an AD enforces one --with regard to benchmarks, scope, or procedure-- he or she usually becomes _really_ unpopular with the membership of the relevant WG... and most of the rest of the community, at best, ignores the action. Often, we end up with sloppy charters because some group insists, very loudly, that _something_ must be done, and done quickly, because of perceived market or timing pressures. ADs who try to resist those pressures are criticized as unresponsive and foot-dragging, and, in general, no one comes to their defense. We've had proposals whose effect would be to attach real costs to sloppy charters and drifting WGs. While both of the recent ones --PACT and the "WG ceiling" draft-- have their own serious limitations and problems, they were not even discussed and explored seriously (e.g., to look at the problems and figure out how to work around them), presumably because people in the community don't, in the last analysis, really want those constraints on _their_ WGs, regardless of how they might feel about those of others. I'd like to see if, in Vienna and thereafter, we can get ADs to report on the draft charters they have turned down, or forced into major revisions, because they were sloppy and on the WGs they have efficiently shut down for drifting off-charter (or just plain drifting). And then I think we should loudly cheer those ADs. This is of a piece with part of "WGs produce poor-quality work". Ultimately, poor quality work comes out because the community tolerates poor quality work. The AD, or advisor, or random WG participant, who pushes back (either when things are under way or "late") is routinely reviled for holding things up, causing delays, being opposed to the principle on which the work is based, etc. At plenaries, on mailing lists and, when nomcom time comes around, in whispering campaigns, we hear complaints about someone who has "caused" a delay; we don't hear complaints about those who quietly let garbage go through. That situation requires a careful balance, but, whatever that balance is, we clearly haven't found it: the community's position _in practice_ is pretty clear. As an aside, if we do not somehow change this manifest community attitude, it will eventually kill SIRS too. I'd predict that it would work well for a while --almost any "change", "improvement", or "new method" does-- but that, eventually, we will find reviewers who push back on poor quality being abused for holding things up that represent clear WG consensus... and getting no support for trying to enforce quality. Some of the good ones will decide that they didn't sign up for the abuse and drop out, others will start adopting a more relaxed attitude and letting things go through... just as many ADs have done. I suggest that much of the problem here is that, in Pogo's immortal words, "we have met the enemy and they are us". And we had better figure out how to turn that around. john From problem-statement-bounces@alvestrand.no Fri Jun 6 10:06:22 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24402 for ; Fri, 6 Jun 2003 10:06:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 284316256B; Fri, 6 Jun 2003 16:05:52 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7B694622BB for ; Fri, 6 Jun 2003 16:05:44 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19OHqY-0001CT-00; Fri, 06 Jun 2003 07:05:34 -0700 Date: Fri, 6 Jun 2003 10:03:28 -0400 From: Keith Moore To: Message-Id: <20030606100328.7ab1e3b1.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Cc: pekkas@netcore.fi Subject: Re: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > For protocol work, we should > have a tight scope on what is contained in the draft (& later PS). tight scope is good, but there's a limit. We tried to keep tight scope in MIME, and in so doing, we failed to recognize some of MIME's limitations until it was too late to change it. I think it's useful to limit the scope of a core protocol spec and to make it extensible, but it's also useful to at least map out how you expect likely extensions to work, and even to try a few of them - just don't put them into the base spec. From problem-statement-bounces@alvestrand.no Fri Jun 6 10:09:31 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24754 for ; Fri, 6 Jun 2003 10:09:30 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B8349625CB; Fri, 6 Jun 2003 16:08:59 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by eikenes.alvestrand.no (Postfix) with ESMTP id 32808625CB for ; Fri, 6 Jun 2003 16:08:55 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19OHtj-0005Yi-00; Fri, 06 Jun 2003 07:08:51 -0700 Date: Fri, 6 Jun 2003 10:06:46 -0400 From: Keith Moore To: Brian E Carpenter Message-Id: <20030606100646.5984619b.moore@cs.utk.edu> In-Reply-To: <3EE07FFE.32A07F4A@hursley.ibm.com> References: <3EE07FFE.32A07F4A@hursley.ibm.com> X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Subject: Re: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > In any case, since we don't actually use the complexity we > already have (3 grades of standard), the need is clearly to > *simplify* the document scheme, not to complicate it. the need is clearly to change the set of maturity levels. whether this results in fewer levels is not yet clear. From problem-statement-bounces@alvestrand.no Fri Jun 6 10:15:09 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25388 for ; Fri, 6 Jun 2003 10:15:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CAADA6256B; Fri, 6 Jun 2003 16:14:37 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5E79F622BB for ; Fri, 6 Jun 2003 16:14:29 +0200 (CEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA14010; Fri, 6 Jun 2003 07:14:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h56EESU14292; Fri, 6 Jun 2003 07:14:28 -0700 X-mProtect: <200306061414> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6xw9JN; Fri, 06 Jun 2003 07:14:26 PDT Message-ID: <3EE0A1D8.7060306@iprg.nokia.com> Date: Fri, 06 Jun 2003 07:14:48 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore References: <4.3.2.7.2.20030605172112.0309fe00@mailhost.iprg.nokia.com> <3EE02D2C.9040009@piuha.net> <20030606094820.59a7f558.m Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hello Keith, Keith Moore wrote: >>>Perfection doesn't work. Shipping products and getting bug reports works. >>> >>> >>Agree 100%. >> >> > >Disagree 100%. It costs much more to fix bugs after shipping product than it >does to do so beforehand. Forcing customers to accept the costs of poor >protocol design is just irresponsible. > > You seem to assume that the customers are going to sit around waiting. Most will buy a system that works, and the perfect product will, after a three year delay, be a footnote in history. And that's where recent IETF protocol efforts may be heading. I agree with Bob and Jari. Regards, Charlie P. From problem-statement-bounces@alvestrand.no Fri Jun 6 10:17:14 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25589 for ; Fri, 6 Jun 2003 10:17:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 143DD6256B; Fri, 6 Jun 2003 16:16:44 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mallard.mail.pas.earthlink.net (mallard.mail.pas.earthlink.net [207.217.120.48]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7199B622BB for ; Fri, 6 Jun 2003 16:16:41 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19OI1E-00017Z-00; Fri, 06 Jun 2003 07:16:36 -0700 Date: Fri, 6 Jun 2003 10:14:30 -0400 From: Keith Moore To: Ralph Droms Message-Id: <20030606101430.2bfaeac0.moore@cs.utk.edu> In-Reply-To: <4.3.2.7.2.20030606075416.04354208@funnel.cisco.com> References: <4.3.2.7.2.20030606075416.04354208@funnel.cisco.com> X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Subject: Re: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 of the important states that is missing today is > > stable specification used for prototyping agree, though you might qualify "stable" to mean "during the prototyping period". it can be extremely useful to prototype subsets of a protocol even though those subsets are not complete enough to ship. and what's the point of prototyping if not to allow for the possibility of changing something? (but since this is the problem statement working group, isn't it enough to say for now that there's a mismatch between our document maturity levels and both industry expectation and IETF energies?) From problem-statement-bounces@alvestrand.no Fri Jun 6 10:20:04 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25699 for ; Fri, 6 Jun 2003 10:20:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C59926256B; Fri, 6 Jun 2003 16:19:33 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by eikenes.alvestrand.no (Postfix) with ESMTP id AC636622BB for ; Fri, 6 Jun 2003 16:19:30 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19OI3z-0000oJ-00; Fri, 06 Jun 2003 07:19:27 -0700 Date: Fri, 6 Jun 2003 10:17:19 -0400 From: Keith Moore To: Spencer Dawkins Message-Id: <20030606101719.08cb6f7a.moore@cs.utk.edu> In-Reply-To: <03fb01c32c27$bf9d2740$0200a8c0@DFNJGL21> References: <03fb01c32c27$bf9d2740$0200a8c0@DFNJGL21> X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Subject: Re: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > If Brian's "one-shot standard" proposal plus Harald's > maintenance team proposal gave us STDs as the > common case, this would be routine. You know, every time I see "STD" in this discussion my mind immediately substitutes "sexually transmitted diseases". It's hard to think favorably about a proposal that "gives" us those. From problem-statement-bounces@alvestrand.no Fri Jun 6 10:31:03 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26004 for ; Fri, 6 Jun 2003 10:31:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 234A16256B; Fri, 6 Jun 2003 16:30:33 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 66D41622BB for ; Fri, 6 Jun 2003 16:30:24 +0200 (CEST) Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h56EULLU027771 for ; Fri, 6 Jun 2003 10:30:22 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn3-66.cisco.com [10.21.64.66]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id KAA11959 for ; Fri, 6 Jun 2003 10:30:20 -0400 (EDT) Message-Id: <4.3.2.7.2.20030606102530.0901cef0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Jun 2003 10:30:14 -0400 To: problem-statement@alvestrand.no From: Ralph Droms In-Reply-To: <20030606101430.2bfaeac0.moore@cs.utk.edu> References: <4.3.2.7.2.20030606075416.04354208@funnel.cisco.com> <4.3.2.7.2.20030606075416.04354208@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Regarding "problem statement" versus "proposed solution" ... I was careful to refer to a "missing state" rather than a missing maturity level or process. The problem is that we need a way to do prototyping, requiring some stable-during-the-prototyping document, that does not then result in deployment of implementations of a buggy protocol. - Ralph At 10:14 AM 6/6/2003 -0400, Keith Moore wrote: >> One of the important states that is missing today is >> >> stable specification used for prototyping > >agree, though you might qualify "stable" to mean >"during the prototyping period". it can be extremely >useful to prototype subsets of a protocol even though >those subsets are not complete enough to ship. and >what's the point of prototyping if not to allow for >the possibility of changing something? > >(but since this is the problem statement working group, isn't >it enough to say for now that there's a mismatch between our >document maturity levels and both industry expectation and IETF >energies?) From problem-statement-bounces@alvestrand.no Fri Jun 6 10:32:57 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26073 for ; Fri, 6 Jun 2003 10:32:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 685AC625D0; Fri, 6 Jun 2003 16:32:26 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9F002622BB for ; Fri, 6 Jun 2003 16:32:23 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19OIGM-0003pj-00; Fri, 06 Jun 2003 07:32:15 -0700 Date: Fri, 6 Jun 2003 10:30:08 -0400 From: Keith Moore To: Charlie Perkins Message-Id: <20030606103008.476f235f.moore@cs.utk.edu> In-Reply-To: <3EE0A1D8.7060306@iprg.nokia.com> References: <4.3.2.7.2.20030605172112.0309fe00@mailhost.iprg.nokia.com> <3EE02D2C.9040009@piuha.net> <3EE0A1D8.7060306@iprg.nokia.com> X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Subject: Re: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > You seem to assume that the customers are going to sit around waiting. > > Most will buy a system that works, most will buy a system without knowing whether it works or not, and pull their hair out when they have trouble getting it to work in practice, and then guess about who is to blame, and make arbitrary demands about who has to fix it that have nothing to do with the actual cause of the problem. > And that's where recent IETF protocol efforts may be heading. NOBODY has said anything about requiring things to be perfect, so stop accusing people of that. What has been repeatedly suggested is that the criteria for maturity levels should be better matched with industry expectation and IETF energy levels. What's wrong with that? From problem-statement-bounces@alvestrand.no Fri Jun 6 10:47:37 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26696 for ; Fri, 6 Jun 2003 10:47:37 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 84744625D0; Fri, 6 Jun 2003 16:47:07 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0E33C622BB; Fri, 6 Jun 2003 16:47:05 +0200 (CEST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h56El2wc016751; Fri, 6 Jun 2003 07:47:03 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIB76139; Fri, 6 Jun 2003 07:47:01 -0700 (PDT) Message-Id: <200306061447.AIB76139@mira-sjc5-c.cisco.com> To: Harald Tveit Alvestrand From: Melinda Shore In-Reply-To: Message from harald@alvestrand.no <74750000.1054904612@askvoll.hjemme.alvestrand.no> Date: Fri, 06 Jun 2003 10:47:01 -0400 Cc: problem-statement@alvestrand.no Subject: Re: ISSUE: Goal of problem-statement document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > SUGGESTED RESOLUTION: Change this section to say that the > document attempts to be a basis for consensus on the root > causes. One of the things that's of concern here is an interest in trying to find ways to make progress in the absence of consensus about each identified problem, the dependency analysis, and a ranking. We absolutely do believe that the document will provide guidance, but it's reasonable to suspect that it's likely that the only way we'll be able to reach real consensus on some of it is if we dilute the discussion to the point it isn't useful. Melinda From problem-statement-bounces@alvestrand.no Fri Jun 6 10:52:31 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26841 for ; Fri, 6 Jun 2003 10:52:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 85B766256B; Fri, 6 Jun 2003 16:52:01 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id C83EB622BB for ; Fri, 6 Jun 2003 16:51:58 +0200 (CEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA15114; Fri, 6 Jun 2003 07:51:57 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h56EpvX08349; Fri, 6 Jun 2003 07:51:57 -0700 X-mProtect: <200306061451> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxlnRg7; Fri, 06 Jun 2003 07:51:54 PDT Message-ID: <3EE0AAA1.3000808@iprg.nokia.com> Date: Fri, 06 Jun 2003 07:52:17 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore References: <4.3.2.7.2.20030605172112.0309fe00@mailhost.iprg.nokia.com> <3EE02D2C.9040009@piuha.net> <3EE0A1D8.7060306@iprg.nok Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hello Keith, You're using nasty words like "accuse". Keith Moore wrote: >>You seem to assume that the customers are going to sit around waiting. >> >>Most will buy a system that works, >> >> > >most will buy a system without knowing whether it works or not, and pull their >hair out when they have trouble getting it to work in practice, and then guess >about who is to blame, and make arbitrary demands about who has to fix it that >have nothing to do with the actual cause of the problem. > Life sucks that way. It helps to buy from reputable vendors. Industrial product managers with a habit of success tend to do better than you portray. >>And that's where recent IETF protocol efforts may be heading. >> >> > >NOBODY has said anything about requiring things to be perfect, so stop >accusing people of that. What has been repeatedly suggested is that the criteria >for maturity levels should be better matched with industry expectation and >IETF energy levels. What's wrong with that? > But when you hear that industry has expectations about timeliness you seem to go nonlinear. Furthermore, I suggest that IETF processes demotivate and drain the energy of otherwise enthusiastic IETF engineers. Regards, Charlie P. From problem-statement-bounces@alvestrand.no Fri Jun 6 10:56:00 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27055 for ; Fri, 6 Jun 2003 10:56:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D6A45625D4; Fri, 6 Jun 2003 16:55:29 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 465D3622BB; Fri, 6 Jun 2003 16:55:23 +0200 (CEST) Date: Fri, 06 Jun 2003 16:55:23 +0200 From: Harald Tveit Alvestrand To: Melinda Shore Message-ID: <82680000.1054911323@askvoll.hjemme.alvestrand.no> In-Reply-To: <200306061447.AIB76139@mira-sjc5-c.cisco.com> References: <200306061447.AIB76139@mira-sjc5-c.cisco.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) 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: ISSUE: Goal of problem-statement document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 fredag, juni 06, 2003 10:47:01 -0400 Melinda Shore wrote: >> SUGGESTED RESOLUTION: Change this section to say that the >> document attempts to be a basis for consensus on the root >> causes. > > One of the things that's of concern here is an interest in > trying to find ways to make progress in the absence of > consensus about each identified problem, the dependency > analysis, and a ranking. We absolutely do believe that the > document will provide guidance, but it's reasonable to > suspect that it's likely that the only way we'll be able to > reach real consensus on some of it is if we dilute the > discussion to the point it isn't useful. I think we do have consensus on a fair number of points (including the "no explicit agreed mission", for instance) - I'd like to probe and try to refine some more of these points before declaring that this document is "as good as we can make it". We might quickly come to consensus about what we can't come to consensus on :-) From problem-statement-bounces@alvestrand.no Fri Jun 6 10:56:40 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27111 for ; Fri, 6 Jun 2003 10:56:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 685F1625DA; Fri, 6 Jun 2003 16:56:09 +0200 (CEST) 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 D3044622BB for ; Fri, 6 Jun 2003 16:56:04 +0200 (CEST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])h56Eu4D08494 for ; Fri, 6 Jun 2003 17:56:04 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com ; Fri, 6 Jun 2003 17:56:04 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 17:56:02 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 17:56:02 +0300 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" Date: Fri, 6 Jun 2003 17:56:02 +0300 Message-ID: Thread-Topic: Sloppy Charters (was: Re: Discipline of Internet Protocol Engineering) Thread-Index: AcMsM0R6eGHCvqrIT+6VNPk7hY0gaAACBa4g From: To: , X-OriginalArrivalTime: 06 Jun 2003 14:56:02.0511 (UTC) FILETIME=[BF9065F0:01C32C3B] Subject: RE: Sloppy Charters (was: Re: Discipline of Internet Protocol Engineering) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA27111 John, > While I fully agree, I think that, in this area and several > others, we've set up the wrong incentive structure. When we > have tight charters, they are often, perhaps typically, not > enforced. When an AD enforces one --with regard to benchmarks, > scope, or procedure-- he or she usually becomes _really_ > unpopular with the membership of the relevant WG... and most of > the rest of the community, at best, ignores the action. This sounds much more like a breakdown in the communication between the chair and the AD. If the chair is not able to organize the WG / charter correctly, so that the AD has to step in, I am not suprised that the WG revolts. Currently, the chair - AD communication seems to be suffering. I am not so sure how it is in other areas, but I sense that ADs are not giving sufficient technical direction to their WGs. I, for one, would be happy to have more discussions with the IESG on the future of my WG, in fact, I think I need more. John L. From problem-statement-bounces@alvestrand.no Fri Jun 6 10:58:59 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27242 for ; Fri, 6 Jun 2003 10:58:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3F24C625D4; Fri, 6 Jun 2003 16:58:17 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 24681622BB for ; Fri, 6 Jun 2003 16:58:04 +0200 (CEST) Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h56Ew1LU005957; Fri, 6 Jun 2003 10:58:01 -0400 (EDT) Message-Id: <200306061458.h56Ew1LU005957@rtp-core-1.cisco.com> To: Brian E Carpenter In-reply-to: Your message of Fri, 06 Jun 2003 13:50:22 +0200. <3EE07FFE.32A07F4A@hursley.ibm.com> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Fri, 06 Jun 2003 10:58:01 -0400 From: Eric Rosen Cc: problem-statement@alvestrand.no Subject: Re: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: erosen@cisco.com 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 Perhaps we need to understand better just what problem we are trying to solve by revising the categorization of standards. I'd make two observations: 1. Nobody cares whether the IETF says that a protocol is ready for deployment or not. Service providers, vendors, enterprises, etc., will decide this for themselves. By "nobody", I mean "nobody who is in a position to decide whether to do any large scale deployments". In the old world of the ITU-T people don't deploy until the standards process is finished, which leads to (a) bizarre standards and (b) slow progress. That may have been okay when telecom providers were monopolies, but it is not okay in the competitive environment of today. 2. People do care about whether the protocol has a public specification which is sufficiently detailed so as to enable interoperability among multiple independent implementations. However, they will not wait (nor should they) for such a specification before deployment. Based on these observations, there has arisen a significant constituency in the IETF (though not seen much on this list) which believes that the only proper function of the IETF is to publish specifications which are multi-vendor interoperable. Members of this constituency see no benefit at all for IESG review. Members of this constituency would also be overjoyed if all their specs could just get published as "Experimental" or "Informational", and once the specs get published, they have no interest in moving them further along in the process. Most people on this list seem to think that there is a value in having a category of "standard" which means something more than "multi-vendor interoperable." But I don't think there is a clear consensus on just what we want that to mean, and that's one of our big problems. Some possible considerations are: - correctly achieves the function which it is intended to achieve - adequately address scalability and security considerations in the intended scope of applicability - adequately (though not excessively) flexible - not a lot more complicated than it needs to be - can be reasonably defended against alternatives - specification is competently and professionally done - impact on other areas has been addressed - there exists significant interest in deploying this etc. To me, it makes sense to have a standards category which says that the specification is not merely adequate for interoperability, but also that it has been judged against these other considerations. Considerations often cited which I don't agree with: - must not be intended for uses which violate my personal values - must not be intended for uses which violate my idea of how the Internet should be used - must not be intended for uses which allow Service Providers to add value - must not violate some alleged philosophical principle articulated 25 years ago - must not make it more difficult to write multi-party peer-to-peer applications - must have the highest conceivable level of security - guaranteed bug-free Based on the considerations I think are important, I don't understand why we need more than one category of standard, so I would tend to agree with Brian: "let's scrap it all and have a single level (with recycling in grade for corrections/updates)." From problem-statement-bounces@alvestrand.no Fri Jun 6 11:15:31 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28018 for ; Fri, 6 Jun 2003 11:15:30 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E23306256B; Fri, 6 Jun 2003 17:15:00 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by eikenes.alvestrand.no (Postfix) with ESMTP id EA4C0622BB for ; Fri, 6 Jun 2003 17:14:57 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19OIvb-00062H-00; Fri, 06 Jun 2003 08:14:51 -0700 Date: Fri, 6 Jun 2003 11:12:43 -0400 From: Keith Moore To: Charlie Perkins Message-Id: <20030606111243.6bb4c7fd.moore@cs.utk.edu> In-Reply-To: <3EE0AAA1.3000808@iprg.nokia.com> References: <4.3.2.7.2.20030605172112.0309fe00@mailhost.iprg.nokia.com> <3EE02D2C.9040009@piuha.net> <3EE0AAA1.3000808@iprg.nokia.com> X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Subject: Re: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > >most will buy a system without knowing whether it works or not, and pull > >their hair out when they have trouble getting it to work in practice, and > >then guess about who is to blame, and make arbitrary demands about who has > >to fix it that have nothing to do with the actual cause of the problem. > > > Life sucks that way. It helps to buy from reputable vendors. gee, it's tempting, but I'm not going to get into an argument about which vendors are reputable. suffice it to say that for kinds of the products I buy, there are none. YMMV. > >NOBODY has said anything about requiring things to be perfect, so stop > >accusing people of that. What has been repeatedly suggested is that the > >criteria for maturity levels should be better matched with industry > >expectation and IETF energy levels. What's wrong with that? > > > But when you hear that industry has expectations about timeliness > you seem to go nonlinear. nope. it's when I hear suggestions that we should lower the quality of our output even further because we're supposedly trying to make it "perfect" that I go nonlinear. > Furthermore, I suggest that IETF processes > demotivate and drain the energy of otherwise enthusiastic IETF engineers. agree entirely. but I propose that we fix the process to make better use of those energies rather than simply relaxing our criteria in the interest of timeliness. From problem-statement-bounces@alvestrand.no Fri Jun 6 11:17:12 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28069 for ; Fri, 6 Jun 2003 11:17:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 05B666256B; Fri, 6 Jun 2003 17:16:43 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by eikenes.alvestrand.no (Postfix) with ESMTP id 49C9A622BB for ; Fri, 6 Jun 2003 17:16:34 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19OIxA-0000J7-00; Fri, 06 Jun 2003 08:16:28 -0700 Date: Fri, 6 Jun 2003 11:14:22 -0400 From: Keith Moore To: erosen@cisco.com Message-Id: <20030606111422.469e9101.moore@cs.utk.edu> In-Reply-To: <200306061458.h56Ew1LU005957@rtp-core-1.cisco.com> References: <3EE07FFE.32A07F4A@hursley.ibm.com> <200306061458.h56Ew1LU005957@rtp-core-1.cisco.com> X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Cc: brian@hursley.ibm.com Subject: Re: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Fri, 06 Jun 2003 10:58:01 -0400 Eric Rosen wrote: > there has arisen a significant constituency in > the IETF (though not seen much on this list) which believes that the only > proper function of the IETF is to publish specifications which are > multi-vendor interoperable. those people are naive. From problem-statement-bounces@alvestrand.no Fri Jun 6 11:38:23 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28836 for ; Fri, 6 Jun 2003 11:38:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 69521625D9; Fri, 6 Jun 2003 17:37:53 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6EBDA6256B for ; Fri, 6 Jun 2003 17:37:51 +0200 (CEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA17148; Fri, 6 Jun 2003 08:37:50 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h56Fbow11832; Fri, 6 Jun 2003 08:37:50 -0700 X-mProtect: <200306061537> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4Y8jnf; Fri, 06 Jun 2003 08:37:47 PDT Message-ID: <3EE0B562.5010505@iprg.nokia.com> Date: Fri, 06 Jun 2003 08:38:10 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore References: <4.3.2.7.2.20030605172112.0309fe00@mailhost.iprg.nokia.com> <3EE02D2C.9040009@piuha.net> <3EE0AAA1.3000808@iprg.nok Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hello Keith, Keith Moore wrote >gee, it's tempting, but I'm not going to get into an argument about which >vendors are reputable. suffice it to say that for kinds of the products I >buy, there are none. YMMV. > Indeed, my mileage varies. >>But when you hear that industry has expectations about timeliness >>you seem to go nonlinear. >> >> > >nope. it's when I hear suggestions that we should lower the quality of our >output even further because we're supposedly trying to make it "perfect" that >I go nonlinear. > Let's take site-local as an example. By your criteria, it seems to me we still would not have published any IPv6 address architecture document because of seeming flaw in the site-local design philosophy that was promulgated. I suggest that it would have been totally counterproductive to introduce such delay. Furthermore, I believe that other protocol efforts HAVE sustained nearly equal damage because of similar reluctance to allow wider deployment experience. Proposed Standard effectively mean{s,t}, "let's get wider deployment experience". >>Furthermore, I suggest that IETF processes >>demotivate and drain the energy of otherwise enthusiastic IETF engineers. >> >> > >agree entirely. but I propose that we fix the process to make better use >of those energies rather than simply relaxing our criteria in the interest >of timeliness. > Your criteria strongly inhibit timeliness. Regards, Charlie P. From problem-statement-bounces@alvestrand.no Fri Jun 6 11:49:35 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29250 for ; Fri, 6 Jun 2003 11:49:34 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DAA8D625D9; Fri, 6 Jun 2003 17:49:04 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id BF7266256B for ; Fri, 6 Jun 2003 17:48:58 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h56Fmrk11892; Fri, 6 Jun 2003 11:48:53 -0400 (EDT) Date: Fri, 6 Jun 2003 11:48:53 -0400 From: Keith Moore To: Charlie Perkins Message-Id: <20030606114853.0b887e3e.moore@cs.utk.edu> In-Reply-To: <3EE0B562.5010505@iprg.nokia.com> References: <4.3.2.7.2.20030605172112.0309fe00@mailhost.iprg.nokia.com> <3EE02D2C.9040009@piuha.net> <3EE0B562.5010505@iprg.nokia.com> X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Subject: Re: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > Let's take site-local as an example. By your criteria, it seems to me > we still would not have published any IPv6 address architecture > document because of seeming flaw in the site-local design philosophy > that was promulgated. nope. I would have marked that address range as "reserved" and published the document without site-local. > Furthermore, I believe that other protocol efforts HAVE sustained > nearly equal damage because of similar reluctance to allow wider > deployment experience. Proposed Standard effectively mean{s,t}, > "let's get wider deployment experience". No, it meant "let's get implementation experience". > >agree entirely. but I propose that we fix the process to make better > >use of those energies rather than simply relaxing our criteria in the > >interest of timeliness. > > > Your criteria strongly inhibit timeliness. You don't even know what my criteria are, Charlie, because I haven't tried to define them in detail. This is the problem statement WG, not the problem resolution WG. Our job is to identify problems, not to argue over the merits of solutions that haven't even been outlined yet. We have a identified a problem that our standards maturity levels do not match with either industry expectations or IETF energies. Do you agree with that problem statement or not? Keith From problem-statement-bounces@alvestrand.no Fri Jun 6 12:00:32 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29849 for ; Fri, 6 Jun 2003 12:00:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4E851625D9; Fri, 6 Jun 2003 18:00:01 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 032066256B for ; Fri, 6 Jun 2003 17:59:58 +0200 (CEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA17928; Fri, 6 Jun 2003 08:59:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h56Fxuq01170; Fri, 6 Jun 2003 08:59:56 -0700 X-mProtect: <200306061559> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpduDt8X5; Fri, 06 Jun 2003 08:59:54 PDT Message-ID: <3EE0BA90.70503@iprg.nokia.com> Date: Fri, 06 Jun 2003 09:00:16 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore References: <4.3.2.7.2.20030605172112.0309fe00@mailhost.iprg.nokia.com> <3EE02D2C.9040009@piuha.net> <3EE0B562.5010505@iprg.nok Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hello Keith Keith Moore wrote: >>Let's take site-local as an example. By your criteria, it seems to me >>we still would not have published any IPv6 address architecture >>document because of seeming flaw in the site-local design philosophy >>that was promulgated. >> >> > >nope. I would have marked that address range as "reserved" and >published the document without site-local. > But the rest of the working group would have disagreed, and the discussion could have continued for years. > > > >>Furthermore, I believe that other protocol efforts HAVE sustained >>nearly equal damage because of similar reluctance to allow wider >>deployment experience. Proposed Standard effectively mean{s,t}, >>"let's get wider deployment experience". >> >> > >No, it meant "let's get implementation experience". > Implementation tests whether it can be built. Deployment tests whether it works. I think my formulation is correct. I also think that we MUST NOT publish Proposed Standard documents that do not have implementation experience and interoperability experience. > > > >>Your criteria strongly inhibit timeliness. >> >> > >You don't even know what my criteria are, Charlie, because I haven't >tried to define them in detail. > I know that your criteria have the effects that you have described in your e-mails, enough so that I can stand by my statement. > >This is the problem statement WG, not the problem resolution WG. >Our job is to identify problems, not to argue over the merits of >solutions that haven't even been outlined yet. We have a identified >a problem that our standards maturity levels do not match with >either industry expectations or IETF energies. Do you agree with >that problem statement or not? > Yes. I agree with the statement. I want to see a more timely Proposed Standard. If the "Proposal" isn't right, I want to see that we can recycle to new a new Proposed Standard. I do NOT believe we have to issue poorer quality documents to meet better timeliness, but I _do_ think that some AD demands result in the need to document entire systems instead of just protocols, thus delaying protocol publication. This is another big mistake in my opinion. I suggest that the criterion has to be "does it work", instead of "how do I use it"? This is related to the previous discussion about the need for an applicability statement. Regards, Charlie P. From problem-statement-bounces@alvestrand.no Fri Jun 6 12:03:32 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29993 for ; Fri, 6 Jun 2003 12:03:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2C81A625D9; Fri, 6 Jun 2003 18:03:02 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 771676256B for ; Fri, 6 Jun 2003 18:02:52 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19OJg3-000GBl-00; Fri, 06 Jun 2003 11:02:51 -0500 Date: Fri, 06 Jun 2003 12:02:51 -0400 From: John C Klensin To: "john.loughney@nokia.com" , "problem-statement@alvestrand.no" Message-ID: <131405601.1054900971@p3.JCK.COM> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: RE: Sloppy Charters (was: Re: Discipline of Internet Protocol Engineering) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 John, I think those sorts of weak communications are a problem. Without knowing which WG you head, or which AD is involved, I'd suggest that, if you have a continuing poor-communication problem, you need to have some serious conversations with the AD and, if necessary, perhaps with the other AD in the area about a switch, or with the IETF Chair. If those don't work, you need to think about conversations with Nomcoms or more dramatic actions. But they aren't what I was talking about. At one time or another, virtually every AD has had someone (or, more often, a group) approach him or her with some interest and a story about how IETF needs to move now or industry will pass us by, or we will be in disrepute, or the Internet will suffer in some horrible way. There is always some truth in the story. In the most extreme of these circumstances, decent charters are hard to develop -- the enthusiasts have either only the broadest of ideas what they really want/need to do, or some ideas that are frightfully overfocused and unlikely to work in an unconstrained, public-Internet environment. Usually, after a BOF or two (between which the AD is accused of foot-dragging or being unresponsive), progress continues toward a charter amidst suspicions about bad faith (as in "they will agree to anything, then ignore it once the WG is chartered"). The WG is then authorized, sometimes out of general exhaustion and the AD's sense that there are far more important things to do than continue negotiating with a bunch of impossible people. And then, in the worst cases and as predicted, the group goes wandering in the weeds, goes off-charter, or produces work that is significantly inferior. If the AD pushes back, the WG complains that, having been chartered, they have the "right" to do their thing. And it is further downhill from there. That scenario has been described before. My problem, in this context, isn't with the scenario itself. It is with the fact that the ADs who do try to push back, hard and consistently, tend to get zero or negative support from the community for doing so. And then we, sooner or later but inevitably, get the leadership, management, and standards quality we deserve. john --On Friday, 06 June, 2003 17:56 +0300 "john.loughney@nokia.com" wrote: > John, > >> While I fully agree, I think that, in this area and several >> others, we've set up the wrong incentive structure. When we >> have tight charters, they are often, perhaps typically, not >>... > This sounds much more like a breakdown in the communication > between the chair and the AD. If the chair is not able to > organize the WG / charter correctly, so that the AD has to > step in, I am not suprised that the WG revolts. > > Currently, the chair - AD communication seems to be suffering. > I am not so sure how it is in other areas, but I sense that > ADs are not giving sufficient technical direction to their > WGs. I, for one, would be happy to have more discussions > with the IESG on the future of my WG, in fact, I think I > need more. > > John L. From problem-statement-bounces@alvestrand.no Fri Jun 6 12:06:01 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00163 for ; Fri, 6 Jun 2003 12:06:01 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2E4ED625D9; Fri, 6 Jun 2003 18:05:32 +0200 (CEST) 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 C8DFB6256B for ; Fri, 6 Jun 2003 18:05:29 +0200 (CEST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])h56G5TD22853 for ; Fri, 6 Jun 2003 19:05:29 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com ; Fri, 6 Jun 2003 19:05:29 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 19:05:28 +0300 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 19:05:27 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 19:05:27 +0300 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" Date: Fri, 6 Jun 2003 19:05:26 +0300 Message-ID: Thread-Topic: Sloppy Charters (was: Re: Discipline of Internet Protocol Engineering) Thread-Index: AcMsRRh3qrFOzuP7TTW3YnHT3cUKRQAACeqA From: To: , X-OriginalArrivalTime: 06 Jun 2003 16:05:27.0238 (UTC) FILETIME=[71EF4E60:01C32C45] Subject: RE: Sloppy Charters (was: Re: Discipline of Internet Protocol Engineering) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA00163 Hi John, > I think those sorts of weak communications are a problem. > Without knowing which WG you head, or which AD is involved, I'd > suggest that, if you have a continuing poor-communication > problem, you need to have some serious conversations with the AD > and, if necessary, perhaps with the other AD in the area about a > switch, or with the IETF Chair. If those don't work, you need > to think about conversations with Nomcoms or more dramatic > actions. I am not thinking of my AD in particular, but also the IESG in general. As I've edited documents in several areas, I've noticed a general tendancy that the IESG has many balls to juggle, and engaging chairs / editors in technical things tends to fall (unless it is a discussion during IETF last call). John From problem-statement-bounces@alvestrand.no Fri Jun 6 12:18:22 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00965 for ; Fri, 6 Jun 2003 12:18:21 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C050A625D9; Fri, 6 Jun 2003 18:17:52 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 583066256B for ; Fri, 6 Jun 2003 18:17:50 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19OJuX-000GD9-00; Fri, 06 Jun 2003 11:17:49 -0500 Date: Fri, 06 Jun 2003 12:17:49 -0400 From: John C Klensin To: "john.loughney@nokia.com" , "problem-statement@alvestrand.no" Message-ID: <132303672.1054901869@p3.JCK.COM> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: RE: Sloppy Charters (was: Re: Discipline of Internet Protocol Engineering) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Friday, 06 June, 2003 19:05 +0300 "john.loughney@nokia.com" wrote: >> I think those sorts of weak communications are a problem. >> Without knowing which WG you head, or which AD is involved, >> I'd suggest that, if you have a continuing >> poor-communication problem, you need to have some serious >> conversations with the AD and, if necessary, perhaps with >> the other AD in the area about a switch, or with the IETF >> Chair. If those don't work, you need to think about >> conversations with Nomcoms or more dramatic actions. > > I am not thinking of my AD in particular, but also the IESG in > general. As I've edited documents in several areas, I've > noticed a general tendancy that the IESG has many balls to > juggle, and engaging chairs / editors in technical things > tends to fall (unless it is a discussion during IETF last > call). And, personally, I believe _that_ problem has no solution at all unless and until a majority of the IESG are ready to stand up and say "we are seriously overloaded, and we are ready to do something about it. We understand that starts with accepting the fact that we really can't do everything and then moves on to being willing (and anxious) to look closely at any proposal that might plausibly reduce load." I've heard things pretty close to that (and pretty consistently) from Harald. But most of the ADs have appeared to me to have been largely silent or to accept the status quo. And, again, I don't think the community gives nearly enough support to those who push back, which encourages and reinforces all sorts of bad behavior patterns. john From problem-statement-bounces@alvestrand.no Fri Jun 6 13:16:35 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02918 for ; Fri, 6 Jun 2003 13:16:34 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 80722622BB; Fri, 6 Jun 2003 19:16:05 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A8A46225B for ; Fri, 6 Jun 2003 19:16:03 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h56HG0k11986; Fri, 6 Jun 2003 13:16:00 -0400 (EDT) Date: Fri, 6 Jun 2003 13:16:00 -0400 From: Keith Moore To: Charlie Perkins Message-Id: <20030606131600.2ef63437.moore@cs.utk.edu> In-Reply-To: <3EE0BA90.70503@iprg.nokia.com> References: <4.3.2.7.2.20030605172112.0309fe00@mailhost.iprg.nokia.com> <3EE02D2C.9040009@piuha.net> <3EE0BA90.70503@iprg.nokia.com> X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Subject: Re: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 the problem statement WG, not the problem resolution WG. > >Our job is to identify problems, not to argue over the merits of > >solutions that haven't even been outlined yet. We have a identified > >a problem that our standards maturity levels do not match with > >either industry expectations or IETF energies. Do you agree with > >that problem statement or not? > > > Yes. I agree with the statement. > > I want to see a more timely Proposed Standard. If the "Proposal" > isn't right, I want to see that we can recycle to new a new Proposed > Standard. I want to see us completely re-evaluate our maturity levels. I think if we try to tweak the ones we have we'll fail to fix most of the problems we have with the current setup. Given that assumption, arguments about how we are using the existing set of maturity levels aren't terribly enlightening. But at any rate the task at hand is to identify the problem, not to argue about how to fix it. As for site-local, we need to examine why that got into the IPv6 spec in the first place without any evidence that it would actually work. But that's a separate topic. From problem-statement-bounces@alvestrand.no Fri Jun 6 13:17:49 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03055 for ; Fri, 6 Jun 2003 13:17:48 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 563BC6256B; Fri, 6 Jun 2003 19:17:20 +0200 (CEST) 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 8FEAD622BB for ; Fri, 6 Jun 2003 19:17:18 +0200 (CEST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])h56HHHD01662 for ; Fri, 6 Jun 2003 20:17:18 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com ; Fri, 6 Jun 2003 20:17:17 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 20:17:16 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 20:17:16 +0300 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" Date: Fri, 6 Jun 2003 20:17:15 +0300 Message-ID: Thread-Topic: Sloppy Charters (was: Re: Discipline of Internet Protocol Engineering) Thread-Index: AcMsRy8zZNNHn0sLRnyWwXeHWj5dTQAB/ClA From: To: , X-OriginalArrivalTime: 06 Jun 2003 17:17:16.0143 (UTC) FILETIME=[7A3E07F0:01C32C4F] Subject: Possibly stupid suggestion (was: Sloppy Charters (was: Re: Discipline of Internet Protocol Engineering) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA03055 Hi John, > We understand that starts with accepting > the fact that we really can't do everything and then moves on to > being willing (and anxious) to look closely at any proposal that > might plausibly reduce load." I've heard things pretty close to > that (and pretty consistently) from Harald. But most of the ADs > have appeared to me to have been largely silent or to accept the > status quo. Would it be a stupid idea, perhaps, to circulate a short survey to, for example, IESG members & WG chairs, asking them what problems & difficulties they have in their 'job'? Perhaps Harald could collect these, strip off the names & the WG chairs could talley them up & see if there are any revealing patterns ... John L. From problem-statement-bounces@alvestrand.no Fri Jun 6 13:24:12 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03269 for ; Fri, 6 Jun 2003 13:24:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 166786256B; Fri, 6 Jun 2003 19:23:43 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2D654622BB for ; Fri, 6 Jun 2003 19:23:40 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h56HNYk12001; Fri, 6 Jun 2003 13:23:35 -0400 (EDT) Date: Fri, 6 Jun 2003 13:23:34 -0400 From: Keith Moore To: John C Klensin Message-Id: <20030606132334.0d0ac5db.moore@cs.utk.edu> In-Reply-To: <132303672.1054901869@p3.JCK.COM> References: <132303672.1054901869@p3.JCK.COM> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: john.loughney@nokia.com Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: Sloppy Charters (was: Re: Discipline of Internet Protocol Engineering) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > And, personally, I believe _that_ problem has no solution at all > unless and until a majority of the IESG are ready to stand up > and say "we are seriously overloaded, and we are ready to do > something about it. We understand that starts with accepting > the fact that we really can't do everything and then moves on to > being willing (and anxious) to look closely at any proposal that > might plausibly reduce load." and I suspect that, for this to happen, we'll need to find ways to shift many of those burdens to other people rather than to simply avoid doing them. From problem-statement-bounces@alvestrand.no Fri Jun 6 14:15:29 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05680 for ; Fri, 6 Jun 2003 14:15:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2F4536256B; Fri, 6 Jun 2003 20:14:58 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 496A8622BB for ; Fri, 6 Jun 2003 20:14:55 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19OLjq-000Gd1-00 for problem-statement@alvestrand.no; Fri, 06 Jun 2003 13:14:54 -0500 Date: Fri, 06 Jun 2003 14:14:54 -0400 From: John C Klensin To: "problem-statement@alvestrand.no" Message-ID: <139328333.1054908894@p3.JCK.COM> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ISSUE: Procedural rapid ossification X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 A number of list transactions/ discussions in the last few weeks, and a few recent offline discussions, have convinced me that we have another problem that both belongs on the list and calls for thought about this WG, its processes, and those it is spawning. Summary: In a system that is designed around having firm general principles and considerable IESG discretion within those principles, we are showing a disturbing tendency to turn IESG "rules of convenience" into rigid strictures that cannot be violated or deviated from. It is a bad combination. ---- At least prior to the current round of discussions, IETF discussions of procedures have been driven by a model in which the procedural BCPs construct a framework for doing work, but the details of that framework are left for the IESG to fill in. When issues or crises have arisen, we've generally avoided making specific procedural changes to compensate, instead realizing that we could not anticipate all cases and that "fighting the last war" is not a good way to proceed. It is exactly this model that makes trusting the IESG so important: if they cannot be counted on to fill in those details appropriately and fairly, and to avoid moving their authority past the boundaries of the framework or ignoring the framework entirely, we have a problem that no amount of low-level procedural tinkering is going to fix. That is part of a different thread; this note is about the present situation and assumes a trusted and well-behaved IESG. Over the last decade, the IESG has established a great many rules to fill in process details. Most of them are well within IESG authority to "manage the process". But it is important to remember that these are rules created by the IESG -- in some cases without a great deal of debate or consideration. As such, the IESG can change them, make exceptions to them, etc. And we seem to have lost sight of that and, instead, are burying ourselves in procedures that rapidly move from organizational conveniences to rigid and immutable doctrine. Some examples: * I-D submission and WG/BOF scheduling deadlines: The various pre-meeting deadlines for submitting I-Ds and for requests to schedule meeting slots were worked out between the IESG and the Secretariat. In the I-D case, the goal was to be sure that documents could actually appear well before the meetings started. In the meeting slot case, a deadline date was needed to permit carefully balancing requests and the desire to avoid conflicts of sessions that required the same people. An additional, although later, constraint involved getting the agenda printed and ready for distribution at the meeting. The reasonableness and appropriateness of such rules is obvious to anyone who has even carefully contemplated organizing a complex meeting. But the suggestion that the IESG cannot make an exception if they consider it important enough falls somewhere on the scale from "silly" to "dangerous". The deadline dates are not fundamental principles that are critical to the existence of the IETF as we know it. They are useful guidelines that the IESG has set up and can modify, or make exceptions to, at will. * BOF scheduling. Over the years, as pressure for meetings slots and requests for BOFs has increased, the IESG has become increasingly specific about requirements for requesting, and being granted, a BOF. Again, this is clearly necessary since the alternative would be having all meeting time taken over by BOFs. Whatever the requirements are at a given time, they are requirements imposed by the IESG as part of their job to efficiently manage the meetings and the process. But, if the IESG decides that something is important enough to waive the rules in a particular case, they can do so since these are _their_ rules. I assume they would not do that capriciously; I hope that they would explain the logic for making an exception to the community (and especially to those whose BOF requests were denied). But they clearly have authority to make exceptions; nothing else makes sense. * What is a WG? And what isn't a WG or BOF? RFCs 2026 and 2418 make some fairly specific statements about WGs and BOFs and how they operate, particularly those involved in the standards process. But, unless we get enough carried away with procedures to read those documents with an "anything not explicitly permitted is forbidden" perspective, they don't prohibit other forms of WG or BOF organization for other purposes, nor do they prohibit completely different kinds of structures. So I suggest that, in the general case, a BOF is anything the IESG says is a BOF, a WG is -- subject to some constraints about charters, etc.-- anything the IESG says is a WG, and, if the IESG wants to create a special type of gathering called, e.g., A Big Hokum and give it meeting time and mailing lists, nothing we have procedurally prevents them from doing so and we shouldn't waste time trying to create specific rules for such things. * What, really, is an "umbrella WG"? Along the same themes as the above, we've had some recent discussion about "umbrella WGs". I used to think I knew what an "umbrella WG" was... we had a special word for it, and the word was "Area" or "Subarea". Under the formal procedures, the IESG can create and delete areas at its discretion. It is actually easier, procedurally, to create an area than to create a WG, since there is no formal requirement for posting draft charters, allowing for comments from the community and other standards bodies, and so on. There are practically no constraints on the IESG about getting rid of any area either. The only thing the IESG is prohibited from doing involves creating an Area and appointing someone outside the IESG to head it -- that appointment has to be made by the nomcom. The procedures leave the boundary between "area" (with an AD on the IESG) and various subarea, umbrella, and super-WG concepts strictly in the IESG's hands (along with Big Hokums). But we should avoid getting so rigid about what any of those terms might mean with regard to structure and duration that it prevents our thinking clearly and creatively. * What is the procedure for submitting a document for IESG processing? The IESG makes these procedures up, and defines them as needed. Having procedures is A Good Thing -- they very much reduce the possibility of general confusion and apparent abuse. But, if the procedures need to be tuned, or if different procedures are needed for particular cases, we shouldn't need to spin up a WG to write a document: a WG Chair should be able to make a determination that the idea has some consensus and then pass it off to the IESG as a recommendation by sending a simple email note. The IESG then ought to be able to hold a short discussion, adopt the idea if they conclude it would be useful, and briefly explain not --or engage in some discussion on the subject-- if they think it is not. Spinning up WGs and writing documents at that level could actually be a disadvantage: we really don't want to start getting the IESG so tied up in BCPs that micromanage their procedures that we need big-structure working groups every time some special case comes along. Let's look for ways to move forward while creating as little bureaucracy and formal structure as possible. We really don't have the extra cycles to waste on that stuff if there is any reasonable alternative in a given case. john From problem-statement-bounces@alvestrand.no Fri Jun 6 16:25:10 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11345 for ; Fri, 6 Jun 2003 16:25:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 330CB6256B; Fri, 6 Jun 2003 22:24:40 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mx-out.daemonmail.net (mx-out.daemonmail.net [216.104.160.39]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4E3B8621FA for ; Fri, 6 Jun 2003 22:24:34 +0200 (CEST) Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.9.3p2/8.9.3) with SMTP id NAA97904 for ; Fri, 6 Jun 2003 13:24:32 -0700 (PDT) (envelope-from spencer@mcsr-labs.org) Received: from (12.237.229.250 [12.237.229.250]) by mail.varaha.com with SMTP id 2TP0YXV2 Fri, 06 Jun 2003 13:24:32 -0700 (PDT) Message-ID: <04dd01c32c69$a693d400$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <132303672.1054901869@p3.JCK.COM> Date: Fri, 6 Jun 2003 15:24:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: Sloppy Charters (was: Re: Discipline of Internet Protocol Engineering) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Yeah, I'm kind of depressed by the lack of feedback from ADs on current AD workload. How would the rest of us know? But to focus on the documents - the problem resolution draft is fairly explicit in section 4.5 about the "huge time commitment" required to serve on IESG, in the context that this seriously reduces the pool of potential leaders for NOMCOM. I'm talking about the bullet that begins "- The current organization of the IETF does not scale. " Could we hear from some other people who have been in this role? Are we (the editorial team) just making this up, or is this really an issue? Spencer, who is unpleasantly surprised that he can't find text in the problem draft on this specific point... 2.5.1 says "very large load of responsibility", but doesn't say "TOO large". ----- Original Message ----- From: "John C Klensin" To: ; Sent: Friday, June 06, 2003 11:17 AM Subject: RE: Sloppy Charters (was: Re: Discipline of Internet Protocol Engineering) > > > --On Friday, 06 June, 2003 19:05 +0300 "john.loughney@nokia.com" > wrote: > > > > I am not thinking of my AD in particular, but also the IESG in > > general. As I've edited documents in several areas, I've > > noticed a general tendancy that the IESG has many balls to > > juggle, and engaging chairs / editors in technical things > > tends to fall (unless it is a discussion during IETF last > > call). > > And, personally, I believe _that_ problem has no solution at all > unless and until a majority of the IESG are ready to stand up > and say "we are seriously overloaded, and we are ready to do > something about it. We understand that starts with accepting > the fact that we really can't do everything and then moves on to > being willing (and anxious) to look closely at any proposal that > might plausibly reduce load." I've heard things pretty close to > that (and pretty consistently) from Harald. But most of the ADs > have appeared to me to have been largely silent or to accept the > status quo. > > And, again, I don't think the community gives nearly enough > support to those who push back, which encourages and reinforces > all sorts of bad behavior patterns. > > john > From problem-statement-bounces@alvestrand.no Fri Jun 6 16:35:51 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11654 for ; Fri, 6 Jun 2003 16:35:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B1CC1625BD; Fri, 6 Jun 2003 22:35:21 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mx-out.daemonmail.net (mx-out.daemonmail.net [216.104.160.39]) by eikenes.alvestrand.no (Postfix) with ESMTP id B5B396256B for ; Fri, 6 Jun 2003 22:35:15 +0200 (CEST) Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.9.3p2/8.9.3) with SMTP id NAA00950 for ; Fri, 6 Jun 2003 13:35:14 -0700 (PDT) (envelope-from spencer@mcsr-labs.org) Received: from (12.237.229.250 [12.237.229.250]) by mail.varaha.com with SMTP id CF00qX10 Fri, 06 Jun 2003 13:35:14 -0700 (PDT) Message-ID: <04f601c32c6b$25392250$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <139328333.1054908894@p3.JCK.COM> Date: Fri, 6 Jun 2003 15:35:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: ISSUE: Procedural rapid ossification X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Dear John (Klensin), I look forward to the Vienna meeting with increased anticipation. Thank you for the slap across the face ("thanks, I needed that"). Since you mention I-D submission deadlines specifically - I remember the Munich IETF, and hearing from an IAB member who missed the I-D cutoff by several minutes (less than 10), so we couldn't discuss the proposal (can't remember if it was a WG document or not). After that, I've had very high regard for the IETF's rules. You are suggesting that my regard might have been a little TOO high. An interesting thought. Spencer ----- Original Message ----- From: "John C Klensin" To: Sent: Friday, June 06, 2003 1:14 PM Subject: ISSUE: Procedural rapid ossification > A number of list transactions/ discussions in the last few > weeks, and a few recent offline discussions, have convinced me > that we have another problem that both belongs on the list and > calls for thought about this WG, its processes, and those it is > spawning. > > Summary: In a system that is designed around having firm general > principles and considerable IESG discretion within those > principles, we are showing a disturbing tendency to turn IESG > "rules of convenience" into rigid strictures that cannot be > violated or deviated from. It is a bad combination. > [deleted rest of interesting e-mail] From problem-statement-bounces@alvestrand.no Fri Jun 6 16:47:41 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12111 for ; Fri, 6 Jun 2003 16:47:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8FE98625BD; Fri, 6 Jun 2003 22:47:10 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4BD706256B for ; Fri, 6 Jun 2003 22:47:07 +0200 (CEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA01718; Fri, 6 Jun 2003 13:47:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h56Kl5N11679; Fri, 6 Jun 2003 13:47:05 -0700 X-mProtect: <200306062047> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqlM5rr; Fri, 06 Jun 2003 13:47:03 PDT Message-ID: <3EE0FDC7.2FD060C4@iprg.nokia.com> Date: Fri, 06 Jun 2003 13:47:03 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Spencer Dawkins References: <04dd01c32c69$a693d400$0200a8c0@DFNJGL21> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Sloppy Charters (was: Re: Discipline of Internet ProtocolEngineering) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hello Spencer, For every dimension, there is a scale, and thus a potential scalability problem. Maybe it would be good to consider various axes separately: - Number of documents to review - Number of working groups to coordinate - Number of architectural principles to enforce - Number of meetings to attend - Number of document processing steps to approve - Number of mailing list contributions to read That took me about 39 seconds to write, and I am pretty sure more job responsibilities could be added to that list. Not all of these axes are orthogonal though. Maybe it would be worthwhile to figure out how the various parts of the job might be separated. For instance, we might discuss whether document review and shepherding has to be done by the same persons that schedule BOFs. It's not immediately obvious how many differnt different jobs might be created from the job of one AD. Regards, Charlie P. PS: Charlie's scalability axiom: "If you don't like a protocol, you can always claim it isn't scalable". Spencer Dawkins wrote: > > Yeah, I'm kind of depressed by the lack of feedback from ADs on > current AD workload. How would the rest of us know? > > But to focus on the documents - the problem resolution draft is > fairly explicit in section 4.5 about the "huge time commitment" required > to serve on IESG, in the context that this seriously reduces the pool > of potential leaders for NOMCOM. > > I'm talking about the bullet that begins > > "- The current organization of the IETF does not scale. " > > Could we hear from some other people who have been in this role? Are > we (the editorial team) just making this up, or is this really an issue? > > Spencer, who is unpleasantly surprised that he can't find text in the > problem draft on this specific point... 2.5.1 says "very large load > of responsibility", but doesn't say "TOO large". > > ----- Original Message ----- > From: "John C Klensin" > To: ; > Sent: Friday, June 06, 2003 11:17 AM > Subject: RE: Sloppy Charters (was: Re: Discipline of Internet Protocol > Engineering) > > > > > > > --On Friday, 06 June, 2003 19:05 +0300 "john.loughney@nokia.com" > > wrote: > > > > > > I am not thinking of my AD in particular, but also the IESG in > > > general. As I've edited documents in several areas, I've > > > noticed a general tendancy that the IESG has many balls to > > > juggle, and engaging chairs / editors in technical things > > > tends to fall (unless it is a discussion during IETF last > > > call). > > > > And, personally, I believe _that_ problem has no solution at all > > unless and until a majority of the IESG are ready to stand up > > and say "we are seriously overloaded, and we are ready to do > > something about it. We understand that starts with accepting > > the fact that we really can't do everything and then moves on to > > being willing (and anxious) to look closely at any proposal that > > might plausibly reduce load." I've heard things pretty close to > > that (and pretty consistently) from Harald. But most of the ADs > > have appeared to me to have been largely silent or to accept the > > status quo. > > > > And, again, I don't think the community gives nearly enough > > support to those who push back, which encourages and reinforces > > all sorts of bad behavior patterns. > > > > john > > From problem-statement-bounces@alvestrand.no Fri Jun 6 16:48:46 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12183 for ; Fri, 6 Jun 2003 16:48:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 41766625BD; Fri, 6 Jun 2003 22:48:16 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1170C6256B for ; Fri, 6 Jun 2003 22:48:12 +0200 (CEST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])ESMTP id h56Km8B10681 for ; Fri, 6 Jun 2003 16:48:08 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10P75H>; Fri, 6 Jun 2003 22:48:06 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501BC29A4@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Spencer Dawkins , problem-statement@alvestrand.no Date: Fri, 6 Jun 2003 22:47:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Sloppy Charters (was: Re: Discipline of Internet Protocol Eng ineering) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > Sent: vrijdag 6 juni 2003 22:25 > To: problem-statement@alvestrand.no > Subject: Re: Sloppy Charters (was: Re: Discipline of Internet Protocol > Engineering) > > > Yeah, I'm kind of depressed by the lack of feedback from ADs on > current AD workload. How would the rest of us know? > So do you want all of the ADs to make a statement if they feel overloaded or not? I will admit that I feel overloaded. The worst thing is that you can;t actually take a 3 week vacation. Cause when you get back, you get severely punished for that by you mail inbox. And as far as I know, the nomcom asks for a 60% time commitment for new ADs. And I think it is no secret that they often assume at least a 60 hour workweek if not more, so it is basically a full time job. And there is ALWAYS more that we can do... if just had more time. Bert From problem-statement-bounces@alvestrand.no Fri Jun 6 16:52:57 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12373 for ; Fri, 6 Jun 2003 16:52:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 90B9F622AF; Fri, 6 Jun 2003 22:52:26 +0200 (CEST) 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 6F64C621FA for ; Fri, 6 Jun 2003 22:52:19 +0200 (CEST) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h56KqIra004376; Fri, 6 Jun 2003 16:52:18 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h56KqIOt004375; Fri, 6 Jun 2003 16:52:18 -0400 (EDT) Date: Fri, 6 Jun 2003 16:52:18 -0400 (EDT) From: Scott Bradner Message-Id: <200306062052.h56KqIOt004375@newdev.harvard.edu> To: spencer@mcsr-labs.org In-Reply-To: <04f601c32c6b$25392250$0200a8c0@DFNJGL21> Cc: problem-statement@alvestrand.no Subject: Re: ISSUE: Procedural rapid ossification X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > Since you mention I-D submission deadlines specifically - > I remember the Munich IETF, and hearing from an IAB member > who missed the I-D cutoff by several minutes (less than 10), so > we couldn't discuss the proposal (can't remember if it was a WG > document or not). from 2418 7.1. Session documents All relevant documents to be discussed at a session should be published and available as Internet-Drafts at least two weeks before a session starts. Any document which does not meet this publication deadline can only be discussed in a working group session with the specific approval of the working group chair(s). Since it is important that working group members have adequate time to review all documents, granting such an exception should only be done under unusual conditions. the chair can override the deadline if the chair thinks it is important Scott From problem-statement-bounces@alvestrand.no Fri Jun 6 16:56:06 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12438 for ; Fri, 6 Jun 2003 16:56:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6F87A622AF; Fri, 6 Jun 2003 22:55:36 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 84D3F621FA for ; Fri, 6 Jun 2003 22:55:34 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19OOFJ-000HAX-00; Fri, 06 Jun 2003 15:55:33 -0500 Date: Fri, 06 Jun 2003 16:55:33 -0400 From: John C Klensin To: Spencer Dawkins , "problem-statement@alvestrand.no" Message-ID: <148967153.1054918533@p3.JCK.COM> In-Reply-To: <04f601c32c6b$25392250$0200a8c0@DFNJGL21> References: <139328333.1054908894@p3.JCK.COM> <04f601c32c6b$25392250$0200a8c0@DFNJGL21> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: ISSUE: Procedural rapid ossification X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Friday, 06 June, 2003 15:35 -0500 Spencer Dawkins wrote: > Dear John (Klensin), > > I look forward to the Vienna meeting with increased > anticipation. > > Thank you for the slap across the face ("thanks, I needed > that"). > > Since you mention I-D submission deadlines specifically - > I remember the Munich IETF, and hearing from an IAB member > who missed the I-D cutoff by several minutes (less than 10), so > we couldn't discuss the proposal (can't remember if it was a WG > document or not). Just in case I was the relevant IAB member, note that you just invoked two separate rules... (1) There is an I-D cutoff, and documents submitted after it are not going to get posted. Can the IESG make an exception to that rule if they consider it important enough? That has, I believe, always been the case. Should they do it very often? No, that would probably cause chaos and accusations of unfairness. But the notion that they _cannot_ make an exception would be, IMO, just wrong. (2) Many WGs, and some areas, have adopted a rule that documents that weren't posted before the IETF meeting starts can't be discussed because there would be insufficient time for people to read and assimilate them. Is that a good rule? Almost always. Can the relevant AD, or even the WG Chair, waive it if that is in the WG's best interests? Yes, I hope so -- if that is impossible, we have really gotten hung up on procedures to the exclusion of substance. Should an exception occur very often? I personally think that would be a really bad idea. And, for whatever it worth, were I an AD or WG Chair, I'd be a lot more sympathetic to a 10-minute-after-deadline request to ask the Secretariat to post a draft anyone, or to an hour-after-deadline request to post a link to the draft on a web page and notify the WG's mailing list that it is on the meeting agenda, than I would to someone standing up during a WG meeting and saying "well, I've got this draft that missed the deadline, and which no one has seen, but I think we should discuss it anyway". The first two options preserve the principle of early and widely-available posting. The "in the meeting" one would seem to be nonsense and abusive of the time of the WG participants... but there might be an exception somewhere. > After that, I've had very high regard for the IETF's rules. > > You are suggesting that my regard might have been a little TOO > high. An interesting thought. Very possibly. They are rules. Almost all of them are useful rules. They have not been chiseled into stone by a divine hand and I think we put ourselves at risk by pretending that they were. regards, john From problem-statement-bounces@alvestrand.no Fri Jun 6 19:06:29 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17878 for ; Fri, 6 Jun 2003 19:06:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C580A622AF; Sat, 7 Jun 2003 01:05:59 +0200 (CEST) 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 1BDDD621FA for ; Sat, 7 Jun 2003 01:05:53 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h56N8mF06134; Fri, 6 Jun 2003 16:08:48 -0700 Date: Fri, 6 Jun 2003 16:05:52 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <17925157915.20030606160552@brandenburg.com> To: Eric Rosen In-Reply-To: <200306061458.h56Ew1LU005957@rtp-core-1.cisco.com> References: <200306061458.h56Ew1LU005957@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Eric, ER> Most people on this list seem to think that there is a value in having a ER> category of "standard" which means something more than "multi-vendor ER> interoperable." It occurs to me that you may have backed into exactly the real disparity. Historically, the goal of IETF work was to produce specifications that were KNOWN to be interoperable. In recent years, we stopped worrying about the reality of interoperability and settled for "looks goods after a static review of the document". And we let the rest of the world decide what to do with the document after that. So, for one thing, we have stopped very seriously worrying about running code, or actual use, or any such mundane concern. (and no, that's not an absolute, but I believe it does characterize the change in IETF culture.) d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Fri Jun 6 19:16:54 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18056 for ; Fri, 6 Jun 2003 19:16:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 50D36622AF; Sat, 7 Jun 2003 01:16:25 +0200 (CEST) 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 A6660621FA for ; Sat, 7 Jun 2003 01:16:21 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h56NJHF06606; Fri, 6 Jun 2003 16:19:17 -0700 Date: Fri, 6 Jun 2003 16:15:35 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <15925741524.20030606161535@brandenburg.com> To: Melinda Shore In-Reply-To: <200306061324.AIB70919@mira-sjc5-c.cisco.com> References: <200306061324.AIB70919@mira-sjc5-c.cisco.com> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Staying on Track (Re: Documenting pilots (RE: pausable explanation for the Document Series)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Dave Crocker List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Melinda, MS> I'm not crazy about things like what's going on with the MS> SIRS proposal (going off and collecting volunteers without MS> real agreement from the cohort that this is a good thing to MS> do) because it feels pre-emptive and unco-operative, Oh boy, do we have different views about such efforts. Let's be clear about the nature of this sort of "preemptive" and "uncooperative" effort: 1. At the last IETF meeting, Brian came up with an idea, chatted it up, got good reactions and suggestions, recruited someone to help with the writing a few paragraphs on it and then circulated the idea informally. 2. The writeup was chatted up, got good suggestions and reactions, and turned into an I-D. 3. The I-D got chatted up, got good suggestions and reactions, and turned into an experiment. 4. The experiment has, so far, gotten volunteers, started to offer itself for public use, and will prove useful -- or not -- on its merits. It has no force of law, or anything other than basic credibility. It also has not had months and months of delay. So, in fact, this is about as far as you can get from being preemptive or uncooperative. On the other hand, yes, it is also very far from relying on bureaucratic approval. Rather than being worried that it has occurred, perhaps we should be worried that more such efforts have not? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Sat Jun 7 03:50:08 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08238 for ; Sat, 7 Jun 2003 03:50:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 45452625BE; Sat, 7 Jun 2003 09:49:37 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id A066D6256B; Sat, 7 Jun 2003 09:49:35 +0200 (CEST) Date: Sat, 07 Jun 2003 09:49:35 +0200 From: Harald Tveit Alvestrand To: Charlie Perkins , Keith Moore Message-ID: <105850000.1054972175@askvoll.hjemme.alvestrand.no> In-Reply-To: <3EE0BA90.70503@iprg.nokia.com> References: <4.3.2.7.2.20030605172112.0309fe00@mailhost.iprg.nokia.com> <3EE02D2C.9040009@piuha.net> <3EE0B562.5010505@iprg.nok <3EE0BA90.70503@iprg.nokia.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) 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: Suggesting document fixes (Re: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 fredag, juni 06, 2003 09:00:16 -0700 Charlie Perkins wrote: >> This is the problem statement WG, not the problem resolution WG. >> Our job is to identify problems, not to argue over the merits of >> solutions that haven't even been outlined yet. We have a identified >> a problem that our standards maturity levels do not match with >> either industry expectations or IETF energies. Do you agree with >> that problem statement or not? >> > Yes. I agree with the statement. Charlie, Keith: Since you have something you agree on, and which I agree on too, and which I cannot find in the problem-statement document as currently written, perhaps the two of you could try to formulate a proposal for a change to the problem-statement document that incorporates this point, and which Melinda can track as an "issue to be resolved"? Unless we capture the agreement, it might become lost again.... Harald From problem-statement-bounces@alvestrand.no Sat Jun 7 10:02:12 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13139 for ; Sat, 7 Jun 2003 10:02:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A657B6238F; Sat, 7 Jun 2003 16:01:41 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id B568B621B8 for ; Sat, 7 Jun 2003 16:01:38 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19OeGE-000LTO-00; Sat, 07 Jun 2003 09:01:34 -0500 Date: Sat, 07 Jun 2003 10:01:34 -0400 From: John C Klensin To: Dave Crocker , Melinda Shore Message-ID: <210527462.1054980094@p3.JCK.COM> In-Reply-To: <15925741524.20030606161535@brandenburg.com> References: <200306061324.AIB70919@mira-sjc5-c.cisco.com> <15925741524.20030606161535@brandenburg.com> X-Mailer: Mulberry/3.0.3 (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: Staying on Track (Re: Documenting pilots (RE: pausable explanation for the Document Series)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Dave, I need to _slightly_ support Melinda's position on this. I certainly wouldn't have used words like "preemptive" or "uncooperative". But... In a cultural problem that goes back long before we, as you observed elsewhere, started putting more focus on static description than on demonstrated interoperability (and, IMO, blew it on both), we have had a habit of proposing, documenting, and sometimes even trying "experiments" which lack evaluation criteria... or any way, other than force of personality, to really determine whether they "worked". Nor do we have real procedures for documenting what we have learned. In that regard, SIRS has been, I think, better than the average. But it is a handy example, so let's look at it, with the understanding that I'm deliberately broadening the example a bit to illustrate a problem with the way we often do business ... some of that example may not actually apply to SIRS. It establishes goals as: > The procedure described in this document is intended to > solve, or palliate, a number of related problems that > have been observed in the IETF process [PROBLEM]: > > * overload of the IESG (leading to delay) > > * perception that authority and influence > in the IETF are concentrated in too few > hands > > * submission of documents to the IESG that > still have significant problems (leading > to delay) > > * failure to detect fundamental problems > and Internet- wide issues at an early > stage Certainly worthwhile. But, quoting from your note, "...started to offer itself for public use, and will prove useful -- or not -- on its merits. How are those merits to be evaluated so as to determine whether this is a success? The document then goes on to say: > However, > it is likely that drafts with at least three positive > reviews from SIRs in different areas will experience > much shorter IESG review cycles than drafts with fewer > positive reviews. [...] > In all likelihood, Drafts without reviews will get > worse IESG response time than today, whereas Drafts > with reviews will be processed much more rapidly, > especially as the IESG's confidence in the SIR > procedure increases. Plausible hypotheses indeed. But, for a given document coming out of a given WG, we have no practical and objective way to accurately estimate how long it would have taken to get through the IESG without SIRS support, so it is not possible to objectively know whether SIRS sped thing up. I don't think it likely, but a counter-hypothesis is that the IESG, upon receiving a document with three or five SIRS signoffs but disagreeing anyway, would decide that it needed to give more extensive explanations to those senior people, or discuss issues with them even before going back to discuss them with the WG. That would probably positively leverage quality, but would have a negative effect on speed. And, of course, trying to guess at whether SIRS improved quality in comparison to what the IESG would have done, to/with a given document without it. is even more difficult. So, you collect some reviewers, and some WGs choose to use them. For some of those WGs --perhaps the ones who were in good shape anyway but that, too, is pretty subjective-- the reviews help the IESG expedite the process. For others, they don't appear to. Do we then declare the experiment a success and try to make it mandatory? Does anyone who doesn't think it has proven itself a success get to speak up without being overwhelmed in rhetoric and forceful assertions? Do we infer that ADs who don't quickly sign off on SIRS-endorsed documents are obstructionist nit-pickers and need to be fired? And so on. As I hope my recent notes make clear, I'm not in favor of trying to invent procedures to alleviate any of the above, or of delaying things until such procedures reach some extraordinary consensus. But I'd be much happier about the idea --even as an experiment-- had the IESG been willing to stand up and say "fascinating idea, lets try it". And it would have been even better, at least from an "experimental" context, had the IESG chosen to say "It would be good to really do this as an experiment and therefore to be able to make some comparisons. So let's look at the following mix of areas, or specific groups of WGs, first, leave the others with status quo, and see how things work out. I'm disappointed that type of response from the IESG hasn't happened. Maybe they don't think they have been asked. And the latter is, of course, what my recent notes have been about: if we need a formal document and request to publish it as an RFC and/or a formal WG call for consensus and response, in order to get an IESG response to a "we think this would be worth trying, do you have reactions or suggestions/requirements about how to try it", then, IMO, we are in deep trouble. But, going ahead with something on the grounds that it is an experiment, without objective evaluation criteria or any real possibility of them, and without IESG comment, input, or participation... That seems to me to be an opportunity for some future demagogue, with some other experiment, to try something, claim it succeeded, and then insist --loudly and by whispering campaign-- it was a success and that IESG failure to immediately adopt it indicates that all of those rascals should be thrown out and the procedural structure blown up (and replaced with one of the demagogue's liking) to mark their way. john --On Friday, 06 June, 2003 16:15 -0700 Dave Crocker wrote: > Melinda, > > MS> I'm not crazy about things like what's going on with the > MS> SIRS proposal (going off and collecting volunteers without > MS> real agreement from the cohort that this is a good thing to > MS> do) because it feels pre-emptive and unco-operative, > > > Oh boy, do we have different views about such efforts. > > Let's be clear about the nature of this sort of "preemptive" > and "uncooperative" effort: > > 1. At the last IETF meeting, Brian came up with an idea, > chatted it up, got good reactions and suggestions, recruited > someone to help with the writing a few paragraphs on it and > then circulated the idea informally. > > 2. The writeup was chatted up, got good suggestions and > reactions, and turned into an I-D. > > 3. The I-D got chatted up, got good suggestions and reactions, > and turned into an experiment. > > 4. The experiment has, so far, gotten volunteers, started to > offer itself for public use, and will prove useful -- or not > -- on its merits. It has no force of law, or anything other > than basic credibility. > > It also has not had months and months of delay. > > So, in fact, this is about as far as you can get from being > preemptive or uncooperative. > > On the other hand, yes, it is also very far from relying on > bureaucratic approval. > > Rather than being worried that it has occurred, perhaps we > should be worried that more such efforts have not? > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > > From problem-statement-bounces@alvestrand.no Sat Jun 7 10:20:12 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14441 for ; Sat, 7 Jun 2003 10:20:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EEDCC625BE; Sat, 7 Jun 2003 16:19:41 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4CEB26256C; Sat, 7 Jun 2003 16:19:38 +0200 (CEST) Date: Sat, 07 Jun 2003 16:19:38 +0200 From: Harald Tveit Alvestrand To: John C Klensin Message-ID: <111100000.1054995578@askvoll.hjemme.alvestrand.no> In-Reply-To: <210527462.1054980094@p3.JCK.COM> References: <200306061324.AIB70919@mira-sjc5-c.cisco.com> <15925741524.20030606161535@brandenburg.com> <210527462.1054980094@p3.JCK.COM> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Cc: "problem-statement@alvestrand.no" Subject: Re: Staying on Track (Re: Documenting pilots (RE: pausable explanation for the Document Series)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA14441 --On lørdag, juni 07, 2003 10:01:34 -0400 John C Klensin wrote: > As I hope my recent notes make clear, I'm not in favor of trying to > invent procedures to alleviate any of the above, or of delaying things > until such procedures reach some extraordinary consensus. But I'd be > much happier about the idea --even as an experiment-- had the IESG been > willing to stand up and say "fascinating idea, lets try it". Full disclosure: I said "fascinating idea, let's try it". Or the semantic equivalent thereof. I thought at the time, and still think, that the IESG doesn't have to give blessing to this experiment - so I spoke only as myself. > And it > would have been even better, at least from an "experimental" context, had > the IESG chosen to say "It would be good to really do this as an > experiment and therefore to be able to make some comparisons. So let's > look at the following mix of areas, or specific groups of WGs, first, > leave the others with status quo, and see how things work out. Given the variability between areas that Eric Rescorla's numbers showed up, and the variability between groups, I think this is difficult to do. I'd be very interested in seeing someone propose metrics to measure whether or not the experiment succeeded. But I don't really see why the IESG should be the one doing that. > I'm disappointed that type of response from the IESG hasn't happened. > Maybe they don't think they have been asked. And the latter is, of > course, what my recent notes have been about: if we need a formal > document and request to publish it as an RFC and/or a formal WG call for > consensus and response, in order to get an IESG response to a "we think > this would be worth trying, do you have reactions or > suggestions/requirements about how to try it", then, IMO, we are in deep > trouble. But, going ahead with something on the grounds that it is an > experiment, without objective evaluation criteria or any real possibility > of them, and without IESG comment, input, or participation... That seems > to me to be an opportunity for some future demagogue, with some other > experiment, to try something, claim it succeeded, and then insist > --loudly and by whispering campaign-- it was a success and that IESG > failure to immediately adopt it indicates that all of those rascals > should be thrown out and the procedural structure blown up (and replaced > with one of the demagogue's liking) to mark their way. Point. *Someone* needs to do quality control and measurement on experiments. But .... the IESG has other jobs. Our standard-and-often-recommended practice when asked to do something is to figure out who to ask to do it. Who should be asked in this case, and who should do the asking? Harald From problem-statement-bounces@alvestrand.no Sat Jun 7 10:41:03 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14703 for ; Sat, 7 Jun 2003 10:41:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6101F625C4; Sat, 7 Jun 2003 16:40:33 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id B7EA0625BE; Sat, 7 Jun 2003 16:40:30 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA18878; Sat, 7 Jun 2003 07:40:06 -0700 (PDT) Message-Id: <5.1.0.14.2.20030607101949.0473e580@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 07 Jun 2003 10:28:48 -0400 To: Harald Tveit Alvestrand From: Margaret Wasserman In-Reply-To: <111100000.1054995578@askvoll.hjemme.alvestrand.no> References: <210527462.1054980094@p3.JCK.COM> <200306061324.AIB70919@mira-sjc5-c.cisco.com> <15925741524.20030606161535@brandenburg.com> <210527462.1054980094@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: John C Klensin Cc: "problem-statement@alvestrand.no" Subject: Re: Staying on Track (Re: Documenting pilots (RE: pausable explanation for the Document Series)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 At 04:19 PM 6/7/2003 +0200, Harald Tveit Alvestrand wrote: >Point. > >*Someone* needs to do quality control and measurement on experiments. >But .... the IESG has other jobs. Our standard-and-often-recommended >practice when asked to do something is to figure out who to ask to do it. > >Who should be asked in this case, and who should do the asking? The process document currently suggests forming a WG to evaluate improvements to the WG process, develop metrics, run experiments, etc... IMO, the group should focus on making iterative improvements to the quality, timeliness and predictability of WG output that are expected to have near-term results. I think that there is a lot of low-hanging fruit regarding the process used by WGs, including milestone management, reviews, etc. So, I think that we can make quite an improvement in the operation of the IETF through process improvements in this area. There has been some support for the creation of this WG, and for holding a BOF in Vienna. However, there have also been folks who have argued that a WG is "too heavyweight" to do this, and that we should be performing this function in a more adhoc manner. In particular, John has suggested that the IESG run the process. Although I accept that it is within the area of responsibility of the IESG to run this function, we also have an acknowledged overload problem for individual IESG members. So, I think that this is a perfect example of a responsibility that the IESG can, and should, delegate to members of the community with expertise in process improvement, metrics development, etc. Because I think that this activity should be open to the community, I favor a WG. What do others think? It would be nice to get some consensu on this, so I know what to say in the document. Margaret From problem-statement-bounces@alvestrand.no Sat Jun 7 10:51:17 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14888 for ; Sat, 7 Jun 2003 10:51:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 443EB625C4; Sat, 7 Jun 2003 16:50:46 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id 11EB6625BE for ; Sat, 7 Jun 2003 16:50:34 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA21046; Sat, 7 Jun 2003 07:50:06 -0700 (PDT) Message-Id: <5.1.0.14.2.20030607103526.047b6b78@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 07 Jun 2003 10:45:56 -0400 To: john.loughney@nokia.com From: Margaret Wasserman In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: RE: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 At 06:03 PM 6/4/2003 +0300, john.loughney@nokia.com wrote: > > Right. With the growth of the IETF, the increase in complexity > > and scope of our work, etc. the job of an AD has become so > > large, time-consuming and complex that there are very few people > > who can do it. And, there are even fewer people who are willing > > to do it... > >Do we have stats to back that up? I don't have any statistics, per se, but there is quite a bit of supporting evidence: - Successive nomcoms have indicated that they've had trouble finding qualified people who are willing to serve on the IESG, and they have explicitly cited the time commitment as a serious issue. - Members of the IESG have made presentations or comments at several IESG plenaries regarding the level of their workload, the number of pages of documentation they are expected to read per week, etc. - Multiple IESG members have specifically stated, during the problem effort, that they are overloaded. Margaret From problem-statement-bounces@alvestrand.no Sat Jun 7 10:52:08 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14919 for ; Sat, 7 Jun 2003 10:52:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5BED0625CC; Sat, 7 Jun 2003 16:51:34 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id D9B3A625CA; Sat, 7 Jun 2003 16:50:46 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19Of1q-000Lbb-00; Sat, 07 Jun 2003 09:50:46 -0500 Date: Sat, 07 Jun 2003 10:50:45 -0400 From: John C Klensin To: Harald Tveit Alvestrand Message-ID: <213478726.1054983045@p3.JCK.COM> In-Reply-To: <111100000.1054995578@askvoll.hjemme.alvestrand.no> References: <200306061324.AIB70919@mira-sjc5-c.cisco.com> <15925741524.20030606161535@brandenburg.com> <210527462.1054980094@p3.JCK.COM> <111100000.1054995578@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/3.0.3 (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: Staying on Track (Re: Documenting pilots (RE: pausable explanation for the Document Series)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On Saturday, 07 June, 2003 16:19 +0200 Harald Tveit Alvestrand wrote: >> As I hope my recent notes make clear, I'm not in favor of >> trying to invent procedures to alleviate any of the above, or >> of delaying things until such procedures reach some >> extraordinary consensus. But I'd be much happier about the >> idea --even as an experiment-- had the IESG been willing to >> stand up and say "fascinating idea, lets try it". > > Full disclosure: I said "fascinating idea, let's try it". Or > the semantic equivalent thereof. I thought at the time, and > still think, that the IESG doesn't have to give blessing to > this experiment - so I spoke only as myself. Good to know. I agree that the IESG shouldn't have to bless these things. But it _might_ have been helpful had your observation/ comment been a bit better advertised. For many of these things, I (and perhaps others) get nervous if there is no appearance of _anyone_ on the "inside" saying, at least, "ok, doesn't seem harmful, try it". If at least someone does, and no one speaks up and says "terrible, risky, doom, destruction,...", then going ahead seems rational. Put differently, I don't see any need for formal IESG consensus. But an informal sanity check with the IESG seems prudent. >> And it >> would have been even better, at least from an "experimental" >> context, had the IESG chosen to say "It would be good to >> really do this as an experiment and therefore to be able to >> make some comparisons. So let's look at the following mix of >> areas, or specific groups of WGs, first, leave the others >> with status quo, and see how things work out. > > Given the variability between areas that Eric Rescorla's > numbers showed up, and the variability between groups, I think > this is difficult to do. I'd be very interested in seeing > someone propose metrics to measure whether or not the > experiment succeeded. But I don't really see why the IESG > should be the one doing that. I didn't want to suggest that the IESG should do any evaluations. But, if the IESG has insights about why some things take longer than others, and what might or might not impact that, which have not be shared with the community (and my impression is that few of them have), then it is probably time. With comments like the above, please distinguish between things that I think it would be good if the IESG would do if they knew how and had the time and things that I think the community should task the IESG to do, feasible or not. If I wasn't clear enough about the above falling into the first category, I apologize. And "that type" below referred to some response along the lines of "go ahead and try it", not the experimental design. >> I'm disappointed that type of response from the IESG hasn't >> happened. Maybe they don't think they have been asked. And >> the latter is, of course, what my recent notes have been >> about: if we need a formal document and request to publish it >> as an RFC and/or a formal WG call for consensus and response, >> in order to get an IESG response to a "we think this would be >> worth trying, do you have reactions or >> suggestions/requirements about how to try it", then, IMO, we >> are in deep trouble. But, going ahead with something on >> the grounds that it is an experiment, without objective >> evaluation criteria or any real possibility of them, and >> without IESG comment, input, or participation... That seems >> to me to be an opportunity for some future demagogue, with >> some other experiment, to try something, claim it succeeded, >> and then insist --loudly and by whispering campaign-- it was >> a success and that IESG failure to immediately adopt it >> indicates that all of those rascals should be thrown out and >> the procedural structure blown up (and replaced with one of >> the demagogue's liking) to mark their way. > > Point. > > *Someone* needs to do quality control and measurement on > experiments. But .... the IESG has other jobs. Our > standard-and-often-recommended practice when asked to do > something is to figure out who to ask to do it. I wish that "figure out who to ask to do it" were true; I think significant evidence contradicts that assertion. But that is a different problem and thread. > Who should be asked in this case, and who should do the asking? Harald, my notion of "propose an experiment" is that the people doing the proposing are obligated to propose the mechanisms by which it can be evaluated and its success or failure determined. Without that, it isn't a proposal for an experiment, it is a suggestion about some sort of more-or-less ritualized exercise. The SIRS draft is especially interesting in that regard because it makes a series of assertions in likelihood terms. Are those assertions plausible? Yes. But likelihood assertions need to be testable -- at least going out and maybe coming in. And the responsibility for demonstrating how they can be tested lies with the authors, not the IESG. The IESG's sole responsibiity in this area, IMO, is that, if one of these things comes along that the IESG needs to process (and that doesn't included informal questions, or individual submissions to the RFC Editor-- although I would hope that they would apply similar criteria), and it proposes an "experiment" without a clue about evaluation, that ought to be sufficient grounds to bounce it. All of that is pretty theoretical. What I'm worried about specifically is the risk of bad experimental chains tying our ability to make rational protocol or procedural decisions in knots. There, SIRS is a lousy example: it seems like a good idea, and the authors have been pretty careful about review. If someone can say "we will go off and try this 'experiment'"... "ok, it succeeded, therefore I invoke the 'running code' principle and the IETF needs to adopt it", we slide toward a process model that I find almost as frightening as I do the canonizing of any statement the IESG, or any AD, or the Secretariat, chooses to make about procedures or the belief that we can't do anything without formal community action. We can tie ourselves in terrible knots at either extreme. john From problem-statement-bounces@alvestrand.no Sat Jun 7 11:20:04 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15341 for ; Sat, 7 Jun 2003 11:20:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 79ACD625C9; Sat, 7 Jun 2003 17:19:34 +0200 (CEST) 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 0CDBA625C4 for ; Sat, 7 Jun 2003 17:19:19 +0200 (CEST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])h57FJID13878 for ; Sat, 7 Jun 2003 18:19:18 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com ; Sat, 7 Jun 2003 18:19:17 +0300 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 7 Jun 2003 18:19:17 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 7 Jun 2003 18:19:17 +0300 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" Date: Sat, 7 Jun 2003 18:19:15 +0300 Message-ID: Thread-Topic: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) Thread-Index: AcMtBCYpfIihsiUgTlew4yYHPmrGBwAA9qtA From: To: X-OriginalArrivalTime: 07 Jun 2003 15:19:17.0465 (UTC) FILETIME=[296F3C90:01C32D08] Cc: problem-statement@alvestrand.no Subject: RE: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA15341 Hi Margaret, 2 points: 1) IESG overload. I think that this is a well known situtation 2) > And, there are even fewer people who are willing to do it... This was the point I was asking if we have any way to measure it. John > -----Original Message----- > From: ext Margaret Wasserman [mailto:mrw@windriver.com] > Sent: 07 June, 2003 17:46 > To: Loughney John (NRC/Helsinki) > Cc: problem-statement@alvestrand.no > Subject: RE: Trusting the IESG to manage the reform process > (was:Re:Doingthe Right Things?) > > > At 06:03 PM 6/4/2003 +0300, john.loughney@nokia.com wrote: > > > Right. With the growth of the IETF, the increase in complexity > > > and scope of our work, etc. the job of an AD has become so > > > large, time-consuming and complex that there are very few people > > > who can do it. And, there are even fewer people who are willing > > > to do it... > > > >Do we have stats to back that up? > > I don't have any statistics, per se, but there is quite a bit > of supporting evidence: > > - Successive nomcoms have indicated that they've had > trouble finding qualified people who are > willing to serve on the IESG, and they have > explicitly cited the time commitment as a > serious issue. > - Members of the IESG have made presentations or > comments at several IESG plenaries regarding > the level of their workload, the number of > pages of documentation they are expected to > read per week, etc. > - Multiple IESG members have specifically stated, > during the problem effort, that they are > overloaded. > > Margaret > > > From problem-statement-bounces@alvestrand.no Sat Jun 7 11:29:22 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15491 for ; Sat, 7 Jun 2003 11:29:21 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 26ABF625CC; Sat, 7 Jun 2003 17:28:51 +0200 (CEST) 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 6505E625C9 for ; Sat, 7 Jun 2003 17:28:47 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h57FVXF05606; Sat, 7 Jun 2003 08:31:33 -0700 Date: Sat, 7 Jun 2003 08:26:03 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <7883969071.20030607082603@brandenburg.com> To: John C Klensin In-Reply-To: <210527462.1054980094@p3.JCK.COM> References: <200306061324.AIB70919@mira-sjc5-c.cisco.com> <210527462.1054980094@p3.JCK.COM> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: "problem-statement@alvestrand.no" Subject: Re: Staying on Track (Re: Documenting pilots (RE: pausable explanation for the Document Series)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 John, JCK> blew it on both), we have had a habit of proposing, documenting, JCK> and sometimes even trying "experiments" which lack evaluation JCK> criteria... First, we are currently experiencing organizational lock-jaw, and the jaw is mostly locked shut. We are focused, instead, on discussing the problem rather than doing anything about it. That kind of situation calls for more a more aggressive approach to taking action. Aggressive, not brash. Second, meaningful, objective measures for the effectiveness of such actions are tough, as you know better than most IETF participants. Absent really good objective measures, I am a fan of simplistic measures. When a solution proposal has a reasonably coherent and constructive logic, and folks get engaged in debating and refining it, and others are willing to try it out, then I think we have a pretty good subjective measure of likely utility. When we've done the experiment for awhile, I'm guessing that the relative utility of it will be obvious, one way or the other. (I'll note that your question highlights a long-standing difference in our approach to things. I entirely agree with the desire to do evaluations, but believe that taking reasoned action is more important than waiting for complete analysis, evaluation or the like. My own bias is to view this in the category of best being the enemy of the good. I'd guess your own bias is brashness is the enemy of long-term effectiveness.) JCK> It establishes goals as: ... JCK> How are those merits to be evaluated so as to JCK> determine whether this is a success? The document then goes on JCK> to say: >> However, >> it is likely that drafts with at least three positive >> reviews from SIRs in different areas will experience >> much shorter IESG review cycles than drafts with fewer ... JCK> Plausible hypotheses indeed. And your concern (criticism) about this section of the document is entirely reasonable -- even valid. Frankly I made a point of not challenging this part of Brian's writing, and focused only on tuning it. There were a number of reasons for my choice. First, this particular stated outcome is good to state -- as a communication act to the IESG (ie, lobbying.) To the extent that working groups feel a lack of standing in a 'negotiation' with an AD, this should help their case, but only if their case has legitimate substance. Second, this realm is sufficiently complex to warrant the cook's attitude of "if all of the ingredients are good stuff, the odds are high that the result will be too." That is, this seems to me such a patently good mechanism to put in, I frankly do not see any potential downside. (Yes, there are opportunities for abuse, and all institutions ossify and get abused, and ...) This is fundamentally a "staff" position and its used is controlled by the working group. And, by the way, our community has shown a complete lack of skills at anything involving social analysis, nevermind social evaluation. So, waiting for development and agreement on the measures you seek is an infinite task. We don't/can't even do valid, serious measurement of whether our specifications are actually used. And *that* as quite a bit easier than the measurements you are calling for. JCK> I don't think it likely, but a counter-hypothesis is that the JCK> IESG, upon receiving a document with three or five SIRS signoffs JCK> but disagreeing anyway, would decide that it needed to give more JCK> extensive explanations to those senior people, or discuss issues JCK> with them even before going back to discuss them with the WG. JCK> That would probably positively leverage quality, but would have JCK> a negative effect on speed. a) i strongly doubt it, in the long run; in the short run, I've no doubt there is a "training" and adjusting process that will need to take place. b) we are slow enough, now, so that getting slower would not be noticed; no i do not mean it's ok to get slower, but rather than this is an unlikely outcome and that -- given that it is unlikely -- the downside of it's occurring is tolerable, in an odd sort of way. JCK> And, of course, trying to guess at whether SIRS improved quality JCK> in comparison to what the IESG would have done, to/with a given JCK> document without it. is even more difficult. We have no concept of quality measurement now. So, effectively, you are stacking a series of essentially impossible dependencies in the way of taking localized, subjectively reasonable -- and apparently reasonably popular -- action. Again, this is where our philosophies of project management diverge utterly. JJCK> For some of those WGs --perhaps the ones who were in good shape JCK> anyway but that, too, is pretty subjective-- the reviews help JCK> the IESG expedite the process. For others, they don't appear JCK> to. Do we then declare the experiment a success and try to make JCK> it mandatory? Does anyone who doesn't think it has proven JCK> itself a success get to speak up without being overwhelmed in JCK> rhetoric and forceful assertions? Do we infer that ADs who JCK> don't quickly sign off on SIRS-endorsed documents are JCK> obstructionist nit-pickers and need to be fired? And so on. The 'and so on' is key. My experimentalist training entirely agrees with you. My project management experience knows that that your points really are a trap that ensures taking no action. The and so on highlights the fact that there are an infinite set of unknowns. We cannot wait until we resolve all of them. For that matter, the ones you list are enough to make clear that we would take essentially forever before being able to start the 'experiment'. And, no, this is not a controlled experiment. JJCK> consensus. But I'd be much happier about the idea --even as an JCK> experiment-- had the IESG been willing to stand up and say JCK> "fascinating idea, lets try it". Well, I made a point of not citing this in the note to Melinda, simply to keep the focus on our difference in philosophy, but... Brian cleared this with Harald first. I classed that as a courtesy, rather than a requirement, which is why it does not satisfy your point. But it IS relevant to it. JCK> And it would have been even JCK> better, at least from an "experimental" context, had the IESG JCK> chosen to say "It would be good to really do this as an JCK> experiment and therefore to be able to make some comparisons. Having the IESG take initiative on such things would be fine, but since that has not happened, we need to take constructive action anyway. JCK> That seems JCK> to me to be an opportunity for some future demagogue, with some JCK> other experiment, to try something, claim it succeeded, and then JCK> insist --loudly and by whispering campaign-- it was a success JCK> and that IESG failure to immediately adopt it indicates that all 1. In my note to Melinda, I made a point of documenting just how extensive the community involvement in the SIRS effort had already been. This was intended to mitigate concerns about individual rashness. 2. The plan in fact got very strong positive encouragement from folks. That is another reason that concern over personal demagoguery should be reduced. 3. The serious threat from demagogues won't be reduced by any of this; they work on their own dynamics and use whatever is convenient to their purposes. If we give the worry about demagogues a veto over all change, we will remain frozen forever. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Sat Jun 7 12:41:18 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16438 for ; Sat, 7 Jun 2003 12:41:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 37C67625C2; Sat, 7 Jun 2003 18:40:47 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id 47182625C0 for ; Sat, 7 Jun 2003 18:40:39 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA19351; Sat, 7 Jun 2003 09:40:09 -0700 (PDT) Message-Id: <5.1.0.14.2.20030607123251.047d9aa0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 07 Jun 2003 12:36:19 -0400 To: Dave Crocker From: Margaret Wasserman In-Reply-To: <144363905408.20030605154702@brandenburg.com> References: <3EDDA77F.8050700@piuha.net> <3EDDA77F.8050700@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Complex Problems (Was: Re: Discipline of Internet Protocol Engineering) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Dave, At 03:47 PM 6/5/2003 -0700, Dave Crocker wrote: >The IETF has a very poor track record with fuzzy goals, >and a very good one with very concrete, very near-term and very narrow >goals. You say this repeatedly, and I agree with it, but we seem to reach different conclusions based on this fact... Your reasoning seems to run: The IETF is bad at resolving complex issues, so we should only work on small, well-defined problems. My reasons runs: The IETF is bad at resolving complex problems, so we need to find a way to get better at it. Some problems just _are_ complex... Claiming that we should only form WGs with narrow charters begs the question: How do we organize ourselves to solve the complex problems? Margaret From problem-statement-bounces@alvestrand.no Sat Jun 7 15:24:56 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20061 for ; Sat, 7 Jun 2003 15:24:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EC10D625C7; Sat, 7 Jun 2003 21:24:23 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2644E625C5 for ; Sat, 7 Jun 2003 21:24:21 +0200 (CEST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h57JOICL024131 for ; Sat, 7 Jun 2003 12:24:18 -0700 (PDT) Received: from cisco.com (sjc-vpn1-385.cisco.com [10.21.97.129]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AGY82464; Sat, 7 Jun 2003 12:20:45 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Sat, 7 Jun 2003 15:24:17 -0400 Date: Sat, 7 Jun 2003 15:24:17 -0400 From: Scott W Brim To: "problem-statement@alvestrand.no" Message-ID: <20030607192417.GG2124@sbrim-w2k01> Mail-Followup-To: Scott W Brim , "problem-statement@alvestrand.no" References: <210527462.1054980094@p3.JCK.COM> <200306061324.AIB70919@mira-sjc5-c.cisco.com> <15925741524.20030606161535@brandenburg.com> <210527462.1054980094@p3.JCK.COM> <5.1.0.14.2.20030607101949.0473e580@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030607101949.0473e580@mail.windriver.com> User-Agent: Mutt/1.4i Subject: Re: Staying on Track (Re: Documenting pilots (RE: pausable explanation for the Document Series)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Sat, Jun 07, 2003 10:28:48AM -0400, Margaret Wasserman allegedly wrote: > The process document currently suggests forming a WG to evaluate > improvements to the WG process, develop metrics, run experiments, > etc... IMO, the group should focus on making iterative > improvements to the quality, timeliness and predictability of > WG output that are expected to have near-term results. I think > that there is a lot of low-hanging fruit regarding the process > used by WGs, including milestone management, reviews, etc. So, > I think that we can make quite an improvement in the operation > of the IETF through process improvements in this area. All sounds good. > There has been some support for the creation of this WG, and for > holding a BOF in Vienna. However, there have also been folks who have > argued that a WG is "too heavyweight" to do this, and that we should > be performing this function in a more adhoc manner. In particular, > John has suggested that the IESG run the process. > > Although I accept that it is within the area of responsibility of the > IESG to run this function, we also have an acknowledged overload > problem for individual IESG members. So, I think that this is a > perfect example of a responsibility that the IESG can, and should, > delegate to members of the community with expertise in process > improvement, metrics development, etc. > > Because I think that this activity should be open to the community, I > favor a WG. > > What do others think? Why do we have design teams? For that same reason, we want a relatively small group to do most of the work in fashioning ideas and trying to get experiments done. WGs aren't the most fast-moving of structures. However, refreshing new ideas from refreshing new people are going to be very valuable, and WG design teams can get static. So what you want is a small group of people, with membership which must be churned periodically (but not too often, say once a year), who take input from a large group and come up with short-term process experiments and then push them to completion. You can put this in the working group structure if you like, and we can use NomCom's procedures for determining membership in the small group, but the only reason to do so is that WGs are all we know how to do. I would just call it a task force, an ad hoc group, a kind of directorate, some group type with a good acronym, but not bother to make it a WG. .swb From problem-statement-bounces@alvestrand.no Sat Jun 7 17:22:21 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22102 for ; Sat, 7 Jun 2003 17:22:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BEF6A625BE; Sat, 7 Jun 2003 23:21:50 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id 79121621B8; Sat, 7 Jun 2003 23:21:47 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19Ol8E-0000cV-00; Sat, 07 Jun 2003 21:21:46 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19Ol8E-0000GM-RZ; Sat, 07 Jun 2003 14:21:46 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 7 Jun 2003 14:21:46 -0700 To: Harald Tveit Alvestrand References: <74750000.1054904612@askvoll.hjemme.alvestrand.no> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: ISSUE: Goal of problem-statement document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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, in line with many contributors to the mailing list, do not > believe that the process of problem resolution will be helped > by continued rework of the root issues in what would probably > be a vain attempt to achieve any sort of consensus. Instead, > the general tenor and scope of the problems identified will > provide a guide in setting up the processes needed to resolve > the problems and provide input to the resolvers. i always found this part particularly amusing considering it is being pushed by the same folk who so strongly push for a classic software engineering management view of the wg product process. how can we think we will produce a good result if we do not first define the needs and requirements well? randy From problem-statement-bounces@alvestrand.no Sat Jun 7 17:29:40 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22304 for ; Sat, 7 Jun 2003 17:29:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C4EDC625BE; Sat, 7 Jun 2003 23:29:09 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id BE133621B8 for ; Sat, 7 Jun 2003 23:29:01 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19OlFE-0000yJ-00; Sat, 07 Jun 2003 21:29:00 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19OlFD-0000Gn-Gw; Sat, 07 Jun 2003 14:28:59 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 7 Jun 2003 14:28:58 -0700 To: Keith Moore References: <4.3.2.7.2.20030605172112.0309fe00@mailhost.iprg.nokia.com> <3EE02D2C.9040009@piuha.net> <20030606094820.59a7f558.moore@cs.utk.edu> Message-Id: Cc: hinden@IPRG.nokia.com Cc: jari.arkko@piuha.net Cc: problem-statement@alvestrand.no Subject: Re: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 >>> Perfection doesn't work. Shipping products and getting bug reports works. >> Agree 100%. > Disagree 100%. It costs much more to fix bugs after shipping > product than it does to do so beforehand. Forcing customers to > accept the costs of poor protocol design is just irresponsible. now now. we could aspire to being the microsoft of standards. sell a lot of half-baked crap, laugh our way to the bank, and not be able to face ourselves in the mirror. randy --- ps: sorry to pick on microsoft, it's the image. From problem-statement-bounces@alvestrand.no Sat Jun 7 17:39:29 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22457 for ; Sat, 7 Jun 2003 17:39:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 78727621B8; Sat, 7 Jun 2003 23:38:59 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id E97BF61C73 for ; Sat, 7 Jun 2003 23:38:53 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19OlOn-0001ef-00; Sat, 07 Jun 2003 21:38:53 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19OlOn-0000H9-4u; Sat, 07 Jun 2003 14:38:53 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 7 Jun 2003 14:38:52 -0700 To: John C Klensin References: <132303672.1054901869@p3.JCK.COM> Message-Id: Cc: "john.loughney@nokia.com" Cc: "problem-statement@alvestrand.no" Subject: Re: RE: Sloppy Charters (was: Re: Discipline of Internet Protocol Engineering) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > And, personally, I believe _that_ problem has no solution at all > unless and until a majority of the IESG are ready to stand up > and say "we are seriously overloaded, and we are ready to do > something about it. We understand that starts with accepting > the fact that we really can't do everything and then moves on to > being willing (and anxious) to look closely at any proposal that > might plausibly reduce load." some of us have executed the load reduction proposals by trying to say "no" to some things and by getting review teams in place. there are problems with this o everybody thinks we should say "no," but to other people's bright ideas, not theirs. o we catch hell for saying "no" to anything. o i often catch hell for having review teams and directorates to help me because, among other things, i bet my ass on reviewers i know and choose, not those chosen by public beauty contests. note that it is my signature that goes on a directorate's recommendation. damned if you do, damned if you don't. so, i do what seems right. randy From problem-statement-bounces@alvestrand.no Sat Jun 7 21:36:17 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28262 for ; Sat, 7 Jun 2003 21:36:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 049126238F; Sun, 8 Jun 2003 03:35:47 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 180C462206 for ; Sun, 8 Jun 2003 03:35:44 +0200 (CEST) Received: from bs.jck.com ([209.187.148.211] helo=localhost) by bs.jck.com with esmtp (Exim 4.10) id 19Op5v-000No6-00; Sat, 07 Jun 2003 20:35:41 -0500 Date: Sat, 07 Jun 2003 21:35:36 -0400 From: John C Klensin To: Randy Bush Message-ID: <1094671.1055021736@KLENSIN-TP> In-Reply-To: References: <132303672.1054901869@p3.JCK.COM> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: "john.loughney@nokia.com" Cc: "problem-statement@alvestrand.no" Subject: Re: RE: Sloppy Charters (was: Re: Discipline of Internet Protocol Engineering) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Randy, Your explanation is exactly the reason I keep suggesting that, until and unless the community really starts expressing strong support for load-reduction activities generally and those that involve saying "no" (or "it isn't good enough, fix it") in particular, it is difficult for "blaming" the IESG for doing anything other than making the best of a bad situation. I (and (I hope many others) have certainly noticed the "say 'no' to anything you like, as long as it isn't _my_ idea" nonsense. The community, and not just the IESG, needs to push back on that stuff, or we are all, I fear, doomed. So, on that dimension at least, thanks for trying and please keep it up. john --On Saturday, June 07, 2003 14:38 -0700 Randy Bush wrote: >> And, personally, I believe _that_ problem has no solution at >> all unless and until a majority of the IESG are ready to >> stand up and say "we are seriously overloaded, and we are >> ready to do something about it. We understand that starts >> with accepting the fact that we really can't do everything >> and then moves on to being willing (and anxious) to look >> closely at any proposal that might plausibly reduce load." > > some of us have executed the load reduction proposals by trying > to say "no" to some things and by getting review teams in > place. > > there are problems with this > > o everybody thinks we should say "no," but to other people's > bright ideas, not theirs. > > o we catch hell for saying "no" to anything. > > o i often catch hell for having review teams and directorates > to help me because, among other things, i bet my ass on > reviewers i know and choose, not those chosen by public > beauty contests. note that it is my signature that goes > on a directorate's recommendation. > > damned if you do, damned if you don't. so, i do what seems > right. > > randy > From problem-statement-bounces@alvestrand.no Sat Jun 7 22:09:59 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28790 for ; Sat, 7 Jun 2003 22:09:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D9EC5623D1; Sun, 8 Jun 2003 04:08:32 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5949A6238A for ; Sun, 8 Jun 2003 04:08:02 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id A1FEABF3A; Sat, 7 Jun 2003 22:07:58 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 22:07:57 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 22:07:57 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241316@tayexc13.americas.cpqcorp.net> Thread-Topic: Trusting the IESG to manage the reform process (was: Re:Doingthe Right Things?) Thread-Index: AcMp5MZwdDj0cTo/QNOWvHVbFJMm0gDfOtOg From: "Bound, Jim" To: "Brian E Carpenter" , "John C Klensin" X-OriginalArrivalTime: 08 Jun 2003 02:07:57.0761 (UTC) FILETIME=[C7BD1B10:01C32D62] Cc: problem-statement@alvestrand.no Subject: RE: Trusting the IESG to manage the reform process (was: Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA28790 Brian, I in base principle agree with you. But when an AD tells me this bit shifting this way will cause a problem and I feel the AD is completely wrong in a private discussion as author I think the AD and I should debate that bit shifting technically in front of our peers not giving me a mandate or holding up the spec or process because they are an AD. The only AD on the IESG I have ever worked with that could stand in the technical fire with me is Erik Nordmark and he is willing to go head to head technically on total technical details not the politics of interoperability (which is the next step). Scott and Allison manage that process very well as a note (or Scott Bradner did) so this was not an issue I ever saw in the Transport Area. I am not talking about architecture I am talking down dirty deep code stuff from the outcome of a protocol on implementation. An AD not being able to do this but be suspect of a spec part is fine. But: 1. That should happen early on the WG should not spend 1 year on soemthing that has been sitting in the spec and then 1 year later the AD brings it up. They should get an aw shit for that act and then later it is an aw shit with the next NOMCOM. Example declaring IPsec is wrong choice for Mobile IPv6 at the last minute a few years ago was perfect example. 2. Open up as AD in the role of AD stating they fear this or that and let the WG air it out and debate it. /jim /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Tuesday, June 03, 2003 11:27 AM > To: John C Klensin > Cc: problem-statement@alvestrand.no > Subject: Re: Trusting the IESG to manage the reform process > (was: Re:Doingthe Right Things?) > > > John C Klensin wrote: > > > > Summary: If we can't trust the current IESG for reform-process > > management, we are in deep trouble. > > We have no choice except to trust them, because the IESG > approving a BCP is the only way (short of anarchy) of > effecting change. > > So, as you were suggesting, let's divide-and-conquer by > cutting off bite sized problems, designing solutions, and > sending them to the IESG. > > Er, I'm working on one of those. If everybody here worked on > one, we might be done soon. > > Brian > From problem-statement-bounces@alvestrand.no Sat Jun 7 22:19:02 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29039 for ; Sat, 7 Jun 2003 22:19:01 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2291A623D1; Sun, 8 Jun 2003 04:17:20 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail05.zma.compaq.com (mailout.zma.compaq.com [161.114.64.105]) by eikenes.alvestrand.no (Postfix) with ESMTP id 72560621B8; Sun, 8 Jun 2003 04:16:48 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 1D7A0BBC1; Sat, 7 Jun 2003 22:16:47 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 22:16:46 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 22:16:46 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848B8@tayexc13.americas.cpqcorp.net> Thread-Topic: Trusting the IESG to manage the reform process (was: Re:Doingthe Right Things?) Thread-Index: AcMp/ED2QRMDx7CURHeUG19NykzLMwDZp33w From: "Bound, Jim" To: "Harald Tveit Alvestrand" , "Brian E Carpenter" , "John C Klensin" X-OriginalArrivalTime: 08 Jun 2003 02:16:46.0898 (UTC) FILETIME=[03210120:01C32D64] Cc: problem-statement@alvestrand.no Subject: RE: Trusting the IESG to manage the reform process (was: Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA29039 Harald, A lot of the problems are not solvable with a process or ruleset or even a mandate. When an AD is wrong give it up and move on OR if the WG overwhelming has been defeated by the WG the AD then they should give it up. This is sooooooooooooo important to be an AD. The AD primary responsibility is that the specs sent to the IESG are clear, interoperable and with other protocols dependent on them, I think now is secure or stated where it is not, and most of all keep their Area going and forward. An AD must accept in the role that what they feel is the correct technical answer will be the minority and they will loose. Use the words you want I can't and won't appease the left distaste of words like win, loose, best, worst, etc. For example WG Chairs very rarely have this problem because they are in the spot light everyday of the WG they have to look into that mirror everyday and face the music as a peer to the WG and the leader. ADs sit at another level. The trick is to make them have to look in the mirror too and face the music. And doing it the plenary is completely useless. It is almost like a joke and the IESG hopes people yell at them for a good time. To me the plenary is nothing but a joke. To me usually not entertaining. /jim > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: Tuesday, June 03, 2003 2:16 PM > To: Brian E Carpenter; John C Klensin > Cc: problem-statement@alvestrand.no > Subject: Re: Trusting the IESG to manage the reform process > (was: Re:Doingthe Right Things?) > > > > > --On tirsdag, juni 03, 2003 17:26:50 +0200 Brian E Carpenter > wrote: > > > John C Klensin wrote: > >> > >> Summary: If we can't trust the current IESG for reform-process > >> management, we are in deep trouble. > > > > We have no choice except to trust them, because the IESG > approving a > > BCP is the only way (short of anarchy) of effecting change. > > > > So, as you were suggesting, let's divide-and-conquer by cutting off > > bite sized problems, designing solutions, and sending them to the > > IESG. > > > > Er, I'm working on one of those. If everybody here worked > on one, we > > might be done soon. > > Brian, > > while I agree with you on a number of issues..... > > in side conversations, I've made a number of comments on the > difficulty of > crossing a chasm in two steps. > In particular, I believe that the problem: > > 2.5.1 Span of Authority > > Overt authority in the IETF is concentrated in the small number of > people sitting on the IESG at that time. Existing IETF > processes work > to funnel tasks on to this small number of people > (primarily the Area > Directors (ADs) in the IESG). This concentration slows up the > process and puts a very large load of responsibility on to the > shoulders of these people who are required to act as the senior > management for Working Group (WG) chairs as well as acting > as quality > backstops for the large number of documents issued by the IETF. > > cannot be solved by making small changes to the IETF and IESG > procedures; > we need to change the way we make decisions, which is a BIG change. > > [yes, I have issues with the wording. But that's not important.] > > If there is a core problem that must be solved and cannot be > solved by > biting off small pieces, I think we cannot afford to ignore it. > > Harald > > > From problem-statement-bounces@alvestrand.no Sat Jun 7 22:20:18 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29082 for ; Sat, 7 Jun 2003 22:20:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CE762623D1; Sun, 8 Jun 2003 04:19:46 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail04.zma.compaq.com (mailout.zma.compaq.com [161.114.64.104]) by eikenes.alvestrand.no (Postfix) with ESMTP id 503356238A for ; Sun, 8 Jun 2003 04:19:37 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 313B5A0A1; Sat, 7 Jun 2003 22:19:36 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 22:19:35 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 22:19:35 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848B9@tayexc13.americas.cpqcorp.net> Thread-Topic: Document Series Thread-Index: AcMqLy2Rj8/5dsCcQrmfLKnrhRzECgDNRuzw From: "Bound, Jim" To: "Bob Hinden" , "Dave Crocker" X-OriginalArrivalTime: 08 Jun 2003 02:19:35.0990 (UTC) FILETIME=[67EA6560:01C32D64] Cc: problem-statement@alvestrand.no Subject: RE: Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA29082 This is exactly what is happening in the IETF. /jim > -----Original Message----- > From: Bob Hinden [mailto:hinden@IPRG.nokia.com] > Sent: Tuesday, June 03, 2003 8:03 PM > To: Dave Crocker > Cc: problem-statement@alvestrand.no > Subject: Re: Document Series > > > Dave, > > >Here is my own thought on useful stages: > > > >1. Technical discussion and convergence -- form community > consensus 2. > >Technical refinement -- lock down the details 3. Proof of > concept and > >debugging 4. Stability -- community operational acceptance > > > >The first is pure mayhem, and that's good. People explore, suggest, > >debate. Eventually, they should start to form group preferences and > >focus on getting the details worked into a specification > that provides > >detail which readers can understand and see as coherent and > sufficient > >for achieving a specific set of useful functions. Then they test the > >thing, to see whether interoperable implementations can be > developed. > >Then they actually use the thing, eventually achieving some sort of > >critical mass of deployment. > > > >Now, the clever reader will observe that we already have > exactly these > >stages. (Personal I-D, WG ID -> PS, Draft, Full.) Yet the > latter 2 are > >virtually unused. > > As you correctly point out the IETF (and as implemented by > the IESG) is not > using the standards process we have defined. It has been > changed where the > initial barrier has been raised very high at Proposed > Standard and hardy > anything gets to Draft standard, let alone (Full) Standard. > > I think that many of the problems folks are complaining about > stem from > this. It causes the IESG to worry about letting a document > get to PS that > is not perfect. This results in many detailed reviews and > documents being > blocked for what might seem minor reasons. This in turn > creates a work > load on the IESG that is close to impossible. The resulting > delays cause > frustration between authors, chairs, working groups, AD, etc. > I think that > a lot of this stems from trying to make PS the biggest hurdle. > > I think that if we implemented the standard process as > written (and as > intended) that many of these problems would go away. > Perfection would only > have to be achieved at Standard (and close to perfection at Draft > standard). This would mean that problems with specifications > could be > found by people implementation the protocols and running into > problems, and > then bringing the issues back into the working groups. > Interoperability > problems would be found. This would spread the load of improving the > quality of the specifications to a much larger community of > people than > just the IESG members. Running code and interoperability > would be the > real test for quality. > > Enforcing the time outs would create incentives to move the > specifications > through the standards process. I also suspect that some > (perhaps many) > specifications never really get implemented, so as long as we > enforced the > time outs as specified, that these would just go away. > > There is a lot of parallels with the multi-step IETF > standards process as > with building products. First versions of products always have > problem. Most successful product companies learn that trying > to make the > first product perfect is counter productive because it > creates long delays > and the real test is getting the product to the costumers. Then the > company really learns how well the product works and meets > the market need > (i.e., requirements). It through creating new versions of > the products > that problems are fixed and quality is improved. Companies > that delay the > first release until the product is perfect usually go out of > business. I > wonder if that is what is happening with the IETF. > > Bob > > From problem-statement-bounces@alvestrand.no Sat Jun 7 22:23:52 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29169 for ; Sat, 7 Jun 2003 22:23:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 40BCC623D1; Sun, 8 Jun 2003 04:22:05 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail03.zma.compaq.com (mailout.zma.compaq.com [161.114.64.103]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9170D6238A for ; Sun, 8 Jun 2003 04:21:35 +0200 (CEST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id E642953B; Sat, 7 Jun 2003 22:21:32 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 22:21:32 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 22:21:32 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848BA@tayexc13.americas.cpqcorp.net> Thread-Topic: Document Series Thread-Index: AcMqMj1JMWIrZEveQVupOi270GNR9QDMiOLQ From: "Bound, Jim" To: "Joel M. Halpern" , X-OriginalArrivalTime: 08 Jun 2003 02:21:32.0734 (UTC) FILETIME=[AD801DE0:01C32D64] Subject: RE: Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA29169 I completely disagree with you Mr. Halpern. The standard is not to be as robust or mean't to be at PS. Please re-read Bob Hinden's mail more carefully. /jim > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > Sent: Tuesday, June 03, 2003 8:14 PM > To: problem-statement@alvestrand.no > Subject: Re: Document Series > > > I think we are each making assumptions about the history that > led to this, > and it would not surprise me if we are making different > assumptions. Note that I do not have data to back my > understanding / memory, so I may > well be confused. > > My understanding is that the higher bar to PS arose as a > consequence of > things being widely deployed at PS and things not advancing > to Draft rather > than the deployment and non-advancement being a consequence > of the high bar. > > This is important in the sense that if the lack of > advancement came first, > then simply lowering the bar will not help us get better > standards, and in > fact could result in our ending up with lower quality > documents permanently. > > Yours, > Joel M. Halpern > > At 05:03 PM 6/3/2003 -0700, Bob Hinden wrote (in response to > Dave Crocker): > >As you correctly point out the IETF (and as implemented by > the IESG) is > >not using the standards process we have defined. It has > been changed > >where the initial barrier has been raised very high at > Proposed Standard > >and hardy anything gets to Draft standard, let alone (Full) Standard. > > > >I think that many of the problems folks are complaining > about stem from > >this. It causes the IESG to worry about letting a document > get to PS that > >is not perfect. This results in many detailed reviews and > documents being > >blocked for what might seem minor reasons. This in turn > creates a work > >load on the IESG that is close to impossible. The resulting > delays cause > >frustration between authors, chairs, working groups, AD, > etc. I think > >that a lot of this stems from trying to make PS the biggest hurdle. > > > From problem-statement-bounces@alvestrand.no Sat Jun 7 22:29:23 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29405 for ; Sat, 7 Jun 2003 22:29:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BE17C623D1; Sun, 8 Jun 2003 04:28:40 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7B8376238A for ; Sun, 8 Jun 2003 04:28:25 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id CC9D9BE04; Sat, 7 Jun 2003 22:28:24 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 22:28:24 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 22:28:22 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241317@tayexc13.americas.cpqcorp.net> Thread-Topic: Document Series Thread-Index: AcMqnHzzalSfhnJOTDW+bxmuAvw/+QCyG48A From: "Bound, Jim" To: "Ralph Droms" , X-OriginalArrivalTime: 08 Jun 2003 02:28:24.0690 (UTC) FILETIME=[A30B9D20:01C32D65] Subject: RE: Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA29405 My view is: PS is for base prototype of a spec and then implementation. DS is for pre-product implementation and if lots do it product implementation. S(full) is lots of entities are using it and it does not have to be the entire Internet. Anything more than this will result in late time to market and the result of that is being seen today, and soon we will see protocol proposals to other than the IETF to other SDOs if we don't fix this and the initial death of this SDO except for maintenance of the current IP (which is a large job and we call it in business the cash cow). But the new and interesting work required for the market will go elsewhere if we don't fix this. I think that should be stated as a problem too. Most of us don't want to have to deal with multiple SDOs to work on the IP standards but we are to a minor degree already. /jim > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Wednesday, June 04, 2003 9:23 AM > To: problem-statement@alvestrand.no > Subject: Re: Document Series > > > My experience with DS and full Standard is that no one is > interested because of the lack of perceived difference > between the requirements between the standards levels and the > lack of perceived added value in progressing a spec to DS or > full standard. That is, I disagree with Brian's statement > about the requirements for DS and full standard being too > high - I think the problem is a lack of differentiation among > the three standards levels. > > Here's how I see the standards track: > The required correctness for PS is high enough that a PS spec > is "good enough" for vendor implementation and deployment. > The reward for moving to DS and full standard is not worth > the investment of effort. > > The tension I see is the need for a specification that is > sufficiently baked and stable to be used for prototyping, > interoperability testing and proof-of-correctness for the > spec doc, but that does *not* result in deployment. It's the > premature deployment that (a) casts goofs in the spec in > stone and (b) eliminates any motivation to move the > specification through the standards track. > > - Ralph > > At 02:58 PM 6/4/2003 +0200, Brian E Carpenter wrote: > >Keith Moore wrote: > >> > >> O> My understanding is that the higher bar to PS arose as a > >> O> consequence of > >> > things being widely deployed at PS and things not advancing to > >> > Draft rather than the deployment and non-advancement being a > >> > consequence of the high bar. > >> > >> that's my understanding also. > >> > >> > This is important in the sense that if the lack of > advancement came > >> > first, then simply lowering the bar will not help us get better > >> > standards, and in fact could result in our ending up with lower > >> > quality documents permanently. > >> > >> I'm in strong agreement with this. What we need to do is > find a way > >> for standards to at least the level that is currently > required for PS > >> more quickly, not to lower the bar for PS. > > > >Fully agree. > > > >> We might even need to raise the bar slightly. > > > >Do you mean that we are frequently releasing PS documents > that contain > >significant defects? We certainly can't expect PS documents to be > >perfect. > > > >Another problem I see is that the barrier to Standard is so > high that > >nobody is interested, and the barrier to DS is high enough that very > >few people are interested. That being so, apart from some academic > >ideals, I question the value of having 3 grades at all. > Since we hardly > >use the top two grades, why have them? > > > > Brian > > From problem-statement-bounces@alvestrand.no Sat Jun 7 22:32:24 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29463 for ; Sat, 7 Jun 2003 22:32:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 756EE6257F; Sun, 8 Jun 2003 04:31:53 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail03.zma.compaq.com (mailout.zma.compaq.com [161.114.64.103]) by eikenes.alvestrand.no (Postfix) with ESMTP id AECAF6238A for ; Sun, 8 Jun 2003 04:31:39 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id D98676C8; Sat, 7 Jun 2003 22:31:37 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 22:31:37 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 22:31:37 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> Thread-Topic: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) Thread-Index: AcMqoxC+ddOIl6sFQniiEEs5SRZYPACws9RQ From: "Bound, Jim" To: "Margaret Wasserman" , "Brian E Carpenter" X-OriginalArrivalTime: 08 Jun 2003 02:31:37.0736 (UTC) FILETIME=[161C1880:01C32D66] Cc: problem-statement@alvestrand.no Subject: RE: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA29463 One solution is for the ADs to entrust more authority and empower chairs to make stronger decisions on what should and should not move forward. But then the AD would have to give up some of their authority too. /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Wednesday, June 04, 2003 10:06 AM > To: Brian E Carpenter > Cc: problem-statement@alvestrand.no > Subject: Re: Trusting the IESG to manage the reform process > (was:Re:Doingthe Right Things?) > > > > Hi Brian, > > At 02:49 PM 6/4/2003 +0200, Brian E Carpenter wrote: > >I think there was something else. The IETF also put in place > mechanisms > >for renewal and accountability of the decision-taking group. > And that, > >if I'm not mistaken, was to reduce the incidence of hubris. > > > >In other words, there was no attempt to solve a scaling problem. > > > >What Harald is referring to is a scaling problem, imho. > > Right. With the growth of the IETF, the increase in > complexity and scope of our work, etc. the job of an AD has > become so large, time-consuming and complex that there are > very few people who can do it. And, there are even fewer > people who are willing to do it... We need to figure out > some way to solve this problem, and that almost certainly > involve some reorganization and re-definition of roles at the > top of the IETF. > > This could be driven by the IESG -- they could create new > roles under themselves and delegate work. Or, it could be > driven by the community. I actually would have preferred the > former, but the IESG seems to have chosen the latter... > > > > If the latter suffices, then in fact we continue to make > decisions > > > in the same way. We simply target different types of decisions to > > > different groups. > > > >...or simply give the existing decision-taking group better input to > >work with, such as fully reviewed and nit-free documents. > > I think that we're all in agreement that the quality, > timeliness and predictability of WG output is unacceptably low. > > It might be amusing to watch WG chairs come up with ways to > blame the IESG for this -- they didn't charter us properly, > they didn't manage us properly, they didn't give us early > feedback, etc... But, that's all just whining. It is the > responsibility of the WG chair to manage the WG to produce > high quality and timely work, to get adequate review for our > documents, and to manage our milestones. And, most of us are > falling down on the job. > > As I'm sure you know, high quality, nit-free documents don't > happen by accident... And, it doesn't matter how many times > we ask for them, or whine about the fact that our editors > don't produce them. We need to actually put some quality > processes in place during WG creation of these documents to > improve the quality of WG output. > > IMO, though, this won't solve the scaling problems that have > lead to the ADs job being so large/complex that there is a > limited pool of people that can/will do it... That needs to > be solved separately. > > Margaret > > > > > From problem-statement-bounces@alvestrand.no Sat Jun 7 22:34:16 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29483 for ; Sat, 7 Jun 2003 22:34:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C880C623D1; Sun, 8 Jun 2003 04:33:42 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by eikenes.alvestrand.no (Postfix) with ESMTP id 246DE623D1; Sun, 8 Jun 2003 04:32:36 +0200 (CEST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id BC657855B; Sat, 7 Jun 2003 22:32:34 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 22:32:34 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 22:32:33 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848BF@tayexc13.americas.cpqcorp.net> Thread-Topic: Trusting the IESG to manage the reform process (was: Re:Doingthe Right Things?) Thread-Index: AcMqqSt7Jhc6iGh9Q7uHypQHUdziZwCvPL4A From: "Bound, Jim" To: "Keith Moore" , "Dave Crocker" X-OriginalArrivalTime: 08 Jun 2003 02:32:34.0609 (UTC) FILETIME=[38023A10:01C32D66] Cc: harald@alvestrand.no Cc: dhc@dcrocker.net Cc: problem-statement@alvestrand.no Subject: RE: Trusting the IESG to manage the reform process (was: Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA29483 I think it did a lot of good for this community. /jim > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Wednesday, June 04, 2003 10:50 AM > To: Dave Crocker > Cc: harald@alvestrand.no; dhc@dcrocker.net; moore@cs.utk.edu; > problem-statement@alvestrand.no > Subject: Re: Trusting the IESG to manage the reform process > (was: Re:Doingthe Right Things?) > > > > The Kobe change to IETF organization was actually quite small. > > Strategic. Essential. > > and it's caused a lot of harm. > From problem-statement-bounces@alvestrand.no Sat Jun 7 22:35:04 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29506 for ; Sat, 7 Jun 2003 22:35:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9A97E6257F; Sun, 8 Jun 2003 04:34:34 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail05.zma.compaq.com (mailout.zma.compaq.com [161.114.64.105]) by eikenes.alvestrand.no (Postfix) with ESMTP id 277CA6238A for ; Sun, 8 Jun 2003 04:33:58 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 6E253BD77; Sat, 7 Jun 2003 22:33:57 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 22:33:57 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 22:33:56 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848C0@tayexc13.americas.cpqcorp.net> Thread-Topic: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) Thread-Index: AcMqs9DbgtyAKSCXQ6Wxe3VlXtNp2wCsnsfQ From: "Bound, Jim" To: "EKR" , "Wijnen, Bert (Bert)" X-OriginalArrivalTime: 08 Jun 2003 02:33:57.0297 (UTC) FILETIME=[694B6A10:01C32D66] Cc: problem-statement@alvestrand.no Cc: Brian E Carpenter Subject: RE: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA29506 Reward and Punshiment should be used more. /jim > -----Original Message----- > From: Eric Rescorla [mailto:ekr@rtfm.com] > Sent: Wednesday, June 04, 2003 12:13 PM > To: Wijnen, Bert (Bert) > Cc: problem-statement@alvestrand.no; Brian E Carpenter > Subject: Re: Trusting the IESG to manage the reform process > (was:Re:Doingthe Right Things?) > > > "Wijnen, Bert (Bert)" writes: > > > > > > > > > Absent specific proposals, we cannot know whether the cited > > > > problem of a bottleneck requires us "to change the way we make > > > > decisions" or more simply requires that we do > divide-and-conquer > > > > with existing tasks and responsibilities. > > > > > > > > If the latter suffices, then in fact we continue to > make decisions > > > > in the same way. We simply target different types of > decisions to > > > > different groups. > > > > > > ...or simply give the existing decision-taking group > better input to > > > work with, such as fully reviewed and nit-free documents. > > > > > Amen! > > I'm afraid we're now back to the issue I mentioned before SF. > Do WGs get rewarded for producing such documents and punished > for not producing them. I'm not sure that's true. To the > extent it's not, it's hardly surprising that they don't. > > -Ekr > > -- > [Eric Rescorla ekr@rtfm.com] > http://www.rtfm.com/ > From problem-statement-bounces@alvestrand.no Sat Jun 7 22:41:23 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29614 for ; Sat, 7 Jun 2003 22:41:21 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F0FCE6259B; Sun, 8 Jun 2003 04:39:41 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail03.zma.compaq.com (mailout.zma.compaq.com [161.114.64.103]) by eikenes.alvestrand.no (Postfix) with ESMTP id 32F6D6238A; Sun, 8 Jun 2003 04:38:23 +0200 (CEST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 78974678; Sat, 7 Jun 2003 22:38:22 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 22:38:22 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 22:38:21 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848C1@tayexc13.americas.cpqcorp.net> Thread-Topic: pausable explanation for the Document Series Thread-Index: AcMrKhGp3NH2A1elSOuWwm0u5K0fEwCPHBCg From: "Bound, Jim" To: "Harald Tveit Alvestrand" , , X-OriginalArrivalTime: 08 Jun 2003 02:38:22.0179 (UTC) FILETIME=[072D3330:01C32D67] Subject: RE: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA29614 If we want PS to mean do prototype but don't product the outcome. Then if a spec cannot get to PS say in 5 IETF meetings then it should just die or got to experimental. Then we have to use our partners in industry like ISOC, Fora, other Standards bodies, and the Press to make it clear to the market and vendors that PS will no longer or treated by the IETF as "installed base" to not change it. We would have to grandfather all stuff before that for purposes of installed base or it would be "perceived" as coo to kill something. Most vendors are very careful with PS. /jim > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: Thursday, June 05, 2003 2:14 AM > To: john.loughney@nokia.com; problem-statement@alvestrand.no > Subject: Re: pausable explanation for the Document Series > > > > > --On torsdag, juni 05, 2003 06:53:57 +0300 > john.loughney@nokia.com wrote: > > > Hi all, > > > > I've always assumed that industry does not use DS or FS > simply because > > the IETF does not produce them in any great number. The > IETF doesn't > > seem to produce them because WGs are, in general, charted > to make PSs; > > after which, they try to shut down. There is very little > incentive in > > the IETF progress documents. Industry, being industry, takes what > > they get & runs with it. > > > > I'm not sure how many of the proposals discussed would impact this > > situation in any meaningful way. > > at least two try to: > > Brian's DS/Full merger > > > Maintenance Teams > > > but industry running on PS is not a core problem, I think. > > The more-core problem is industry running on protocols with > design flaws > and protocol bugs, which cannot be fixed because of the > installed base. > > If PS was perfect, this would not be a serious problem. But > it isn't so. > > (my favourite example of deployment lock-in is the MIME > version number - > when the first post-RFC revision of the MIME spec was done, > we wanted to > increase the version number from 1.0 to 1.1, to celebrate the > fixing of > many bugs and unclear points in the specification. > One vendor had a product in days-before-release state, which > would not > interoperate with UAs that sent 1.1 in the version number. > We decided to freeze the version number at 1.0 forever...... > not a big loss to humanity, but it looks stupid.) > > Harald > > From problem-statement-bounces@alvestrand.no Sat Jun 7 22:41:51 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29632 for ; Sat, 7 Jun 2003 22:41:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5A41B6258A; Sun, 8 Jun 2003 04:41:17 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4601A6258A; Sun, 8 Jun 2003 04:39:30 +0200 (CEST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 8AA2CBD42; Sat, 7 Jun 2003 22:39:29 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 22:39:29 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 22:39:28 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848C2@tayexc13.americas.cpqcorp.net> Thread-Topic: IETF mission (RE: pausable explanation for the Document Series) Thread-Index: AcMrTgTobZ9GHOK2RYO2cqXIkI18VQCGQXUA From: "Bound, Jim" To: "Harald Tveit Alvestrand" , , X-OriginalArrivalTime: 08 Jun 2003 02:39:29.0367 (UTC) FILETIME=[2F394670:01C32D67] Subject: RE: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA29632 Every spec MUST have applicability statement or it should not get past the RFC Editor even for experimental. /jim > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: Thursday, June 05, 2003 6:34 AM > To: john.loughney@nokia.com; problem-statement@alvestrand.no > Subject: IETF mission (RE: pausable explanation for the > Document Series) > > > > > --On torsdag, juni 05, 2003 11:36:04 +0300 > john.loughney@nokia.com wrote: > > >> The more-core problem is industry running on protocols with design > >> flaws and protocol bugs, which cannot be fixed because of the > >> installed base. > > > > Depends upon how you look at things. I would say that the > more-core > > problem is that our quality control may be less than ideal. As the > > IETF is not a protocol enforcement agency, what the > industry does with > > what we make is beyond our control, in my opinion. > > actually this comes back to the IETF mission statement thing.... > > if the mission of the IETF is to "make the Internet work", with our > particular task in pursuit of that mission being to "make > high quality, > timely standards for the Internet", then flaws in the > standards that the > industry runs on are signs that we haven't achieved our mission. > > I don't think we can assert "control", in the sense of "I decide, it > happens" - if I asserted that I was in control of the IETF, > I'd be as silly > as if the IETF claimed that it was in control of the Internet. > > But I do have influence over what the IETF does (and so do > you), and the > IETF does have influence over what the industry does. > > Might be semantic quibbling .... then again, it might > actually matter when > we decide what to do. > > > > >> If PS was perfect, this would not be a serious problem. > But it isn't > >> so. > > > > This touches on the relevant issue. Should PS be perfect? At what > > level do we raise (or lower) the bar? What can we do about it? One > > possibility would be that we make sure that PS documents are as > > perfect as possible (raise the bar). Another could be to > require some > > sort of best practices document for most major PS documents (which > > would capture operational issues, etc). > > RFC 2026 invented the term "applicability statements" - > that's a term that > seems to have fallen by the wayside...... > > > Another > > could be your Maintenance Team idea, especially if it is > coupled with > > an object that captures all of the relevant RFCs, drafts in > progress, > > bug reports, etc. I also think that if we go the route of > Maintenence > > Teams, perhaps the object could also preserve any issue > lists created > > during WG / IETF last call. > > The "protocol, its current state and history book" site? > Seems to make > sense to me..... much of ancient history is actually > preserved in various > archives, but it can be VERY hard to find...... > > Nice thought! > > From problem-statement-bounces@alvestrand.no Sat Jun 7 22:46:58 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29663 for ; Sat, 7 Jun 2003 22:46:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A9701623D1; Sun, 8 Jun 2003 04:46:26 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by eikenes.alvestrand.no (Postfix) with ESMTP id 74F7D6238A for ; Sun, 8 Jun 2003 04:46:02 +0200 (CEST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 93F53A12C; Sat, 7 Jun 2003 22:46:01 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 22:46:01 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 22:46:00 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241318@tayexc13.americas.cpqcorp.net> Thread-Topic: IETF mission (RE: pausable explanation for the Document Series) Thread-Index: AcMre3Vbc2PVO7qJRiaGGe+9aqk8/gB696OQ From: "Bound, Jim" To: "Charles E. Perkins" , X-OriginalArrivalTime: 08 Jun 2003 02:46:01.0460 (UTC) FILETIME=[18EDEB40:01C32D68] Cc: problem-statement@alvestrand.no Subject: RE: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA29663 This is not to Charlie. > Be conservative in the claimed applicability, but generous > in the potential applicability. I disagree with this and its orginal words for many reasons. It says NOTHING in logic only in emotion. And with 911 and SPAM being liberal in what one receives is history. Customers don't want to hear this. I understand well the implememtation of TCP and how that particular and other transport code works and that part I take as what John was speaking about. But these great words have become a political football for people to tout a strategy when they really don't have a strategy or a clue at a moment when they believe they want to respond. Or in the evil case when they want a backdoor to put proprietary vendor extensions in their product and force behaviors on SDO protocols in that manner and that John never meant't to be I strongly believe. /jim From problem-statement-bounces@alvestrand.no Sat Jun 7 22:49:56 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29712 for ; Sat, 7 Jun 2003 22:49:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CFDFF6258A; Sun, 8 Jun 2003 04:48:47 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail04.zma.compaq.com (mailout.zma.compaq.com [161.114.64.104]) by eikenes.alvestrand.no (Postfix) with ESMTP id 10E056238A; Sun, 8 Jun 2003 04:48:22 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id DE544A2EA; Sat, 7 Jun 2003 22:48:20 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 22:48:20 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 22:48:20 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848C4@tayexc13.americas.cpqcorp.net> Thread-Topic: pausable explanation for the Document Series Thread-Index: AcMrwzNgRbJNrmOcR7SYM/h2hS2YUgBpPNWg From: "Bound, Jim" To: "Bob Hinden" , "Harald Tveit Alvestrand" X-OriginalArrivalTime: 08 Jun 2003 02:48:20.0776 (UTC) FILETIME=[6BF7DA80:01C32D68] Cc: john.loughney@nokia.com Cc: problem-statement@alvestrand.no Subject: RE: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA29712 > Perfection doesn't work. Shipping products and getting bug > reports works. It is also called spiral engineering. And I again fully agree with Bob. /jim From problem-statement-bounces@alvestrand.no Sat Jun 7 22:54:00 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29739 for ; Sat, 7 Jun 2003 22:53:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4EA776258A; Sun, 8 Jun 2003 04:51:40 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by eikenes.alvestrand.no (Postfix) with ESMTP id 63A9E6238A for ; Sun, 8 Jun 2003 04:50:54 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 2A985707; Sat, 7 Jun 2003 22:50:53 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 22:50:53 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 22:50:52 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848C5@tayexc13.americas.cpqcorp.net> Thread-Topic: Discipline of Internet Protocol Engineering Thread-Index: AcMrw+AEe5HEI2dyTlaGoRAmBi7FwQBpINEw From: "Bound, Jim" To: "Bob Hinden" , "Dave Crocker" X-OriginalArrivalTime: 08 Jun 2003 02:50:53.0041 (UTC) FILETIME=[C6B9A610:01C32D68] Cc: problem-statement@alvestrand.no Subject: RE: Discipline of Internet Protocol Engineering X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA29739 Not only that but be proud and excited about being and doing the management instead being an architect for the Internet which the IETF is not regardless. Again its the mission. The one thing in our spec that needs more work: draft-ietf-problem-process-00.txt Is the discussion of core values. Should we call it something else? /jim > -----Original Message----- > From: Bob Hinden [mailto:hinden@IPRG.nokia.com] > Sent: Thursday, June 05, 2003 8:38 PM > To: Dave Crocker > Cc: problem-statement@alvestrand.no > Subject: Re: Discipline of Internet Protocol Engineering > > > > >Properly designed milestones will, at least, set the stage > for exactly > >that kind of thinking. Or perhaps the way to talk about > this is that > >you are calling for the intermediate milestones that will > achieve the > >ones in the charter. > > > >Egad. As you note, this starts sounding like classic project > >management. > > > >What a thought. > > Worse still, we might even want people in the IESG with some real > management experience. > > Bob > > From problem-statement-bounces@alvestrand.no Sat Jun 7 22:54:38 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29755 for ; Sat, 7 Jun 2003 22:54:37 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 02AA3623D1; Sun, 8 Jun 2003 04:53:59 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail05.zma.compaq.com (mailout.zma.compaq.com [161.114.64.105]) by eikenes.alvestrand.no (Postfix) with ESMTP id 71840625C3; Sun, 8 Jun 2003 04:52:45 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 71C6DBE4D; Sat, 7 Jun 2003 22:52:44 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 22:52:44 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 22:52:43 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848C6@tayexc13.americas.cpqcorp.net> Thread-Topic: pausable explanation for the Document Series Thread-Index: AcMrwyTvX9dwcQqQTKSiBi/uD7M/KwAJvSkQAF+txKA= From: "Bound, Jim" To: , , X-OriginalArrivalTime: 08 Jun 2003 02:52:44.0275 (UTC) FILETIME=[09069C30:01C32D69] Cc: problem-statement@alvestrand.no Subject: RE: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA29755 And what bugs are permitted and not permitted and why we made those trade-offs when sending to the AD should be done. If the AD don't agree have them relay clearly why they think the WG is wrong and come to the mail list. /jim > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Friday, June 06, 2003 1:15 AM > To: hinden@iprg.nokia.com; harald@alvestrand.no > Cc: problem-statement@alvestrand.no > Subject: RE: pausable explanation for the Document Series > > > Hi Bob, > > > >The more-core problem is industry running on protocols with design > > >flaws > > >and protocol bugs, which cannot be fixed because of the > installed base. > > > > > >If PS was perfect, this would not be a serious problem. > But it isn't > > >so. > > > > First versions of anything are never perfect. This is true for > > products > > and standards. As long as we try to solve the problem by > trying to make > > the first version perfect we will fail. It only delays the > first version > > and causes it to miss the market need. The only solution I > know of is to > > do new versions. This seems to work well in industry. > > > > Perfection doesn't work. Shipping products and getting bug > > reports works. > > I agree with you on this point. Until someone writes an ascii to > C (or your favorite coding language) to convert I-Ds to > running code, it'll be impossible to ensure that a PS does > not have bugs. A more sensible way forward, in my opinion, would be > to ensure a better way for bug reporting, document updating, > etc. I think Harald's maintainence teams is a good potential solution. > > John > From problem-statement-bounces@alvestrand.no Sat Jun 7 22:55:44 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29794 for ; Sat, 7 Jun 2003 22:55:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A2BD3623D1; Sun, 8 Jun 2003 04:55:12 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail05.zma.compaq.com (mailout.zma.compaq.com [161.114.64.105]) by eikenes.alvestrand.no (Postfix) with ESMTP id 486006238A for ; Sun, 8 Jun 2003 04:54:57 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 83342BE4D; Sat, 7 Jun 2003 22:54:56 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 22:54:56 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 22:54:55 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848C7@tayexc13.americas.cpqcorp.net> Thread-Topic: pausable explanation for the Document Series Thread-Index: AcMr8diTolThe3JPSleHn9v+9uDcfQBdzokQ From: "Bound, Jim" To: , "Bob Hinden" X-OriginalArrivalTime: 08 Jun 2003 02:54:56.0399 (UTC) FILETIME=[57C721F0:01C32D69] Cc: problem-statement@alvestrand.no Subject: RE: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA29794 And a lot of them are just sitting there because either someone forgot or afraid of going to PS to the ADs now they have made it so painful. Example IPv6 MLDv3 to support exactly what we do for IGMPv3. Unreal. /jim > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Friday, June 06, 2003 1:57 AM > To: Bob Hinden > Cc: problem-statement@alvestrand.no > Subject: Re: pausable explanation for the Document Series > > > Bob Hinden wrote: > > >> The more-core problem is industry running on protocols with design > >> flaws and protocol bugs, which cannot be fixed because of the > >> installed base. > >> > >> If PS was perfect, this would not be a serious problem. > But it isn't > >> so. > > > > > > First versions of anything are never perfect. This is true for > > products > > and standards. As long as we try to solve the problem by > trying to make > > the first version perfect we will fail. It only delays the first > > version and causes it to miss the market need. The only > solution I know > > of is to do new versions. This seems to work well in industry. > > > > Perfection doesn't work. Shipping products and getting bug reports > > works. > > Agree 100%. Waterfall development vs. incremental > development. Serious debates early on in the project how all > possible features "must" be supported. Claims that engineers > would not make the mistakes they usually do, if they had just > done more "planning" or "design". Introduction of reviews, so > that more problems can be caught. Claims that the product we > are making is soooo important that we can not possibly have > any bugs or missing features in it. In the end, key success > factors for the project are missed, because no one bothered > to try out how the thing would work out in real usage. Or > competition is on its improvement cycle 17 when your first > buggy release comes out. Or you run out of money. Finally, > the management blames the engineers for bad quality. > > I've been there in the distant past, but I know better now. > But I'm alarmed that the above sounds very much like the > discussions we're having here. > > A few observations on what this might mean for > the IETF: > > - It really is essential to get real usage, not just > more reviews or interop tests. So *some* amount of > industry adoption early on is required. > > - Having to "fix" a standard (e.g. deprecate site-locals) > is not a sign of bad early specifications, its a sign > of being able to learn and adopt. > > - While we normally don't like to compromise on things > like quality, security, scalability, we have to learn > to do things in pieces better. And when we are already > doing things in small pieces, we need to have a better > view of the full architecture/roadmap early on. > > - This doesn't necessarily mean that we have to put out > more PS RFCs with a lower quality. We could keep > ahead of the industry's exaggeration of PS status > value by introducing a new document level lower in > chain. > > --Jari > > > From problem-statement-bounces@alvestrand.no Sat Jun 7 23:00:02 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29865 for ; Sat, 7 Jun 2003 23:00:01 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 84D53623D1; Sun, 8 Jun 2003 04:57:24 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by eikenes.alvestrand.no (Postfix) with ESMTP id E13946238A for ; Sun, 8 Jun 2003 04:56:49 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id C98FBBC64; Sat, 7 Jun 2003 22:56:48 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 22:56:48 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 22:56:48 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848C8@tayexc13.americas.cpqcorp.net> Thread-Topic: pausable explanation for the Document Series Thread-Index: AcMr8diTolThe3JPSleHn9v+9uDcfQBd3TEw From: "Bound, Jim" To: , "Bob Hinden" X-OriginalArrivalTime: 08 Jun 2003 02:56:48.0617 (UTC) FILETIME=[9AAA3D90:01C32D69] Cc: problem-statement@alvestrand.no Subject: RE: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA29865 This sounds like really good input to our process draft I suggest too and instead of just having Be conservative what you send but liberal in what your receive how about adding what Bob Hinden just said about products and bugs and add that to our "core" values and it would mean a lot more and get a lot more done. /jim > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Friday, June 06, 2003 1:57 AM > To: Bob Hinden > Cc: problem-statement@alvestrand.no > Subject: Re: pausable explanation for the Document Series > > > Bob Hinden wrote: > > >> The more-core problem is industry running on protocols with design > >> flaws and protocol bugs, which cannot be fixed because of the > >> installed base. > >> > >> If PS was perfect, this would not be a serious problem. > But it isn't > >> so. > > > > > > First versions of anything are never perfect. This is true for > > products > > and standards. As long as we try to solve the problem by > trying to make > > the first version perfect we will fail. It only delays the first > > version and causes it to miss the market need. The only > solution I know > > of is to do new versions. This seems to work well in industry. > > > > Perfection doesn't work. Shipping products and getting bug reports > > works. > > Agree 100%. Waterfall development vs. incremental > development. Serious debates early on in the project how all > possible features "must" be supported. Claims that engineers > would not make the mistakes they usually do, if they had just > done more "planning" or "design". Introduction of reviews, so > that more problems can be caught. Claims that the product we > are making is soooo important that we can not possibly have > any bugs or missing features in it. In the end, key success > factors for the project are missed, because no one bothered > to try out how the thing would work out in real usage. Or > competition is on its improvement cycle 17 when your first > buggy release comes out. Or you run out of money. Finally, > the management blames the engineers for bad quality. > > I've been there in the distant past, but I know better now. > But I'm alarmed that the above sounds very much like the > discussions we're having here. > > A few observations on what this might mean for > the IETF: > > - It really is essential to get real usage, not just > more reviews or interop tests. So *some* amount of > industry adoption early on is required. > > - Having to "fix" a standard (e.g. deprecate site-locals) > is not a sign of bad early specifications, its a sign > of being able to learn and adopt. > > - While we normally don't like to compromise on things > like quality, security, scalability, we have to learn > to do things in pieces better. And when we are already > doing things in small pieces, we need to have a better > view of the full architecture/roadmap early on. > > - This doesn't necessarily mean that we have to put out > more PS RFCs with a lower quality. We could keep > ahead of the industry's exaggeration of PS status > value by introducing a new document level lower in > chain. > > --Jari > > > From problem-statement-bounces@alvestrand.no Sat Jun 7 23:04:18 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29971 for ; Sat, 7 Jun 2003 23:04:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 718396258A; Sun, 8 Jun 2003 05:03:29 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1BDBC6238A; Sun, 8 Jun 2003 05:02:28 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 3F6F973F; Sat, 7 Jun 2003 23:02:26 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 23:02:26 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 23:02:25 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241319@tayexc13.americas.cpqcorp.net> Thread-Topic: pausable explanation for the Document Series Thread-Index: AcMr8hFi0a+XIOFDRRiWMHo4GrW/6wBd3/aQ From: "Bound, Jim" To: "Pekka Savola" , "Bob Hinden" X-OriginalArrivalTime: 08 Jun 2003 03:02:26.0021 (UTC) FILETIME=[63C60150:01C32D6A] Cc: john.loughney@nokia.com Cc: Harald Tveit Alvestrand Cc: problem-statement@alvestrand.no Subject: RE: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA29971 > I partially disagree. It's often too challenging to later change > fundamental design decisions made early on: just shipping a > spec with a > thought like "we'll fix the issues later" seems like a recipe for > disaster. This is a paranoid and low risk way of viewing first implemenation of products and standards. The key compromise to this paranoid view is to make sure that applications do not depend on the change at least for product. For a standard that is where the applicability statement comes in. The paranoid view will have us doing things like DHCPv6 and MObile IPv6 for 6 years to just get to PS and this is UACCEPTABLE. > > Naturally, when updating the documents some features are > ripped off, some > clarifications added etc., but this *typically* cannot > influence the basic > way specs work. And therefore, the core things in specs must > be in very > good shape. Defining what is core then is a key to success for those who want to do prototype and for those that are paranoid. > > In consequence, "security will be described in other documents" or > "deployment will be considered in other documents" doesn't > sound like a > good idea. These can often hide some very nasty surprises > which affect > your design decisions on the core spec. I would agree with the above. But a spec does not have to be secure on the Internet for PS prototype only in a lab. That is the core issue for me. /jim > > -- > 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 Sat Jun 7 23:08:12 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00039 for ; Sat, 7 Jun 2003 23:08:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 63C96623D1; Sun, 8 Jun 2003 05:07:39 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1C86D6238A for ; Sun, 8 Jun 2003 05:07:06 +0200 (CEST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 4AB14BF73; Sat, 7 Jun 2003 23:07:05 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 23:07:05 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 23:07:04 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848CA@tayexc13.americas.cpqcorp.net> Thread-Topic: pausable explanation for the Document Series Thread-Index: AcMr9Rs4x/ww+vt6RH+qdzxo+/xL4gBdVM8A From: "Bound, Jim" To: "Pekka Savola" , X-OriginalArrivalTime: 08 Jun 2003 03:07:05.0132 (UTC) FILETIME=[0A22F6C0:01C32D6B] Cc: problem-statement@alvestrand.no Subject: RE: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA00039 > In real world, people implement the protocols for pilot/test > purposes in > any case. This can be done when the I-D has reached > reasonable level of > stability. I am sorry but this is no longer true for most specs except by the original proponents. The IETF has burned all with the high bar on PS and most of us "product" engineers won't touch it until it is PS. Unless we see consortia out of the IETF to help us move it forward as a group of vendors. FYI that is what is happening and will happen with IPv6 Transition mechanisms as a note as one example. So your thought is old and does not apply. Not good argument to John and invalid now. It used to be true yes. > > Of course, we could try to add some "experimental" category > below PS, to > try to document these pilot protocols -- but this is slightly > problematic > also, as we have to make sure people understand that if protocol is > modified for PS, no backward-compatibility must be required.. No this will not work. Go back to Bob Hinden phrase as priniciple. Avoiding that principle is just hiding the problem and not facing it right here and right now. Someone here will loose and someone here will win. I hope you loose of course. /jim > > -- > 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 Sat Jun 7 23:12:09 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00108 for ; Sat, 7 Jun 2003 23:12:06 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6D345623D1; Sun, 8 Jun 2003 05:11:26 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by eikenes.alvestrand.no (Postfix) with ESMTP id 730B76238A for ; Sun, 8 Jun 2003 05:10:13 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id A7B21A18E; Sat, 7 Jun 2003 23:10:08 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 23:10:08 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 23:10:08 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848CB@tayexc13.americas.cpqcorp.net> Thread-Topic: IETF mission (RE: pausable explanation for the Document Series) Thread-Index: AcMsJGCSSpgaELL3SkamoSd8mgc53QBRuNOg From: "Bound, Jim" To: "Ralph Droms" , X-OriginalArrivalTime: 08 Jun 2003 03:10:08.0549 (UTC) FILETIME=[77762D50:01C32D6B] Subject: RE: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA00108 This will work and good idea. But it should not be a red herring for the IESG to use and really keep PS as high bar and not hear Bob Hindens input. /jim > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Friday, June 06, 2003 8:08 AM > To: problem-statement@alvestrand.no > Subject: Re: IETF mission (RE: pausable explanation for the > Document Series) > > > Regarding Brian's call for radical thinking... > > Is the problem: > > the 3 step standards track is largely fictional > > the root problem or just a symptom? > > I think it's just a symptom of a mismatch among industry > uses for IETF standards, WG processes and IESG goals. > > The current *usage* of the standards track effectively > has a single hurdle at PS. I suggest we need to devise > a process and set of hurdles that include some intermediate > states that are not well-defined in the current usage of the > standards track. > > One of the important states that is missing today is > > stable specification used for prototyping > > My recent experience with specifications in the dhc WG > has been that "running (prototype) code" trumps > (potentially ad infinitum) speculative discussion about > whether the protocol is correct and completely > specified. > > The design problem, of course, is devising the right > document classifications and process to strike a balance > among nimbleness (getting to a stable specification > quickly), correctness and allowing for changes after > the prototypes have been developed (avoiding the > "we've deployed the prototype and now we can't change > the protocol" problem)... > > - Ralph > > At 01:50 PM 6/6/2003 +0200, Brian E Carpenter wrote: > >john.loughney@nokia.com wrote: > >> > >> Hi Charles, > >> > >> > I also wholeheartedly support the inclusion of an applicability > >> > statement whenever it makes sense. However, I also suggest that > >> > the protocol SHOULD (within engineering discretion) not > >> > intentionally restrict its applcability to the situations > >> > delineated in the applicability statement. > >> > > >> > I would restate Postel's maxim: > >> > > >> > Be conservative in the claimed applicability, but > generous in the > >> > potential applicability. > >> > >> What I am concerned about is there seems to be a movement > to make a > >> super-PS, one which would be the equavalent of a DS & have > no bugs. > >> I am not sure of the feasibility of this, but I have noticed that > >> simple protocol documents are getting overloaded with a lot of > >> applicability info, deployment concerns, best practices and > >> implementation guides. Somehow, I think overloading a single > >> document with this info, is not a reciepe for success. > > > >In any case, since we don't actually use the complexity we > already have > >(3 grades of standard), the need is clearly to > >*simplify* the document scheme, not to complicate it. My thinking is > >getting more radical the longer this discussion continues. > Let's think > >seriously about > > > > Problem: the 3 step standards track is largely fictional > > > >and possible solutions along the lines of > > > > Solution: let's scrap it and have all "standards" RFCs as a single > > level (with recycling in grade for corrections/updates). > > > > Brian > > From problem-statement-bounces@alvestrand.no Sat Jun 7 23:12:32 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00128 for ; Sat, 7 Jun 2003 23:12:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A4E6E625C0; Sun, 8 Jun 2003 05:11:45 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail05.zma.compaq.com (mailout.zma.compaq.com [161.114.64.105]) by eikenes.alvestrand.no (Postfix) with ESMTP id E62A46238A for ; Sun, 8 Jun 2003 05:10:55 +0200 (CEST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 41D53BDBB; Sat, 7 Jun 2003 23:10:55 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 23:10:55 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 23:10:54 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848CC@tayexc13.americas.cpqcorp.net> Thread-Topic: Staying on Track (Re: Documenting pilots (RE: pausable explanation for the Document Series)) Thread-Index: AcMsKmkXJlB5MoW+QEij6XxnayhwfQBQQwGw From: "Bound, Jim" To: "Margaret Wasserman" , X-OriginalArrivalTime: 08 Jun 2003 03:10:55.0132 (UTC) FILETIME=[933A2DC0:01C32D6B] Subject: RE: Staying on Track (Re: Documenting pilots (RE: pausable explanation for the Document Series)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA00128 I am ok with them except the process doc on "Core Values" I just don't agree. /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Friday, June 06, 2003 8:46 AM > To: problem-statement@alvestrand.no > Subject: Staying on Track (Re: Documenting pilots (RE: > pausable explanation for the Document Series)) > > > > > I hate to do this, but... > > Not that I have any official authority to say this, but... > > At this point, this mailing list is almost exclusively > discussing solutions to problems, and refinements to those solutions. > > I, too, find it more fun and constructive to discuss > solutions, but this WG is only chartered to produce: > > 1 - A problem statement > 2 - Recommendations for a process to solve > the problems. > > Are people happy enough with those documents that we're > ready to publish them and move on? If so, let's do > that. If not, please send feedback on the documents to > this list, and keep solutions discussions on the solutions > mailing list. > > Thanks, > Margaret > > > From problem-statement-bounces@alvestrand.no Sat Jun 7 23:13:01 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00144 for ; Sat, 7 Jun 2003 23:13:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D79C4623D1; Sun, 8 Jun 2003 05:12:31 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by eikenes.alvestrand.no (Postfix) with ESMTP id A407F6238A for ; Sun, 8 Jun 2003 05:12:26 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id D96F541D0; Sat, 7 Jun 2003 23:12:25 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 23:12:25 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 23:12:25 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848CD@tayexc13.americas.cpqcorp.net> Thread-Topic: Staying on Track (Re: Documenting pilots (RE: pausableexplanation for the Document Series)) Thread-Index: AcMsLwbB5TAddXeSQiK9waqamazH/wBPKAPg From: "Bound, Jim" To: "Melinda Shore" , "Margaret Wasserman" X-OriginalArrivalTime: 08 Jun 2003 03:12:25.0705 (UTC) FILETIME=[C9368590:01C32D6B] Cc: problem-statement@alvestrand.no Subject: RE: Staying on Track (Re: Documenting pilots (RE: pausableexplanation for the Document Series)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA00144 I think what is documented and accurate and now just needs refinement. /jim > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Friday, June 06, 2003 9:25 AM > To: Margaret Wasserman > Cc: problem-statement@alvestrand.no > Subject: Re: Staying on Track (Re: Documenting pilots (RE: > pausableexplanation for the Document Series)) > > > > Are people happy enough with those documents that we're > > ready to publish them and move on? If so, let's do > > that. If not, please send feedback on the documents to > > this list, and keep solutions discussions on the solutions mailing > > list. > > I'm also very concerned about keeping the documents moving > forward, but I do think that the notion of what we need to do > about short-term solution efforts that would be hampered by > the overhead associated with working group creation do need > to be addressed and I think some interesting ideas have been > popping out of the discussion. > > One of the problems with the discussion, however, is that we > still don't have a way to accommodate ad-hoc, short-lived, > individual voluntary, or what-have-you efforts, and that does > need to be dealt with. Personally (i.e. not as chair) I'm > not crazy about things like what's going on with the SIRS > proposal (going off and collecting volunteers without real > agreement from the cohort that this is a good thing to > do) because it feels pre-emptive and unco-operative, but on > the other hand given our decision-making structure I'm not > sure what the alternatives are if anything is going to > happen in real time. If anybody has wisdom about how to do > short-term efforts within the IETF, this would be an > excellent time to discuss it. > > Melinda > > From problem-statement-bounces@alvestrand.no Sat Jun 7 23:16:09 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00172 for ; Sat, 7 Jun 2003 23:16:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5F58A623D1; Sun, 8 Jun 2003 05:14:28 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail03.zma.compaq.com (mailout.zma.compaq.com [161.114.64.103]) by eikenes.alvestrand.no (Postfix) with ESMTP id DB3426238A for ; Sun, 8 Jun 2003 05:14:10 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id F3A3A41D0; Sat, 7 Jun 2003 23:14:08 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 23:14:08 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 23:14:08 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848CE@tayexc13.americas.cpqcorp.net> Thread-Topic: pausable explanation for the Document Series Thread-Index: AcMsMrO07AhGEp9ITdyJo9VIq6GOhwBOQ9Jw From: "Bound, Jim" To: "Keith Moore" , X-OriginalArrivalTime: 08 Jun 2003 03:14:08.0516 (UTC) FILETIME=[067E3C40:01C32D6C] Cc: problem-statement@alvestrand.no Cc: hinden@IPRG.nokia.com Subject: RE: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA00172 You miss the point I think? And this is exactly how most products ship it is impossible to find all bugs in any first software release. What you try to find are the show stoppers based on what that means for that product function. So I suggest your disagreeing with reality? /jim > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Friday, June 06, 2003 9:48 AM > To: jari.arkko@piuha.net > Cc: hinden@IPRG.nokia.com; moore@cs.utk.edu; > problem-statement@alvestrand.no > Subject: Re: pausable explanation for the Document Series > > > > > Perfection doesn't work. Shipping products and getting > bug reports > > > works. > > > > Agree 100%. > > Disagree 100%. It costs much more to fix bugs after shipping > product than it > does to do so beforehand. Forcing customers to accept the > costs of poor protocol design is just irresponsible. > From problem-statement-bounces@alvestrand.no Sat Jun 7 23:16:25 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00190 for ; Sat, 7 Jun 2003 23:16:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 386546259B; Sun, 8 Jun 2003 05:15:47 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5C4D7625C0 for ; Sun, 8 Jun 2003 05:15:19 +0200 (CEST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id D1FF4BCA3; Sat, 7 Jun 2003 23:15:17 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 23:15:17 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 23:15:17 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848CF@tayexc13.americas.cpqcorp.net> Thread-Topic: pausable explanation for the Document Series Thread-Index: AcMsNgbR9UCBYcaeQqe92OuCMnpy9ABNhETg From: "Bound, Jim" To: "Charlie Perkins" , "Keith Moore" X-OriginalArrivalTime: 08 Jun 2003 03:15:17.0617 (UTC) FILETIME=[2FAE3610:01C32D6C] Cc: problem-statement@alvestrand.no Subject: RE: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA00190 And I agree with Charlie. /jim > -----Original Message----- > From: Charlie Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Friday, June 06, 2003 10:15 AM > To: Keith Moore > Cc: problem-statement@alvestrand.no > Subject: Re: pausable explanation for the Document Series > > > > Hello Keith, > > Keith Moore wrote: > > >>>Perfection doesn't work. Shipping products and getting > bug reports > >>>works. > >>> > >>> > >>Agree 100%. > >> > >> > > > >Disagree 100%. It costs much more to fix bugs after > shipping product > >than it > >does to do so beforehand. Forcing customers to accept the > costs of poor > >protocol design is just irresponsible. > > > > > You seem to assume that the customers are going to sit around waiting. > > Most will buy a system that works, and the perfect product > will, after a three year delay, be a footnote in history. > > And that's where recent IETF protocol efforts may be heading. > > I agree with Bob and Jari. > > Regards, > Charlie P. > > From problem-statement-bounces@alvestrand.no Sat Jun 7 23:19:02 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00256 for ; Sat, 7 Jun 2003 23:19:01 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 547BB6258D; Sun, 8 Jun 2003 05:18:05 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail05.zma.compaq.com (mailout.zma.compaq.com [161.114.64.105]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4C0186238A; Sun, 8 Jun 2003 05:17:25 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 7D830BD74; Sat, 7 Jun 2003 23:17:24 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 23:17:24 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 23:17:23 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848D0@tayexc13.americas.cpqcorp.net> Thread-Topic: ISSUE: Goal of problem-statement document Thread-Index: AcMsOosLmMyd+eVrTnG/fQK6TvsROgBMaYRA From: "Bound, Jim" To: "Melinda Shore" , "Harald Tveit Alvestrand" X-OriginalArrivalTime: 08 Jun 2003 03:17:24.0390 (UTC) FILETIME=[7B3E3C60:01C32D6C] Cc: problem-statement@alvestrand.no Subject: RE: ISSUE: Goal of problem-statement document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA00256 One thing I thing we should ask if we have consensus on and that is the bar for PS is to high. Fixing that is a solution we have to work. But it should be documented as a problem just based on the fact that it created much discussion and the issue of maturity levels. So I think we found another problem to add. thanks /jim > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Friday, June 06, 2003 10:47 AM > To: Harald Tveit Alvestrand > Cc: problem-statement@alvestrand.no > Subject: Re: ISSUE: Goal of problem-statement document > > > > SUGGESTED RESOLUTION: Change this section to say that the document > > attempts to be a basis for consensus on the root causes. > > One of the things that's of concern here is an interest in > trying to find ways to make progress in the absence of > consensus about each identified problem, the dependency > analysis, and a ranking. We absolutely do believe that the > document will provide guidance, but it's reasonable to > suspect that it's likely that the only way we'll be able to > reach real consensus on some of it is if we dilute the > discussion to the point it isn't useful. > > Melinda > From problem-statement-bounces@alvestrand.no Sat Jun 7 23:21:22 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00287 for ; Sat, 7 Jun 2003 23:21:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 63DB46257F; Sun, 8 Jun 2003 05:20:26 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail04.zma.compaq.com (mailout.zma.compaq.com [161.114.64.104]) by eikenes.alvestrand.no (Postfix) with ESMTP id B99BA6257F for ; Sun, 8 Jun 2003 05:18:41 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id CBAC47F4B; Sat, 7 Jun 2003 23:18:39 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 23:18:39 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 23:18:38 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848D1@tayexc13.americas.cpqcorp.net> Thread-Topic: pausable explanation for the Document Series Thread-Index: AcMsO0UtP7FtewwJQ+aRc7TuwqPrawBMTHgg From: "Bound, Jim" To: "Charlie Perkins" , "Keith Moore" X-OriginalArrivalTime: 08 Jun 2003 03:18:39.0624 (UTC) FILETIME=[A8160880:01C32D6C] Cc: problem-statement@alvestrand.no Subject: RE: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA00287 A favorite phrase of mine and I think my colleague Charlie sums it up Keith. Caveat Emptor. /jim > -----Original Message----- > From: Charlie Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Friday, June 06, 2003 10:52 AM > To: Keith Moore > Cc: problem-statement@alvestrand.no > Subject: Re: pausable explanation for the Document Series > > > > Hello Keith, > > You're using nasty words like "accuse". > > Keith Moore wrote: > > >>You seem to assume that the customers are going to sit > around waiting. > >> > >>Most will buy a system that works, > >> > >> > > > >most will buy a system without knowing whether it works or not, and > >pull their hair out when they have trouble getting it to work in > >practice, and then guess about who is to blame, and make arbitrary > >demands about who has to fix it that have nothing to do with > the actual > >cause of the problem. > > > Life sucks that way. It helps to buy from reputable vendors. > Industrial product managers with a habit of success tend to > do better than you portray. > > >>And that's where recent IETF protocol efforts may be heading. > >> > >> > > > >NOBODY has said anything about requiring things to be > perfect, so stop > >accusing people of that. What has been repeatedly suggested is that > >the criteria for maturity levels should be better matched > with industry > >expectation and IETF energy levels. What's wrong with that? > > > But when you hear that industry has expectations about > timeliness you seem to go nonlinear. Furthermore, I suggest > that IETF processes demotivate and drain the energy of > otherwise enthusiastic IETF engineers. > > Regards, > Charlie P. > > > From problem-statement-bounces@alvestrand.no Sat Jun 7 23:21:41 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00302 for ; Sat, 7 Jun 2003 23:21:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DD9FD625C5; Sun, 8 Jun 2003 05:20:35 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by eikenes.alvestrand.no (Postfix) with ESMTP id 69E316238A; Sun, 8 Jun 2003 05:19:44 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 9CBE97C3A; Sat, 7 Jun 2003 23:19:43 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 23:19:43 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 23:19:43 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848D2@tayexc13.americas.cpqcorp.net> Thread-Topic: ISSUE: Goal of problem-statement document Thread-Index: AcMsO7M1LIzTE4z9RCyXUXzzSfkPUwBMOvgg From: "Bound, Jim" To: "Harald Tveit Alvestrand" , "Melinda Shore" X-OriginalArrivalTime: 08 Jun 2003 03:19:43.0514 (UTC) FILETIME=[CE2ADFA0:01C32D6C] Cc: problem-statement@alvestrand.no Subject: RE: ISSUE: Goal of problem-statement document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA00302 no expliciy agreed mission is wishy washy with no meet and we will never figure that out but get close by documenting our bullets. Saying PS bar is to high now that has some meat. /jim > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: Friday, June 06, 2003 10:55 AM > To: Melinda Shore > Cc: problem-statement@alvestrand.no > Subject: Re: ISSUE: Goal of problem-statement document > > > > > --On fredag, juni 06, 2003 10:47:01 -0400 Melinda Shore > > wrote: > > >> SUGGESTED RESOLUTION: Change this section to say that the document > >> attempts to be a basis for consensus on the root causes. > > > > One of the things that's of concern here is an interest in > trying to > > find ways to make progress in the absence of consensus about each > > identified problem, the dependency analysis, and a ranking. We > > absolutely do believe that the document will provide guidance, but > > it's reasonable to suspect that it's likely that the only > way we'll be > > able to reach real consensus on some of it is if we dilute the > > discussion to the point it isn't useful. > > I think we do have consensus on a fair number of points > (including the "no > explicit agreed mission", for instance) - I'd like to probe > and try to > refine some more of these points before declaring that this > document is "as > good as we can make it". > > We might quickly come to consensus about what we can't come > to consensus on > :-) > > > From problem-statement-bounces@alvestrand.no Sat Jun 7 23:23:49 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00329 for ; Sat, 7 Jun 2003 23:23:48 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 284E461C73; Sun, 8 Jun 2003 05:23:10 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail03.zma.compaq.com (mailout.zma.compaq.com [161.114.64.103]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5C722623D1 for ; Sun, 8 Jun 2003 05:22:40 +0200 (CEST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 8C14A525; Sat, 7 Jun 2003 23:22:39 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 23:22:39 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 23:22:38 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848D3@tayexc13.americas.cpqcorp.net> Thread-Topic: IETF mission (RE: pausable explanation for the Document Series) Thread-Index: AcMsPEqk6+Z76w8qS5SQEEfcK7jKmwBMLGPg From: "Bound, Jim" To: , "Brian E Carpenter" X-OriginalArrivalTime: 08 Jun 2003 03:22:39.0367 (UTC) FILETIME=[36FBE970:01C32D6D] Cc: problem-statement@alvestrand.no Subject: RE: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA00329 I vote for this. But would need grandfather for that preceding this or the market will feed the IETF to pigs :-) /jim > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Friday, June 06, 2003 10:58 AM > To: Brian E Carpenter > Cc: problem-statement@alvestrand.no > Subject: Re: IETF mission (RE: pausable explanation for the > Document Series) > > > > Perhaps we need to understand better just what problem we > are trying to solve by revising the categorization of standards. > > I'd make two observations: > > 1. Nobody cares whether the IETF says that a protocol > is ready for > deployment or not. Service providers, vendors, > enterprises, etc., will > decide this for themselves. > > By "nobody", I mean "nobody who is in a position to > decide whether to do > any large scale deployments". In the old world of the > ITU-T people don't > deploy until the standards process is finished, which > leads to (a) > bizarre standards and (b) slow progress. That may have > been okay when > telecom providers were monopolies, but it is not okay in > the competitive > environment of today. > > 2. People do care about whether the protocol has a > public specification > which is sufficiently detailed so as to enable > interoperability among > multiple independent implementations. However, they will > not wait (nor > should they) for such a specification before deployment. > > Based on these observations, there has arisen a significant > constituency in the IETF (though not seen much on this > list) which believes that the only proper function of the > IETF is to publish specifications which are > multi-vendor interoperable. Members of this constituency > see no benefit at all for IESG review. Members of this > constituency would also be overjoyed > if all their specs could just get published as > "Experimental" or > "Informational", and once the specs get published, they have > no interest in moving them further along in the process. > > Most people on this list seem to think that there is a > value in having a category of "standard" which means > something more than "multi-vendor interoperable." But I > don't think there is a clear consensus on just what we want > that to mean, and that's one of our big problems. > > Some possible considerations are: > > - correctly achieves the function which it is intended to achieve > - adequately address scalability and security considerations > in the intended > scope of applicability > - adequately (though not excessively) flexible > - not a lot more complicated than it needs to be > - can be reasonably defended against alternatives > - specification is competently and professionally done > - impact on other areas has been addressed > - there exists significant interest in deploying this > > etc. > > To me, it makes sense to have a standards category which > says that the specification is not merely adequate for > interoperability, but also that it has been judged against > these other considerations. > > Considerations often cited which I don't agree with: > > - must not be intended for uses which violate my personal values > - must not be intended for uses which violate my idea of > how the Internet > should be used > - must not be intended for uses which allow Service Providers > to add value > - must not violate some alleged philosophical principle > articulated 25 years > ago > - must not make it more difficult to write > multi-party peer-to-peer > applications > - must have the highest conceivable level of security > - guaranteed bug-free > > Based on the considerations I think are important, I don't > understand why we need more than one category of standard, > so I would tend to agree with > Brian: "let's scrap it all and have a single level (with > recycling in grade for corrections/updates)." > > > > > From problem-statement-bounces@alvestrand.no Sat Jun 7 23:40:55 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00516 for ; Sat, 7 Jun 2003 23:40:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 076B36238A; Sun, 8 Jun 2003 05:40:26 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6A5A1621B8 for ; Sun, 8 Jun 2003 05:40:23 +0200 (CEST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id B15F9A2F7; Sat, 7 Jun 2003 23:40:22 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 23:40:22 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 23:40:22 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848D4@tayexc13.americas.cpqcorp.net> Thread-Topic: pausable explanation for the Document Series Thread-Index: AcMtO9u9c/ZrdUF4QGO+BzY97vd7mwAMeyFg From: "Bound, Jim" To: "Randy Bush" , "Keith Moore" X-OriginalArrivalTime: 08 Jun 2003 03:40:22.0523 (UTC) FILETIME=[B0ACA4B0:01C32D6F] Cc: jari.arkko@piuha.net Cc: hinden@IPRG.nokia.com Cc: problem-statement@alvestrand.no Subject: RE: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA00516 > now now. we could aspire to being the microsoft of > standards. sell a lot of half-baked crap, laugh our way to > the bank, and not be able to face ourselves in the mirror. > > randy > > --- > > ps: sorry to pick on microsoft, it's the image. You should not have done this sir. I am sorry but you simply cannot do this anymore. This is very wrong and not right. Children all over the world impart have access to the Internet because of Microsoft, Cisco, Sun, HP, Juniper, Nokia, et al. To trash them on this very public list is simply not right. OK privately but this is not even funny. Realize there good be person on this list that could influence a procurement and possibly pause based on a comment here. You have crossed a line here and I wish you had not done that, I really do. In the future can you refrain from calling any vendors parts "crap"? Especially as an IESG member in this community, and yes that does make it worse. /jim From problem-statement-bounces@alvestrand.no Sat Jun 7 23:44:33 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00571 for ; Sat, 7 Jun 2003 23:44:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 81A83623D1; Sun, 8 Jun 2003 05:43:58 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8D3F26238A for ; Sun, 8 Jun 2003 05:43:55 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id DD77A739; Sat, 7 Jun 2003 23:43:54 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 7 Jun 2003 23:43:54 -0400 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="us-ascii" Date: Sat, 7 Jun 2003 23:43:54 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848D5@tayexc13.americas.cpqcorp.net> Thread-Topic: Cutting through the accumulating sludge (was: Re: Doing the Right Things? and/or WG Quality Processes WG) Thread-Index: AcMpfZfm9+35lDrgQVOOkxgOIX0/xQD8jnDg From: "Bound, Jim" To: "Randy Bush" , "John C Klensin" X-OriginalArrivalTime: 08 Jun 2003 03:43:54.0708 (UTC) FILETIME=[2F258140:01C32D70] Cc: problem-statement@alvestrand.no Subject: RE: Cutting through the accumulating sludge (was: Re: Doing the Right Things? and/or WG Quality Processes WG) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA00571 Would you keep your vendor comments to private conversations. I would be glad to enlighten you on both counts below but we would have to agree on what dynamic means. Siting specific history of a company with data your willing to stand up to in court is fine if it helps give us examples of points in time for our work here. /jim > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, June 02, 2003 11:09 PM > To: John C Klensin > Cc: problem-statement@alvestrand.no > Subject: Re: Cutting through the accumulating sludge (was: > Re: Doing the Right Things? and/or WG Quality Processes WG) > > > > I am suggesting that, if there seems to be general sympathy on > > the list (or otherwise) for this, that the relevant AD just do > > it --or delegate it to the WG Chairs or an appointed > > coordinator-- to do it. The authority is there; nothing in the > > current procedures requires us to find a tree and dance around > > it in a circle while chanting "rough consensus and running > > code", or to create a charter and WG, before doing anything. > > i think we really do not have a clear vision of what we > should be doing, so it is easier to talk about the processes > and enemies of doing it. no blame. this is extremely > difficult stuff. > > i keep thinking of the analog to how some engineering > companies dealt with the conflicts/tensions of staying nimble > while undergoing large growth. > > digital equipment tried to maintain a dynamic engineering > culture while growing massively. it did not work. > > hp is still trying, but has become more and more stodgy and > has not stayed lively and dynamic. > > intel may be the most successful. one key to this success is > not touching anything that does not have at least a 40% > margin. i.e., they say "no" to a lot of bright ideas. i do > not believe that we have the culture to do that. > > randy > > From problem-statement-bounces@alvestrand.no Sun Jun 8 00:45:44 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01331 for ; Sun, 8 Jun 2003 00:45:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7B31161C73; Sun, 8 Jun 2003 06:45:14 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mx-out.daemonmail.net (mx-out.daemonmail.net [216.104.160.39]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4063F61C73 for ; Sun, 8 Jun 2003 06:45:08 +0200 (CEST) Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.9.3p2/8.9.3) with SMTP id VAA32426 for ; Sat, 7 Jun 2003 21:45:06 -0700 (PDT) (envelope-from spencer@mcsr-labs.org) Received: from (12.237.229.250 [12.237.229.250]) by mail.varaha.com with SMTP id wQ80SVE2 Sat, 07 Jun 2003 21:45:05 -0700 (PDT) Message-ID: <074a01c32d78$bd318350$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <74750000.1054904612@askvoll.hjemme.alvestrand.no> Date: Sat, 7 Jun 2003 23:45:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: ISSUE: Goal of problem-statement document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Dear Randy, I'm reading your note as carefully as I can, and see you are asking that we understand needs and requirements well. I agree, and want to focus on the definition of "well enough". Speaking only for myself, I agreed with our text (and may have suggested it) because I strongly suspected that the engineering alternative was discussing each problem, determining its root cause, and agreeing on a prioritized list of root causes before we did anything. I would love to be wrong. I can't speak for others, but my goal here was to avoid having to figure out what the IETF consensus was on a prioritized root cause list before moving on any root cause. This looked like death to me. I don't believe there are ANY scope limits on discussions about the relative priority of root IETF problems, unlike our normal engineering work. So I thought developing a root cause list (which we have done, at least at some level) was sufficient, without spending time trying to determine priorities. I thought this was "good enough". I would love to hear other opinions. Spencer Dawkins ----- Original Message ----- From: "Randy Bush" To: "Harald Tveit Alvestrand" Cc: Sent: Saturday, June 07, 2003 4:21 PM Subject: Re: ISSUE: Goal of problem-statement document > > We, in line with many contributors to the mailing list, do not > > believe that the process of problem resolution will be helped > > by continued rework of the root issues in what would probably > > be a vain attempt to achieve any sort of consensus. Instead, > > the general tenor and scope of the problems identified will > > provide a guide in setting up the processes needed to resolve > > the problems and provide input to the resolvers. > > i always found this part particularly amusing considering it is > being pushed by the same folk who so strongly push for a classic > software engineering management view of the wg product process. > how can we think we will produce a good result if we do not first > define the needs and requirements well? > > randy > From problem-statement-bounces@alvestrand.no Sun Jun 8 00:53:37 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01516 for ; Sun, 8 Jun 2003 00:53:37 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3F0A96257F; Sun, 8 Jun 2003 06:53:08 +0200 (CEST) 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 BA56A623D1 for ; Sun, 8 Jun 2003 06:53:04 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h584txF01801; Sat, 7 Jun 2003 21:55:59 -0700 Date: Sat, 7 Jun 2003 21:52:56 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <174132382475.20030607215256@brandenburg.com> To: Margaret Wasserman In-Reply-To: <5.1.0.14.2.20030607123251.047d9aa0@mail.windriver.com> References: <3EDDA77F.8050700@piuha.net> <3EDDA77F.8050700@piuha.net> <5.1.0.14.2.20030607123251.047d9aa0@mail.windriver.com> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Complex Problems (Was: Re: Discipline of Internet Protocol Engineering) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Margaret, MW> Your reasoning seems to run: The IETF is bad at resolving MW> complex issues, so we should only work on small, well-defined MW> problems. Actually, my reasoning runs a bit differently, and that bit of difference is important: IETF work has been notably successful only when it has done bite-sized bits of coherent work. It has attacked complex issues successfully only when it has attacked the issues piecemeal. So, we should do what we know we are good at, rather than do what we know we are bad at. MW> My reasons runs: The IETF is bad at resolving complex MW> problems, so we need to find a way to get better at it. That would be delightful. But it does not make sense to place a requirement into our critical path for something which we have almost 15 years of failure performing. Better still, we have no basis for yet believing we know how to perform it. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Sun Jun 8 07:35:15 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19338 for ; Sun, 8 Jun 2003 07:35:15 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 93B5F6257D; Sun, 8 Jun 2003 13:34:43 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 681D86238A; Sun, 8 Jun 2003 13:34:37 +0200 (CEST) Date: Sun, 08 Jun 2003 13:34:37 +0200 From: Harald Tveit Alvestrand To: Spencer Dawkins , problem-statement@alvestrand.no Message-ID: <119960000.1055072077@askvoll.hjemme.alvestrand.no> In-Reply-To: <074a01c32d78$bd318350$0200a8c0@DFNJGL21> References: <74750000.1054904612@askvoll.hjemme.alvestrand.no> <074a01c32d78$bd318350$0200a8c0@DFNJGL21> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Subject: Re: ISSUE: Goal of problem-statement document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA19338 --On lørdag, juni 07, 2003 23:45:08 -0500 Spencer Dawkins wrote: > I can't speak for others, but my goal here was to avoid > having to figure out what the IETF consensus was on a > prioritized root cause list before moving on any root cause. > This looked like death to me. I don't believe there are ANY > scope limits on discussions about the relative priority of > root IETF problems, unlike our normal engineering work. > > So I thought developing a root cause list (which we have > done, at least at some level) was sufficient, without spending > time trying to determine priorities. I thought this was "good > enough". actually I tend to agree with your sentiment, but not with the text of the document as written. if we can formulate the text as saying "we think there is IETF consensus that this statement of root causes is good enough to guide us into the process of what to try to fix first", I think it would be better. What I reacted most strongly to was the statement "a vain attempt to achieve any sort of consensus" - we need SOME sort of consensus. Harald From problem-statement-bounces@alvestrand.no Sun Jun 8 07:39:33 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19373 for ; Sun, 8 Jun 2003 07:39:33 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2EC596257D; Sun, 8 Jun 2003 13:39:02 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 11AF96238A for ; Sun, 8 Jun 2003 13:39:00 +0200 (CEST) Date: Sun, 08 Jun 2003 13:39:00 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <120210000.1055072340@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ISSUE: Determinants for timeliness missing in section 2.1 X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 OK, I'll push two specific issues into the debate today.... first one... ISSUE: In section 2.1, "Participants in the IETF do not share a common understanding of its mission", I think there is a bullet missing. The determination of "timely" market is a problem that is not mentioned. SUGGESTED RESOLUTION: Add something like this: o The IETF is unable to determine explicitly what effect it desires to have in the marketplace, and is therefore unable to determine what requirements of timeliness are appropriate to consider when planning work. I believe this is a core problem which underlies our commonly occuring inability to have rational discussion about time-to-market vs quality. From problem-statement-bounces@alvestrand.no Sun Jun 8 07:42:37 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19415 for ; Sun, 8 Jun 2003 07:42:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3A3016257D; Sun, 8 Jun 2003 13:42:05 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4A2716238A for ; Sun, 8 Jun 2003 13:42:00 +0200 (CEST) Date: Sun, 08 Jun 2003 13:42:00 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <120940000.1055072520@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: MINOR ISSUE: "reputation" vs "mission". X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Second issue of the day.... this should be extremely minor.... In section 2.1 - "Participants in the IETF do not Share a Common Understanding of its Mission", the following text occurs: o Working Groups can potentially be hijacked by sectional interests to the detriment of the IETF's reputation. ISSUE: The IETF's reputation is not a goal. To make a slogan out of the question: if we aim for a good reputation, we will not achieve it. if we aim for and achieve quality work, we will achieve a good reputation. SUGGESTED RESOLUTION: Replace "reputation" with "mission". From problem-statement-bounces@alvestrand.no Sun Jun 8 07:51:44 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19506 for ; Sun, 8 Jun 2003 07:51:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0DB4F62577; Sun, 8 Jun 2003 13:51:12 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mx-out.daemonmail.net (mx-out.daemonmail.net [216.104.160.39]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6C2666238A for ; Sun, 8 Jun 2003 13:51:09 +0200 (CEST) Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.9.3p2/8.9.3) with SMTP id EAA77061 for ; Sun, 8 Jun 2003 04:51:08 -0700 (PDT) (envelope-from spencer@mcsr-labs.org) Received: from (12.237.229.250 [12.237.229.250]) by mail.varaha.com with SMTP id q2K0M7Q2 Sun, 08 Jun 2003 04:51:07 -0700 (PDT) Message-ID: <08c301c32db4$41a76b00$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <74750000.1054904612@askvoll.hjemme.alvestrand.no> <074a01c32d78$bd318350$0200a8c0@DFNJGL21> <119960000.1055072077@askvoll.hjemme.alvestrand.no> Date: Sun, 8 Jun 2003 06:51:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: ISSUE: Goal of problem-statement document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit Dear Harald, I understand - I wondered about this when typing my note, but you said it better in your note than I thought it in my mind! Thank you, Spencer ----- Original Message ----- From: "Harald Tveit Alvestrand" To: "Spencer Dawkins" ; Sent: Sunday, June 08, 2003 6:34 AM Subject: Re: ISSUE: Goal of problem-statement document --On lørdag, juni 07, 2003 23:45:08 -0500 Spencer Dawkins wrote: > I can't speak for others, but my goal here was to avoid > having to figure out what the IETF consensus was on a > prioritized root cause list before moving on any root cause. > This looked like death to me. I don't believe there are ANY > scope limits on discussions about the relative priority of > root IETF problems, unlike our normal engineering work. > > So I thought developing a root cause list (which we have > done, at least at some level) was sufficient, without spending > time trying to determine priorities. I thought this was "good > enough". actually I tend to agree with your sentiment, but not with the text of the document as written. if we can formulate the text as saying "we think there is IETF consensus that this statement of root causes is good enough to guide us into the process of what to try to fix first", I think it would be better. What I reacted most strongly to was the statement "a vain attempt to achieve any sort of consensus" - we need SOME sort of consensus. Harald From problem-statement-bounces@alvestrand.no Sun Jun 8 08:45:09 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19902 for ; Sun, 8 Jun 2003 08:45:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 45D2D62577; Sun, 8 Jun 2003 14:44:19 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by eikenes.alvestrand.no (Postfix) with ESMTP id 07CB16238A for ; Sun, 8 Jun 2003 14:44:12 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 1725784A2; Sun, 8 Jun 2003 08:44:07 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sun, 8 Jun 2003 08:44:06 -0400 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="us-ascii" Date: Sun, 8 Jun 2003 08:44:06 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848E3@tayexc13.americas.cpqcorp.net> Thread-Topic: ISSUE: Goal of problem-statement document Thread-Index: AcMteMhoiaBEXvezQzOtO9NT52wjwQAQqAyg From: "Bound, Jim" To: "Spencer Dawkins" , X-OriginalArrivalTime: 08 Jun 2003 12:44:06.0876 (UTC) FILETIME=[A64DD9C0:01C32DBB] Subject: RE: ISSUE: Goal of problem-statement document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA19902 I agree with you Spencer. If we have to have total consensus on root cause it is death. I think when you see 5 or 6 bright people from multiple vantage points say something is at the root it warrants at least being on the list for now. /jim > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > Sent: Sunday, June 08, 2003 12:45 AM > To: problem-statement@alvestrand.no > Subject: Re: ISSUE: Goal of problem-statement document > > > Dear Randy, > > I'm reading your note as carefully as I can, and see you are > asking that we understand needs and requirements well. I > agree, and want to focus on the definition of "well enough". > > Speaking only for myself, I agreed with our text (and may > have suggested it) because I strongly suspected that the > engineering alternative was discussing each problem, > determining its root cause, and agreeing on a prioritized > list of root causes before we did anything. > > I would love to be wrong. > > I can't speak for others, but my goal here was to avoid > having to figure out what the IETF consensus was on a > prioritized root cause list before moving on any root cause. > This looked like death to me. I don't believe there are ANY > scope limits on discussions about the relative priority of > root IETF problems, unlike our normal engineering work. > > So I thought developing a root cause list (which we have > done, at least at some level) was sufficient, without > spending time trying to determine priorities. I thought this > was "good enough". > > I would love to hear other opinions. > > Spencer Dawkins > > ----- Original Message ----- > From: "Randy Bush" > To: "Harald Tveit Alvestrand" > Cc: > Sent: Saturday, June 07, 2003 4:21 PM > Subject: Re: ISSUE: Goal of problem-statement document > > > > > We, in line with many contributors to the mailing list, do not > > > believe that the process of problem resolution will be helped > > > by continued rework of the root issues in what would probably > > > be a vain attempt to achieve any sort of consensus. Instead, > > > the general tenor and scope of the problems identified will > > > provide a guide in setting up the processes needed to resolve > > > the problems and provide input to the resolvers. > > > > i always found this part particularly amusing considering > it is being > > pushed by the same folk who so strongly push for a classic software > > engineering management view of the wg product process. how can we > > think we will produce a good result if we do not first define the > > needs and requirements well? > > > > randy > > > From problem-statement-bounces@alvestrand.no Sun Jun 8 08:46:38 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19926 for ; Sun, 8 Jun 2003 08:46:37 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 228A462577; Sun, 8 Jun 2003 14:46:05 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6FC946238A; Sun, 8 Jun 2003 14:45:50 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id BEBDDA25E; Sun, 8 Jun 2003 08:45:49 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sun, 8 Jun 2003 08:45:49 -0400 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" Date: Sun, 8 Jun 2003 08:45:49 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848E4@tayexc13.americas.cpqcorp.net> Thread-Topic: ISSUE: Goal of problem-statement document Thread-Index: AcMtsfiz/QAj6b6kQlyIefxjrsGOrAACbzYg From: "Bound, Jim" To: "Harald Tveit Alvestrand" , "Spencer Dawkins" , X-OriginalArrivalTime: 08 Jun 2003 12:45:49.0672 (UTC) FILETIME=[E3934680:01C32DBB] Subject: RE: ISSUE: Goal of problem-statement document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA19926 I think long discussion on this list and clear disagreement means there is a problem. So lets call it list debate consensus? /jim > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: Sunday, June 08, 2003 7:35 AM > To: Spencer Dawkins; problem-statement@alvestrand.no > Subject: Re: ISSUE: Goal of problem-statement document > > > > > --On lørdag, juni 07, 2003 23:45:08 -0500 Spencer Dawkins > wrote: > > > I can't speak for others, but my goal here was to avoid having to > > figure out what the IETF consensus was on a prioritized root cause > > list before moving on any root cause. This looked like > death to me. I > > don't believe there are ANY scope limits on discussions about the > > relative priority of root IETF problems, unlike our normal > engineering > > work. > > > > So I thought developing a root cause list (which we have done, at > > least at some level) was sufficient, without spending time > trying to > > determine priorities. I thought this was "good enough". > > actually I tend to agree with your sentiment, but not with > the text of the > document as written. > > if we can formulate the text as saying "we think there is > IETF consensus > that this statement of root causes is good enough to guide us > into the > process of what to try to fix first", I think it would be better. > > What I reacted most strongly to was the statement "a vain attempt to > achieve any sort of consensus" - we need SOME sort of consensus. > > Harald > > > From problem-statement-bounces@alvestrand.no Sun Jun 8 08:48:27 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19950 for ; Sun, 8 Jun 2003 08:48:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 55F37625C3; Sun, 8 Jun 2003 14:47:56 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail03.zma.compaq.com (mailout.zma.compaq.com [161.114.64.103]) by eikenes.alvestrand.no (Postfix) with ESMTP id A133A6238A; Sun, 8 Jun 2003 14:47:53 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id A9B047E6; Sun, 8 Jun 2003 08:47:52 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sun, 8 Jun 2003 08:47:52 -0400 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="us-ascii" Date: Sun, 8 Jun 2003 08:47:52 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042848E5@tayexc13.americas.cpqcorp.net> Thread-Topic: ISSUE: Determinants for timeliness missing in section 2.1 Thread-Index: AcMtsphs6JiCSHaISoeWqtkzeTVJdwACUl4Q From: "Bound, Jim" To: "Harald Tveit Alvestrand" , X-OriginalArrivalTime: 08 Jun 2003 12:47:52.0499 (UTC) FILETIME=[2CC93030:01C32DBC] Subject: RE: ISSUE: Determinants for timeliness missing in section 2.1 X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA19950 I also want to see. ISSUE: "IETF process for PS is an issue for achieving such goal and affecting time to market delivery of our specifications". Text from many mails. /jim > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: Sunday, June 08, 2003 7:39 AM > To: problem-statement@alvestrand.no > Subject: ISSUE: Determinants for timeliness missing in section 2.1 > > > OK, I'll push two specific issues into the debate today.... > first one... > > ISSUE: In section 2.1, "Participants in the IETF do not share > a common > understanding of its mission", I think there is a bullet > missing. The determination of "timely" market is a problem > that is not mentioned. > > SUGGESTED RESOLUTION: Add something like this: > o The IETF is unable to determine explicitly what effect it > desires to > have in the marketplace, and is therefore unable to determine what > requirements of timeliness are appropriate to consider when > planning work. > > I believe this is a core problem which underlies our commonly > occuring > inability to have rational discussion about time-to-market vs quality. > From problem-statement-bounces@alvestrand.no Sun Jun 8 09:29:09 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20570 for ; Sun, 8 Jun 2003 09:29:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B0C6462577; Sun, 8 Jun 2003 15:28:37 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by eikenes.alvestrand.no (Postfix) with ESMTP id 404EA622B1 for ; Sun, 8 Jun 2003 15:28:35 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180])h58DSQZX104820; Sun, 8 Jun 2003 15:28:31 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h58DSQDT088410; Sun, 8 Jun 2003 15:28:26 +0200 Received: from gsine05.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA51326 from ; Sun, 8 Jun 2003 15:28:22 +0200 Message-Id: <3EE33466.1014C05A@hursley.ibm.com> Date: Sun, 08 Jun 2003 15:04:38 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: erosen@cisco.com References: <200306061458.h56Ew1LU005957@rtp-core-1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Eric Rosen wrote: ... > Considerations often cited which I don't agree with: It's a bit hard to separate the polemic from the rational in this list, but let's try: > - must not be intended for uses which violate my personal values That really doesn't seem to me to be a factor. As we saw with RFC 1984 and RFC 2804, to take two examples that may be relevant to your underlying point, when there is a clear majority view among the individual engineers who make up the IETF, the IETF may decide that certain things are inappropriate topics for standardization in the IETF. > - must not be intended for uses which violate my idea of how the Internet > should be used Same response. > - must not be intended for uses which allow Service Providers to add value There is a principle, which I think has been articulated often as a shared value in the IETF, that we shouldn't standardize things that harm the Internet as a whole, or that destroy global connectivity and access. It may well be that this principle is sometimes in conflict with tools that might serve short-term commercial interests of SPs. I would indeed hope that the IETF would decline to standardize such things. But your version is caricature. > - must not violate some alleged philosophical principle articulated 25 years > ago Let's just pretend you didn't write "alleged" and "philosophical". There are a bunch of engineering principles that *were* articulated between about 1974 and 1985 that are objectively behind the Internet's success (compared say to SNA, DECnet, and OSI). Some them were collected in RFC 1958. The basic physics of packet switching hasn't actually changed much since 1969. So if you think that there have been changes that invalidate some of those principles, please write the Internet-Draft explaining this. > - must not make it more difficult to write multi-party peer-to-peer > applications Yes, that's a very valid technical objection to certain things. The future of e-business certainly requires multi-party peer-to-peer connectivity, so I'd say there's a few hundred billion dollars of revenue riding on this one. > - must have the highest conceivable level of security Caricature. "Must not have sloppy security" is more like it. > - guaranteed bug-free Caricature, but indeed any pretence that we can have bug-free specs first time is illusory. Brian From problem-statement-bounces@alvestrand.no Sun Jun 8 12:12:27 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24663 for ; Sun, 8 Jun 2003 12:12:27 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 26ED962577; Sun, 8 Jun 2003 18:11:56 +0200 (CEST) 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 7AC33621B8; Sun, 8 Jun 2003 18:11:53 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h58GEqF27285; Sun, 8 Jun 2003 09:14:52 -0700 Date: Sun, 8 Jun 2003 09:11:52 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <771413672.20030608091152@brandenburg.com> To: Harald Tveit Alvestrand In-Reply-To: <120940000.1055072520@askvoll.hjemme.alvestrand.no> References: <120940000.1055072520@askvoll.hjemme.alvestrand.no> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: MINOR ISSUE: "reputation" vs "mission". X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Harald, HTA> SUGGESTED RESOLUTION: Replace "reputation" with "mission". good catch. good suggestion. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Sun Jun 8 12:18:47 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24709 for ; Sun, 8 Jun 2003 12:18:46 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AEA9F62577; Sun, 8 Jun 2003 18:18:17 +0200 (CEST) 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 98FBB622B1; Sun, 8 Jun 2003 18:18:06 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h58GL5F27507; Sun, 8 Jun 2003 09:21:05 -0700 Date: Sun, 8 Jun 2003 09:13:36 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <481518433.20030608091336@brandenburg.com> To: Harald Tveit Alvestrand In-Reply-To: <120210000.1055072340@askvoll.hjemme.alvestrand.no> References: <120210000.1055072340@askvoll.hjemme.alvestrand.no> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: ISSUE: Determinants for timeliness missing in section 2.1 X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Harald, HTA> SUGGESTED RESOLUTION: Add something like this: HTA> o The IETF is unable to determine explicitly what effect it desires to HTA> have in the marketplace, and is therefore unable to determine what HTA> requirements of timeliness are appropriate to consider when planning work. i thought we knew exactly what effect we wanted to have: we want to define protocols that get used. i suspect you mean something deeper than that. please clarify. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Sun Jun 8 12:35:18 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24860 for ; Sun, 8 Jun 2003 12:35:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9589062577; Sun, 8 Jun 2003 18:34:48 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6307A622B1; Sun, 8 Jun 2003 18:34:44 +0200 (CEST) Date: Sun, 08 Jun 2003 18:34:44 +0200 From: Harald Tveit Alvestrand To: Dave Crocker Message-ID: <125670000.1055090084@askvoll.hjemme.alvestrand.no> In-Reply-To: <481518433.20030608091336@brandenburg.com> References: <120210000.1055072340@askvoll.hjemme.alvestrand.no> <481518433.20030608091336@brandenburg.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Cc: problem-statement@alvestrand.no Subject: Re: ISSUE: Determinants for timeliness missing in section 2.1 X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA24860 --On søndag, juni 08, 2003 09:13:36 -0700 Dave Crocker wrote: > Harald, > > HTA> SUGGESTED RESOLUTION: Add something like this: > HTA> o The IETF is unable to determine explicitly what effect it desires > to HTA> have in the marketplace, and is therefore unable to determine > what HTA> requirements of timeliness are appropriate to consider when > planning work. > > i thought we knew exactly what effect we wanted to have: we want to > define protocols that get used. > > i suspect you mean something deeper than that. please clarify. ok... I'll argue by controversial example again, as usual... The IPv6 proponents were in a desperate hurry to get this deployed in 1993, because addresses were running out. The IPv6 opponents did not agree on the basic needs, and therefored did not agree on the requirements for the timetable. Addresses got more expensive, which led to tricks (like NAT) to avoid consuming them so rapidly. So around 1997 there was a kind of lull, where the IPv6 advocates slogged along, refining their stuff and considering what added features could help "sell" IPv6 in the marketplace. In 2003, the pain of those tricks seems to have grown to the point where we (again) are desperate to get IPv6 deployed. And some of the stuff that seemed like a good idea in 1997 doesn't seem so great any more. If we'd had perfect (fore/hind)sight, we might have concluded in 1993 that we needed something by 1997, and would plan take a little more time to - for instance - settle the endpoint-identifier vs aggregatable/routable identifier by 1995 rather than leaving bits and pieces that point in both directions cluttering up the landscape (and the discussion lists!) to the present day. Or in the IM debaclee - if we had had consensus in 1997 that nobody's going to make IM systems interoperable over the next five years if we don't do it, and that this interoperability is actually what the IETF wants, we might have been able to force the IMPP group to stop dithering about and get its documents published three years ago. In both of those cases, we started off (IMHO) with unclear and unresolved visions of what we wanted to achieve, and this led to setting schedules that had much to do with our feeling of hurry, but little to do with a realistic expectation of when the industry needed our end product. In the case of DHCPv6 - we got an external customer (3GPP), with a documented need and a fixed deadline - and the document got out. The customer provided the necessary timeframe - "if you want to get this done in this particular context in a standard way, give us the standard by this date". Beneficial results for all. From problem-statement-bounces@alvestrand.no Sun Jun 8 12:48:18 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25041 for ; Sun, 8 Jun 2003 12:48:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 77706625CC; Sun, 8 Jun 2003 18:47:47 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4100F62577; Sun, 8 Jun 2003 18:47:41 +0200 (CEST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h58GlYLV013003; Sun, 8 Jun 2003 12:47:35 -0400 (EDT) Date: Sun, 8 Jun 2003 12:47:34 -0400 (EDT) From: Ralph Droms To: Harald Tveit Alvestrand In-Reply-To: <125670000.1055090084@askvoll.hjemme.alvestrand.no> Message-ID: References: <120210000.1055072340@askvoll.hjemme.alvestrand.no> <125670000.1055090084@askvoll.hjemme.alvestrand.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Dave Crocker Cc: problem-statement@alvestrand.no Subject: Re: ISSUE: Determinants for timeliness missing in section 2.1 X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Harald, I understand the point you are trying to make ... but I'm not sure DHCPv6 is such a good example. Unless there's more to the acceptance of DHCPv6 by the IESG than I know about, I think this history of DHCPv6 is something of an oversimplification and omits many other pressures - both positivie and negative - on the forward progresss of DHCPv6. - Ralph On Sun, 8 Jun 2003, Harald Tveit Alvestrand wrote: > In the case of DHCPv6 - we got an external customer (3GPP), with a > documented need and a fixed deadline - and the document got out. > The customer provided the necessary timeframe - "if you want to get this > done in this particular context in a standard way, give us the standard by > this date". > > Beneficial results for all. > > > From problem-statement-bounces@alvestrand.no Sun Jun 8 18:50:39 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03023 for ; Sun, 8 Jun 2003 18:50:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5C3546257A; Mon, 9 Jun 2003 00:50:08 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7594E6256C for ; Mon, 9 Jun 2003 00:50:06 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19P8zD-000Arl-00; Sun, 08 Jun 2003 22:50:05 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19P6iy-0000fc-BK; Sun, 08 Jun 2003 13:25:08 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 8 Jun 2003 13:25:07 -0700 To: "Spencer Dawkins" References: <74750000.1054904612@askvoll.hjemme.alvestrand.no> <074a01c32d78$bd318350$0200a8c0@DFNJGL21> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: ISSUE: Goal of problem-statement document X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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, in line with many contributors to the mailing list, do not >>> believe that the process of problem resolution will be helped >>> by continued rework of the root issues in what would probably >>> be a vain attempt to achieve any sort of consensus. Instead, >>> the general tenor and scope of the problems identified will >>> provide a guide in setting up the processes needed to resolve >>> the problems and provide input to the resolvers. >> >> i always found this part particularly amusing considering it is >> being pushed by the same folk who so strongly push for a classic >> software engineering management view of the wg product process. >> how can we think we will produce a good result if we do not first >> define the needs and requirements well? > > I can't speak for others, but my goal here was to avoid > having to figure out what the IETF consensus was on a > prioritized root cause list before moving on any root cause. > This looked like death to me. I don't believe there are ANY > scope limits on discussions about the relative priority of > root IETF problems, unlike our normal engineering work. > > So I thought developing a root cause list (which we have > done, at least at some level) was sufficient, without spending > time trying to determine priorities. I thought this was "good > enough". problem is that the statement in 1.3 does not say that. the word priority does not occur in 1.3. again, it says very clearly We, in line with many contributors to the mailing list, do not believe that the process of problem resolution will be helped by continued rework of the root issues in what would probably be a vain attempt to achieve any sort of consensus. i applaud the later attempts to get at the root issues. but i believe the above statement dilutes their importance and could [unintentionally] be used to dilute attention to the root causes when we try to find ways to work on the problems. randy From problem-statement-bounces@alvestrand.no Sun Jun 8 18:51:34 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03048 for ; Sun, 8 Jun 2003 18:51:34 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A69256257F; Mon, 9 Jun 2003 00:51:05 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4F3F16259B for ; Mon, 9 Jun 2003 00:50:40 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19P8zH-000Arl-00; Sun, 08 Jun 2003 22:50:39 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19P5Yj-0000cb-GE; Sun, 08 Jun 2003 12:10:29 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 8 Jun 2003 12:10:28 -0700 To: "Bound, Jim" References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> Message-Id: Cc: Margaret Wasserman Cc: problem-statement@alvestrand.no Cc: Brian E Carpenter Subject: RE: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 solution is for the ADs to entrust more authority and empower > chairs to make stronger decisions on what should and should not > move forward. that is not the problem i see day to day. what i see is chairs not wanting to take a stand against weak documents, ersatz populism being easier, and preferring to let it through to ietf last call and iesg, letting the iesg take the heat. > But then the AD would have to give up some of their authority > too. rofl! all the authority and fifteen cents will get you on the subway [0]. but it seems not to make a squat difference to get higher quality documents out from the wgs. randy --- [0] showing my age :-) From problem-statement-bounces@alvestrand.no Sun Jun 8 20:04:22 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04145 for ; Sun, 8 Jun 2003 20:04:21 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E9BAA6256C; Mon, 9 Jun 2003 02:03:50 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2823162278 for ; Mon, 9 Jun 2003 02:03:48 +0200 (CEST) Received: by romeo.rtfm.com (Postfix, from userid 556) id C94D7ABA9; Sun, 8 Jun 2003 17:09:59 -0700 (PDT) To: Randy Bush References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> From: Eric Rescorla Date: 08 Jun 2003 17:09:59 -0700 In-Reply-To: Message-ID: Lines: 25 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Margaret Wasserman Cc: problem-statement@alvestrand.no Cc: Brian E Carpenter Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: EKR 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 Randy Bush writes: > > But then the AD would have to give up some of their authority > > too. > > rofl! all the authority and fifteen cents will get you on the > subway [0]. I'm not sure what you're saying here. The ADs have immense authority--the authority to block documents. Since companies and WGs spend lots of time and money trying to get documents passed, the ability to block > but it seems not to make a squat difference to get > higher quality documents out from the wgs. As I said previously it's not at all clear to me that having a high quality document has much of an impact on how quickly a document proceeds through the IESG. What incentives do WGs have to produce high quality documents? -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From problem-statement-bounces@alvestrand.no Sun Jun 8 20:12:35 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04300 for ; Sun, 8 Jun 2003 20:12:34 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 16DC26256C; Mon, 9 Jun 2003 02:12:04 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id A696C62278 for ; Mon, 9 Jun 2003 02:11:57 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19PAGN-0004Dy-3E; Sun, 08 Jun 2003 17:11:51 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 8 Jun 2003 17:11:50 -0700 To: Eric Rescorla References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> Message-Id: Cc: Margaret Wasserman Cc: problem-statement@alvestrand.no Cc: Brian E Carpenter Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 >> rofl! all the authority and fifteen cents will get you on the >> subway [0]. > I'm not sure what you're saying here. The ADs have immense > authority--the authority to block documents. nice hyperbole, but the fact is no one blocks documents, we point out what we think are problems and ask to discuss them to either find out we have misunderstood or, should the problem be real, actually get the problem addressed. this is the same 'authority' the author, editor, wg chair, or reviewer has. big whoopie doo. the question is what can be done to improve the quality of documents. > Since companies and WGs spend lots of time and money trying to > get documents passed, the ability to block artificial polarization. as i said above, documents can be called for discussion by 92.3% of the population. the problem is that some authors, editors, wg chairs, ... seem to prefer the lazy but beauty contest winning path of saying yes to anything and then hoping the iesg will take the heat for asking the hard questions. randy From problem-statement-bounces@alvestrand.no Sun Jun 8 20:22:56 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04462 for ; Sun, 8 Jun 2003 20:22:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B31066256C; Mon, 9 Jun 2003 02:22:24 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by eikenes.alvestrand.no (Postfix) with ESMTP id 05C7062278 for ; Mon, 9 Jun 2003 02:22:16 +0200 (CEST) Received: by romeo.rtfm.com (Postfix, from userid 556) id B3E7DABA9; Sun, 8 Jun 2003 17:28:29 -0700 (PDT) To: Randy Bush References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> From: Eric Rescorla Date: 08 Jun 2003 17:28:29 -0700 In-Reply-To: Message-ID: Lines: 51 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Margaret Wasserman Cc: problem-statement@alvestrand.no Cc: Brian E Carpenter Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: EKR 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 Randy Bush writes: > >> rofl! all the authority and fifteen cents will get you on the > >> subway [0]. > > I'm not sure what you're saying here. The ADs have immense > > authority--the authority to block documents. > > nice hyperbole, but the fact is no one blocks documents, we point > out what we think are problems and ask to discuss them to either > find out we have misunderstood or, should the problem be real, > actually get the problem addressed. this is the same 'authority' > the author, editor, wg chair, or reviewer has. big whoopie doo. Randy, this is disingenuous. A single reviewer cannot make a document fail to progress, though they can make a big stink. An AD can, and they frequently do. One example: The IESG held TLS for nearly a year because they insisted that their be a mandatory algorithm and that it be DH/3DES/SHA. No other group of 13 people in the IETF could have done that, no matter how big a stink they raised. In point of fact, 2 or 3 ADs could have done this. > the question is what can be done to improve the quality of > documents. I agree that that's the question, but in order to address that question we must first clearly understand what's happening at the moment. > > Since companies and WGs spend lots of time and money trying to > > get documents passed, the ability to block > > artificial polarization. as i said above, documents can be called > for discussion by 92.3% of the population. Yes, but most of those people can't kill it entirely if they so choose. The IESG effectively can. > the problem is that > some authors, editors, wg chairs, ... seem to prefer the lazy but > beauty contest winning path of saying yes to anything and then > hoping the iesg will take the heat for asking the hard questions. This neither shocks nor surprises me. People respond to incentives. I ask again: what incentives do the WGs have to produce documents that meet the IESG's definition of quality? -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From problem-statement-bounces@alvestrand.no Sun Jun 8 20:33:44 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04735 for ; Sun, 8 Jun 2003 20:33:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED3B96256C; Mon, 9 Jun 2003 02:33:12 +0200 (CEST) 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 635BF62278; Mon, 9 Jun 2003 02:32:59 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h590ZwF13288; Sun, 8 Jun 2003 17:35:58 -0700 Date: Sun, 8 Jun 2003 17:32:46 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <721113479.20030608173246@brandenburg.com> To: Harald Tveit Alvestrand In-Reply-To: <125670000.1055090084@askvoll.hjemme.alvestrand.no> References: <120210000.1055072340@askvoll.hjemme.alvestrand.no> <481518433.20030608091336@brandenburg.com> <125670000.1055090084@askvoll.hjemme.alvestrand.no> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: ISSUE: Determinants for timeliness missing in section 2.1 X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Harald, Thank you for the examples. They are both painful and enlightening. I think there is a commonality among the two examples and a number of other problematic IETF efforts. HTA> The IPv6 proponents were in a desperate hurry to get this deployed in 1993, HTA> because addresses were running out. HTA> The IPv6 opponents did not agree on the basic needs, and therefored did not HTA> agree on the requirements for the timetable. During those debates, an interesting fulcrum for the two sides was the definition of "running out". For some, it was "reasonable requests for address blocks get turned down". For others it was "there are no more addresses left to assign". There were plenty of statements about *existing* problems getting desired (and, I would argue, reasonable) allocations. In other words, if we looked at the question of having difficulty getting needed address blocks, we were already in a crisis. Those arguing for a lack of urgency took the latter definition, and developed clever analyses that said we would not have a problem until 2010 or 2020. Key to this is that those who felt a sense of urgency were forced to take many years longer. This, then, gave the IPv6 work an opportunity to add a remarkable number of additional requirements that would have been approached more incrementally, if the urgency had been allowed to direct near-term efforts. HTA> If we'd had perfect (fore/hind)sight, we might have concluded in 1993 that HTA> we needed something by 1997, Let me suggest that wishing for, and thinking about, such insight is something we all tend to do, but that it is exactly the wrong point to consider. We will never have it. Wishing otherwise distracts us from finding constructive paths. What well *might* be constructive is to try to understand why we did not take the action that we now wish we had. In this case, I believe the constructive path should have been to note the considerable base of support for near-term efforts and then letting it proceed. Instead, frankly, the IETF served primarily as a block to near-term efforts. That is, when we talk about being unable to get agreement, what we mean is that we could not get a strong consensus among everyone who was participating in the discussions. On its face, that sounds exactly like a lack of consensus. What it misses is the opportunity to redefine the population for which consensus is sought. There are times that the only thing to do is divide the constituencies up. Each will achieve a strong consensus for their independent views. As long as each has credible participation, that should be enough. And though I use this example far too much, I will again cite the MIME and ESMTP efforts. Those seeking to support 'international' characters in Internet mail could not agree on a single approach. So the efforts were divided between the "enhance content labeling" versus "enhance transport". And they went their separate ways. The results was quite nice. Except for being required to share MIB data, SNMP and CMOT were allowed to develop independently. Again, the result was quite nice. HTA> Or in the IM debaclee - if we had had consensus in 1997 that nobody's going HTA> to make IM systems interoperable over the next five years if we don't do HTA> it, and that this interoperability is actually what the IETF wants, we HTA> might have been able to force the IMPP group to stop dithering about and HTA> get its documents published three years ago. 1. The IM discussions were saddled with the very real difficulty of being unable to partition the problem into sufficiently independent technical pieces, until 2 years ago. There is a strong argument that that was too late. Even then, not very many people seemed able to maintain the conceptual separation. 2. Multiple proposals were, in fact, developed, as you know, since it was on your watch as working group chair. However, again, they were forced to "coordinate" and, in effect, were made dependent on a fourth, separate effort that had the claimed intend of permitting "gatewaying" among the alternatives. Worse, that fourth effort did not have a documented charter and its goal moved around, making its work at best inconsistent. HTA> In both of those cases, we started off (IMHO) with unclear and unresolved HTA> visions of what we wanted to achieve, and this led to setting schedules HTA> that had much to do with our feeling of hurry, but little to do with a HTA> realistic expectation of when the industry needed our end product. On the contrary, I believe there were plenty of people in both situations that had a very clear vision of what they wanted to achieve. The real problem is that they were prevented from pursuing those visions, due to requirements to satisfy additional constraints and/or to coordinate with competing efforts. As much as we all dislike fragmented results, the IETF has a pretty terrible track record when it tries to coerce coordination. (Just ask the SNMP MIB guys how much they like ASN.1, for example.) This all suggests two lines of changes: 1. Really require clear, focused, near-term deliverables, and require that the deliverables result in a discrete, usable bits of functionality. (Derivative change is to stop chartering efforts that cannot define those clear, focused, near-term deliverables.) 2. Stop requiring the the deliverables be saddled with large amounts of additional constraints and features and coordination with others, and especially stop trying to coordinate among competing efforts. Any effort that can amass a credible constituency for doing the work and seeming likely to implement it should be allowed to proceed. When competition is between paradigms, the differences can't be resolved. If we can legitimately get the community to choose one paradigm, then fine, but when the schism holds, then divide and let time and work do the conquering. HTA> In the case of DHCPv6 - we got an external customer (3GPP), with a HTA> documented need and a fixed deadline - and the document got out. That's what happened for fax-over-email, too, based on ITU deadlines. I would agree that it had very good effect. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Sun Jun 8 20:41:56 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04876 for ; Sun, 8 Jun 2003 20:41:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F15D76256C; Mon, 9 Jun 2003 02:41:25 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id B41A062278 for ; Mon, 9 Jun 2003 02:41:18 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19PAir-0004Gm-4i; Sun, 08 Jun 2003 17:41:17 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 8 Jun 2003 17:41:16 -0700 To: Eric Rescorla References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > The IESG held TLS for nearly a year because they insisted that > their be a mandatory algorithm and that it be DH/3DES/SHA. No > other group of 13 people in the IETF could have done that, no > matter how big a stink they raised. In point of fact, 2 or 3 ADs > could have done this. false. the authors could have. the editor(s) if they existed could have. the wg chair(s) could have. respected members of the security directorate could have. ... and my guess, though i am not a security expert, is that they probably SHOULD HAVE. > I ask again: what incentives do the WGs have to produce documents > that meet the IESG's definition of quality? as a multi-decade manager of O(20^(2-3)) engineers, i came to the conclusion that 82.3% of whether an engineer produces quality is whether they have pride in their work and their team. the classic hiring manager's joke about engineers is that we ask "what is the project and with whom will i be working. .... oh yes, my spouse told me to ask about salary and benefits." what keeps the cows in the pasture is the quality of the grass not the height of the fence. a fair portion of our culture is weak on giving credit where it is due, saying "this was maude's idea, not mine," etc. when the culture was smaller in number, it was easier for the work to be known by the person(s) who produced it. this is good and bad, depending on whether the work is good or not so good (i will resist examples:-). if we spent more of our time praising and encouraging the good work of our peers as opposed to labeling them as idiots, black helicopter pilots, etc. perhaps we all would take the necessary corrective constructive criticism a bit better and the results would be better. randy From problem-statement-bounces@alvestrand.no Sun Jun 8 20:55:48 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05136 for ; Sun, 8 Jun 2003 20:55:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3C3866256C; Mon, 9 Jun 2003 02:55:17 +0200 (CEST) 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 81B5762278 for ; Mon, 9 Jun 2003 02:55:14 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h590w8F14138; Sun, 8 Jun 2003 17:58:08 -0700 Date: Sun, 8 Jun 2003 17:52:25 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <5022291864.20030608175225@brandenburg.com> To: Eric Rescorla In-Reply-To: References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Eric, ER> I ask again: what incentives do the WGs have to produce documents ER> that meet the IESG's definition of quality? I think you just highlighted a key problem: The IESG can and must provide a quality control mechanism. But it is the community that must define the necessary quality. And, yes, "the community" is a pretty darn fuzzy construct, which is why we end up with each AD (and each IAB member) defining their own criteria and applying them independently. Still, we need to find reasonable, community based criteria -- beyond just the criteria of the working group, so that it represents a broader view -- with the IESG enforcing it, rather than inventing it. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Sun Jun 8 20:59:19 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05190 for ; Sun, 8 Jun 2003 20:59:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5034C6256C; Mon, 9 Jun 2003 02:58:48 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id 89A6362278 for ; Mon, 9 Jun 2003 02:58:41 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19PAzf-0004Jt-N3; Sun, 08 Jun 2003 17:58:39 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 8 Jun 2003 17:58:39 -0700 To: Dave Crocker References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> <5022291864.20030608175225@brandenburg.com> Message-Id: Cc: problem-statement@alvestrand.no Cc: Eric Rescorla Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > Still, we need to find reasonable, community based criteria -- > beyond just the criteria of the working group, so that it > represents a broader view -- with the IESG enforcing it, rather > than inventing it. does not scale. this is still the mode where the authors, wgs, chairs, ... wuss out. quality management 101: the philosophy of building quality has to be pushed to the edges so it encompasses the whole organization. randy From problem-statement-bounces@alvestrand.no Sun Jun 8 21:25:23 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05707 for ; Sun, 8 Jun 2003 21:25:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AD2096256C; Mon, 9 Jun 2003 03:24:51 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by eikenes.alvestrand.no (Postfix) with ESMTP id C0EDC62278 for ; Mon, 9 Jun 2003 03:24:44 +0200 (CEST) Received: by romeo.rtfm.com (Postfix, from userid 556) id AE200ABAB; Sun, 8 Jun 2003 18:30:58 -0700 (PDT) To: Dave Crocker References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> <5022291864.20030608175225@brandenburg.com> From: Eric Rescorla Date: 08 Jun 2003 18:30:58 -0700 In-Reply-To: <5022291864.20030608175225@brandenburg.com> Message-ID: Lines: 32 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: problem-statement@alvestrand.no Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: EKR 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 Dave Crocker writes: > Eric, > > ER> I ask again: what incentives do the WGs have to produce documents > ER> that meet the IESG's definition of quality? > > I think you just highlighted a key problem: > > The IESG can and must provide a quality control mechanism. But it is > the community that must define the necessary quality. > > And, yes, "the community" is a pretty darn fuzzy construct, which is why > we end up with each AD (and each IAB member) defining their own criteria > and applying them independently. > > Still, we need to find reasonable, community based criteria -- beyond > just the criteria of the working group, so that it represents a broader > view -- with the IESG enforcing it, rather than inventing it. I don't have a problem with this. The point I'm trying to make (and tried to make in SF) was that it seems to me that a rather small part of the variation in how long a document takes to clear the IESG is the quality of the document (whatever that means). Accordingly, I don't think that WGs have a particularly strong incentive to meet any particular bar. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From problem-statement-bounces@alvestrand.no Sun Jun 8 21:30:37 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05900 for ; Sun, 8 Jun 2003 21:30:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F2CFE6256C; Mon, 9 Jun 2003 03:30:06 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by eikenes.alvestrand.no (Postfix) with ESMTP id 32A6B62278 for ; Mon, 9 Jun 2003 03:30:04 +0200 (CEST) Received: by romeo.rtfm.com (Postfix, from userid 556) id 8BF2AABAB; Sun, 8 Jun 2003 18:36:17 -0700 (PDT) To: Randy Bush References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> From: Eric Rescorla Date: 08 Jun 2003 18:36:17 -0700 In-Reply-To: Message-ID: Lines: 73 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: problem-statement@alvestrand.no Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: EKR 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 Randy Bush writes: > > The IESG held TLS for nearly a year because they insisted that > > their be a mandatory algorithm and that it be DH/3DES/SHA. No > > other group of 13 people in the IETF could have done that, no > > matter how big a stink they raised. In point of fact, 2 or 3 ADs > > could have done this. > > false. the authors could have. the editor(s) if they existed > could have. In this case, the editors wanted something different. But you're wrong about what they could have done. Editors have been removed from documents based on WG consensus before. > the wg chair(s) could have. The chairs are again subject to WG consensus, and occasionally do get removed for this kind of thing. > respected members of the > security directorate could have. ... There was no security directorate at the time, but the security directorage has no power per se. The only power they have is to lobby the AD. The only people in the IETF who can realistically block a document semi-indefinitely over the will of the WG are the ADs. However much we might will it to be so, the IETF is not a democracy. At best, it's a republic, and not much of one at that. > > I ask again: what incentives do the WGs have to produce documents > > that meet the IESG's definition of quality? > > as a multi-decade manager of O(20^(2-3)) engineers, i came to the > conclusion that 82.3% of whether an engineer produces quality is > whether they have pride in their work and their team. the classic > hiring manager's joke about engineers is that we ask "what is the > project and with whom will i be working. .... oh yes, my spouse > told me to ask about salary and benefits." Hmm... I'm not sure I subscribe to this theory, but in any case... I think that there are two things going on: (1) The WGs have a genuinely different definition of quality from that of the IESG. As a consequence, many arguments about quality are really about whose standard will be enforced. The perennial arguments about security come to mind. In cases like this, no amount of pride in work will solve the problem since the issue is a difference of opinion. The IESG can of course force people to comply with their view but that only works if people are consistently rewarded for doing so (or punished for not doing so). (2) Protocol quality and document quality are not necessarily the same thing. In many cases, people are interested in having a protocol they consider good (with the caveat above) but don't much care about the technical writing. Engineers skimp on tech doc all the time. We don't want that, but again we have to force people to do it because it doesn't come naturally to them. Consider the following thought experiment: take all the documents that come before the IESG in a year. Rank them in terms of quality. Then plot quality against "time to approve". Ask what the correlation is. If there's not a high correlation, why would you expect people to produce high quality work? -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From problem-statement-bounces@alvestrand.no Sun Jun 8 23:32:58 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08149 for ; Sun, 8 Jun 2003 23:32:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 98FAD6257F; Mon, 9 Jun 2003 05:32:28 +0200 (CEST) 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 6A28D6256C for ; Mon, 9 Jun 2003 05:32:26 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h593ZQF19979 for ; Sun, 8 Jun 2003 20:35:26 -0700 Date: Sun, 8 Jun 2003 20:32:16 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <131883516.20030608203216@brandenburg.com> To: problem-statement@alvestrand.no In-Reply-To: References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> <5022291864.20030608175225@brandenburg.com> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 >> Still, we need to find reasonable, community based criteria -- >> beyond just the criteria of the working group, so that it >> represents a broader view -- with the IESG enforcing it, rather >> than inventing it. 1. RB> does not scale. this is still the mode where the authors, wgs, RB> chairs, ... wuss out. 2. RB> quality management 101: the philosophy of building quality has to RB> be pushed to the edges so it encompasses the whole organization. These two two statements appear to be mutually exclusive. The first says you can't trust all the folks "out there" because they wuss out, while the second says you have to have quality "at the edges". If the latter does not mean all those folk "out there" then who are you referring to? Most interestingly, the first statement fundamentally translates to: The entire body of folk who do the core work of the IETF have no understanding or integrity about quality. That doesn't leave much of a base for creating quality, does it? But perhaps what I originally said was not sufficiently grokked. So let's try again: We need a framework for quality that is embraced by the *general* IETF community, so it can be enforced by the IESG, to help individual *portions* of the IETF community (ie, individual working groups) produce work consistent with that framework. What we have now is: a) no broad base of shared sense about quality, b) invention of criteria by individual area directors, c) inconsistent application of the criteria, and d) application of the criteria far too late in the process. What we need are specific suggestions, beyond recitation of generic course teachings. Something we can actually apply, to improve the production of quality specs in a timely manner. ER> The only people in the IETF who can realistically block a ER> document semi-indefinitely over the will of the WG are the ER> ADs. It is curious to see some people try to claim that this is not so, or at least that it never happens, no matter how many of the IETF's worker bees claim it IS so and it DOES happen. That kind of disconnect is rather dangerous to an organization. ER> (1) The WGs have a genuinely different definition of quality from ER> that of the IESG. As a consequence, many arguments about quality ER> are really about whose standard will be enforced. Worst of all is that neither 'side' typically has their quality model documented. So we wind up arguing nits or intangibles, rather than substantive issues. ER> Consider the following thought experiment: take all the documents ER> that come before the IESG in a year. Rank them in terms of quality. ER> Then plot quality against "time to approve". Ask what the correlation ER> is. If there's not a high correlation, why would you expect people ER> to produce high quality work? Interesting suggestion. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Mon Jun 9 00:39:23 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08820 for ; Mon, 9 Jun 2003 00:39:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6ADE662581; Mon, 9 Jun 2003 06:38:54 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9CCFB6256C for ; Mon, 9 Jun 2003 06:38:51 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19PEQj-0004jz-Rc; Sun, 08 Jun 2003 21:38:49 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 8 Jun 2003 21:38:49 -0700 To: Eric Rescorla References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> <5022291864.20030608175225@brandenburg.com> Message-Id: Cc: Dave Crocker Cc: problem-statement@alvestrand.no Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > The point I'm trying to make (and tried to make in SF) was that > it seems to me that a rather small part of the variation in how > long a document takes to clear the IESG is the quality of the > document (whatever that means). and what substantiates that perception? randy From problem-statement-bounces@alvestrand.no Mon Jun 9 00:57:21 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09030 for ; Mon, 9 Jun 2003 00:57:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EAC6762581; Mon, 9 Jun 2003 06:56:51 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id E475F6256C for ; Mon, 9 Jun 2003 06:56:49 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19PEi8-00058N-MA; Sun, 08 Jun 2003 21:56:48 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 8 Jun 2003 21:56:47 -0700 To: Dave Crocker References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> <5022291864.20030608175225@brandenburg.com> <131883516.20030608203216@brandenburg.com> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 >>> Still, we need to find reasonable, community based criteria -- >>> beyond just the criteria of the working group, so that it >>> represents a broader view -- with the IESG enforcing it, rather >>> than inventing it. > > 1. > RB> does not scale. this is still the mode where the authors, wgs, > RB> chairs, ... wuss out. > > 2. > RB> quality management 101: the philosophy of building quality has to > RB> be pushed to the edges so it encompasses the whole organization. > > > These two two statements appear to be mutually exclusive. The first says you > can't trust all the folks "out there" because they wuss out, while the > second says you have to have quality "at the edges". If the latter does > not mean all those folk "out there" then who are you referring to? > > Most interestingly, the first statement fundamentally translates to: > > The entire body of folk who do the core work of the IETF have no > understanding or integrity about quality. no. it says YOUR STATEMENT ABOUT THEM is incorrect. randy From problem-statement-bounces@alvestrand.no Mon Jun 9 01:06:01 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09225 for ; Mon, 9 Jun 2003 01:06:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D60CA62590; Mon, 9 Jun 2003 07:05:29 +0200 (CEST) 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 A888762586 for ; Mon, 9 Jun 2003 07:05:26 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h5958OF23005; Sun, 8 Jun 2003 22:08:24 -0700 Date: Sun, 8 Jun 2003 22:05:09 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1237455788.20030608220509@brandenburg.com> To: Randy Bush In-Reply-To: References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> <5022291864.20030608175225@brandenburg.com> <131883516.20030608203216@brandenburg.com> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Cc: Dave Crocker Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Randy, RB> no. it says YOUR STATEMENT ABOUT THEM is incorrect. Thanks. No doubt that cleared everything up. d/ ps. exercise for the reader: 1) which statement and about whom? 2) extra credit: what about the statement was incorrect and why? -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Mon Jun 9 01:08:57 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09248 for ; Mon, 9 Jun 2003 01:08:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D7C5262594; Mon, 9 Jun 2003 07:08:26 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5D03862590 for ; Mon, 9 Jun 2003 07:08:25 +0200 (CEST) Received: by romeo.rtfm.com (Postfix, from userid 556) id 419D4ABAC; Sun, 8 Jun 2003 22:14:38 -0700 (PDT) To: Randy Bush References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> <5022291864.20030608175225@brandenburg.com> From: Eric Rescorla Date: 08 Jun 2003 22:14:37 -0700 In-Reply-To: Message-ID: Lines: 32 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Dave Crocker Cc: problem-statement@alvestrand.no Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: EKR 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 Randy Bush writes: > > The point I'm trying to make (and tried to make in SF) was that > > it seems to me that a rather small part of the variation in how > > long a document takes to clear the IESG is the quality of the > > document (whatever that means). > > and what substantiates that perception? Well, there's people's personal experience, of course, but as we all know, the plural of anecdote is not data. As I noted at the time, the variance of time-to-approve is quite large, even for documents that are approved by the IETF as-is. That's not completely inconsistent with document quality, but if the documents that are taking a long time to clear (>100 days) are really that low quality, it's somewhat surprising that they aren't sent back for revision. Do I have any totally convincing evidence? No. It's just my intuition, combined with the lack of strong evidence to the contrary. However, to the extent to which people believe that the quality effect is small then there's no incentive to quality, regardless of whether it's in fact true. I of course can't speak for what other people believe, though I imagine that that would be relatively easy to discover without too much complicated analyiss. Really, -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From problem-statement-bounces@alvestrand.no Mon Jun 9 01:11:36 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09317 for ; Mon, 9 Jun 2003 01:11:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B649E62598; Mon, 9 Jun 2003 07:11:04 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id C6B5662594 for ; Mon, 9 Jun 2003 07:11:00 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19PEvr-0005Fk-FS; Sun, 08 Jun 2003 22:10:59 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 8 Jun 2003 22:10:58 -0700 To: Dave Crocker References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> <5022291864.20030608175225@brandenburg.com> <131883516.20030608203216@brandenburg.com> <1237455788.20030608220509@brandenburg.com> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > ps. exercise for the reader: > 1) which statement and about whom? your quoted at the top of the message. the part you deleted. > 2) extra credit: what about the statement was incorrect and why? the comments i made that you also deleted randy From problem-statement-bounces@alvestrand.no Mon Jun 9 01:18:00 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09383 for ; Mon, 9 Jun 2003 01:17:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 97F8162594; Mon, 9 Jun 2003 07:17:29 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6299F62590 for ; Mon, 9 Jun 2003 07:17:27 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19PF26-0005Q8-7E; Sun, 08 Jun 2003 22:17:26 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 8 Jun 2003 22:17:25 -0700 To: Eric Rescorla References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> <5022291864.20030608175225@brandenburg.com> Message-Id: Cc: Dave Crocker Cc: problem-statement@alvestrand.no Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > Do I have any totally convincing evidence? No. It's just my > intuition, ack > combined with the lack of strong evidence to the contrary. uh, i usually avoid the no white crows logic. maybe we should look at the time to process through iesg and the reasons we can find. i do not claim to know any answer, but of course have silly perceptions based on my narrow little view of the movie. so it would be really good to have some actual data. would be nice if bill, harald, or someone with time could find a way to get something real on which we could base a discussion. > to the extent to which people believe that the quality effect is > small then there's no incentive to quality, regardless of whether > it's in fact true. good point. most of what i hear is similar to crocker's "the iesg is imposing it's view of quality," not the iesg is delaying documents for reasonsa we don't understand. of course, the data-tracker stuff should help make all this a bit more visible. randy From problem-statement-bounces@alvestrand.no Mon Jun 9 01:23:54 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09443 for ; Mon, 9 Jun 2003 01:23:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E259F62594; Mon, 9 Jun 2003 07:23:22 +0200 (CEST) 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 B091D62590 for ; Mon, 9 Jun 2003 07:23:19 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h595QHF23719; Sun, 8 Jun 2003 22:26:17 -0700 Date: Sun, 8 Jun 2003 22:23:06 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <4638533538.20030608222306@brandenburg.com> To: Randy Bush In-Reply-To: References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> <5022291864.20030608175225@brandenburg.com> <131883516.20030608203216@brandenburg.com> <1237455788.20030608220509@brandenburg.com> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Cc: Dave Crocker Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Randy, >> ps. exercise for the reader: >> 1) which statement and about whom? RB> your quoted at the top of the message. the part you deleted. Presumably you mean: >>> Still, we need to find reasonable, community based criteria -- >>> beyond just the criteria of the working group, so that it >>> represents a broader view -- with the IESG enforcing it, rather >>> than inventing it. >> 2) extra credit: what about the statement was incorrect and why? RB> the comments i made that you also deleted Including brief text segments, for context reference, is rather different than "deleting" text. Given your own predilection for cryptic reference, it's odd that you would describe it so pejoratively. In any event: > 1. > RB> does not scale. this is still the mode where the authors, wgs, > RB> chairs, ... wuss out. > 2. > RB> quality management 101: the philosophy of building quality has to > RB> be pushed to the edges so it encompasses the whole organization. 1) Note that you did not address the contradiction between your two statements, 2) You did not explain who is left, after you dismiss the worth of authors, wgs and chairs, and 3) what is it, for example, about "community based criteria" that will not scale. And what is it you are suggesting as an alternative that a) is practical, b) WILL scale, and c) is acceptable to the IETF community (ie, the folks on whose behalf area directors are supposed to operate)? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Mon Jun 9 01:30:05 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09519 for ; Mon, 9 Jun 2003 01:30:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6590E62594; Mon, 9 Jun 2003 07:29:33 +0200 (CEST) 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 5CAE762590 for ; Mon, 9 Jun 2003 07:29:30 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h595WSF23955; Sun, 8 Jun 2003 22:32:28 -0700 Date: Sun, 8 Jun 2003 22:29:25 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <19438911932.20030608222925@brandenburg.com> To: Randy Bush In-Reply-To: References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> <5022291864.20030608175225@brandenburg.com> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Randy, RB> good point. most of what i hear is similar to crocker's "the iesg RB> is imposing it's view of quality," not the iesg is delaying RB> documents for reasonsa we don't understand. What is really ironic is that you did not see that I was pointedly being polite, since the latter explanation you cite would mean that the IESG is not even being clear about its reasons and hence could be operating arbitrarily. And, indeed, that is a common thread of concern that is expressed by all those worker bees that you have dismissed as wussing out. But that's ok. Since you believe area directors are not inventing their quality requirements, please direct folks to the statements of community-based quality that area directors are working from. It really would make things quite a bit easier. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Mon Jun 9 01:31:44 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09561 for ; Mon, 9 Jun 2003 01:31:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CA53F6256C; Mon, 9 Jun 2003 07:31:13 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by eikenes.alvestrand.no (Postfix) with ESMTP id 001F861D30 for ; Mon, 9 Jun 2003 07:31:04 +0200 (CEST) Received: by romeo.rtfm.com (Postfix, from userid 556) id 508B2ABAC; Sun, 8 Jun 2003 22:37:17 -0700 (PDT) To: Randy Bush References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> <5022291864.20030608175225@brandenburg.com> From: Eric Rescorla Date: 08 Jun 2003 22:37:17 -0700 In-Reply-To: Message-ID: Lines: 30 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Dave Crocker Cc: problem-statement@alvestrand.no Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: EKR 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 Randy Bush writes: > > Do I have any totally convincing evidence? No. It's just my > > intuition, > > ack > > > combined with the lack of strong evidence to the contrary. > > uh, i usually avoid the no white crows logic. I don't see how we can avoid taking one position or the other, because we have to decide what to do. > maybe we should look at the time to process through iesg and the > reasons we can find. i do not claim to know any answer, but of > course have silly perceptions based on my narrow little view of the > movie. so it would be really good to have some actual data. would > be nice if bill, harald, or someone with time could find a way to > get something real on which we could base a discussion. Well, Dave, Marshall, and I have all taken a stab at processing the data we do have, which at least includes the time in and time out of the IESG, as well as the magnitude of the changes. I don't know what their conclusions were, but my analysis didn't exactly sell me that there was a large quality effect. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From problem-statement-bounces@alvestrand.no Mon Jun 9 01:33:32 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09609 for ; Mon, 9 Jun 2003 01:33:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7112962590; Mon, 9 Jun 2003 07:33:01 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id B59BA61D30 for ; Mon, 9 Jun 2003 07:32:56 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19PFH4-0005oT-VG; Sun, 08 Jun 2003 22:32:55 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 8 Jun 2003 22:32:54 -0700 To: Dave Crocker References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> <5022291864.20030608175225@brandenburg.com> <131883516.20030608203216@brandenburg.com> <1237455788.20030608220509@brandenburg.com> <4638533538.20030608222306@brandenburg.com> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > 2) You did not explain who is left, after you dismiss the worth > of authors, wgs and chairs, and once again, i did not dismiss anyone's worth. i said your proposal did. > 3) what is it, for example, about "community based criteria" that > will not scale. nothing. asking the iesg to be the only enforcer of them will not scale. > And what is it you are suggesting as an alternative that a) is > practical, b) WILL scale, and c) is acceptable to the IETF > community (ie, the folks on whose behalf area directors are > supposed to operate)? unlike some here, i don't think i have all the answers. i am still trying to understand the root problems, hence my participation in the problem-statement list and my basing most of my comments on my admittedly small and narrow personal experience and view not theory. but as i have previously suggested, i suspect we can not scale and produce quality without saying "no" to some things, as tempting as doing everything may be, and without building quality and review into the whole system, from inception through the wgs, through last calls and final review, whether that be iesg or whatever the world becomes. if we come to agreement that producing quality and scaling are two core problems, then i think there is some organizational and management experience from within the computer industry and outside from which we can draw some ideas on quality management etc. but i don't think we've reached consensus that these are the issues yet. randy From problem-statement-bounces@alvestrand.no Mon Jun 9 01:51:46 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09938 for ; Mon, 9 Jun 2003 01:51:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 03A5662586; Mon, 9 Jun 2003 07:51:15 +0200 (CEST) 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 7C2AF6256C for ; Mon, 9 Jun 2003 07:51:10 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h595s9F24699; Sun, 8 Jun 2003 22:54:09 -0700 Date: Sun, 8 Jun 2003 22:50:50 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <2740197300.20030608225050@brandenburg.com> To: Randy Bush In-Reply-To: References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> <5022291864.20030608175225@brandenburg.com> <131883516.20030608203216@brandenburg.com> <1237455788.20030608220509@brandenburg.com> <4638533538.20030608222306@brandenburg.com> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Randy, >> 2) You did not explain who is left, after you dismiss the worth >> of authors, wgs and chairs, and RB> once again, i did not dismiss anyone's worth. i said your proposal RB> did. That is what: RB> does not scale. this is still the mode where the authors, wgs, RB> chairs, ... wuss out. meant??? Wow. A suggestion that we have community-based criteria dismisses authors wgs and chairs? Double wow. >> 3) what is it, for example, about "community based criteria" that >> will not scale. RB> nothing. asking the iesg to be the only enforcer of them will not RB> scale. And another "oh, so *that* is what you meant". This is one of those cases where "cryptic" translates into: It would have helped if you had not deleted the clarity of your note, before sending it the first time. The formal statement about the IESG quality function is that it is a safety mechanism, to help when a working group has essentially running rogue. It is supposed to be a backup mechanism, not a primary mechanism. That role is very different from being "the only enforcer" and I don't recall anyone -- certainly not me -- saying anything like "only" or "the" or any other such label of exclusivity. In any event, if you don't want the IESG to perform any quality functions at all, then what do you propose? Automatically approve anything a working group approves, rather does not raise a major ruckus in the IETF Last Call? RB> but as i have previously suggested, i suspect we can not scale and RB> produce quality without saying "no" to some things, and most folks agree with you. so the concept is not a controversial one. as you note, it is the practise that is challenging. RB> if we come to agreement that producing quality and scaling are two RB> core problems, then i think there is some organizational and RB> management experience from within the computer industry and outside RB> from which we can draw some ideas on quality management etc. but i RB> don't think we've reached consensus that these are the issues yet. really? time to ask folks whether anyone needs convincing of these two points. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Mon Jun 9 02:08:07 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18312 for ; Mon, 9 Jun 2003 02:08:06 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4DA156258D; Mon, 9 Jun 2003 08:07:36 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4459B62586 for ; Mon, 9 Jun 2003 08:07:33 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19PFoZ-0006eR-S1; Sun, 08 Jun 2003 23:07:31 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 8 Jun 2003 23:07:31 -0700 To: Dave Crocker References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> <5022291864.20030608175225@brandenburg.com> <131883516.20030608203216@brandenburg.com> <1237455788.20030608220509@brandenburg.com> <4638533538.20030608222306@brandenburg.com> <2740197300.20030608225050@brandenburg.com> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > A suggestion that we have community-based criteria dismisses authors wgs > and chairs? i am amazed that you have such a hard time understanding. but you seem to have caught it later on in the message at only the third repetition. > The formal statement about the IESG quality function is that it is a > safety mechanism, to help when a working group has essentially running > rogue. It is supposed to be a backup mechanism, not a primary mechanism. > > That role is very different from being "the only enforcer" and I don't > recall anyone -- certainly not me -- saying anything like "only" or > "the" or any other such label of exclusivity. your paragraph you keep forgetting: > Still, we need to find reasonable, community based criteria -- > beyond just the criteria of the working group, so that it > represents a broader view -- with the IESG enforcing it, rather > than inventing it. ^^^^^^^^^^^^^^^^^^^^^^^^^^ as i am on an 18 hour visit home between a week of us tour and now a week in tokyo, and i have a ing 07:15 conf call, please excuse that i don't have the free time on my hands to go around this one point as many times as you seem to. but do have fun, dave, do have fun. randy From problem-statement-bounces@alvestrand.no Mon Jun 9 02:12:34 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21374 for ; Mon, 9 Jun 2003 02:12:33 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7E4146258D; Mon, 9 Jun 2003 08:12:02 +0200 (CEST) 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 35F0E62586 for ; Mon, 9 Jun 2003 08:11:59 +0200 (CEST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])h596BwD15609 for ; Mon, 9 Jun 2003 09:11:58 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com ; Mon, 9 Jun 2003 09:11:57 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 9 Jun 2003 09:11:57 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 9 Jun 2003 09:11:57 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 9 Jun 2003 09:11:57 +0300 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" Date: Mon, 9 Jun 2003 09:11:51 +0300 Message-ID: Thread-Topic: Trusting the IESG to manage the reform process (was:Re:DoingtheRight Things?) Thread-Index: AcMuSJ0RETjPTg+VQxGBXwJPSf1SmAABP0Og From: To: X-OriginalArrivalTime: 09 Jun 2003 06:11:57.0218 (UTC) FILETIME=[07F2B820:01C32E4E] Cc: problem-statement@alvestrand.no Subject: RE: Trusting the IESG to manage the reform process (was:Re:DoingtheRight Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA21374 Hi all, Cutting out the parts of the discussion not relevant to my view: > if we come to agreement that producing quality and scaling are two > core problems, then i think there is some organizational and > management experience from within the computer industry and outside > from which we can draw some ideas on quality management etc. but i > don't think we've reached consensus that these are the issues yet. If it matters, I believe two major core problems are 1) producing quality documents 2) solving current scaling problems and to add a third: 3) producing timely documents (this has relations to 1 & 2). Anyhow, perhaps a reasonable way forward would be to see if we can gain consensus on at least 2 or 3 (not limited to the one's I've listed) core problems & start to move forward on them; while still examining other problems. John From problem-statement-bounces@alvestrand.no Mon Jun 9 02:19:53 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22093 for ; Mon, 9 Jun 2003 02:19:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B9E1162590; Mon, 9 Jun 2003 08:19:22 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id A0C306258D for ; Mon, 9 Jun 2003 08:19:20 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19PFzz-0006vt-AW; Sun, 08 Jun 2003 23:19:19 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 8 Jun 2003 23:19:18 -0700 To: References: Message-Id: Cc: problem-statement@alvestrand.no Subject: RE: Trusting the IESG to manage the reform process (was:Re:DoingtheRight Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 am still unsure, but think basically agree. so let me pick nits before getting some sleep. > If it matters, I believe two major core problems are > 1) producing quality documents s/documents/standards for the internet/ as i am not sure all we produce is the documents, and i think we need to keep our focus on the internet. note that the iesg mission statement from london also included 'relevant,' another easy to measure criterion :-). > 2) solving current scaling problems how about 'the scaling problems we understand today,' or something like that, as we would like what we do to last a while? > and to add a third: > 3) producing timely documents (this has relations to 1 & 2). yup. but, as hta points out, there are subtilties here. randy From problem-statement-bounces@alvestrand.no Mon Jun 9 02:28:19 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22245 for ; Mon, 9 Jun 2003 02:28:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4DCBE6259B; Mon, 9 Jun 2003 08:27:49 +0200 (CEST) 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 A509262590 for ; Mon, 9 Jun 2003 08:27:45 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h596UiF25824; Sun, 8 Jun 2003 23:30:44 -0700 Date: Sun, 8 Jun 2003 23:27:37 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <16042403903.20030608232737@brandenburg.com> To: Randy Bush In-Reply-To: References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> <5022291864.20030608175225@brandenburg.com> <131883516.20030608203216@brandenburg.com> <1237455788.20030608220509@brandenburg.com> <4638533538.20030608222306@brandenburg.com> <2740197300.20030608225050@brandenburg.com> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Randy, >> A suggestion that we have community-based criteria dismisses authors wgs >> and chairs? RB> i am amazed that you have such a hard time understanding. You shouldn't be. >> The formal statement about the IESG quality function is that it is a >> safety mechanism, to help when a working group has essentially running >> rogue. It is supposed to be a backup mechanism, not a primary mechanism. >> >> That role is very different from being "the only enforcer" and I don't >> recall anyone -- certainly not me -- saying anything like "only" or >> "the" or any other such label of exclusivity. RB> your paragraph you keep forgetting: >> represents a broader view -- with the IESG enforcing it, rather >> than inventing it. ^^^^^^^^^^^^^^^^^^^^^^^^^^ That's really excellent. Ignore the opening sentence: DC>The IESG can and must provide a quality control mechanism. but jump on a later sentence as if there were no context. Yes, it is difficult to imagine why anyone would have trouble understanding your meaning. RB> ... RB>excuse that i don't have the free time on my hands to go around Not too pressed for time to have a bit more constructive fun, it would seem. Thanks for your help in developing a constructive exchange. When you say "i am still trying to understand the root problems," you demonstrate an inventive approach to the exploration. Anyone would feel strongly encouraged to participate. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Mon Jun 9 03:23:55 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23224 for ; Mon, 9 Jun 2003 03:23:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B75D862590; Mon, 9 Jun 2003 09:23:23 +0200 (CEST) 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 74E496258D for ; Mon, 9 Jun 2003 09:23:20 +0200 (CEST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])h597NJD23609 for ; Mon, 9 Jun 2003 10:23:19 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com ; Mon, 9 Jun 2003 10:23:19 +0300 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 9 Jun 2003 10:23:18 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 9 Jun 2003 10:22:27 +0300 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" Date: Mon, 9 Jun 2003 10:22:22 +0300 Message-ID: Thread-Topic: Trusting the IESG to manage the reform process(was:Re:DoingtheRight Things?) Thread-Index: AcMuTxZ4b6YxVR3kThixHT4cowsfawACBwSg From: To: X-OriginalArrivalTime: 09 Jun 2003 07:22:27.0501 (UTC) FILETIME=[E164ADD0:01C32E57] Cc: problem-statement@alvestrand.no Subject: RE: Trusting the IESG to manage the reform process(was:Re:DoingtheRight Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA23224 Hi Randy, > i am still unsure, but think basically agree. so let me pick nits > before getting some sleep. > > > If it matters, I believe two major core problems are > > 1) producing quality documents > > s/documents/standards for the internet/ > > as i am not sure all we produce is the documents, and i think > we need to keep our focus on the internet. Well, at the end of the day, they are documents, but perhaps 'documents & standards for the Internet' would be fine. > note that the iesg mission statement from london also included > 'relevant,' another easy to measure criterion :-). Relevant is fairly fuzzy, I agree. > > 2) solving current scaling problems > > how about 'the scaling problems we understand today,' or something > like that, as we would like what we do to last a while? Agreed. > > and to add a third: > > 3) producing timely documents (this has relations to 1 & 2). > > yup. but, as hta points out, there are subtilties here. Agreed & I was exactly thinking of that when I suggested the third point. Thinking a bit more on this topic, timeliness is a dimension which is often overlooked in our work. In otherwords, we should have some sense of what the target is of our work. John From problem-statement-bounces@alvestrand.no Mon Jun 9 04:28:29 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24043 for ; Mon, 9 Jun 2003 04:28:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 259556258D; Mon, 9 Jun 2003 10:27:59 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id F38056258D; Mon, 9 Jun 2003 10:27:56 +0200 (CEST) Date: Mon, 09 Jun 2003 10:27:57 +0200 From: Harald Tveit Alvestrand To: Dave Crocker Message-ID: <148310000.1055147276@askvoll.hjemme.alvestrand.no> In-Reply-To: <721113479.20030608173246@brandenburg.com> References: <120210000.1055072340@askvoll.hjemme.alvestrand.no> <481518433.20030608091336@brandenburg.com> <125670000.1055090084@askvoll.hjemme.alvestrand.no> <721113479.20030608173246@brandenburg.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Cc: problem-statement@alvestrand.no Subject: Re: ISSUE: Determinants for timeliness missing in section 2.1 X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA24043 --On søndag, juni 08, 2003 17:32:46 -0700 Dave Crocker wrote: > HTA> In both of those cases, we started off (IMHO) with unclear and > unresolved HTA> visions of what we wanted to achieve, and this led to > setting schedules HTA> that had much to do with our feeling of hurry, but > little to do with a HTA> realistic expectation of when the industry > needed our end product. > > On the contrary, I believe there were plenty of people in both > situations that had a very clear vision of what they wanted to achieve. > The real problem is that they were prevented from pursuing those > visions, due to requirements to satisfy additional constraints and/or to > coordinate with competing efforts. I don't think those two descriptions contradict each other.... as I frequently say when asking for charters to be more clear: "if you don't write it down in a way I understand, how can I tell that we agree?" From problem-statement-bounces@alvestrand.no Mon Jun 9 04:54:03 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24464 for ; Mon, 9 Jun 2003 04:54:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D670B625A8; Mon, 9 Jun 2003 10:53:33 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 46FA362590; Mon, 9 Jun 2003 10:53:32 +0200 (CEST) Date: Mon, 09 Jun 2003 10:53:32 +0200 From: Harald Tveit Alvestrand To: Dave Crocker Message-ID: <154870000.1055148812@askvoll.hjemme.alvestrand.no> In-Reply-To: <148310000.1055147276@askvoll.hjemme.alvestrand.no> References: <120210000.1055072340@askvoll.hjemme.alvestrand.no> <481518433.20030608091336@brandenburg.com> <125670000.1055090084@askvoll.hjemme.alvestrand.no> <721113479.20030608173246@brandenburg.com> <148310000.1055147276@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Cc: problem-statement@alvestrand.no Subject: Re: ISSUE: Determinants for timeliness missing in section 2.1 X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA24464 following up my own posts is a bad habit, but this one was probably too cryptic..... When we have the case of "plenty of people .... that had a very clear vision of what they wanted to achieve", and have "requirements to satisfy additional constraints", the people imposing additional constraints are people too, and part of the community. What's more, in the cases where those "imposing" people are chosen as leaders of the community, they believe that they represent other members of the community - and may even be right. So - I think it is fair to say that AS A COMMUNITY, we had "unclear and unresolved visions of what we wanted to achieve". Harald --On mandag, juni 09, 2003 10:27:57 +0200 Harald Tveit Alvestrand wrote: > > > --On søndag, juni 08, 2003 17:32:46 -0700 Dave Crocker > wrote: > >> HTA> In both of those cases, we started off (IMHO) with unclear and >> unresolved HTA> visions of what we wanted to achieve, and this led to >> setting schedules HTA> that had much to do with our feeling of hurry, but >> little to do with a HTA> realistic expectation of when the industry >> needed our end product. >> >> On the contrary, I believe there were plenty of people in both >> situations that had a very clear vision of what they wanted to achieve. >> The real problem is that they were prevented from pursuing those >> visions, due to requirements to satisfy additional constraints and/or to >> coordinate with competing efforts. > > I don't think those two descriptions contradict each other.... > as I frequently say when asking for charters to be more clear: > > "if you don't write it down in a way I understand, how can I tell that we > agree?" > > > From problem-statement-bounces@alvestrand.no Mon Jun 9 04:57:32 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24540 for ; Mon, 9 Jun 2003 04:57:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9088C625AA; Mon, 9 Jun 2003 10:57:02 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8369C6259B; Mon, 9 Jun 2003 10:57:00 +0200 (CEST) Date: Mon, 09 Jun 2003 10:57:00 +0200 From: Harald Tveit Alvestrand To: "Bound, Jim" , problem-statement@alvestrand.no Message-ID: <157500000.1055149020@askvoll.hjemme.alvestrand.no> In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B042848E5@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B042848E5@tayexc13.americas.cpqc orp.net> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Subject: RE: ISSUE: Determinants for timeliness missing in section 2.1 X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA24540 --On søndag, juni 08, 2003 08:47:52 -0400 "Bound, Jim" wrote: > I also want to see. > > ISSUE: "IETF process for PS is an issue for achieving such goal and > affecting time to market delivery of our specifications". Text from > many mails. I would prefer Charlie's and Keith's formulation, since their formulation from June 6: "We have a identified a problem that our standards maturity levels do not match with either industry expectations or IETF energies." (ok, it needs some wordsmithing) offer a more general view of the problem. From problem-statement-bounces@alvestrand.no Mon Jun 9 05:50:57 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25458 for ; Mon, 9 Jun 2003 05:50:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 08C4B625B9; Mon, 9 Jun 2003 11:50:27 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 446CC62586 for ; Mon, 2 Jun 2003 21:21:09 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19Murk-000LwL-00 for problem-statement@alvestrand.no; Mon, 02 Jun 2003 14:21:08 -0500 Date: Mon, 02 Jun 2003 15:21:08 -0400 From: John C Klensin To: "problem-statement@alvestrand.no" Message-ID: <522458074.1054567268@p3.JCK.COM> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Mon, 09 Jun 2003 11:50:21 +0200 Subject: Trusting the IESG to manage the reform process (was: Re: Doing the Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit In writing the note about an accelerated process, I realized I'm making an assumption that needs a bit of explanation. Several of the issues here, and what processes might and might not work, are ultimately about whether or not IESG is completely broken and/or in some "us versus them" mode that implies we can't trust them with much of anything, especially anything involving reform or evolution. There are clearly people in the community who believe that the current IESG has formed a closed circle, developed a "them against us" mentality, and cannot be trusted. I don't know how large that group is (although I suspect "not very" would be a good guess). But, if they are right, we don't need incremental procedural suggestions, we need really radical reform. Why? Because at least two consecutive nomcoms, acting independently, have selected (or reselected) the current IESG members. If they have managed to select people who would engage in that sort of conspiracy of untrustworthy behavior, and to do it so successfully that, not only can the IESG behave in undesirable ways, but that no one on the IESG has been willing to speak up in public and say "I see a problem here, but it is all those other folks, not me", then there is something hopelessly broken about the nomcom model, probably to the point that we need to discard it and start over. No one has suggested that yet, but, if people seriously believe that the IESG can no longer be trusted to manage the standards process, or a reform process, or both, I think it is time to move past "list problems only" and get that on the table. Why can't we, instead, just make up some new rules and procedures to "control" the IESG? Because our enforcement mechanisms are almost non-existent if the IESG is unwilling. The IESG has already demonstrated that, under their general responsibility and authority to manage the process, they can and will make up procedural rules that bend written procedures pretty severely. If we trust them, that process may need to be tuned and constrained (as I believe it does) to make our expectations about the limits of what they can do without consulting the community more clear. But, if the trust isn't there, any effort to make more/different rules and procedures is just to give them additional things that they can ignore. So, whether it be about a final decision on a new AD, or on figuring out which process suggestions can just be accepted and deployed without going through a long and complex process, or on managing the process in other ways, I think we need to trust them to make management-level decisions about how best to move forward and hold them accountable for doing that acceptably well. And, if we can't trust them, or at least their good intentions and willingness to do what the community wants and needs, that far, then we had best stop the process of examining the leaves on the forest floor while the place goes up in flames around us. john From problem-statement-bounces@alvestrand.no Mon Jun 9 07:00:04 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27671 for ; Mon, 9 Jun 2003 07:00:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B93C76259B; Mon, 9 Jun 2003 12:59:33 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id 117AC6257F; Mon, 9 Jun 2003 12:59:23 +0200 (CEST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])h59AxMW24188; Mon, 9 Jun 2003 13:59:22 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com ; Mon, 9 Jun 2003 13:59:22 +0300 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 9 Jun 2003 13:59:22 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 9 Jun 2003 13:59:21 +0300 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" Date: Mon, 9 Jun 2003 13:59:20 +0300 Message-ID: Thread-Topic: Staying on Track (Re: Documenting pilots (RE: pausable explanation for the Document Series)) Thread-Index: AcMtAsS93w5VScgXS522ZMzG6STxsQBcy6zw From: To: , X-OriginalArrivalTime: 09 Jun 2003 10:59:21.0589 (UTC) FILETIME=[2E64EA50:01C32E76] Cc: john-ietf@jck.com Cc: problem-statement@alvestrand.no Subject: RE: Staying on Track (Re: Documenting pilots (RE: pausable explanation for the Document Series)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA27671 Hi Margaret, > The process document currently suggests forming a WG to evaluate > improvements to the WG process, develop metrics, run experiments, > etc... IMO, the group should focus on making iterative > improvements to the quality, timeliness and predictability of > WG output that are expected to have near-term results. I think > that there is a lot of low-hanging fruit regarding the process > used by WGs, including milestone management, reviews, etc. So, > I think that we can make quite an improvement in the operation > of the IETF through process improvements in this area. > > There has been some support for the creation of this WG, and for > holding a BOF in Vienna. However, there have also been folks who > have argued that a WG is "too heavyweight" to do this, and > that we should be performing this function in a more adhoc manner. > In particular, John has suggested that the IESG run the process. > > Although I accept that it is within the area of responsibility > of the IESG to run this function, we also have an acknowledged > overload problem for individual IESG members. So, I think that > this is a perfect example of a responsibility that the IESG can, > and should, delegate to members of the community with expertise > in process improvement, metrics development, etc. > > Because I think that this activity should be open to the > community, I favor a WG. > > What do others think? > > It would be nice to get some consensu on this, so I know what to > say in the document. I think that this would be a definate good use of face-to-face time in Vienna. I do not have enough foresight to know if there will be support to create a working group around it, but I think we should consider doing something along the lines that you have proposed. John L. From problem-statement-bounces@alvestrand.no Mon Jun 9 07:35:47 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28156 for ; Mon, 9 Jun 2003 07:35:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8E706625C5; Mon, 9 Jun 2003 13:35:16 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3DE396257F for ; Mon, 9 Jun 2003 13:35:13 +0200 (CEST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])ESMTP id h59BZ9P06663 for ; Mon, 9 Jun 2003 06:35:09 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10Q3G3>; Mon, 9 Jun 2003 13:35:08 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501BC2AFE@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Dave Crocker Date: Mon, 9 Jun 2003 13:35:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Cc: problem-statement@alvestrand.no Subject: RE: Trusting the IESG to manage the reform process (was:Re:Doingt he Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Dave writes: > But that's ok. Since you believe area directors are not > inventing their quality requirements, please direct folks > to the statements of community-based quality that area > directors are working from. > For MIB Doctor reviews, which happen to satisfy my "quality" expectations, we have a document for MIB review: draft-ietf-ops-mib-review-guidelines-01.txt Thanks to Mike Heard as a hard-working editor of that document. We have created it it with the team of MIB Doctors trying to come to consensus what we find important for quality and consistency. We also alerted all WG chairs and a few mailing lists about it and asked for input and comments. We have received a little bit but not much. We of course expect WGs to check their documents against those guidelines before submitting for MIB Doctor review. What we continue to receive, is MIB documents for review that clearly have not been checked at ALL (not a single iota) to this "guidelines" document. > It really would make things quite a bit easier. > So... we hoped it would make things easier and that WGs, members, editors, authors, chairs etc would do a simple check before submitting the doc... but very few seem to take the time up till now. What a pitty. Actually it would be best if MIB documentes where checked at revision zero against the mib review guidelines. I believe that the Security Area has similar docs out that describe what needs to be considered from a security point of view. Maybe we need more. Maybe what we have is not good enuf.. Input is welcome! In terms of: "do good documents get rewarded and bad docs pubished" If one of the MIB doctors who is doing a review tells me: this doc is in good shape and meets all guidelines that we documented... I can tell you that the doc goes much faster than when the MIB doctor tells me and the authors/wg that they did'nt even do a clean compile to check the syntax. It s me off and I can't get eager to go through many rounds of "helping" to improve the doc. Maybe that is bad behaviour on my side... but is a SYNTAX check not the least we may ask for before a doc gets sunmitted? Bert > d/ From problem-statement-bounces@alvestrand.no Mon Jun 9 08:07:43 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29452 for ; Mon, 9 Jun 2003 08:07:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 009A8625C8; Mon, 9 Jun 2003 14:07:11 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from netcore.fi (netcore.fi [193.94.160.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 434BB6257F for ; Mon, 9 Jun 2003 14:07:09 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h59C6p311023; Mon, 9 Jun 2003 15:06:51 +0300 Date: Mon, 9 Jun 2003 15:06:50 +0300 (EEST) From: Pekka Savola To: Eric Rescorla In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Randy Bush Cc: Dave Crocker Cc: problem-statement@alvestrand.no Subject: time-to-approve etc. [Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?)] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 8 Jun 2003, Eric Rescorla wrote: > Randy Bush writes: > > > The point I'm trying to make (and tried to make in SF) was that > > > it seems to me that a rather small part of the variation in how > > > long a document takes to clear the IESG is the quality of the > > > document (whatever that means). > > > > and what substantiates that perception? [...] > > As I noted at the time, the variance of time-to-approve is quite > large, even for documents that are approved by the IETF as-is. That's > not completely inconsistent with document quality, but if the > documents that are taking a long time to clear (>100 days) are really > that low quality, it's somewhat surprising that they aren't sent back > for revision. It might be interesting to note a few more fine-grained metrics for determining the document quality, e.g.: - the number of DISCUSS votes raised in the IESG * and how soon after raising the DISCUSSes a new document is published which addresses those issues (ie. the time it's not an IESG issue) - documents which were approved as-is, but an RFC editor note was added by the IESG (causing some delay) FWIW, I have personal experience for authoring or commenting a few documents which have been through the IESG, a few notes: - one document has been pending a revised version from the author for over 6 months (the author knows the ball is at his feet) - one document for which comments were given took about a month for even the authors to reply - one document has been pending Expert Review by WG for about a year So, my perception is that the most time-consuming thing after submission to the IESG appears to be resolving issues raised by IESG; I hope nobody sees this delay as a problem of IESG :-). To conclude, I guess adding *real-time* transparency ("where does this document stand? where is the ball for the document ie. who's in charge at the moment? "do I have any documents I should take action on?") is crucial (I-D tracker helps but may not be enough). -- 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 Mon Jun 9 08:23:20 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00062 for ; Mon, 9 Jun 2003 08:23:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5DCC7625C6; Mon, 9 Jun 2003 14:22:49 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0E9A46257F for ; Mon, 9 Jun 2003 14:22:42 +0200 (CEST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h59CMdwc007519 for ; Mon, 9 Jun 2003 05:22:39 -0700 (PDT) Received: from cisco.com (sjc-vpn1-385.cisco.com [10.21.97.129]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AGZ32130; Mon, 9 Jun 2003 05:18:39 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Mon, 9 Jun 2003 08:22:37 -0400 Date: Mon, 9 Jun 2003 08:22:37 -0400 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030609122237.GF2424@sbrim-w2k01> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Sun, Jun 08, 2003 06:36:17PM -0700, Eric Rescorla allegedly wrote: > Consider the following thought experiment: take all the documents that > come before the IESG in a year. Rank them in terms of quality. Then > plot quality against "time to approve". Ask what the correlation is. > If there's not a high correlation, why would you expect people to > produce high quality work? Perhaps, but only if you consider the starting point. Documents which take the longest in getting through the IESG can have poor quality to start with, and still aren't great when they get out but at least they're tolerable. What you could look for in your experiment is the change in quality between when the document is sent to the IESG and when it emerges, versus time. From problem-statement-bounces@alvestrand.no Mon Jun 9 08:41:24 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01744 for ; Mon, 9 Jun 2003 08:41:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E4FD7625AA; Mon, 9 Jun 2003 14:40:46 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id 319E96257F for ; Mon, 9 Jun 2003 14:40:39 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.14]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA08603; Mon, 9 Jun 2003 05:40:07 -0700 (PDT) Message-Id: <5.1.0.14.2.20030609082137.04808e78@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 09 Jun 2003 08:29:20 -0400 To: Randy Bush From: Margaret Wasserman In-Reply-To: References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> <5022291864.20030608175225@brandenburg.com> <131883516.20030608203216@brandenburg.com> <1237455788.20030608220509@brandenburg.com> <4638533538.20030608222306@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Cc: Dave Crocker Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Randy, At 10:32 PM 6/8/2003 -0700, Randy Bush wrote: >if we come to agreement that producing quality and scaling are two >core problems, then i think there is some organizational and >management experience from within the computer industry and outside >from which we can draw some ideas on quality management etc. but i >don't think we've reached consensus that these are the issues yet. The problem statement lists both of these concerns, although it labels them differently: - Lack of effective engineering practices (the text of which is all about WGs producing timely, high quality, predictable output). - Management structure not matched to size and complexity of the IETF. Many people have helped us to refine and reword those sections, but I don't remember anyone indicating a lack of belief that these two problems exist... Why don't you think we've reached consensus? It seems quite clear to me that we have consensus that both of these problems exist and need to be fixed. And, I agree that it might be valid to draw on experience from the computer industry, academia, other standards bodies, etc. for ideas on how to fix these problems. Are you waiting for a particular event -- such as the WG chairs declaring consensus? Or document publication? Margaret From problem-statement-bounces@alvestrand.no Mon Jun 9 09:12:37 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03291 for ; Mon, 9 Jun 2003 09:12:37 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AA33A6259B; Mon, 9 Jun 2003 15:12:06 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 958A66259B; Mon, 9 Jun 2003 15:11:58 +0200 (CEST) Date: Mon, 09 Jun 2003 15:11:58 +0200 From: Harald Tveit Alvestrand To: Pekka Savola Message-ID: <170870000.1055164318@askvoll.hjemme.alvestrand.no> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) 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: time-to-approve etc. [Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?)] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 mandag, juni 09, 2003 15:06:50 +0300 Pekka Savola wrote: >> As I noted at the time, the variance of time-to-approve is quite >> large, even for documents that are approved by the IETF as-is. That's >> not completely inconsistent with document quality, but if the >> documents that are taking a long time to clear (>100 days) are really >> that low quality, it's somewhat surprising that they aren't sent back >> for revision. > > It might be interesting to note a few more fine-grained metrics for > determining the document quality, e.g.: > > - the number of DISCUSS votes raised in the IESG this could possibly serve as a metric of the number of *different* concerns raised by the IESG, but because of the IESG's common practice of saying "no further objections" when everyone agrees that the important problems they've seen have already have been flagged, it's not a measure of the percieved depth of the problems found. > * and how soon after raising the DISCUSSes a new document is published > which addresses those issues (ie. the time it's not an IESG issue) this metric could be very interesting, if we can measure it. > - documents which were approved as-is, but an RFC editor note was added > by the IESG (causing some delay) I don't think this adds delay, except for the cases where: - the IESG takes time to write up the RFC Editor note - the author or WG objects to the content of the note The first happens a few times, but is usually (in my recent experience) on the order of a week. Have people seen the second happen much? From problem-statement-bounces@alvestrand.no Mon Jun 9 09:44:37 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04583 for ; Mon, 9 Jun 2003 09:44:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8679F6257F; Mon, 9 Jun 2003 15:44:06 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.wrs.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id 49C02622AC for ; Mon, 9 Jun 2003 15:44:03 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.14]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA04307 for ; Mon, 9 Jun 2003 06:43:38 -0700 (PDT) Message-Id: <5.1.0.14.2.20030609093834.04842640@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 09 Jun 2003 09:39:45 -0400 To: problem-statement@alvestrand.no From: Margaret Wasserman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Fwd: Re: time-to-approve etc. [Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?)] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 didn't make it to the list the first time because Pekka's original included multiple cc: lines, which my mail reader seems to ignore. Margaret >Date: Mon, 09 Jun 2003 08:39:48 -0400 >To: Pekka Savola >From: Margaret Wasserman >Subject: Re: time-to-approve etc. [Re: Trusting the IESG to manage the >reform process (was:Re:Doingthe Right Things?)] > > >Hi Pekka, > >At 03:06 PM 6/9/2003 +0300, you wrote: >>So, my perception is that the most time-consuming thing after submission >>to the IESG appears to be resolving issues raised by IESG; I hope nobody >>sees this delay as a problem of IESG :-). > >In most cases, I agree that this isn't an IESG problem... > >However, it is true that cryptic or poorly understood issues can >take a long time to resolve. So, if it takes a significant amount >of time for the WG or authors to understand the IESG's issues, >that may be the fault of the IESG. > >I also believe that the feedback from the IESG could be offered >more openly (perhaps by mailing it to the pertinent WG?) which >would allow the WG to put pressure on the chairs and authors to >correct the problems. Right now, it can appear to a WG that a >document has "disappeared" in the IESG, when actually it is >waiting for updates from the authors. > >Margaret From problem-statement-bounces@alvestrand.no Mon Jun 9 10:09:24 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05711 for ; Mon, 9 Jun 2003 10:09:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A8D5E6257F; Mon, 9 Jun 2003 16:08:53 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from netcore.fi (netcore.fi [193.94.160.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5ACB1622AC for ; Mon, 9 Jun 2003 16:08:51 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h59E8oE12247 for ; Mon, 9 Jun 2003 17:08:50 +0300 Date: Mon, 9 Jun 2003 17:08:50 +0300 (EEST) From: Pekka Savola To: problem-statement@alvestrand.no Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Subject: Re: time-to-approve etc. [Re: Trusting the IESG to manage thereform process (was:Re:Doingthe Right Things?)] (fwd) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8BIT Hi, This was my off-list response [slightly edited afterwards] to Margaret's comment. It made me think of a few more other things, which may be something people might want to comment on. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ---------- Forwarded message ---------- Date: Mon, 9 Jun 2003 16:34:53 +0300 (EEST) From: Pekka Savola To: Margaret Wasserman Subject: Re: time-to-approve etc. [Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?)] On Mon, 9 Jun 2003, Margaret Wasserman wrote: > At 03:06 PM 6/9/2003 +0300, you wrote: > >So, my perception is that the most time-consuming thing after submission > >to the IESG appears to be resolving issues raised by IESG; I hope nobody > >sees this delay as a problem of IESG :-). > > In most cases, I agree that this isn't an IESG problem... > > However, it is true that cryptic or poorly understood issues can > take a long time to resolve. So, if it takes a significant amount > of time for the WG or authors to understand the IESG's issues, > that may be the fault of the IESG. Yes, this is also true, to some extent. Depending on the responsiveness of the person communicating with the editors, the feedback cycle could be much longer than if the comments were worded so carefully that the problems are understood by the editors (or at least somebody :-). This is often a very difficult thing to do: not because comments are worded improperly, too short to understand etc., but because the issue can be looked at from different angles (e.g. an implementer might not understand operational person speaking, or a prototype designer someone worrying about security considerations, etc.). I've noted that it may cause three different kinds of responses: 1) "We don't think this is a problem" 2) "We don't think this is a major concern [or they may not understand it correctly], but we'll add some text to clarify" 3) "I see the point, thanks for catching it, we'll rework the document" The most dangerous option is 2): there is a disconnect in communication/understanding, but the editorial team is willing to make some "surface" changes to satisfy a "whim" of IESG. In this case, it takes a lot of energy from the communicating person to see whether the issue was addressed *properly* or just on the surface -- and be pain in the ass if not properly. In case 1) you really have to do some more explaining anyway, and 3) is optimal as the people seem to get the point raised and rework the document appropriately. > I also believe that the feedback from the IESG could be offered > more openly (perhaps by mailing it to the pertinent WG?) which > would allow the WG to put pressure on the chairs and authors to > correct the problems. Right now, it can appear to a WG that a > document has "disappeared" in the IESG, when actually it is > waiting for updates from the authors. I agree: I can personally testify that the working groups want to know :-). It isn't useful to keep WG chairs uselessly as middlemen here (happens way too much already IMHO). Two issues come to mind: 1) the person reporting the issues is often not subscribed to the mailing list. Many lists forbid outside postings, or make them wait in a queue (with no assurance when it'll be processed). It may be more practical to be in touch with persons-in-charge. 2) it may be more "politically correct" to approach chairs/editors first, e.g. if the comments were highly negative, OR if the commenting person wants to clarify some issues (ie. to gauge whether they are issues or not); also, the bar to participation which does not include public exchange of raw thoughts may be lower for some than for others. .. but having a trigger which notifies about the state change in a tracking tool email the WG mailing list directly (but without possibly the comments itself) might help in getting folks feel a bit more confortable about the document status.. -- 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 Mon Jun 9 10:14:20 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06207 for ; Mon, 9 Jun 2003 10:14:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1C8626258D; Mon, 9 Jun 2003 16:13:49 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from netcore.fi (netcore.fi [193.94.160.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5D91D622AC; Mon, 9 Jun 2003 16:13:43 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h59EDgY12294; Mon, 9 Jun 2003 17:13:42 +0300 Date: Mon, 9 Jun 2003 17:13:42 +0300 (EEST) From: Pekka Savola To: Harald Tveit Alvestrand In-Reply-To: <170870000.1055164318@askvoll.hjemme.alvestrand.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: problem-statement@alvestrand.no Subject: Re: time-to-approve etc. [Re: Trusting the IESG to manage thereform process (was:Re:Doingthe Right Things?)] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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, 9 Jun 2003, Harald Tveit Alvestrand wrote: > --On mandag, juni 09, 2003 15:06:50 +0300 Pekka Savola > wrote: > > >> As I noted at the time, the variance of time-to-approve is quite > >> large, even for documents that are approved by the IETF as-is. That's > >> not completely inconsistent with document quality, but if the > >> documents that are taking a long time to clear (>100 days) are really > >> that low quality, it's somewhat surprising that they aren't sent back > >> for revision. > > > > It might be interesting to note a few more fine-grained metrics for > > determining the document quality, e.g.: > > > > - the number of DISCUSS votes raised in the IESG > > this could possibly serve as a metric of the number of *different* concerns > raised by the IESG, but because of the IESG's common practice of saying "no > further objections" when everyone agrees that the important problems > they've seen have already have been flagged, it's not a measure of the > percieved depth of the problems found. I agree; it's more important to measure if there is a discuss vote or not (if not, I guess the doc approval should be a very quick process :-), but at least in my perception, several very problematic documents have had at least 4-6 DISCUSS'es from different people.. so I guess it could yield *some* information, but with some standard disclaimers.. I think you could say that the more DISCUSSes a document has, the more potential it has to be a document requiring much more work. However, this does not say anything about documents with one or few DISCUSSes: those may or may not be higher quality documents (depends on what kinds of comments will surface from different IESG members etc.). > > - documents which were approved as-is, but an RFC editor note was added > > by the IESG (causing some delay) > > I don't think this adds delay, except for the cases where: > - the IESG takes time to write up the RFC Editor note > - the author or WG objects to the content of the note > The first happens a few times, but is usually (in my recent experience) on > the order of a week. Have people seen the second happen much? I was thinking of the first. But the issue is that I don't know how long it takes to write these. It's typically given as an action point, so I think at least two weeks is a norm. Tracking this could be useful. -- 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 Mon Jun 9 10:30:51 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06776 for ; Mon, 9 Jun 2003 10:30:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F0D546258D; Mon, 9 Jun 2003 16:30:20 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by eikenes.alvestrand.no (Postfix) with ESMTP id A2FA46257F for ; Mon, 9 Jun 2003 16:30:17 +0200 (CEST) Received: by romeo.rtfm.com (Postfix, from userid 556) id 62D48ABAF; Mon, 9 Jun 2003 07:36:29 -0700 (PDT) To: Scott W Brim References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> <20030609122237.GF2424@sbrim-w2k01> From: Eric Rescorla Date: 09 Jun 2003 07:36:29 -0700 In-Reply-To: <20030609122237.GF2424@sbrim-w2k01> Message-ID: Lines: 30 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: problem-statement@alvestrand.no Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: EKR 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 Scott W Brim writes: > On Sun, Jun 08, 2003 06:36:17PM -0700, Eric Rescorla allegedly wrote: > > Consider the following thought experiment: take all the documents that > > come before the IESG in a year. Rank them in terms of quality. Then > > plot quality against "time to approve". Ask what the correlation is. > > If there's not a high correlation, why would you expect people to > > produce high quality work? > > Perhaps, but only if you consider the starting point. That's what I meant. > Documents which > take the longest in getting through the IESG can have poor quality to > start with, and still aren't great when they get out but at least > they're tolerable. What you could look for in your experiment is the > change in quality between when the document is sent to the IESG and when > it emerges, versus time. That depends on what you're trying to measure. For the purposes of this discussion I'm not trying to measure IESG value-add but rather the extent to which having a good document makes it clear faster (since that's the incentive for the WG to do a better doc). For that question, the starting document quality is what you want. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From problem-statement-bounces@alvestrand.no Mon Jun 9 11:49:32 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09544 for ; Mon, 9 Jun 2003 11:49:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7C0526257F; Mon, 9 Jun 2003 17:49:02 +0200 (CEST) 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 C2DB2621B8 for ; Mon, 9 Jun 2003 17:48:54 +0200 (CEST) Message-ID: <01af01c32e9e$6c415fc0$a66015ac@DCLKEMPFTP> From: "James Kempf" To: "Randy Bush" , "Bound, Jim" References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> Date: Mon, 9 Jun 2003 08:47:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman Cc: problem-statement@alvestrand.no Cc: Brian E Carpenter Subject: Re: Trusting the IESG to manage the reform process (was:Re:DoingtheRight Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Randy, > that is not the problem i see day to day. what i see is chairs not > wanting to take a stand against weak documents, ersatz populism > being easier, and preferring to let it through to ietf last call > and iesg, letting the iesg take the heat. > Putting on my WG chair hat, it is not so simple. WG chairs are essentially middle management, and they have all the problems associated with responsibility without authority that middle management has. In my experience, a WG chair that tries to make a technical argument about a document is viewed as being "just another WG member". WG members with different opinions feel they can endlessly quibble with the chair, go to the AD and complain that the chair is being "uncooperative and blocking WG concensus", etc., if the chair says that they won't release the document to the IESG. If the WG member couches their opposition in terms of what the AD says or the IESG may say, the resistence evaporates, because the IESG has the ultimate authority to block the document. WG chairs only authority is to hire and fire WG document editors, call concensus, and prune the mailing list of people who are really disruptive (at the cost of a long email exchange beforehand to warn the person). They of course control the agenda at meetings, but they need to be careful to be evenhanded here, or risk being accused of bias. If you think that WG chairs should have the authority to block documents, then it needs to be explicitly written into RFC 2418bis. jak From problem-statement-bounces@alvestrand.no Mon Jun 9 11:58:08 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09753 for ; Mon, 9 Jun 2003 11:58:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 853176258D; Mon, 9 Jun 2003 17:57:38 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id C5E816257F for ; Mon, 9 Jun 2003 17:57:35 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19PP1T-000Kt9-Qy; Mon, 09 Jun 2003 08:57:27 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 9 Jun 2003 08:57:27 -0700 To: Pekka Savola References: Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: time-to-approve etc. [Re: Trusting the IESG to manage thereform process (was:Re:Doingthe Right Things?)] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > documents which were approved as-is, but an RFC editor note was > added by the IESG (causing some delay) i am not sure and rfced note causes delay. > adding *real-time* transparency ("where does this document stand? > where is the ball for the document ie., who's in charge at the > moment? "do I have any documents I should take action on?") is > crucial (I-D tracker helps but may not be enough). hmmm. when we started the data-tracker project 2+ years ago, it was meant as automation of the iesg admin process. so it is starting to do a pretty good job of telling me what's on my various plates. but i can guess it does not meet others' needs as well as it might. this is probably not the appropriate list, but some feedback into the d-t project so it better meets the needs of the wgs, authors, etc. would be cool. randy From problem-statement-bounces@alvestrand.no Mon Jun 9 12:04:20 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09879 for ; Mon, 9 Jun 2003 12:04:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 446ED625C5; Mon, 9 Jun 2003 18:03:50 +0200 (CEST) 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 261BF625C8 for ; Mon, 9 Jun 2003 18:03:22 +0200 (CEST) Message-ID: <01e301c32ea0$719f5ba0$a66015ac@DCLKEMPFTP> From: "James Kempf" To: "Dave Crocker" , References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> <5022291864.20030608175225@brandenburg.com> <131883516.20030608203216@brandenburg.com> Date: Mon, 9 Jun 2003 09:01:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: Trusting the IESG to manage the reform process (was:Re:DoingtheRight Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Dave, > We need a framework for quality that is embraced by the *general* IETF > community, so it can be enforced by the IESG, to help individual > *portions* of the IETF community (ie, individual working groups) > produce work consistent with that framework. > I also think we need to explicitly call out and distinguish between: a) engineering decisions that influence quality and lack thereof, b) engineering decisions that don't really impact quality but do determine what ultimately goes into the spec. In my experience, many disagreements between the WG chairs and WGs, and IESG and WGs occur because one side views the decision as in a) and the other in b). In the end, the decisions made in b) don't really make much difference to the technical quality of the standard, but are important for other reasons: compatibility with existing base, relations with outside standards organizations, etc. Or, they may be completely unrelated to any reason except that someone in the WG thought of it and fights any attempt to take their idea out of the spec. jak From problem-statement-bounces@alvestrand.no Mon Jun 9 12:14:02 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10203 for ; Mon, 9 Jun 2003 12:14:01 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7D711625C8; Mon, 9 Jun 2003 18:13:33 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id A10706258D for ; Mon, 9 Jun 2003 18:13:31 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h59GCxk09266; Mon, 9 Jun 2003 12:13:01 -0400 (EDT) Date: Mon, 9 Jun 2003 12:12:59 -0400 From: Keith Moore To: "Bound, Jim" Message-Id: <20030609121259.26003606.moore@cs.utk.edu> In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B042848CE@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B042848CE@tayexc13.americas.cpqcorp.net> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: hinden@IPRG.nokia.com Cc: jari.arkko@piuha.net Cc: moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: Re: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > You miss the point I think? And this is exactly how most products > ship it is impossible to find all bugs in any first software release. > What you try to find are the show stoppers based on what that means > for that product function. > > So I suggest your disagreeing with reality? Not at all. Protocols aren't quite like products in several ways. If a vendor makes a buggy product, it screws those that buy that product, but not everyone else who uses the same protocol. (unless the vendor has a monopoly, in which case I'd argue that the vendor has a higher responsibility.) Also, protocol bugs are often harder to fix than product bugs(depending on the product). Also, protocols aren't specified to the same level of detail that the code to implement those protocols are, so it's reasonable to expect fewer bugs in protocol specs. Again, I think the attempt to characterize the desire to have higher quality in our protocol specs before we call them any kind of standard (and before we consider them ready for deployment) as wanting those protocols to be "bug free" or "perfect" is misleading. Clearly it is neither possible nor realistic to expect bug free protocols. But that does not excuse our publishing a protocol standard with known bugs, nor does it excuse our failures to do due diligence to avoid major problems in our protocol designs. From problem-statement-bounces@alvestrand.no Mon Jun 9 12:35:48 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11063 for ; Mon, 9 Jun 2003 12:35:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6AD9D625C5; Mon, 9 Jun 2003 18:35:19 +0200 (CEST) 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 B05B26257F for ; Mon, 9 Jun 2003 18:35:16 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h59GcFF17034; Mon, 9 Jun 2003 09:38:15 -0700 Date: Mon, 9 Jun 2003 09:29:38 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <12278522399.20030609092938@brandenburg.com> To: "James Kempf" In-Reply-To: <01e301c32ea0$719f5ba0$a66015ac@DCLKEMPFTP> References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> <5022291864.20030608175225@brandenburg.com> <131883516.20030608203216@brandenburg.com> <01e301c32ea0$719f5ba0$a66015ac@DCLKEMPFTP> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Trusting the IESG to manage the reform process (was:Re:DoingtheRight Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 James, JK> I also think we need to explicitly call out and distinguish between: ... JK> In my experience, many disagreements between the WG chairs and WGs, JK> and IESG and WGs occur because one side views the decision as in a) JK> and the other in b). Yes, to both the distinction you raise and the conflict you cite. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Mon Jun 9 14:21:12 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15269 for ; Mon, 9 Jun 2003 14:21:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F2F38625D5; Mon, 9 Jun 2003 20:20:40 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 72D18625D3 for ; Mon, 9 Jun 2003 20:20:38 +0200 (CEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA15135 for ; Mon, 9 Jun 2003 11:20:36 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h59IKav20637 for ; Mon, 9 Jun 2003 11:20:36 -0700 X-mProtect: <200306091820> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdgKmnU0; Mon, 09 Jun 2003 11:20:33 PDT Message-ID: <3EE4D004.4010103@iprg.nokia.com> Date: Mon, 09 Jun 2003 11:20:52 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: problem-statement@alvestrand.no References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hello folks, I'm going to try to describe what I see as a major problem, but the solution is not a black-and-white cure-all rule. It's more a matter of perspective, balance, and judgement. Put simply, protocol specifications are being required to contain too many features. In my favorite example, a very simple signaling protocol specification was eventually required to also incorporate other related specifications: - A discovery algorithm - A key distribution algorithm - Renumbering algorithms - Compatibility recipes for an incompatible security protocol - other stuff too. The requirement for the key distribution algorithm delayed the specification for almost three years. In addition to the obvious problem, there is a more subtle effect that causes more and more delay. That is, that as more stuff gets into the specification, people become less confident about what is there, and more likely to strip out actually useful features in a misguided attempt to make the document smaller and more timely. All along, the problem is that we are not being allowed to make small specifications because we have to do all the stuff that other protocol specifications had to do before the IESG would approve them. Stuff, by the way, that is often undocumented, so that we have to rely on word of mouth and anecdotal information. Another way to say this, is that we are being required to specify entire systems instead of protocol components. I think this is a very bad idea. I think the IESG should sincerely reconsider this policy, and let protocol specifications be published EVEN IF they do not solve the entire problem domain, but just a part of it. Typically, the part that the original protocol specification DOES solve, will be implemented and tested for interoperability. The other stuff that gets glued on will just sit there like a dark jungle. Related to John's note below, it is interesting to observe that the problem I have described causes _all three_ of the problems that John described as "root problems". Regards, Charlie P. john.loughney@nokia.com wrote: >Hi all, > >Cutting out the parts of the discussion not relevant to my view: > > > >>if we come to agreement that producing quality and scaling are two >>core problems, then i think there is some organizational and >>management experience from within the computer industry and outside >>from which we can draw some ideas on quality management etc. but i >>don't think we've reached consensus that these are the issues yet. >> >> > >If it matters, I believe two major core problems are > > 1) producing quality documents > 2) solving current scaling problems > >and to add a third: > > 3) producing timely documents (this has relations to 1 & 2). > >Anyhow, perhaps a reasonable way forward would be to see if we >can gain consensus on at least 2 or 3 (not limited to the one's >I've listed) core problems & start to move forward on them; >while still examining other problems. > >John > > From problem-statement-bounces@alvestrand.no Mon Jun 9 14:34:04 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15930 for ; Mon, 9 Jun 2003 14:34:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D6E54625D3; Mon, 9 Jun 2003 20:33:33 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by eikenes.alvestrand.no (Postfix) with ESMTP id 25DF461D30 for ; Mon, 9 Jun 2003 20:33:27 +0200 (CEST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id E8DA7DD61 for ; Mon, 9 Jun 2003 14:33:25 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 9 Jun 2003 14:33:24 -0400 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="us-ascii" Date: Mon, 9 Jun 2003 14:33:23 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0428493F@tayexc13.americas.cpqcorp.net> Thread-Topic: ISSUE: Determinants for timeliness missing in section 2.1 Thread-Index: AcMt3ble02aRcN8kQIuRVl7EXnUFZAA16aew From: "Bound, Jim" To: X-OriginalArrivalTime: 09 Jun 2003 18:33:24.0992 (UTC) FILETIME=[9CBA5000:01C32EB5] Subject: RE: ISSUE: Determinants for timeliness missing in section 2.1 X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA15930 yep. But I will not comment on this one it is too close to and I can't help but be highly biased on my version of what happen. We have a good spec now and I will leave it at that. but it was far to painful. /jim > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Sunday, June 08, 2003 12:48 PM > To: Harald Tveit Alvestrand > Cc: Dave Crocker; problem-statement@alvestrand.no > Subject: Re: ISSUE: Determinants for timeliness missing in section 2.1 > > > Harald, > > I understand the point you are trying to make ... but I'm not > sure DHCPv6 is such a good example. Unless there's more to > the acceptance of DHCPv6 by the IESG than I know about, I > think this history of DHCPv6 is something of an > oversimplification and omits many other pressures - both > positivie and negative - on the forward progresss of DHCPv6. > > - Ralph > > On Sun, 8 Jun 2003, Harald Tveit Alvestrand wrote: > > > In the case of DHCPv6 - we got an external customer (3GPP), with a > > documented need and a fixed deadline - and the document got > out. The > > customer provided the necessary timeframe - "if you want to > get this > > done in this particular context in a standard way, give us the > > standard by this date". > > > > Beneficial results for all. > > > > > > > > From problem-statement-bounces@alvestrand.no Mon Jun 9 14:34:50 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15965 for ; Mon, 9 Jun 2003 14:34:49 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2CE3C625D5; Mon, 9 Jun 2003 20:34:20 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from linux.research.att.com (H-135-207-24-16.research.att.com [135.207.24.16]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9771461D30 for ; Mon, 9 Jun 2003 20:34:16 +0200 (CEST) Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71])h59IdHEI015209; Mon, 9 Jun 2003 14:39:17 -0400 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46])h59IWiXs027906; Mon, 9 Jun 2003 14:32:44 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h59IYEd22748; Mon, 9 Jun 2003 11:34:14 -0700 (PDT) Message-Id: <200306091834.h59IYEd22748@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: randy@psg.com References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> <5022291864.20030608175225@brandenburg.com> Date: Mon, 9 Jun 2003 11:34:14 -0700 Versions: dmail (solaris) 2.5a/makemail 2.9d Cc: problem-statement@alvestrand.no Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 >maybe we should look at the time to process through iesg and the >reasons we can find. i do not claim to know any answer, but of >course have silly perceptions based on my narrow little view of the >movie. so it would be really good to have some actual data. would >be nice if bill, harald, or someone with time could find a way to >get something real on which we could base a discussion. I just wrote a quick hack to analyze the data I have, and put the results at http://rtg.ietf.org/~fenner/iesg/docstates.txt . There are two types of entries in this file - one for the first time we see a document in my snapshots, e.g. 20020506 draft-ietf-ipngwg-rfc2292bis entered system in Requested and then once for each time it changes state: 20030312 draft-ietf-ipngwg-rfc2292bis IESG Evaluation -> Approved-announcement to be sent after 11 days There is some noise in the data, like the tildes swapping with dashes in this example: 20030426 draft-ietf-ipngwg-icmp-name-lookups IESG Evaluation ~~ Revised ID Needed -> IESG Evaluation -- Revised ID Needed after 170 days 20030525 draft-ietf-ipngwg-icmp-name-lookups IESG Evaluation -- Revised ID Needed -> IESG Evaluation ~~ Revised ID Needed after 29 days but I'll wait for some evidence that cleaning up the data is desired or useful before putting more work into it. (plenty of data, not clear if there's any information...) Bill From problem-statement-bounces@alvestrand.no Mon Jun 9 14:37:18 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16037 for ; Mon, 9 Jun 2003 14:37:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 821CD625D5; Mon, 9 Jun 2003 20:36:45 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail05.zma.compaq.com (mailout.zma.compaq.com [161.114.64.105]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7B801625D3 for ; Mon, 9 Jun 2003 20:36:42 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 72819DE0E; Mon, 9 Jun 2003 14:36:41 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 9 Jun 2003 14:36:41 -0400 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="us-ascii" Date: Mon, 9 Jun 2003 14:36:40 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04284940@tayexc13.americas.cpqcorp.net> Thread-Topic: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) Thread-Index: AcMuG796/Ws0HFF7RCeLJmB1GcSNbwAmibcQ From: "Bound, Jim" To: "Randy Bush" , "Eric Rescorla" X-OriginalArrivalTime: 09 Jun 2003 18:36:41.0164 (UTC) FILETIME=[11A7C8C0:01C32EB6] Cc: Margaret Wasserman Cc: problem-statement@alvestrand.no Cc: Brian E Carpenter Subject: RE: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA16037 ok lets not use "blocking" lets use excessive review by a bar that is to high for the level that the document is trying to achieve. /jim > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Sunday, June 08, 2003 8:12 PM > To: Eric Rescorla > Cc: Bound, Jim; Margaret Wasserman; > problem-statement@alvestrand.no; Brian E Carpenter > Subject: Re: Trusting the IESG to manage the reform process > (was:Re:Doingthe Right Things?) > > > >> rofl! all the authority and fifteen cents will get you on > the subway > >> [0]. > > I'm not sure what you're saying here. The ADs have immense > > authority--the authority to block documents. > > nice hyperbole, but the fact is no one blocks documents, we > point out what we think are problems and ask to discuss them > to either find out we have misunderstood or, should the > problem be real, actually get the problem addressed. this is > the same 'authority' the author, editor, wg chair, or > reviewer has. big whoopie doo. > > the question is what can be done to improve the quality of documents. > > > Since companies and WGs spend lots of time and money trying to get > > documents passed, the ability to block > > artificial polarization. as i said above, documents can be > called for discussion by 92.3% of the population. the > problem is that some authors, editors, wg chairs, ... seem to > prefer the lazy but beauty contest winning path of saying yes > to anything and then hoping the iesg will take the heat for > asking the hard questions. > > randy > > From problem-statement-bounces@alvestrand.no Mon Jun 9 14:41:38 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16155 for ; Mon, 9 Jun 2003 14:41:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CB20F625D5; Mon, 9 Jun 2003 20:41:03 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail03.zma.compaq.com (mailout.zma.compaq.com [161.114.64.103]) by eikenes.alvestrand.no (Postfix) with ESMTP id ABC63625D3 for ; Mon, 9 Jun 2003 20:41:00 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 89233826A; Mon, 9 Jun 2003 14:40:59 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 9 Jun 2003 14:40:59 -0400 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="us-ascii" Date: Mon, 9 Jun 2003 14:40:58 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04284941@tayexc13.americas.cpqcorp.net> Thread-Topic: Trusting the IESG to manage the reform process (was:Re:DoingtheRight Things?) Thread-Index: AcMuH+EBaYilG7rVT76t5BBJkLaArgAlnS9g From: "Bound, Jim" To: "Randy Bush" , "Eric Rescorla" X-OriginalArrivalTime: 09 Jun 2003 18:40:59.0381 (UTC) FILETIME=[AB909250:01C32EB6] Cc: problem-statement@alvestrand.no Subject: RE: Trusting the IESG to manage the reform process (was:Re:DoingtheRight Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA16155 I agree with Randy on its the grass below. One fix would be to list all names of spec writers in drafts not just the editor or first alphabetical name. Also whats up with that new rule that went down that we can't list 10 authors. I thought that was entirely bogus and don't recall an open discussion on that at all it just was mandated and I thought that was completely wrong. maybe I missed the group that openly discussed that change? /jim > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Sunday, June 08, 2003 8:41 PM > To: Eric Rescorla > Cc: problem-statement@alvestrand.no > Subject: Re: Trusting the IESG to manage the reform process > (was:Re:DoingtheRight Things?) > > > > The IESG held TLS for nearly a year because they insisted > that their > > be a mandatory algorithm and that it be DH/3DES/SHA. No > other group > > of 13 people in the IETF could have done that, no matter how big a > > stink they raised. In point of fact, 2 or 3 ADs could have > done this. > > false. the authors could have. the editor(s) if they > existed could have. the wg chair(s) could have. respected > members of the security directorate could have. ... and my > guess, though i am not a security expert, is that they > probably SHOULD HAVE. > > > I ask again: what incentives do the WGs have to produce > documents that > > meet the IESG's definition of quality? > > as a multi-decade manager of O(20^(2-3)) engineers, i came to > the conclusion that 82.3% of whether an engineer produces > quality is whether they have pride in their work and their > team. the classic hiring manager's joke about engineers is > that we ask "what is the project and with whom will i be > working. .... oh yes, my spouse told me to ask about salary > and benefits." > > what keeps the cows in the pasture is the quality of the > grass not the height of the fence. a fair portion of our > culture is weak on giving credit where it is due, saying > "this was maude's idea, not mine," etc. when the culture was > smaller in number, it was easier for the work to be known by > the person(s) who produced it. this is good and bad, > depending on whether the work is good or not so good (i will > resist examples:-). if we spent more of our time praising > and encouraging the good work of our peers as opposed to > labeling them as idiots, black helicopter pilots, etc. > perhaps we all would take the necessary corrective > constructive criticism a bit better and the results would be better. > > randy > > From problem-statement-bounces@alvestrand.no Mon Jun 9 14:50:23 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16372 for ; Mon, 9 Jun 2003 14:50:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4486B625D5; Mon, 9 Jun 2003 20:49:53 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2626E625D3 for ; Mon, 9 Jun 2003 20:49:51 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 477B583B8; Mon, 9 Jun 2003 14:49:50 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 9 Jun 2003 14:49:50 -0400 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="us-ascii" Date: Mon, 9 Jun 2003 14:49:49 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0324132B@tayexc13.americas.cpqcorp.net> Thread-Topic: Trusting the IESG to manage the reform process (was:Re:DoingtheRight Things?) Thread-Index: AcMuIc9DgSAxn/O3St+6I0ttv+kDcAAlNSJA From: "Bound, Jim" To: "Dave Crocker" , "Eric Rescorla" X-OriginalArrivalTime: 09 Jun 2003 18:49:50.0159 (UTC) FILETIME=[E7EEDDF0:01C32EB7] Cc: problem-statement@alvestrand.no Subject: RE: Trusting the IESG to manage the reform process (was:Re:DoingtheRight Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA16372 Dave, On this one and few issues I don't agree. I agree with Eric we need incentives. And WGs must be free to experiment and reach for resolution within reason to solve problems and do engineering design. And I am sorry but I have an issue with some group or unseen force dictating anyting if they don't have the techncial expertise for that subject matter. I don't think that is what you stated but that could be the outcome. For example I have seen where an AD says to the WG I don't think this group has that "expertise". That is outright bullshit and bordering on elitism I simply hate. Thats why we get pissed at ADs too and in this case we all knew far more than the AD technically on the subject they were saying we did not have the expertise as base. They were WRONG. We did correct this behavior and statement in reasonable way I will add. But it took time. And that should not have happen. My point is I don't have much use or support any elitism in our community. I am not say general direction is not good in fact it is. My fear you know well with me from real life in the OSI days where architects in a particular company built an entire architecture for networking and when it got to engineering it simply was not implementable. What I fear are elistist architects who mandate technical policy who never wrote "hello world/" as extreme example. And worse yet never had a job where they were responsible for "shipping" products. I am not saying all should have this background I am saying some resemblance of these attributes should be part of the process. Not just elitist architecture pontification. As side comment I saw yours and Haralds IPv6 discussion about deployment with all due respect you don't know the half of it because your not living it from my view but only discussing it. People in WGs live it not discuss it. /jim > -----Original Message----- > From: Dave Crocker [mailto:dhc@dcrocker.net] > Sent: Sunday, June 08, 2003 8:52 PM > To: Eric Rescorla > Cc: problem-statement@alvestrand.no > Subject: Re: Trusting the IESG to manage the reform process > (was:Re:DoingtheRight Things?) > > > Eric, > > ER> I ask again: what incentives do the WGs have to produce documents > ER> that meet the IESG's definition of quality? > > I think you just highlighted a key problem: > > The IESG can and must provide a quality control mechanism. > But it is the community that must define the necessary quality. > > And, yes, "the community" is a pretty darn fuzzy construct, > which is why we end up with each AD (and each IAB member) > defining their own criteria and applying them independently. > > Still, we need to find reasonable, community based criteria > -- beyond just the criteria of the working group, so that it > represents a broader view -- with the IESG enforcing it, > rather than inventing it. > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > > From problem-statement-bounces@alvestrand.no Mon Jun 9 14:51:16 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16402 for ; Mon, 9 Jun 2003 14:51:15 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 579E3625D5; Mon, 9 Jun 2003 20:50:46 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail05.zma.compaq.com (mailout.zma.compaq.com [161.114.64.105]) by eikenes.alvestrand.no (Postfix) with ESMTP id CDCB3625D3 for ; Mon, 9 Jun 2003 20:50:44 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 19360BE02; Mon, 9 Jun 2003 14:50:44 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 9 Jun 2003 14:50:43 -0400 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="us-ascii" Date: Mon, 9 Jun 2003 14:50:43 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04284943@tayexc13.americas.cpqcorp.net> Thread-Topic: Trusting the IESG to manage the reform process (was:Re:DoingtheRight Things?) Thread-Index: AcMuIlGm6fbG4awsS5a4SU1ZRHiZRwAlZDmg From: "Bound, Jim" To: "Randy Bush" , "Dave Crocker" X-OriginalArrivalTime: 09 Jun 2003 18:50:43.0971 (UTC) FILETIME=[0801ED30:01C32EB8] Cc: problem-statement@alvestrand.no Cc: Eric Rescorla Subject: RE: Trusting the IESG to manage the reform process (was:Re:DoingtheRight Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA16402 I agree with Randy again. But how can me make them not wuss out. Or what tools or policy can we provide them. /jim > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Sunday, June 08, 2003 8:59 PM > To: Dave Crocker > Cc: problem-statement@alvestrand.no; Eric Rescorla > Subject: Re: Trusting the IESG to manage the reform process > (was:Re:DoingtheRight Things?) > > > > Still, we need to find reasonable, community based criteria > -- beyond > > just the criteria of the working group, so that it represents a > > broader view -- with the IESG enforcing it, rather than > inventing it. > > does not scale. this is still the mode where the authors, > wgs, chairs, ... wuss out. > > quality management 101: the philosophy of building quality > has to be pushed to the edges so it encompasses the whole > organization. > > randy > > From problem-statement-bounces@alvestrand.no Mon Jun 9 14:54:26 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16561 for ; Mon, 9 Jun 2003 14:54:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 56C6A625D5; Mon, 9 Jun 2003 20:53:55 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2ED60625D3 for ; Mon, 9 Jun 2003 20:53:53 +0200 (CEST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 1C7AFB9F3; Mon, 9 Jun 2003 14:53:52 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 9 Jun 2003 14:53:51 -0400 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="us-ascii" Date: Mon, 9 Jun 2003 14:53:51 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04284944@tayexc13.americas.cpqcorp.net> Thread-Topic: Trusting the IESG to manage the reform process (was:Re:DoingtheRight Things?) Thread-Index: AcMuRS46+Q4uCmJcTTeqf1GaOjjUBQAcyy3A From: "Bound, Jim" To: "EKR" , "Randy Bush" X-OriginalArrivalTime: 09 Jun 2003 18:53:51.0734 (UTC) FILETIME=[77EC4960:01C32EB8] Cc: Dave Crocker Cc: problem-statement@alvestrand.no Subject: RE: Trusting the IESG to manage the reform process (was:Re:DoingtheRight Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA16561 time to approve is a problem. can we agree on that? /jim > -----Original Message----- > From: Eric Rescorla [mailto:ekr@rtfm.com] > Sent: Monday, June 09, 2003 1:15 AM > To: Randy Bush > Cc: Dave Crocker; problem-statement@alvestrand.no > Subject: Re: Trusting the IESG to manage the reform process > (was:Re:DoingtheRight Things?) > > > Randy Bush writes: > > > > The point I'm trying to make (and tried to make in SF) > was that it > > > seems to me that a rather small part of the variation in > how long a > > > document takes to clear the IESG is the quality of the document > > > (whatever that means). > > > > and what substantiates that perception? > Well, there's people's personal experience, of course, but as > we all know, the plural of anecdote is not data. > > As I noted at the time, the variance of time-to-approve is > quite large, even for documents that are approved by the IETF > as-is. That's not completely inconsistent with document > quality, but if the documents that are taking a long time to > clear (>100 days) are really that low quality, it's somewhat > surprising that they aren't sent back for revision. > > Do I have any totally convincing evidence? No. It's just my > intuition, combined with the lack of strong evidence to the > contrary. However, to the extent to which people believe > that the quality effect is small then there's no incentive to > quality, regardless of whether it's in fact true. I of course > can't speak for what other people believe, though I imagine > that that would be relatively easy to discover without too > much complicated analyiss. > > Really, > -Ekr > > -- > [Eric Rescorla ekr@rtfm.com] > http://www.rtfm.com/ > From problem-statement-bounces@alvestrand.no Mon Jun 9 14:58:30 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16672 for ; Mon, 9 Jun 2003 14:58:29 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8DEB1625D5; Mon, 9 Jun 2003 20:57:59 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by eikenes.alvestrand.no (Postfix) with ESMTP id BFE51625D3 for ; Mon, 9 Jun 2003 20:57:55 +0200 (CEST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 13EF4814E; Mon, 9 Jun 2003 14:57:55 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 9 Jun 2003 14:57:54 -0400 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="us-ascii" Date: Mon, 9 Jun 2003 14:57:54 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04284945@tayexc13.americas.cpqcorp.net> Thread-Topic: Trusting the IESG to manage the reform process(was:Re:DoingtheRight Things?) Thread-Index: AcMuSJ0RETjPTg+VQxGBXwJPSf1SmAABP0OgABrOrBA= From: "Bound, Jim" To: , X-OriginalArrivalTime: 09 Jun 2003 18:57:54.0843 (UTC) FILETIME=[08D3C6B0:01C32EB9] Cc: problem-statement@alvestrand.no Subject: RE: Trusting the IESG to manage the reform process(was:Re:DoingtheRight Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA16672 I like the list but we do have quality documents and most of them are quality. I guess I want to step back. What is not a quality document? WHich RFC? I assume we are not talking about IDs? /jim > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Monday, June 09, 2003 2:12 AM > To: randy@psg.com > Cc: problem-statement@alvestrand.no > Subject: RE: Trusting the IESG to manage the reform > process(was:Re:DoingtheRight Things?) > > > Hi all, > > Cutting out the parts of the discussion not relevant to my view: > > > if we come to agreement that producing quality and scaling are two > > core problems, then i think there is some organizational and > > management experience from within the computer industry and outside > > from which we can draw some ideas on quality management etc. but i > > don't think we've reached consensus that these are the issues yet. > > If it matters, I believe two major core problems are > > 1) producing quality documents > 2) solving current scaling problems > > and to add a third: > > 3) producing timely documents (this has relations to 1 & 2). > > Anyhow, perhaps a reasonable way forward would be to see if > we can gain consensus on at least 2 or 3 (not limited to the one's > I've listed) core problems & start to move forward on them; > while still examining other problems. > > John > From problem-statement-bounces@alvestrand.no Mon Jun 9 15:02:55 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16842 for ; Mon, 9 Jun 2003 15:02:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 13DB7625D5; Mon, 9 Jun 2003 21:02:24 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail04.zma.compaq.com (mailout.zma.compaq.com [161.114.64.104]) by eikenes.alvestrand.no (Postfix) with ESMTP id BED9B625D3 for ; Mon, 9 Jun 2003 21:02:16 +0200 (CEST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 1AE92B870; Mon, 9 Jun 2003 15:02:16 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 9 Jun 2003 15:02:15 -0400 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="us-ascii" Date: Mon, 9 Jun 2003 15:02:15 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04284946@tayexc13.americas.cpqcorp.net> Thread-Topic: Trusting the IESG to manage the reform process (was: Re: Doing the Right Things?) Thread-Index: AcMubJLAYq/levZtQXiBh/MdkgAK4AATKihA From: "Bound, Jim" To: "John C Klensin" , X-OriginalArrivalTime: 09 Jun 2003 19:02:15.0921 (UTC) FILETIME=[A4711E10:01C32EB9] Subject: RE: Trusting the IESG to manage the reform process (was: Re: Doing the Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA16842 maybe we should make a list of what the ideal IESG member and the group should do and how they behave as IESG with IESG hats? this way it is not finger pointing. but saying there is no fix needed for the IESG is simply not dealing with reality IMO. There are problems and they are all not perceived. If all we are going to do is fix everything but the IESG I am going to leave this list because the goal of fixing the IETF will not get done. The IESG needs a fix. I don't know what it is but it needs fixing as other parts of our community. /jim > -----Original Message----- > From: John C Klensin [mailto:john@jck.com] > Sent: Monday, June 02, 2003 3:21 PM > To: problem-statement@alvestrand.no > Subject: Trusting the IESG to manage the reform process (was: > Re: Doing the Right Things?) > > > In writing the note about an accelerated process, I realized I'm > making an assumption that needs a bit of explanation. Several > of the issues here, and what processes might and might not work, > are ultimately about whether or not IESG is completely broken > and/or in some "us versus them" mode that implies we can't trust > them with much of anything, especially anything involving reform > or evolution. > > There are clearly people in the community who believe that the > current IESG has formed a closed circle, developed a "them > against us" mentality, and cannot be trusted. I don't know how > large that group is (although I suspect "not very" would be a > good guess). But, if they are right, we don't need incremental > procedural suggestions, we need really radical reform. Why? > Because at least two consecutive nomcoms, acting independently, > have selected (or reselected) the current IESG members. If they > have managed to select people who would engage in that sort of > conspiracy of untrustworthy behavior, and to do it so > successfully that, not only can the IESG behave in undesirable > ways, but that no one on the IESG has been willing to speak up > in public and say "I see a problem here, but it is all those > other folks, not me", then there is something hopelessly broken > about the nomcom model, probably to the point that we need to > discard it and start over. > > No one has suggested that yet, but, if people seriously believe > that the IESG can no longer be trusted to manage the standards > process, or a reform process, or both, I think it is time to > move past "list problems only" and get that on the table. > > Why can't we, instead, just make up some new rules and > procedures to "control" the IESG? Because our enforcement > mechanisms are almost non-existent if the IESG is unwilling. > The IESG has already demonstrated that, under their general > responsibility and authority to manage the process, they can and > will make up procedural rules that bend written procedures > pretty severely. If we trust them, that process may need to be > tuned and constrained (as I believe it does) to make our > expectations about the limits of what they can do without > consulting the community more clear. But, if the trust isn't > there, any effort to make more/different rules and procedures is > just to give them additional things that they can ignore. > > So, whether it be about a final decision on a new AD, or on > figuring out which process suggestions can just be accepted and > deployed without going through a long and complex process, or on > managing the process in other ways, I think we need to trust > them to make management-level decisions about how best to move > forward and hold them accountable for doing that acceptably > well. And, if we can't trust them, or at least their good > intentions and willingness to do what the community wants and > needs, that far, then we had best stop the process of examining > the leaves on the forest floor while the place goes up in flames > around us. > > john > > From problem-statement-bounces@alvestrand.no Mon Jun 9 15:05:27 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17174 for ; Mon, 9 Jun 2003 15:05:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B4636625D5; Mon, 9 Jun 2003 21:04:56 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4FD64625D3 for ; Mon, 9 Jun 2003 21:04:46 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 90907DDEE; Mon, 9 Jun 2003 15:04:45 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 9 Jun 2003 15:04:45 -0400 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="us-ascii" Date: Mon, 9 Jun 2003 15:04:44 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04284947@tayexc13.americas.cpqcorp.net> Thread-Topic: Trusting the IESG to manage the reform process (was:Re:DoingtheRight Things?) Thread-Index: AcMunqmITAoiW+PKSGaZw0HxUC5ncAAGzJfg From: "Bound, Jim" To: "James Kempf" , "Randy Bush" X-OriginalArrivalTime: 09 Jun 2003 19:04:45.0450 (UTC) FILETIME=[FD916EA0:01C32EB9] Cc: Margaret Wasserman Cc: problem-statement@alvestrand.no Cc: Brian E Carpenter Subject: RE: Trusting the IESG to manage the reform process (was:Re:DoingtheRight Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA17174 Well put. I would say its worst than middle management but "program" management and that is even less authority. /jim > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, June 09, 2003 11:47 AM > To: Randy Bush; Bound, Jim > Cc: Margaret Wasserman; problem-statement@alvestrand.no; > Brian E Carpenter > Subject: Re: Trusting the IESG to manage the reform process > (was:Re:DoingtheRight Things?) > > > Randy, > > > that is not the problem i see day to day. what i see is chairs not > > wanting to take a stand against weak documents, ersatz > populism being > > easier, and preferring to let it through to ietf last call > and iesg, > > letting the iesg take the heat. > > > > Putting on my WG chair hat, it is not so simple. WG chairs > are essentially middle management, and they have all the > problems associated with responsibility without authority > that middle management has. In my experience, a WG chair that > tries to make a technical argument about a document is viewed > as being "just another WG member". WG members with different > opinions feel they can endlessly quibble with the chair, go > to the AD and complain that the chair is being "uncooperative > and blocking WG concensus", etc., if the chair says that they > won't release the document to the IESG. If the WG member > couches their opposition in terms of what the AD says or the > IESG may say, the resistence evaporates, because the IESG has > the ultimate authority to block the document. WG chairs only > authority is to hire and fire WG document editors, call > concensus, and prune the mailing list of people who are > really disruptive (at the cost of a long email exchange > beforehand to warn the person). They of course control the > agenda at meetings, but they need to be careful to be > evenhanded here, or risk being accused of bias. > > If you think that WG chairs should have the authority to > block documents, then it needs to be explicitly written into > RFC 2418bis. > > jak > > From problem-statement-bounces@alvestrand.no Mon Jun 9 15:08:25 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17501 for ; Mon, 9 Jun 2003 15:08:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 942FE625D5; Mon, 9 Jun 2003 21:07:51 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail03.zma.compaq.com (mailout.zma.compaq.com [161.114.64.103]) by eikenes.alvestrand.no (Postfix) with ESMTP id 351E7625D3 for ; Mon, 9 Jun 2003 21:07:49 +0200 (CEST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 7DEF481CC; Mon, 9 Jun 2003 15:07:48 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 9 Jun 2003 15:07:48 -0400 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="us-ascii" Date: Mon, 9 Jun 2003 15:07:47 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04284948@tayexc13.americas.cpqcorp.net> Thread-Topic: pausable explanation for the Document Series Thread-Index: AcMuogpSQfDF65dSRnavBa7gSyMjFwAGAB5g From: "Bound, Jim" To: "Keith Moore" X-OriginalArrivalTime: 09 Jun 2003 19:07:48.0343 (UTC) FILETIME=[6A94B070:01C32EBA] Cc: hinden@IPRG.nokia.com Cc: jari.arkko@piuha.net Cc: problem-statement@alvestrand.no Subject: RE: pausable explanation for the Document Series X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA17501 I understand. But keeping bugs out is something I consider pretty easy to do if we follow a good engineering process and review. Where it gets tricky is the classic engineering trade-off of risk vs going forward and where we live with the warts. Another is if we have option 1, 2, and 3 and the WG is split on supporting all options. This gets back to my issue of we need to put the assumptions we have on the table better. /jim > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Monday, June 09, 2003 12:13 PM > To: Bound, Jim > Cc: moore@cs.utk.edu; jari.arkko@piuha.net; > hinden@IPRG.nokia.com; problem-statement@alvestrand.no > Subject: Re: pausable explanation for the Document Series > > > > You miss the point I think? And this is exactly how most products > > ship it is impossible to find all bugs in any first > software release. > > What you try to find are the show stoppers based on what that means > > for that product function. > > > > So I suggest your disagreeing with reality? > > Not at all. Protocols aren't quite like products in several > ways. If a vendor makes a buggy product, it screws those > that buy that product, but not everyone else who uses the > same protocol. (unless the vendor has a monopoly, in which > case I'd argue that the vendor has a higher > responsibility.) Also, protocol bugs are often harder to fix > than product bugs(depending on the product). Also, protocols > aren't specified to the same level of detail that the code to > implement those protocols are, so it's reasonable to expect > fewer bugs in protocol specs. > > Again, I think the attempt to characterize the desire to have > higher quality in our protocol specs before we call them any > kind of standard (and before we consider them ready for > deployment) as wanting those > protocols to be "bug free" or "perfect" is misleading. > Clearly it is neither possible nor realistic to expect bug > free protocols. But that does not excuse our publishing a > protocol standard with known bugs, nor does it excuse our > failures to do due diligence to avoid major problems in our > protocol designs. > From problem-statement-bounces@alvestrand.no Mon Jun 9 15:15:13 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18185 for ; Mon, 9 Jun 2003 15:15:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4C2AF625D5; Mon, 9 Jun 2003 21:14:42 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2E9EC625D3; Mon, 9 Jun 2003 21:14:32 +0200 (CEST) Date: Mon, 09 Jun 2003 21:14:32 +0200 From: Harald Tveit Alvestrand To: Charlie Perkins , problem-statement@alvestrand.no Message-ID: <8130000.1055186072@askvoll.hjemme.alvestrand.no> In-Reply-To: <3EE4D004.4010103@iprg.nokia.com> References: <3EE4D004.4010103@iprg.nokia.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Charlie, clipping mercilessly from your message.... --On mandag, juni 09, 2003 11:20:52 -0700 Charlie Perkins wrote: > Another way to say this, is that we are being required to specify > entire systems instead of protocol components. I think this is a > very bad idea. I think the IESG should sincerely reconsider this > policy, and let protocol specifications be published EVEN IF > they do not solve the entire problem domain, but just a part of it. > Typically, the part that the original protocol specification DOES > solve, will be implemented and tested for interoperability. The > other stuff that gets glued on will just sit there like a dark jungle. The way I thought of it in the apps area 5+ years back was that a proposal has to document that it is good for AT LEAST ONE THING. (I failed that at times - for instance with TIP, which I still don't know if anyone uses). We (the IETF) want to standardize useful protocols. If there isn't at least one scenario where the protocol is clearly useful, I see absolutely no reason to standardize it. So describing the scenario, including all the bits and pieces from other protocols that have to be there in order to make the protocol useful in that scenario, is, to my mind, a necessary part of documenting the protocol. On the other hand - if a scenario is described, and it's obvious that 5 mins after the protocol-implementing product hits the street, it will be used in another scenario, where the proposed "supporting bits" are clearly going to lead to undesirable situations (I'm thinking about SNMPv1 and the "community string" here, for instance), then we as a community have a responsibility to describe those scenarios too, and provide/reference the adequate mechanisms for those scenarios. For instance by saying that all IPv6 implementations MUST have IPSec support (the "Danvers Doctrine"), or saying that applications MUST behave in the face of congestion (RFC 2914). Harald From problem-statement-bounces@alvestrand.no Mon Jun 9 15:15:45 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18260 for ; Mon, 9 Jun 2003 15:15:44 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2A07E625E8; Mon, 9 Jun 2003 21:15:15 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail05.zma.compaq.com (mailout.zma.compaq.com [161.114.64.105]) by eikenes.alvestrand.no (Postfix) with ESMTP id 12D30625D3 for ; Mon, 9 Jun 2003 21:15:03 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id CD496DCF2; Mon, 9 Jun 2003 15:15:02 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 9 Jun 2003 15:15:02 -0400 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="us-ascii" Date: Mon, 9 Jun 2003 15:15:01 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04284949@tayexc13.americas.cpqcorp.net> Thread-Topic: Trusting the IESG to manage the reform process (was:Re:DoingtheRight Things?) Thread-Index: AcMutcnftzLFRLeCRVWhHOqJOsh8xgABXjgw From: "Bound, Jim" To: "Bill Fenner" , X-OriginalArrivalTime: 09 Jun 2003 19:15:02.0587 (UTC) FILETIME=[6D6910B0:01C32EBB] Cc: problem-statement@alvestrand.no Subject: RE: Trusting the IESG to manage the reform process (was:Re:DoingtheRight Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA18260 this is very useful thanks. The IESG has to much work. This to me proves we need the SIR. /jim > -----Original Message----- > From: Bill Fenner [mailto:fenner@research.att.com] > Sent: Monday, June 09, 2003 2:34 PM > To: randy@psg.com > Cc: problem-statement@alvestrand.no > Subject: Re: Trusting the IESG to manage the reform process > (was:Re:DoingtheRight Things?) > > > > >maybe we should look at the time to process through iesg and the > >reasons we can find. i do not claim to know any answer, but of > >course have silly perceptions based on my narrow little view of the > >movie. so it would be really good to have some actual data. would > >be nice if bill, harald, or someone with time could find a way to > >get something real on which we could base a discussion. > > I just wrote a quick hack to analyze the data I have, and put the > results at http://rtg.ietf.org/~fenner/iesg/docstates.txt . There > are two types of entries in this file - one for the first time > we see a document in my snapshots, e.g. > > 20020506 draft-ietf-ipngwg-rfc2292bis entered > system in Requested > > and then once for each time it changes state: > > 20030312 draft-ietf-ipngwg-rfc2292bis IESG > Evaluation -> Approved-announcement to be sent after 11 days > > There is some noise in the data, like the tildes swapping with dashes > in this example: > > 20030426 draft-ietf-ipngwg-icmp-name-lookups IESG > Evaluation ~~ Revised ID Needed -> IESG Evaluation -- > Revised ID Needed after 170 days > 20030525 draft-ietf-ipngwg-icmp-name-lookups IESG > Evaluation -- Revised ID Needed -> IESG Evaluation ~~ > Revised ID Needed after 29 days > > but I'll wait for some evidence that cleaning up the data is desired > or useful before putting more work into it. (plenty of data, not > clear if there's any information...) > > Bill > From problem-statement-bounces@alvestrand.no Mon Jun 9 15:28:30 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18559 for ; Mon, 9 Jun 2003 15:28:29 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 46020625D3; Mon, 9 Jun 2003 21:27:59 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id D5125625A9; Mon, 9 Jun 2003 21:27:40 +0200 (CEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA18431; Mon, 9 Jun 2003 12:27:39 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h59JRcX12674; Mon, 9 Jun 2003 12:27:38 -0700 X-mProtect: <200306091927> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQnllv5; Mon, 09 Jun 2003 12:27:36 PDT Message-ID: <3EE4DFBB.8080702@iprg.nokia.com> Date: Mon, 09 Jun 2003 12:27:55 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harald Tveit Alvestrand References: <3EE4D004.4010103@iprg.nokia.com> <8130000.1055186072@askvoll.hjemme.alvestrand.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hello Harald, I agree with your statements, and I wonder if you see the value of my argument. Do you think that protocol specifications today are (generally speaking) too complicated, about right, or not yet complicated enough? Regarding "good for AT LEAST ONE THING", does it mean there has to be a killer app? What about IPv6--? Regards, Charlie P. Harald Tveit Alvestrand wrote: > Charlie, > > clipping mercilessly from your message.... > > --On mandag, juni 09, 2003 11:20:52 -0700 Charlie Perkins > wrote: > >> Another way to say this, is that we are being required to specify >> entire systems instead of protocol components. I think this is a >> very bad idea. I think the IESG should sincerely reconsider this >> policy, and let protocol specifications be published EVEN IF >> they do not solve the entire problem domain, but just a part of it. >> Typically, the part that the original protocol specification DOES >> solve, will be implemented and tested for interoperability. The >> other stuff that gets glued on will just sit there like a dark jungle. > > > The way I thought of it in the apps area 5+ years back was that a > proposal has to document that it is good for AT LEAST ONE THING. (I > failed that at times - for instance with TIP, which I still don't know > if anyone uses). > > We (the IETF) want to standardize useful protocols. If there isn't at > least one scenario where the protocol is clearly useful, I see > absolutely no reason to standardize it. So describing the scenario, > including all the bits and pieces from other protocols that have to be > there in order to make the protocol useful in that scenario, is, to my > mind, a necessary part of documenting the protocol. > > On the other hand - if a scenario is described, and it's obvious that > 5 mins after the protocol-implementing product hits the street, it > will be used in another scenario, where the proposed "supporting bits" > are clearly going to lead to undesirable situations (I'm thinking > about SNMPv1 and the "community string" here, for instance), then we > as a community have a responsibility to describe those scenarios too, > and provide/reference the adequate mechanisms for those scenarios. For > instance by saying that all IPv6 implementations MUST have IPSec > support (the "Danvers Doctrine"), or saying that applications MUST > behave in the face of congestion (RFC 2914). > > Harald > > > > > From problem-statement-bounces@alvestrand.no Mon Jun 9 15:50:43 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19174 for ; Mon, 9 Jun 2003 15:50:42 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 207BA625E4; Mon, 9 Jun 2003 21:50:13 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id E293E625A9; Mon, 9 Jun 2003 21:50:10 +0200 (CEST) Date: Mon, 09 Jun 2003 21:50:10 +0200 From: Harald Tveit Alvestrand To: Charlie Perkins Message-ID: <12640000.1055188210@askvoll.hjemme.alvestrand.no> In-Reply-To: <3EE4DFBB.8080702@iprg.nokia.com> References: <3EE4D004.4010103@iprg.nokia.com> <8130000.1055186072@askvoll.hjemme.alvestrand.no> <3EE4DFBB.8080702@iprg.nokia.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) 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: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 mandag, juni 09, 2003 12:27:55 -0700 Charlie Perkins wrote: > > Hello Harald, > > I agree with your statements, and I wonder if you see the value > of my argument. to put it this way - I see logic behind your argument, but can see your argument being used for conclusions that I wouldn't support.... > Do you think that protocol specifications today are (generally > speaking) too complicated, about right, or not yet complicated > enough? protocols should be "as simple as possible, and no simpler"... hard to tell.... > Regarding "good for AT LEAST ONE THING", does it > mean there has to be a killer app? What about IPv6--? no, I wouldn't place the bar that high..... IPv6 is good for moving data that can be used to support a TCP session. If there hadn't been a spec for using IPv6 to support TCP (and a spec for using IPv6 over Ethernet), I'd have said that the IPv6 protocol suite was incomplete. Harald From problem-statement-bounces@alvestrand.no Mon Jun 9 15:59:58 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19381 for ; Mon, 9 Jun 2003 15:59:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C68E0625D3; Mon, 9 Jun 2003 21:59:27 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 022DC61D30 for ; Mon, 9 Jun 2003 21:59:25 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19PSnV-0007Kx-00; Mon, 09 Jun 2003 14:59:17 -0500 Date: Mon, 09 Jun 2003 15:59:17 -0400 From: John C Klensin To: "Bound, Jim" , "problem-statement@alvestrand.no" Message-ID: <19664295.1055174357@p3.JCK.COM> In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B04284946@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B04284946@tayexc13.am ericas.cpqcorp.net> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: RE: Trusting the IESG to manage the reform process (was: Re: Doing the Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On Monday, 09 June, 2003 15:02 -0400 "Bound, Jim" wrote: > maybe we should make a list of what the ideal IESG member and > the group should do and how they behave as IESG with IESG > hats? this way it is not finger pointing. > > but saying there is no fix needed for the IESG is simply not > dealing with reality IMO. There are problems and they are all > not perceived. Jim, I didn't suggest that the IESG didn't need some "fixing". > If all we are going to do is fix everything but the IESG I am > going to leave this list because the goal of fixing the IETF > will not get done. > > The IESG needs a fix. I don't know what it is but it needs > fixing as other parts of our community. Ok. But there are two types of fixes: (i) Going to the IESG and saying "please do this differently". This works iff the IESG is receptive. If the IESG is not receptive, the evidence is that the request will have no effect: we have no mechanism (perhaps fortunately) for carting off to jail for violating the procedures. (ii) Removing or abolishing the [entire] IESG and replacing them/it with a structure that is more responsive to community desires and whims. Personally, I don't think we are at the point where the second is necessary. Your impressions and opinion may differ. But I think it is very important that we distinguish between the two as we try to sort through problems, procedures, and desired changes. regards, john From problem-statement-bounces@alvestrand.no Mon Jun 9 16:03:39 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19551 for ; Mon, 9 Jun 2003 16:03:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3A9E4625ED; Mon, 9 Jun 2003 22:03:08 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id C6EDF625A9; Mon, 9 Jun 2003 22:03:04 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19PSr6-0007Lo-00; Mon, 09 Jun 2003 15:03:00 -0500 Date: Mon, 09 Jun 2003 16:02:59 -0400 From: John C Klensin To: Harald Tveit Alvestrand , Charlie Perkins , "problem-statement@alvestrand.no" Message-ID: <19886825.1055174579@p3.JCK.COM> In-Reply-To: <8130000.1055186072@askvoll.hjemme.alvestrand.no> References: <3EE4D004.4010103@iprg.nokia.com> <8130000.1055186072@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On Monday, 09 June, 2003 21:14 +0200 Harald Tveit Alvestrand wrote: > Charlie, > > clipping mercilessly from your message.... > > --On mandag, juni 09, 2003 11:20:52 -0700 Charlie Perkins > wrote: > >> Another way to say this, is that we are being required to >> specify entire systems instead of protocol components. I >> think this is a very bad idea. I think the IESG should >> sincerely reconsider this policy, and let protocol >> specifications be published EVEN IF they do not solve the >> entire problem domain, but just a part of it. Typically, the >> part that the original protocol specification DOES solve, >> will be implemented and tested for interoperability. The >> other stuff that gets glued on will just sit there like a >> dark jungle. > > The way I thought of it in the apps area 5+ years back was > that a proposal has to document that it is good for AT LEAST > ONE THING. (I failed that at times - for instance with TIP, > which I still don't know if anyone uses). > > We (the IETF) want to standardize useful protocols. If there > isn't at least one scenario where the protocol is clearly > useful, I see absolutely no reason to standardize it. So > describing the scenario, including all the bits and pieces > from other protocols that have to be there in order to make > the protocol useful in that scenario, is, to my mind, a > necessary part of documenting the protocol. >... Harald, I would add one thing to this, which is that the description of a protocol that is to be approved on the basis that it does One Thing usefully must be quite clear about what that One Thing is. In other words, the narrower the focus of a protocol, the more important it is that its description describe what it is good for (and, if necessary, what it is not good for). And that is an area in which I think we have fallen down on the job several times recently. john From problem-statement-bounces@alvestrand.no Mon Jun 9 16:15:39 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19764 for ; Mon, 9 Jun 2003 16:15:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 447BE625D3; Mon, 9 Jun 2003 22:15:09 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from linux.research.att.com (H-135-207-24-16.research.att.com [135.207.24.16]) by eikenes.alvestrand.no (Postfix) with ESMTP id 96932625A9 for ; Mon, 9 Jun 2003 22:14:59 +0200 (CEST) Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71])h59KK1EI016306 for ; Mon, 9 Jun 2003 16:20:01 -0400 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46])h59KDRXs001403 for ; Mon, 9 Jun 2003 16:13:27 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h59KEwR23944; Mon, 9 Jun 2003 13:14:58 -0700 (PDT) Message-Id: <200306092014.h59KEwR23944@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: problem-statement@alvestrand.no References: <9C422444DE99BC46B3AD3C6EAFC9711B042848BE@tayexc13.americas.cpqcorp.net> <5022291864.20030608175225@brandenburg.com> <200306091834.h59IYEd22748@windsor.research.att.com> Date: Mon, 9 Jun 2003 13:14:57 -0700 Versions: dmail (solaris) 2.5a/makemail 2.9d Subject: Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 In the tradition of lies, damn lies, and statistics, I calculated the mean, median, min and max time that documents spent in any state and put it at http://rtg.ietf.org/~fenner/iesg/docstates-stats.html At a minimum, it points out how noisy the data is and how it's probably necessary to put it through a few filters before it's worth drawing conclusions from. Bill From problem-statement-bounces@alvestrand.no Mon Jun 9 16:17:27 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19785 for ; Mon, 9 Jun 2003 16:17:27 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7EBC9625D3; Mon, 9 Jun 2003 22:16:55 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by eikenes.alvestrand.no (Postfix) with ESMTP id 381DE625A9 for ; Mon, 9 Jun 2003 22:16:48 +0200 (CEST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])ESMTP id h59KGgB07309 for ; Mon, 9 Jun 2003 16:16:43 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10Q47T>; Mon, 9 Jun 2003 22:16:41 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501BC2B8F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Bound, Jim" , John C Klensin , problem-statement@alvestrand.no Date: Mon, 9 Jun 2003 22:16:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Trusting the IESG to manage the reform process (was: Re: Doin g the Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Jim writes: > If all we are going to do is fix everything but the IESG I am going to > leave this list because the goal of fixing the IETF will not get done. > > The IESG needs a fix. I don't know what it is but it needs fixing as > other parts of our community. > Mmm... how would you react if I as an AD were to put a DISCUSS on one of your documents and I would state: I don't know what it is but it needs fixing as other documents of our community. Sorry... couldn't resist Bert > /jim From problem-statement-bounces@alvestrand.no Mon Jun 9 16:21:53 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19920 for ; Mon, 9 Jun 2003 16:21:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A72CC625D3; Mon, 9 Jun 2003 22:21:19 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by eikenes.alvestrand.no (Postfix) with ESMTP id 23867625A9 for ; Mon, 9 Jun 2003 22:21:17 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 66F26B7D4; Mon, 9 Jun 2003 16:21:16 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 9 Jun 2003 16:21:15 -0400 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="us-ascii" Date: Mon, 9 Jun 2003 16:21:15 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0428494E@tayexc13.americas.cpqcorp.net> Thread-Topic: Trusting the IESG to manage the reform process (was: Re: Doing the Right Things?) Thread-Index: AcMuwbSXqn29nmPOSN6R0pUuZYwQ4wAAtELg From: "Bound, Jim" To: "John C Klensin" , X-OriginalArrivalTime: 09 Jun 2003 20:21:15.0889 (UTC) FILETIME=[ADAED610:01C32EC4] Subject: RE: Trusting the IESG to manage the reform process (was: Re: Doing the Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA19920 Did not imply or say you did not think they don't need fixing. I think "i" is the approach of course "ii" is not even in my mind. /jim > -----Original Message----- > From: John C Klensin [mailto:john-ietf@jck.com] > Sent: Monday, June 09, 2003 3:59 PM > To: Bound, Jim; problem-statement@alvestrand.no > Subject: RE: Trusting the IESG to manage the reform process > (was: Re: Doing the Right Things?) > > > > > --On Monday, 09 June, 2003 15:02 -0400 "Bound, Jim" > wrote: > > > maybe we should make a list of what the ideal IESG member and the > > group should do and how they behave as IESG with IESG hats? > this way > > it is not finger pointing. > > > > but saying there is no fix needed for the IESG is simply > not dealing > > with reality IMO. There are problems and they are all not > perceived. > > Jim, > > I didn't suggest that the IESG didn't need some "fixing". > > > If all we are going to do is fix everything but the IESG I > am going to > > leave this list because the goal of fixing the IETF will > not get done. > > > > The IESG needs a fix. I don't know what it is but it needs > fixing as > > other parts of our community. > > Ok. But there are two types of fixes: > > (i) Going to the IESG and saying "please do this > differently". This works iff the IESG is receptive. If > the IESG is not receptive, the evidence is that the > request will have no effect: we have no mechanism > (perhaps fortunately) for carting off to jail for > violating the procedures. > > (ii) Removing or abolishing the [entire] IESG and > replacing them/it with a structure that is more > responsive to community desires and whims. > > Personally, I don't think we are at the point where the second > is necessary. Your impressions and opinion may differ. But I > think it is very important that we distinguish between the two > as we try to sort through problems, procedures, and desired > changes. > > regards, > john > > From problem-statement-bounces@alvestrand.no Mon Jun 9 16:22:50 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19940 for ; Mon, 9 Jun 2003 16:22:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 365DD625D3; Mon, 9 Jun 2003 22:22:21 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail03.zma.compaq.com (mailout.zma.compaq.com [161.114.64.103]) by eikenes.alvestrand.no (Postfix) with ESMTP id F1839625A9 for ; Mon, 9 Jun 2003 22:22:15 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 5B00B8165; Mon, 9 Jun 2003 16:22:14 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 9 Jun 2003 16:22:13 -0400 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="us-ascii" Date: Mon, 9 Jun 2003 16:22:12 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0428494F@tayexc13.americas.cpqcorp.net> Thread-Topic: Trusting the IESG to manage the reform process (was: Re: Doing the Right Things?) Thread-Index: AcMuxA8lRiko3wjNQ2e9XXi6TOv4ygAAKaQA From: "Bound, Jim" To: "Wijnen, Bert (Bert)" , "John C Klensin" , X-OriginalArrivalTime: 09 Jun 2003 20:22:13.0967 (UTC) FILETIME=[D04CD5F0:01C32EC4] Subject: RE: Trusting the IESG to manage the reform process (was: Re: Doing the Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA19940 Fair. I will think and send my list ok. /jim > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Monday, June 09, 2003 4:17 PM > To: Bound, Jim; John C Klensin; problem-statement@alvestrand.no > Subject: RE: Trusting the IESG to manage the reform process > (was: Re: Doing the Right Things?) > > > Jim writes: > > If all we are going to do is fix everything but the IESG I > am going to > > leave this list because the goal of fixing the IETF will > not get done. > > > > The IESG needs a fix. I don't know what it is but it needs > fixing as > > other parts of our community. > > > Mmm... how would you react if I as an AD were to put a > DISCUSS on one of your documents and I would state: I don't > know what it is but it needs fixing as other documents of our > community. > > Sorry... couldn't resist > > Bert > > /jim > From problem-statement-bounces@alvestrand.no Mon Jun 9 16:34:33 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20259 for ; Mon, 9 Jun 2003 16:34:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8FDB5625E4; Mon, 9 Jun 2003 22:33:55 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail04.zma.compaq.com (mailout.zma.compaq.com [161.114.64.104]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7515A625A9; Mon, 9 Jun 2003 22:33:50 +0200 (CEST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id C6D1EA2D2; Mon, 9 Jun 2003 16:33:49 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 9 Jun 2003 16:33:49 -0400 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="us-ascii" Date: Mon, 9 Jun 2003 16:33:48 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0324132C@tayexc13.americas.cpqcorp.net> Thread-Topic: The need for smaller protocol specifications Thread-Index: AcMuvUUDXD9Fj6SoRt6KQyczRfpV0AAB5VAA From: "Bound, Jim" To: "Charlie Perkins" , "Harald Tveit Alvestrand" X-OriginalArrivalTime: 09 Jun 2003 20:33:49.0515 (UTC) FILETIME=[6EE109B0:01C32EC6] Cc: problem-statement@alvestrand.no Subject: RE: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA20259 I agree with Charlie but not hearing anyone comment? Maybe I am paranoid but here is what I hear happening: 1. Bob Hinden suggested an idea for time to market. Not one IESG person said this is a good idea not as IESG person but folks who have IESG experience. 2. Charlie gives below I think accurate description at a minimum a problem we face. Again no IESG response here. It could be we are still in define problem space so discussion solution is not time. Or anything we propose that fixes anything other than an intergalitic high level process will not be discussed and esp by the IESG members not as IESG members but as persons in that role with experience. Chairs I have to ask where are you at with the above two bullets if adopted they clearly require a change and action by the IESG. It feels to me the IESG and even past IESG persons don't want to do anything that causes that? Thats my read of all these threads. We are experiencing the same problems on this mail list we are discussing. What are your thoughts? If we are just going to flirt with fixing problems again I see not point in continuing. This is exactly what the ADs do too. A member makes a very logical base statement as the two above and then we get silence from ADs. Why? IMO because it shows a problem in their ranks and they won't admit it. But all here are more than willing to blast WGs, Chairs, and Authors. This list is proving there is a problem real time. It is happening before your eyes. Another IESG member blasted vendors twice this weekend. I asked them will you stop this? No answer and none privately. If I was not a nice guy I would send that mail directly to Sr. VPs I know in those companies and say here is what IESG member said about you on a public mail list. But I am trying to be a nice guy. The key problem with IESG is they think they are beyond the rules and basic codes of engineering discussion and responding to questions. Or they don't answer the question as engineers but as politicians with quip mores and folkways that are not answers to the questions. How do we document this problem? I simply do not know. thanks /jim > -----Original Message----- > From: Charlie Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Monday, June 09, 2003 3:28 PM > To: Harald Tveit Alvestrand > Cc: problem-statement@alvestrand.no > Subject: Re: The need for smaller protocol specifications > > > > Hello Harald, > > I agree with your statements, and I wonder if you see the > value of my argument. > > Do you think that protocol specifications today are (generally > speaking) too complicated, about right, or not yet complicated enough? > > Regarding "good for AT LEAST ONE THING", does it > mean there has to be a killer app? What about IPv6--? > > Regards, > Charlie P. > > > > Harald Tveit Alvestrand wrote: > > > Charlie, > > > > clipping mercilessly from your message.... > > > > --On mandag, juni 09, 2003 11:20:52 -0700 Charlie Perkins > > wrote: > > > >> Another way to say this, is that we are being required to specify > >> entire systems instead of protocol components. I think this is a > >> very bad idea. I think the IESG should sincerely reconsider this > >> policy, and let protocol specifications be published EVEN > IF they do > >> not solve the entire problem domain, but just a part of it. > >> Typically, the part that the original protocol specification DOES > >> solve, will be implemented and tested for interoperability. The > >> other stuff that gets glued on will just sit there like a dark > >> jungle. > > > > > > The way I thought of it in the apps area 5+ years back was that a > > proposal has to document that it is good for AT LEAST ONE THING. (I > > failed that at times - for instance with TIP, which I still > don't know > > if anyone uses). > > > > We (the IETF) want to standardize useful protocols. If > there isn't at > > least one scenario where the protocol is clearly useful, I see > > absolutely no reason to standardize it. So describing the scenario, > > including all the bits and pieces from other protocols that > have to be > > there in order to make the protocol useful in that > scenario, is, to my > > mind, a necessary part of documenting the protocol. > > > > On the other hand - if a scenario is described, and it's > obvious that > > 5 mins after the protocol-implementing product hits the street, it > > will be used in another scenario, where the proposed > "supporting bits" > > are clearly going to lead to undesirable situations (I'm thinking > > about SNMPv1 and the "community string" here, for > instance), then we > > as a community have a responsibility to describe those > scenarios too, > > and provide/reference the adequate mechanisms for those > scenarios. For > > instance by saying that all IPv6 implementations MUST have IPSec > > support (the "Danvers Doctrine"), or saying that applications MUST > > behave in the face of congestion (RFC 2914). > > > > Harald > > > > > > > > > > > > > From problem-statement-bounces@alvestrand.no Mon Jun 9 17:24:15 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21845 for ; Mon, 9 Jun 2003 17:24:14 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7FBAB625F7; Mon, 9 Jun 2003 23:23:39 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id DFB00625F5; Mon, 9 Jun 2003 23:23:16 +0200 (CEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA23637; Mon, 9 Jun 2003 14:23:15 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h59LNEH19581; Mon, 9 Jun 2003 14:23:14 -0700 X-mProtect: <200306092123> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdUxcstP; Mon, 09 Jun 2003 14:23:11 PDT Message-ID: <3EE4FAD2.2020303@iprg.nokia.com> Date: Mon, 09 Jun 2003 14:23:30 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bound, Jim" References: <9C422444DE99BC46B3AD3C6EAFC9711B0324132C@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Harald Tveit Alvestrand Cc: problem-statement@alvestrand.no Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hello Jim, I tried to make this short. My belief is that the IESG demands full-blown system specifications because anything less "could" be implemented inside systems that have features they don't like. Some would say that such demands are characteristic of "control freaks". I won't go that far, but it's certainly an interesting point. A good example is key distribution. If a protocol requires authentication, but does not specify a key distribution mechanism, then the security AD can ask "How can I use this without key distribution?". The answer could be by manual configuration, proprietary protocols, IKE, something new under development in 3GPP$%*, or whatever. But, by imposing the (undocumented anywhere!) requirement for a key distribution adjunct, the IESG 1) delays the specification 2) puts the design responsibility in a perhaps unprepared working group 3) discourages future development of appropriate key distribution, 4) causes protocol bloat, and 5) has a harder time judging the resulting document. It is my belief that the IESG has to bite the bullet and stop causing those effects. The cure is worse than the disease they tried to heal. Separate protocol specifications are better, and more workable if allowed to progress towards deployment and market acceptance at different rates. Perhaps early system implementations won't do the absolutely shiniest best thing, but anyway they will provide good experience for later implementations. We have _got_ to stop thinking that everything has to be perfect before it is useful. It's not like a space shuttle where we only get one chance. And even the best engineering has mistakes. That's life! The IESG can never change that. Very similar complaints could be lodged against requiring discovery protocols to be part of base specifications. In the cases I am most familiar with, this was not an imposition from the IESG, but a response to a feared response from the IESG. In fact, as the number of potential protocol interactions grows nonlinearly in the Internet, we can no longer demand that every protocol must have its interactions with other protocols documented and specified completely -- at least for Proposed Standard!! We have to have a process more friendly towards incremental refinement. And, finally, to reiterate for emphasis in hopes that no one would forget, this is not a black and white thing. It's a matter of balance, and lately the results have become terribly unbalanced towards unmanageable protocol complexity. Regards, Charlie P. Bound, Jim wrote: >I agree with Charlie but not hearing anyone comment? > >Maybe I am paranoid but here is what I hear happening: > >1. Bob Hinden suggested an idea for time to market. Not one IESG >person said this is a good idea not as IESG person but folks who have >IESG experience. > >2. Charlie gives below I think accurate description at a minimum a >problem we face. Again no IESG response here. > >It could be we are still in define problem space so discussion solution >is not time. Or anything we propose that fixes anything other than an >intergalitic high level process will not be discussed and esp by the >IESG members not as IESG members but as persons in that role with >experience. > >Chairs I have to ask where are you at with the above two bullets if >adopted they clearly require a change and action by the IESG. It feels >to me the IESG and even past IESG persons don't want to do anything that >causes that? Thats my read of all these threads. >We are experiencing the same problems on this mail list we are >discussing. >What are your thoughts? If we are just going to flirt with fixing >problems again I see not point in continuing. This is exactly what the >ADs do too. A member makes a very logical base statement as the two >above and then we get silence from ADs. Why? IMO because it shows a >problem in their ranks and they won't admit it. But all here are more >than willing to blast WGs, Chairs, and Authors. This list is proving >there is a problem real time. It is happening before your eyes. >Another IESG member blasted vendors twice this weekend. I asked them >will you stop this? No answer and none privately. If I was not a nice >guy I would send that mail directly to Sr. VPs I know in those companies >and say here is what IESG member said about you on a public mail list. >But I am trying to be a nice guy. The key problem with IESG is they >think they are beyond the rules and basic codes of engineering >discussion and responding to questions. Or they don't answer the >question as engineers but as politicians with quip mores and folkways >that are not answers to the questions. How do we document this problem? >I simply do not know. > >thanks >/jim > > > >>-----Original Message----- >>From: Charlie Perkins [mailto:charliep@IPRG.nokia.com] >>Sent: Monday, June 09, 2003 3:28 PM >>To: Harald Tveit Alvestrand >>Cc: problem-statement@alvestrand.no >>Subject: Re: The need for smaller protocol specifications >> >> >> >>Hello Harald, >> >>I agree with your statements, and I wonder if you see the >>value of my argument. >> >>Do you think that protocol specifications today are (generally >>speaking) too complicated, about right, or not yet complicated enough? >> >>Regarding "good for AT LEAST ONE THING", does it >>mean there has to be a killer app? What about IPv6--? >> >>Regards, >>Charlie P. >> >> >> >>Harald Tveit Alvestrand wrote: >> >> >> >>>Charlie, >>> >>>clipping mercilessly from your message.... >>> >>>--On mandag, juni 09, 2003 11:20:52 -0700 Charlie Perkins >>> wrote: >>> >>> >>> >>>>Another way to say this, is that we are being required to specify >>>>entire systems instead of protocol components. I think this is a >>>>very bad idea. I think the IESG should sincerely reconsider this >>>>policy, and let protocol specifications be published EVEN >>>> >>>> >>IF they do >> >> >>>>not solve the entire problem domain, but just a part of it. >>>>Typically, the part that the original protocol specification DOES >>>>solve, will be implemented and tested for interoperability. The >>>>other stuff that gets glued on will just sit there like a dark >>>>jungle. >>>> >>>> >>>The way I thought of it in the apps area 5+ years back was that a >>>proposal has to document that it is good for AT LEAST ONE THING. (I >>>failed that at times - for instance with TIP, which I still >>> >>> >>don't know >> >> >>>if anyone uses). >>> >>>We (the IETF) want to standardize useful protocols. If >>> >>> >>there isn't at >> >> >>>least one scenario where the protocol is clearly useful, I see >>>absolutely no reason to standardize it. So describing the scenario, >>>including all the bits and pieces from other protocols that >>> >>> >>have to be >> >> >>>there in order to make the protocol useful in that >>> >>> >>scenario, is, to my >> >> >>>mind, a necessary part of documenting the protocol. >>> >>>On the other hand - if a scenario is described, and it's >>> >>> >>obvious that >> >> >>>5 mins after the protocol-implementing product hits the street, it >>>will be used in another scenario, where the proposed >>> >>> >>"supporting bits" >> >> >>>are clearly going to lead to undesirable situations (I'm thinking >>>about SNMPv1 and the "community string" here, for >>> >>> >>instance), then we >> >> >>>as a community have a responsibility to describe those >>> >>> >>scenarios too, >> >> >>>and provide/reference the adequate mechanisms for those >>> >>> >>scenarios. For >> >> >>>instance by saying that all IPv6 implementations MUST have IPSec >>>support (the "Danvers Doctrine"), or saying that applications MUST >>>behave in the face of congestion (RFC 2914). >>> >>> Harald >>> >>> >>> >>> >>> >>> >>> >> >> >> From problem-statement-bounces@alvestrand.no Mon Jun 9 17:46:25 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22199 for ; Mon, 9 Jun 2003 17:46:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 16EC1625F5; Mon, 9 Jun 2003 23:45:56 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A2C6625ED for ; Mon, 9 Jun 2003 23:45:49 +0200 (CEST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h59Ljkjc028336; Mon, 9 Jun 2003 14:45:46 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIE22973; Mon, 9 Jun 2003 14:45:45 -0700 (PDT) Message-Id: <200306092145.AIE22973@mira-sjc5-c.cisco.com> To: "Bound, Jim" From: Melinda Shore In-Reply-To: Message from Jim.Bound@hp.com <9C422444DE99BC46B3AD3C6EAFC9711B0324132C@tayexc13.americas.cpqcorp.net> Date: Mon, 09 Jun 2003 17:45:45 -0400 Cc: problem-statement@alvestrand.no Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > Chairs I have to ask where are you at with the above two bullets if > adopted they clearly require a change and action by the IESG. The charter is very specific in excluding defining solutions from the scope of our work. To the extent that solutions have been discussed here it's been 1) to help frame our understanding of the problems, and 2) to try to figure out what to do about "short-term" problems that can be fixed without the overhead involved with starting up a new working group. The latter certainly excludes any kind of IESG restructuring. Allow me to point out that the more focused we remain on our two documents the more quickly we can get them wrapped up and move on to whatever solutions phase/process/what-have- you we've identified. Melinda From problem-statement-bounces@alvestrand.no Mon Jun 9 19:36:44 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25272 for ; Mon, 9 Jun 2003 19:36:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 653AF625A0; Tue, 10 Jun 2003 01:36:03 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by eikenes.alvestrand.no (Postfix) with ESMTP id 69E786258D; Tue, 10 Jun 2003 01:35:52 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 74D918035; Mon, 9 Jun 2003 19:35:51 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 9 Jun 2003 19:35:50 -0400 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="us-ascii" Date: Mon, 9 Jun 2003 19:35:50 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0324132D@tayexc13.americas.cpqcorp.net> Thread-Topic: The need for smaller protocol specifications Thread-Index: AcMuzWDnKFUb8DYbSCCm+aknmGX/EwAEdqPA From: "Bound, Jim" To: "Charlie Perkins" X-OriginalArrivalTime: 09 Jun 2003 23:35:50.0889 (UTC) FILETIME=[DC867590:01C32EDF] Cc: Harald Tveit Alvestrand Cc: problem-statement@alvestrand.no Subject: RE: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA25272 Charlie, I hear you. I don't think control freaks is where I am going. I think you present a good balance and its good you and others are around. My view is key distribution is not our concern here and IPsec would work with Mobile IPv6 as it was because I know how a market would make it work and how a vendor can build it. But I admit I am extreme and also believe our protocols should do much less and state the security issues but not hold up progress. For mission critical environments what we do here will not be used as is anyway for security where lives and such are at stake. Not at all. Cryptographers give those requirements to the vendor and will not use IETF stuff. Sure Ipsec base will be used but not as we defined it regarding key distribution and encryption/authentication algorithms. /jim > -----Original Message----- > From: Charlie Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Monday, June 09, 2003 5:24 PM > To: Bound, Jim > Cc: Harald Tveit Alvestrand; problem-statement@alvestrand.no > Subject: Re: The need for smaller protocol specifications > > > > Hello Jim, > > I tried to make this short. > > My belief is that the IESG demands full-blown system > specifications because anything less "could" be implemented > inside systems that have features they don't like. Some > would say that such demands are characteristic of "control > freaks". I won't go that far, but it's certainly an > interesting point. > > A good example is key distribution. If a protocol requires > authentication, but does not specify a key distribution > mechanism, then the security AD can ask "How can I use this > without key distribution?". The answer could be by manual > configuration, proprietary protocols, IKE, something new > under development in 3GPP$%*, or whatever. But, by imposing > the (undocumented anywhere!) requirement for a key > distribution adjunct, the IESG > 1) delays the specification > 2) puts the design responsibility in a perhaps unprepared working > group > 3) discourages future development of appropriate key distribution, > 4) causes protocol bloat, and > 5) has a harder time judging the resulting document. > It is my belief that the IESG has to bite the bullet and stop > causing those effects. The cure is worse than the disease > they tried to heal. > > Separate protocol specifications are better, and more > workable if allowed to progress towards deployment and market > acceptance at different rates. Perhaps early system > implementations won't do the absolutely shiniest best thing, > but anyway they will provide good experience for later > implementations. > > We have _got_ to stop thinking that everything has to be > perfect before it is useful. It's not like a space shuttle > where we only get one chance. And even the best engineering > has mistakes. That's life! The IESG can never change that. > > Very similar complaints could be lodged against requiring > discovery protocols to be part of base specifications. In the > cases I am most familiar with, this was not an imposition > from the IESG, but a response to a feared response from the > IESG. In fact, as the number of potential protocol > interactions grows nonlinearly in the Internet, we can no > longer demand that every protocol must have its interactions > with other protocols documented and specified completely -- > at least for Proposed Standard!! We have to have a process > more friendly towards incremental refinement. > > And, finally, to reiterate for emphasis in hopes that no one > would forget, this is not a black and white thing. It's a > matter of balance, and lately the results have become > terribly unbalanced towards unmanageable protocol complexity. > > Regards, > Charlie P. > > > > Bound, Jim wrote: > > >I agree with Charlie but not hearing anyone comment? > > > >Maybe I am paranoid but here is what I hear happening: > > > >1. Bob Hinden suggested an idea for time to market. Not one IESG > >person said this is a good idea not as IESG person but folks > who have > >IESG experience. > > > >2. Charlie gives below I think accurate description at a minimum a > >problem we face. Again no IESG response here. > > > >It could be we are still in define problem space so > discussion solution > >is not time. Or anything we propose that fixes anything > other than an > >intergalitic high level process will not be discussed and esp by the > >IESG members not as IESG members but as persons in that role with > >experience. > > > >Chairs I have to ask where are you at with the above two bullets if > >adopted they clearly require a change and action by the > IESG. It feels > >to me the IESG and even past IESG persons don't want to do anything > >that causes that? Thats my read of all these threads. We are > >experiencing the same problems on this mail list we are discussing. > >What are your thoughts? If we are just going to flirt with fixing > >problems again I see not point in continuing. This is > exactly what the > >ADs do too. A member makes a very logical base statement as the two > >above and then we get silence from ADs. Why? IMO because it shows a > >problem in their ranks and they won't admit it. But all > here are more > >than willing to blast WGs, Chairs, and Authors. This list is proving > >there is a problem real time. It is happening before your eyes. > >Another IESG member blasted vendors twice this weekend. I asked them > >will you stop this? No answer and none privately. If I was > not a nice > >guy I would send that mail directly to Sr. VPs I know in > those companies > >and say here is what IESG member said about you on a public > mail list. > >But I am trying to be a nice guy. The key problem with IESG is they > >think they are beyond the rules and basic codes of engineering > >discussion and responding to questions. Or they don't answer the > >question as engineers but as politicians with quip mores and folkways > >that are not answers to the questions. How do we document > this problem? > >I simply do not know. > > > >thanks > >/jim > > > > > > > >>-----Original Message----- > >>From: Charlie Perkins [mailto:charliep@IPRG.nokia.com] > >>Sent: Monday, June 09, 2003 3:28 PM > >>To: Harald Tveit Alvestrand > >>Cc: problem-statement@alvestrand.no > >>Subject: Re: The need for smaller protocol specifications > >> > >> > >> > >>Hello Harald, > >> > >>I agree with your statements, and I wonder if you see the > >>value of my argument. > >> > >>Do you think that protocol specifications today are (generally > >>speaking) too complicated, about right, or not yet > complicated enough? > >> > >>Regarding "good for AT LEAST ONE THING", does it > >>mean there has to be a killer app? What about IPv6--? > >> > >>Regards, > >>Charlie P. > >> > >> > >> > >>Harald Tveit Alvestrand wrote: > >> > >> > >> > >>>Charlie, > >>> > >>>clipping mercilessly from your message.... > >>> > >>>--On mandag, juni 09, 2003 11:20:52 -0700 Charlie Perkins > >>> wrote: > >>> > >>> > >>> > >>>>Another way to say this, is that we are being required to specify > >>>>entire systems instead of protocol components. I think this is a > >>>>very bad idea. I think the IESG should sincerely reconsider this > >>>>policy, and let protocol specifications be published EVEN > >>>> > >>>> > >>IF they do > >> > >> > >>>>not solve the entire problem domain, but just a part of it. > >>>>Typically, the part that the original protocol specification DOES > >>>>solve, will be implemented and tested for interoperability. The > >>>>other stuff that gets glued on will just sit there like a dark > >>>>jungle. > >>>> > >>>> > >>>The way I thought of it in the apps area 5+ years back was that a > >>>proposal has to document that it is good for AT LEAST ONE > THING. (I > >>>failed that at times - for instance with TIP, which I still > >>> > >>> > >>don't know > >> > >> > >>>if anyone uses). > >>> > >>>We (the IETF) want to standardize useful protocols. If > >>> > >>> > >>there isn't at > >> > >> > >>>least one scenario where the protocol is clearly useful, I see > >>>absolutely no reason to standardize it. So describing the > scenario, > >>>including all the bits and pieces from other protocols that > >>> > >>> > >>have to be > >> > >> > >>>there in order to make the protocol useful in that > >>> > >>> > >>scenario, is, to my > >> > >> > >>>mind, a necessary part of documenting the protocol. > >>> > >>>On the other hand - if a scenario is described, and it's > >>> > >>> > >>obvious that > >> > >> > >>>5 mins after the protocol-implementing product hits the street, it > >>>will be used in another scenario, where the proposed > >>> > >>> > >>"supporting bits" > >> > >> > >>>are clearly going to lead to undesirable situations (I'm thinking > >>>about SNMPv1 and the "community string" here, for > >>> > >>> > >>instance), then we > >> > >> > >>>as a community have a responsibility to describe those > >>> > >>> > >>scenarios too, > >> > >> > >>>and provide/reference the adequate mechanisms for those > >>> > >>> > >>scenarios. For > >> > >> > >>>instance by saying that all IPv6 implementations MUST have IPSec > >>>support (the "Danvers Doctrine"), or saying that applications MUST > >>>behave in the face of congestion (RFC 2914). > >>> > >>> Harald > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> > >> > >> > > > From problem-statement-bounces@alvestrand.no Mon Jun 9 19:40:47 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25379 for ; Mon, 9 Jun 2003 19:40:46 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 45C23625A0; Tue, 10 Jun 2003 01:40:17 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail04.zma.compaq.com (mailout.zma.compaq.com [161.114.64.104]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6DF4F6258D for ; Tue, 10 Jun 2003 01:40:13 +0200 (CEST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 6CE52BAA3; Mon, 9 Jun 2003 19:40:12 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 9 Jun 2003 19:40:12 -0400 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="us-ascii" Date: Mon, 9 Jun 2003 19:40:11 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0324132E@tayexc13.americas.cpqcorp.net> Thread-Topic: The need for smaller protocol specifications Thread-Index: AcMu0H7QpxEPON6+RKyUjNr6VW0mCAAD1uqw From: "Bound, Jim" To: "Melinda Shore" X-OriginalArrivalTime: 09 Jun 2003 23:40:12.0281 (UTC) FILETIME=[7853B690:01C32EE0] Cc: problem-statement@alvestrand.no Subject: RE: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA25379 Melinda, OK. It is hard to not enter solution space. PROBLEM: The IETF process to reach PS cannot support time-to-market requirements. [The current wording we have is good but this can be sub bullet under it as direct problem we could try to fix later in the solution space] PROBLEM: The IETF process to complete specifications puts to many features in those initial specifications. [This would be sub bullet again above]. These are problems in the IETF per this mail list. Thanks /jim > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Monday, June 09, 2003 5:46 PM > To: Bound, Jim > Cc: problem-statement@alvestrand.no > Subject: Re: The need for smaller protocol specifications > > > > Chairs I have to ask where are you at with the above two bullets if > > adopted they clearly require a change and action by the IESG. > > The charter is very specific in excluding defining solutions > from the scope of our work. To the extent that solutions > have been discussed here it's been 1) to help frame our > understanding of the problems, and 2) to try to figure out > what to do about "short-term" problems that can be fixed > without the overhead involved with starting up a new working > group. The latter certainly excludes any kind of IESG restructuring. > > Allow me to point out that the more focused we remain on our > two documents the more quickly we can get them wrapped up and > move on to whatever solutions phase/process/what-have- you > we've identified. > > Melinda > From problem-statement-bounces@alvestrand.no Mon Jun 9 23:14:11 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29200 for ; Mon, 9 Jun 2003 23:14:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 86A55625ED; Tue, 10 Jun 2003 05:13:41 +0200 (CEST) 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 A3FE0625D3 for ; Tue, 10 Jun 2003 05:13:34 +0200 (CEST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])h5A3DX920804 for ; Tue, 10 Jun 2003 06:13:33 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com ; Tue, 10 Jun 2003 06:13:33 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 10 Jun 2003 06:13:33 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 10 Jun 2003 06:13:32 +0300 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" Date: Tue, 10 Jun 2003 06:13:32 +0300 Message-ID: Thread-Topic: Trusting the IESG to manage the reform process(was:Re:DoingtheRight Things?) Thread-Index: AcMuSJ0RETjPTg+VQxGBXwJPSf1SmAABP0OgABrOrBAAEVQHsA== From: To: , X-OriginalArrivalTime: 10 Jun 2003 03:13:33.0019 (UTC) FILETIME=[462952B0:01C32EFE] Cc: problem-statement@alvestrand.no Subject: RE: Trusting the IESG to manage the reform process(was:Re:DoingtheRight Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA29200 Hi Jim, > What is not a quality document? WHich RFC? I assume we are > not talking about IDs? I am, at least, talking IDs. I have read some that were not up-to-snuff, so I think it reasonable to try to get it right from start. That will help to get the document done - or at least I hope so. John From problem-statement-bounces@alvestrand.no Tue Jun 10 00:54:02 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00974 for ; Tue, 10 Jun 2003 00:54:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 774FD625ED; Tue, 10 Jun 2003 06:53:33 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail05.zma.compaq.com (mailout.zma.compaq.com [161.114.64.105]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9333B625D3 for ; Tue, 10 Jun 2003 06:53:31 +0200 (CEST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id B0F63DF43; Tue, 10 Jun 2003 00:53:30 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Tue, 10 Jun 2003 00:53:30 -0400 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="us-ascii" Date: Tue, 10 Jun 2003 00:53:30 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04284969@tayexc13.americas.cpqcorp.net> Thread-Topic: Trusting the IESG to manage the reform process(was:Re:DoingtheRight Things?) Thread-Index: AcMuSJ0RETjPTg+VQxGBXwJPSf1SmAABP0OgABrOrBAAEVQHsAADfdlw From: "Bound, Jim" To: , X-OriginalArrivalTime: 10 Jun 2003 04:53:30.0460 (UTC) FILETIME=[3CEA31C0:01C32F0C] Cc: problem-statement@alvestrand.no Subject: RE: Trusting the IESG to manage the reform process(was:Re:DoingtheRight Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA00974 OK reboot. Now I see what your saying. I am with you yes on the issue. /jim > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Monday, June 09, 2003 11:14 PM > To: Bound, Jim; randy@psg.com > Cc: problem-statement@alvestrand.no > Subject: RE: Trusting the IESG to manage the reform > process(was:Re:DoingtheRight Things?) > > > Hi Jim, > > > What is not a quality document? WHich RFC? I assume we are > > not talking about IDs? > > I am, at least, talking IDs. I have read some that were not > up-to-snuff, so I think it reasonable to try to get it right > from start. That will help to get the document done - or at > least I hope so. > > John > From problem-statement-bounces@alvestrand.no Tue Jun 10 00:59:14 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01129 for ; Tue, 10 Jun 2003 00:59:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F12CF625D3; Tue, 10 Jun 2003 06:58:43 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by eikenes.alvestrand.no (Postfix) with ESMTP id B65546220B; Tue, 10 Jun 2003 06:58:34 +0200 (CEST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id D9A16DE15; Tue, 10 Jun 2003 00:58:33 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Tue, 10 Jun 2003 00:58:33 -0400 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="us-ascii" Date: Tue, 10 Jun 2003 00:58:33 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241330@tayexc13.americas.cpqcorp.net> Thread-Topic: The need for smaller protocol specifications Thread-Index: AcMu4Ulr9t6xEpwHQPGidNBRZNTXGwAKucqg From: "Bound, Jim" To: "Harald Tveit Alvestrand" , "Charlie Perkins" , X-OriginalArrivalTime: 10 Jun 2003 04:58:33.0742 (UTC) FILETIME=[F1AF5AE0:01C32F0C] Subject: RE: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA01129 Harald, That was a good example below. A very good one. It gets to the engineering trade off and I do think there is a responsibility to fix that which can break in some way with other sceanrios. Where we may be failing is that we have to ship for the one scenario and we document better the failure modes in other scenarios or where we simply do not know. But I think it good to ship it and tell the market do it this way any other way is at your own risk. I feel fine and comfortable with that risk its their trip and they own the trip not us. The market will always find dumb things to do with what we produce and also smart things to do with what we produce. If we keep trying to redue the risk for the market by missing time lines for technology the market will not support us. That is one of our customers. This is where we may have divergance on the list here and important point of discussion. /jim > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: Monday, June 09, 2003 3:15 PM > To: Charlie Perkins; problem-statement@alvestrand.no > Subject: Re: The need for smaller protocol specifications > > > Charlie, > > clipping mercilessly from your message.... > > --On mandag, juni 09, 2003 11:20:52 -0700 Charlie Perkins > wrote: > > > Another way to say this, is that we are being required to specify > > entire systems instead of protocol components. I think > this is a very > > bad idea. I think the IESG should sincerely reconsider > this policy, > > and let protocol specifications be published EVEN IF they > do not solve > > the entire problem domain, but just a part of it. > Typically, the part > > that the original protocol specification DOES solve, will be > > implemented and tested for interoperability. The other stuff that > > gets glued on will just sit there like a dark jungle. > > The way I thought of it in the apps area 5+ years back was > that a proposal > has to document that it is good for AT LEAST ONE THING. (I > failed that at > times - for instance with TIP, which I still don't know if > anyone uses). > > We (the IETF) want to standardize useful protocols. If there > isn't at least > one scenario where the protocol is clearly useful, I see > absolutely no > reason to standardize it. So describing the scenario, > including all the > bits and pieces from other protocols that have to be there in > order to make > the protocol useful in that scenario, is, to my mind, a > necessary part of > documenting the protocol. > > On the other hand - if a scenario is described, and it's > obvious that 5 > mins after the protocol-implementing product hits the street, > it will be > used in another scenario, where the proposed "supporting > bits" are clearly > going to lead to undesirable situations (I'm thinking about > SNMPv1 and the > "community string" here, for instance), then we as a community have a > responsibility to describe those scenarios too, and > provide/reference the > adequate mechanisms for those scenarios. For instance by > saying that all > IPv6 implementations MUST have IPSec support (the "Danvers > Doctrine"), or > saying that applications MUST behave in the face of > congestion (RFC 2914). > > Harald > > > > > > From problem-statement-bounces@alvestrand.no Tue Jun 10 02:27:18 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14699 for ; Tue, 10 Jun 2003 02:27:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E095B625ED; Tue, 10 Jun 2003 08:26:45 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id E7047625D3 for ; Tue, 10 Jun 2003 08:26:44 +0200 (CEST) Date: Tue, 10 Jun 2003 08:26:44 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <37960000.1055226404@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: MINOR ISSUE: Desired level of architectural view X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Section 2.1 of the problem-issues document says: o The misty vision has restricted the associated architectural view to an outline top level view. It would be desirable to have roadmaps and architectural views for portions of work which extend beyond a single working group: It may also be the case that it is no longer possible to fit the whole Internet within a single architecture MINOR ISSUE: There is not consensus that an archtiectural view is desirable - see introduction to "architectural principles of the Internet" (RFC 1958), which emphasizes the ability to change more than the grand plan. SUGGESTED RESOLUTION: Reformulate the paragraph to focus on the roadmaps rather than the architectural views - the term "roadmaps" indicates an understanding of where we are and where we want to go, while the term "architectural views" can be understood as "static" views on how things should hang together. PROPOSED NEW FORMULATION: o The misty vision has restricted the ability to describe global technology roadmaps beyond an outline top level view [RFC1958]. It would be desirable to have more detailed roadmaps and architectural views for portions of work which extend beyond a single working group, even if a single unified Internet architecture is not achievable by consensus. [Reminder - I am making these comments in order to make sure we have the problem issue document be the best document we can make before Vienna. If we manage to make it good enough, we can declare consensus on the document in Vienna, and stop discussing what the problem is....] From problem-statement-bounces@alvestrand.no Tue Jun 10 02:30:27 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14785 for ; Tue, 10 Jun 2003 02:30:27 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5E4C8625A3; Tue, 10 Jun 2003 08:29:56 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 96FCE625A3 for ; Tue, 10 Jun 2003 08:29:36 +0200 (CEST) Date: Tue, 10 Jun 2003 08:29:36 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <38050000.1055226576@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ISSUE: Danger of excessively narrow technology focus not mentioned X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Section 2.1 of the problem document again.... ISSUE: The problem identified in [WRONG] as "Technology Focus is Designing for stagnation" is not reflected here, or anywhere else. SUGGESTED RESOLUTION: Add a bullet to the list: o On the other hand, focusing on a too-narrow scope of technology will blinker the IETF's view of "the good of the Internet", and will harm the long-term goal of making the Internet useful; this argues for allowing a relatively wide range of topics to be worked on in the IETF; cross-fertilization has always been one of the IETF's strengths. again, [WRONG] is at http://www.alvestrand.no/ietf/chair/what-is-wrong.html From problem-statement-bounces@alvestrand.no Tue Jun 10 03:55:48 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16366 for ; Tue, 10 Jun 2003 03:55:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CB4BD62601; Tue, 10 Jun 2003 09:55:16 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5CD856220B for ; Tue, 10 Jun 2003 09:55:13 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19PdxU-000N5H-00; Tue, 10 Jun 2003 07:54:20 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19PWxJ-0000Fu-3X; Tue, 10 Jun 2003 09:25:41 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 10 Jun 2003 09:24:09 +0900 To: Margaret Wasserman References: <5.1.0.14.2.20030609093834.04842640@mail.windriver.com> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: time-to-approve etc. [Re: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?)] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 also believe that the feedback from the IESG could be offered > more openly (perhaps by mailing it to the pertinent WG?) which > would allow the WG to put pressure on the chairs and authors to > correct the problems. Right now, it can appear to a WG that a > document has "disappeared" in the IESG, when actually it is > waiting for updates from the authors. definitely agree. and one tries to do that. but it is not infrequent that a document has one or more issues where couching them in terms which would not embarrass the authors if made very publicly (and remember, we have authors from cultures with varying sensitivity to such things) would tax the talents of marcus aurelius let alone the overloaded engineers with which we staff the iesg. while this is not the majority case, it does mean we should not make a hard and fast rule. randy From problem-statement-bounces@alvestrand.no Tue Jun 10 04:38:21 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17103 for ; Tue, 10 Jun 2003 04:38:21 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 47F23625FF; Tue, 10 Jun 2003 10:37:51 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id B9000625A3 for ; Tue, 10 Jun 2003 10:37:41 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19PedQ-000PAV-00; Tue, 10 Jun 2003 08:37:40 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19PedP-0005tb-Mj; Tue, 10 Jun 2003 17:37:39 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 10 Jun 2003 17:37:39 +0900 To: Jim Bound References: <9C422444DE99BC46B3AD3C6EAFC9711B0324132C@tayexc13.americas.cpqcorp.net> Message-Id: Cc: problem-statement@alvestrand.no Subject: RE: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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. Bob Hinden suggested an idea for time to market. Not one IESG > person said this is a good idea not as IESG person but folks who have > IESG experience. 'timely' was one of the ajdectives in the terse iesg statement of the ietf's mission. > 2. Charlie gives below I think accurate description at a minimum a > problem we face. Again no IESG response here. a formal iesg response would take two years as it would have to pass iab and isoc review :-) and, by now you will have seen a number of responses. folk are just busy. e.g., i was on a plane over the pacific. patience, guy. i think harald said it well, and i will paraphrase. yes, protocols often get far too complex. but the way charlie phrases the issue could much more easily be used for things i would not support than for things i would. randy From problem-statement-bounces@alvestrand.no Tue Jun 10 05:17:03 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18148 for ; Tue, 10 Jun 2003 05:17:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8F35B62601; Tue, 10 Jun 2003 11:16:20 +0200 (CEST) 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 D83AB625A3; Tue, 10 Jun 2003 11:16:14 +0200 (CEST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])h5A9GE927382; Tue, 10 Jun 2003 12:16:14 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com ; Tue, 10 Jun 2003 12:16:14 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 10 Jun 2003 12:16:14 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 10 Jun 2003 12:16:13 +0300 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" Date: Tue, 10 Jun 2003 12:16:12 +0300 Message-ID: Thread-Topic: MINOR ISSUE: Desired level of architectural view Thread-Index: AcMvGUiY0wC8IvwfQDqSaMsXwDl6fgAF4YKA From: To: , X-OriginalArrivalTime: 10 Jun 2003 09:16:13.0305 (UTC) FILETIME=[F04D7690:01C32F30] Subject: RE: MINOR ISSUE: Desired level of architectural view X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA18148 Hi Harald, I support your text. Roadmaps are not a bad thing; one could imagine other organizations using the IETF's roadmaps to sort out priorities, etc. for getting work done in the IETF. John > -----Original Message----- > From: ext Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: 10 June, 2003 09:27 > To: problem-statement@alvestrand.no > Subject: MINOR ISSUE: Desired level of architectural view > > > Section 2.1 of the problem-issues document says: > > o The misty vision has restricted the associated > architectural view > to an outline top level view. It would be desirable to have > roadmaps and architectural views for portions of work > which extend > beyond a single working group: It may also be the case > that it is > no longer possible to fit the whole Internet within a single > architecture > > MINOR ISSUE: There is not consensus that an archtiectural > view is desirable > - see introduction to "architectural principles of the Internet" (RFC > 1958), which emphasizes the ability to change more than the > grand plan. > > > SUGGESTED RESOLUTION: Reformulate the paragraph to focus on > the roadmaps > rather than the architectural views - the term "roadmaps" > indicates an > understanding of where we are and where we want to go, while the term > "architectural views" can be understood as "static" views on > how things > should hang together. > > PROPOSED NEW FORMULATION: > > o The misty vision has restricted the ability to describe global > technology roadmaps beyond an outline top level view [RFC1958]. > It would be desirable to have more detailed > roadmaps and architectural views for portions of work > which extend > beyond a single working group, even if a single unified Internet > architecture is not achievable by consensus. > > [Reminder - I am making these comments in order to make sure > we have the > problem issue document be the best document we can make > before Vienna. If > we manage to make it good enough, we can declare consensus on > the document > in Vienna, and stop discussing what the problem is....] > > From problem-statement-bounces@alvestrand.no Tue Jun 10 07:36:59 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20808 for ; Tue, 10 Jun 2003 07:36:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 788436233E; Tue, 10 Jun 2003 13:36:27 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5BCCA621FB for ; Tue, 10 Jun 2003 13:36:24 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19PhQM-000BFE-00; Tue, 10 Jun 2003 06:36:22 -0500 Date: Tue, 10 Jun 2003 07:36:22 -0400 From: John C Klensin To: Brian E Carpenter , "problem-statement@alvestrand.no" Message-ID: <75888662.1055230582@p3.JCK.COM> In-Reply-To: <3EE07FFE.32A07F4A@hursley.ibm.com> References: <3EE07FFE.32A07F4A@hursley.ibm.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Friday, 06 June, 2003 13:50 +0200 Brian E Carpenter wrote: > In any case, since we don't actually use the complexity we > already have (3 grades of standard), the need is clearly to > *simplify* the document scheme, not to complicate it. My > thinking is getting more radical the longer this discussion > continues. Let's think seriously about > > Problem: the 3 step standards track is largely fictional > > and possible solutions along the lines of > > Solution: let's scrap it and have all "standards" RFCs as a > single level (with recycling in grade for > corrections/updates). Sigh. I wondered how long it would take us to get there. Several years ago, when it became clear that the efforts (and investment) on OSI were going nowhere, and that TCP/IP was taking over, many of the "traditional" standards bodies went into a huge excursion of "future standards planning" in which they tried to map out a future in which users and industry didn't automatically come to them every time a standards issue arose. From their perspective, that (and bodies like the IETF) were problems that needed fixing. Now there was a subtext in some of those concerns, which might have been stated as "how do we professional standardizers, process experts, and generalized go-ers (thanks, Marshall) who haven't done real engineering and design for years (if ever) keep our nice jobs, frequent flyer miles, and fine lunches and dinners?" but, regardless of the motivation, the problem remained: what were groups like the IETF doing that they needed to imitate, co-opt, or defeat? There were several answers: (1) We didn't standardize fantasies about where the industry was likely to go, or where we wanted it to go. No "anticipatory standards" here. Documents didn't advance to full standard, or even draft standard, unless there was solid implementation experience. (2) We didn't have a mandatory five-year (or other) review cycle that led to permanent WGs dedicated to each [group of] standards, provided a full-employment situation for WG chairs, and virtually guaranteed second-system effects (while the initial development WG often contained solid engineering expertise and was usually in touch with real customer and product requirements, and the first review cycle might contain some of those people in order to fix bugs that had been discovered, by the time of the second review (third time around) sponsoring companies had almost always pulled out the useful designers, replacing them with people whose fantasies about improvements usually exceeded their experience and knowledge). (3) We were reluctant to simply declare an old standard obsolete and replace it. Instead, we worried a great deal about compatibility and interoperability between old versions and new ones. And we didn't "withdraw" the old documents from the marketplace, making copies of it essentially unavailable. (4) We didn't try to support the standards process, or its bureaucracy, by either selling standards (and tight control over copyrights to make that feasible) or extracting high participation, "membership", or "service" fees from participants. (5) Partially as the result of (4), we enabled and encouraged participation by interested and dedicated individuals and also from academics and researchers (not just corporations, government bodies, and institutional IT departments). (6) Our key participants were still rooted in products -- developing code, determining requirements, doing leading-edge research in the relevant technologies -- rather than being full-time standardizers or process experts. The "optimists" within those traditional standards believed that all of the above were just the result of our lack of organizational maturity. They were convinced that, as age, scale, and a sense of responsibility toward the marketplace caught up with us, much of the above would disappear and we would turn into "them". I thought they were wrong. I'm beginning to wonder. Note, for example: (i) We have apparently succeeded in turning the IESG into a full time job. Some of the members are essentially lent to us for a while from the product-rooted jobs identified in (6) or are still trying to do IESG along with day jobs. But we are, at best, on a slippery slope. (ii) More and more of our proposed standards are approved at "we generally think this is a good idea" phase, rather than on the basis of solid experience along at least some dimensions. That is ok, because we still have Draft and Full standard levels... whoops, we are now talking about dropping those (note that this has nothing to do with whether or not those two grades should be combined). (iii) We are talking about semi-permanent "maintenance WGs". It may well be a good idea, and better than any of the alternatives, but it takes us away from the "WGs get formed around a specific function, do their work, and then dissolve" model... and we had best be careful what we wish for. (iv) Meeting fees have reached a level we would have considered inconceivable a decade ago, and we have considered shifting more authority and responsibility to the Secretariat and other IETF-paid professionals as a means of reducing load on the IESG and/or WG Chairs and Editors, etc. Hmm... john From problem-statement-bounces@alvestrand.no Tue Jun 10 10:03:11 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00590 for ; Tue, 10 Jun 2003 10:03:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 604986220B; Tue, 10 Jun 2003 16:02:40 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id 983C361D30 for ; Tue, 10 Jun 2003 16:02:37 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA28215 for ; Tue, 10 Jun 2003 07:02:11 -0700 (PDT) Message-Id: <5.1.0.14.2.20030610095535.0437ca00@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 Jun 2003 09:58:21 -0400 To: problem-statement@alvestrand.no From: Margaret Wasserman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Wording of Engineering Processes Problem X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 As I mentioned in SF, I think we may want to change the wording of the "Engineering Processes" problem... IMO, the problem isn't that we don't use effective engineering processes (although using them may be part of the solution). I'd state the problem as: "WGs do not consistently produce timely, high-quality and predictable output." Solutions to this problem might include: adoption of quality processes, training, better review during document production, flogging WG chairs who produce crap, etc. What do others think? Margaret From problem-statement-bounces@alvestrand.no Tue Jun 10 10:16:24 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02465 for ; Tue, 10 Jun 2003 10:16:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 70384622A1; Tue, 10 Jun 2003 16:15:53 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 35DF56220B; Tue, 10 Jun 2003 16:15:41 +0200 (CEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA06094; Tue, 10 Jun 2003 07:15:39 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5AEFd106366; Tue, 10 Jun 2003 07:15:39 -0700 X-mProtect: <200306101415> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdeltyEg; Tue, 10 Jun 2003 07:15:37 PDT Message-ID: <3EE5E81A.7060704@iprg.nokia.com> Date: Tue, 10 Jun 2003 07:15:54 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Bush , Harald Tveit Alvestrand References: <9C422444DE99BC46B3AD3C6EAFC9711B0324132C@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hello Randy and Harald, If my characterization of the problem was too general, perhaps you can help to refine it. If you have examples showing how my characterization could be used the wrong way, please help by discussing your examples. If you think that my example of key distribution seemed like a perfectly legitimate exercise of IESG power, then I don't think we're likely to come to agreement, and I would view your opinion as leaning towards requiring specification for entire systems as opposed to mere protocols. Do you prefer system specifications or protocol specifications? Here would be one possible formulation for what I see as a major problem (perhaps _the_ major problem!): -- The IESG has tended to require protocol specifications that specify entire systems, instead of simple component protocols. This limits the applicability of the component protocols to work only in the particular larger system, complicates the implementation of the component protocols, and delays the publication of the component protocols. Regards, Charlie P. PS. I do not believe that IP would pass IESG review today. Think of all the attacks based on routability! Randy Bush wrote: >>2. Charlie gives below I think accurate description at a minimum a >>problem we face. Again no IESG response here. >> >> > >a formal iesg response would take two years as it would have to pass >iab and isoc review :-) > >and, by now you will have seen a number of responses. folk are just >busy. e.g., i was on a plane over the pacific. patience, guy. > >i think harald said it well, and i will paraphrase. yes, protocols >often get far too complex. but the way charlie phrases the issue >could much more easily be used for things i would not support than >for things i would. > >randy > > > From problem-statement-bounces@alvestrand.no Tue Jun 10 10:29:04 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02842 for ; Tue, 10 Jun 2003 10:29:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C71FB622A1; Tue, 10 Jun 2003 16:28:30 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0196661D30; Tue, 10 Jun 2003 16:28:23 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19Pk6k-000Bvz-00; Tue, 10 Jun 2003 09:28:18 -0500 Date: Tue, 10 Jun 2003 10:28:18 -0400 From: John C Klensin To: Charlie Perkins , Randy Bush , Harald Tveit Alvestrand Message-ID: <86204445.1055240898@p3.JCK.COM> In-Reply-To: <3EE5E81A.7060704@iprg.nokia.com> References: <3EE5E81A.7060704@iprg.nokia.com> X-Mailer: Mulberry/3.0.3 (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: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On Tuesday, 10 June, 2003 07:15 -0700 Charlie Perkins wrote: >... > If you think that my example of key distribution seemed > like a perfectly legitimate exercise of IESG power, then > I don't think we're likely to come to agreement, and I would > view your opinion as leaning towards requiring specification > for entire systems as opposed to mere protocols. > > Do you prefer system specifications or protocol specifications? > > Here would be one possible formulation for what I see as > a major problem (perhaps _the_ major problem!): > > -- The IESG has tended to require protocol specifications that > specify entire systems, instead of simple component > protocols. This limits the applicability of the component > protocols to work only in the particular larger system, > complicates the implementation of the component protocols, > and delays the publication of the component protocols. Charlie, While I would often agree with the above, I think there is another, balancing, problem. Perhaps there are differences by area or topic, but I think it would be equally accurate to say: -- The IESG has tended to approve simple component protocol specifications without an adequate understanding of the systems and contexts in which those protocols will be used. If vendors or users adopt the protocols without adequate consideration of those system and contexts, this may create considerable risks for the overall operation of the Internet. While protocol specifications should not be expected about every possible application and context, they should include documentation that describes which contexts have been thought out and evaluated and which ones, if any, are known to be inappropriate. There is obviously a balance that should be found and kept here. Slogans like "complete systems only" and "small components only" are unlikely to lead us to progress, quality, or understanding. Note that I don't think you have been invoking such slogans --I've found your notes helpful and thoughtful-- but it is only a small step from what you have said, or my response above, to them. regards, john From problem-statement-bounces@alvestrand.no Tue Jun 10 11:04:39 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04606 for ; Tue, 10 Jun 2003 11:04:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 118816220B; Tue, 10 Jun 2003 17:04:09 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7B8C461D30 for ; Tue, 10 Jun 2003 17:04:06 +0200 (CEST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5AF43ms014331 for ; Tue, 10 Jun 2003 08:04:03 -0700 (PDT) Received: from cisco.com (sjc-vpn2-173.cisco.com [10.21.112.173]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AHA30806; Tue, 10 Jun 2003 07:59:46 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Tue, 10 Jun 2003 11:03:59 -0400 Date: Tue, 10 Jun 2003 11:03:59 -0400 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030610150359.GT1796@sbrim-w2k01> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: <5.1.0.14.2.20030610095535.0437ca00@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030610095535.0437ca00@mail.windriver.com> User-Agent: Mutt/1.4i Subject: Re: Wording of Engineering Processes Problem X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Tue, Jun 10, 2003 09:58:21AM -0400, Margaret Wasserman allegedly wrote: > > As I mentioned in SF, I think we may want to change the > wording of the "Engineering Processes" problem... > > IMO, the problem isn't that we don't use effective > engineering processes (although using them may be part > of the solution). I'd state the problem as: > > "WGs do not consistently produce timely, high-quality > and predictable output." > > Solutions to this problem might include: adoption of > quality processes, training, better review during document > production, flogging WG chairs who produce crap, etc. > > What do others think? Fine with me. It avoids straying into solutions. From problem-statement-bounces@alvestrand.no Tue Jun 10 11:17:41 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05081 for ; Tue, 10 Jun 2003 11:17:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A19C1622A1; Tue, 10 Jun 2003 17:17:10 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from znsgs01r.nortelnetworks.com (h42s128a211n47.user.nortelnetworks.com [47.211.128.42]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7243B61D30 for ; Tue, 10 Jun 2003 17:16:59 +0200 (CEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124])id h5AFGpS09800; Tue, 10 Jun 2003 16:16:52 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jun 2003 16:16:51 +0100 Message-ID: <4103264BC8D3D51180B7002048400C45016234AE@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "'Margaret Wasserman'" , problem-statement@alvestrand.no Date: Tue, 10 Jun 2003 16:16:44 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: RE: Wording of Engineering Processes Problem X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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. Whilst the problem certainly could be phrased as you suggest, I think it is important to emphasise the failure to live up to our name: An Engineering Task Force should surely use effective engineering practices and we don't always do so - this is not a solution issue (unless this includes changing our name and our whole intent). Regards, Elwyn > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: 10 June 2003 14:58 > To: problem-statement@alvestrand.no > Subject: Wording of Engineering Processes Problem > > > > As I mentioned in SF, I think we may want to change the > wording of the "Engineering Processes" problem... > > IMO, the problem isn't that we don't use effective > engineering processes (although using them may be part > of the solution). I'd state the problem as: > > "WGs do not consistently produce timely, high-quality > and predictable output." > > Solutions to this problem might include: adoption of > quality processes, training, better review during document > production, flogging WG chairs who produce crap, etc. > > What do others think? > > Margaret > > > From problem-statement-bounces@alvestrand.no Tue Jun 10 11:27:31 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05401 for ; Tue, 10 Jun 2003 11:27:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1900A622A1; Tue, 10 Jun 2003 17:27:02 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9B4826220B for ; Tue, 10 Jun 2003 17:26:55 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h5AFQek02863; Tue, 10 Jun 2003 11:26:41 -0400 (EDT) Date: Tue, 10 Jun 2003 11:26:40 -0400 From: Keith Moore To: Margaret Wasserman Message-Id: <20030610112640.4dac7969.moore@cs.utk.edu> In-Reply-To: <5.1.0.14.2.20030610095535.0437ca00@mail.windriver.com> References: <5.1.0.14.2.20030610095535.0437ca00@mail.windriver.com> X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Subject: Re: Wording of Engineering Processes Problem X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > IMO, the problem isn't that we don't use effective > engineering processes (although using them may be part > of the solution). I'd state the problem as: > > "WGs do not consistently produce timely, high-quality > and predictable output." there's more to engineering than these considerations. two things come to mind immediately: cost-effectiveness and responsibility to the public. From problem-statement-bounces@alvestrand.no Tue Jun 10 11:41:29 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06061 for ; Tue, 10 Jun 2003 11:41:29 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3224E622A1; Tue, 10 Jun 2003 17:40:59 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9679D6220B for ; Tue, 10 Jun 2003 17:40:51 +0200 (CEST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])h5AFepa25301 for ; Tue, 10 Jun 2003 18:40:51 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com ; Tue, 10 Jun 2003 18:40:47 +0300 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 10 Jun 2003 18:40:46 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 10 Jun 2003 18:40:45 +0300 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" Date: Tue, 10 Jun 2003 18:40:44 +0300 Message-ID: Thread-Topic: Wording of Engineering Processes Problem Thread-Index: AcMvWUjUtW3URghATXmNH+v40Dk5wQADS4pA From: To: , X-OriginalArrivalTime: 10 Jun 2003 15:40:45.0593 (UTC) FILETIME=[A8753890:01C32F66] Subject: RE: Wording of Engineering Processes Problem X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA06061 Hi Margaret, > As I mentioned in SF, I think we may want to change the > wording of the "Engineering Processes" problem... > > IMO, the problem isn't that we don't use effective > engineering processes (although using them may be part > of the solution). I'd state the problem as: > > "WGs do not consistently produce timely, high-quality > and predictable output." I could buy that. > Solutions to this problem might include: adoption of > quality processes, training, better review during document > production, flogging WG chairs who produce crap, etc. Or how about simple checks & balances? John From problem-statement-bounces@alvestrand.no Tue Jun 10 11:47:23 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06222 for ; Tue, 10 Jun 2003 11:47:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 69E7E622A1; Tue, 10 Jun 2003 17:46:53 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by eikenes.alvestrand.no (Postfix) with ESMTP id F17266220B for ; Tue, 10 Jun 2003 17:46:50 +0200 (CEST) Received: by romeo.rtfm.com (Postfix, from userid 556) id 737A7ABAF; Tue, 10 Jun 2003 08:53:01 -0700 (PDT) To: References: From: Eric Rescorla Date: 10 Jun 2003 08:53:00 -0700 In-Reply-To: Message-ID: Lines: 34 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mrw@windriver.com Cc: problem-statement@alvestrand.no Subject: Re: Wording of Engineering Processes Problem X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: EKR 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 writes: > Hi Margaret, > > > As I mentioned in SF, I think we may want to change the > > wording of the "Engineering Processes" problem... > > > > IMO, the problem isn't that we don't use effective > > engineering processes (although using them may be part > > of the solution). I'd state the problem as: > > > > "WGs do not consistently produce timely, high-quality > > and predictable output." > > I could buy that. > > > Solutions to this problem might include: adoption of > > quality processes, training, better review during document > > production, flogging WG chairs who produce crap, etc. > > Or how about simple checks & balances? I don't think so. The main function of checks and balances in most political systems is to stop things from getting done. If we actually want to produce work that's good, I think we'll have to orient ourselves more towards that goal. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From problem-statement-bounces@alvestrand.no Tue Jun 10 12:45:16 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08593 for ; Tue, 10 Jun 2003 12:45:15 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 83E646233E; Tue, 10 Jun 2003 18:44:45 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id E9B7A6230F for ; Tue, 10 Jun 2003 18:44:42 +0200 (CEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA12602; Tue, 10 Jun 2003 09:44:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5AGieC06768; Tue, 10 Jun 2003 09:44:40 -0700 X-mProtect: <200306101644> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBAYEkE; Tue, 10 Jun 2003 09:44:38 PDT Message-ID: <3EE60B02.1040504@iprg.nokia.com> Date: Tue, 10 Jun 2003 09:44:50 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman References: <5.1.0.14.2.20030610095535.0437ca00@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Wording of Engineering Processes Problem X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hello Margaret, I am reminded of the story about the start-up where things were finally getting taken care of, loose ends straightened out, and so on. They folded soon after. The moral is that work on the edge of technology is messy and unpredictable. I'd rather encourage timeliness than predictability, because the latter probably means that the timeline by which the predictions are made will be expanded to assure success. It seems to me that once interoperability is achieved and major technical difficulties are overcome, the process should be oriented towards expedient publication. Regards, Charlie P. Margaret Wasserman wrote: > > As I mentioned in SF, I think we may want to change the > wording of the "Engineering Processes" problem... > > IMO, the problem isn't that we don't use effective > engineering processes (although using them may be part > of the solution). I'd state the problem as: > > "WGs do not consistently produce timely, high-quality > and predictable output." > > Solutions to this problem might include: adoption of > quality processes, training, better review during document > production, flogging WG chairs who produce crap, etc. > > What do others think? > > Margaret > > From problem-statement-bounces@alvestrand.no Tue Jun 10 12:53:04 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08943 for ; Tue, 10 Jun 2003 12:53:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4F28C6230F; Tue, 10 Jun 2003 18:52:35 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.wrs.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7B5D5622AC for ; Tue, 10 Jun 2003 18:52:28 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([128.224.4.109]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA12190; Tue, 10 Jun 2003 09:51:59 -0700 (PDT) Message-Id: <5.1.0.14.2.20030610124329.043cad30@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 Jun 2003 12:48:05 -0400 To: Charlie Perkins From: Margaret Wasserman In-Reply-To: <3EE60B02.1040504@iprg.nokia.com> References: <5.1.0.14.2.20030610095535.0437ca00@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: Wording of Engineering Processes Problem X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 At 09:44 AM 6/10/2003 -0700, Charlie Perkins wrote: >I'd rather encourage timeliness than predictability, because >the latter probably means that the timeline by which the >predictions are made will be expanded to assure success. I would also prefer to think about timeliness rather than predictability. But, it can be quite difficult to make trade-offs between feature level and timeliness if you don't have any schedule predictability... Also, several people have said, on this list, that their (large) companies sometimes have problems with the lack of predictability of IETF output. They don't understand how much they need to invest to get certain results, which makes it difficult to imply traditional ROI (return on investment) thinking to IETF activities. Margaret From problem-statement-bounces@alvestrand.no Tue Jun 10 13:51:06 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10773 for ; Tue, 10 Jun 2003 13:51:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 195676233E; Tue, 10 Jun 2003 19:50:35 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7B3EC6230F for ; Tue, 10 Jun 2003 19:50:32 +0200 (CEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA15685; Tue, 10 Jun 2003 10:50:31 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5AHoUP01277; Tue, 10 Jun 2003 10:50:30 -0700 X-mProtect: <200306101750> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdYgwdxe; Tue, 10 Jun 2003 10:50:28 PDT Message-ID: <3EE61A65.B8EF9E8A@iprg.nokia.com> Date: Tue, 10 Jun 2003 10:50:29 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: John C Klensin References: <3EE5E81A.7060704@iprg.nokia.com> <86204445.1055240898@p3.JCK.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "problem-statement@alvestrand.no" Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hello John, I think your reformulation will help to refine the problem. Comments below. John C Klensin wrote: > .......... I think there is > another, balancing, problem. Perhaps there are differences by > area or topic, but I think it would be equally accurate to say: > > -- The IESG has tended to approve simple component > protocol specifications without an adequate > understanding of the systems and contexts in which those > protocols will be used. If vendors or users adopt the > protocols without adequate consideration of those system > and contexts, this may create considerable risks for the > overall operation of the Internet. While protocol > specifications should not be expected about every > possible application and context, they should include > documentation that describes which contexts have been > thought out and evaluated and which ones, if any, are > known to be inappropriate. > > There is obviously a balance that should be found and kept here. Exactly. This is an engineering problem, not a mathematical problem, and I have tried to emphasize the need for balance. Your suggested solution (eek! solution space!) seems workable to me, but notably it does NOT imply that the partcular contexts are codified as necessary parts of the base specification. Indeed, once again we may be asked to upgrade the "applicability" part of the specfication. This should be understood as a _possible_ application of the protocol, and not the _only_ application of the protocol. > Slogans like "complete systems only" and "small components only" > are unlikely to lead us to progress, quality, or understanding. One person's "slogan" is another person's "engineering guideline". I do not believe that understanding good engineering guidelines is a hindrance. Perhaps you meant to suggest that no such guidelines are immutable, but have to reflect current practice and understanding. I am suggesting that the current trend towards demanding complete system specifications is itself a mighty hindrance. > Note that I don't think you have been invoking such slogans > --I've found your notes helpful and thoughtful-- but it is only > a small step from what you have said, or my response above, to > them. Thank you very much for the encouragement, and I hope we can continue to refine this particular problem statement. Regards, Charlie P. From problem-statement-bounces@alvestrand.no Tue Jun 10 14:27:41 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11648 for ; Tue, 10 Jun 2003 14:27:41 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0547E62590; Tue, 10 Jun 2003 20:27:11 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2CEED6233E for ; Tue, 10 Jun 2003 20:27:09 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19Pnpr-0000DN-00; Tue, 10 Jun 2003 18:27:08 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19Pnpq-0006DB-Ld; Wed, 11 Jun 2003 03:27:06 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 11 Jun 2003 03:27:06 +0900 To: Margaret Wasserman References: <5.1.0.14.2.20030610095535.0437ca00@mail.windriver.com> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: Wording of Engineering Processes Problem X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > "WGs do not consistently produce timely, high-quality > and predictable output." or "we do not know how to help wgs to consistently ..." or s/know how/have processes and incentives in place/ randy From problem-statement-bounces@alvestrand.no Tue Jun 10 14:31:51 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11897 for ; Tue, 10 Jun 2003 14:31:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D84E66233E; Tue, 10 Jun 2003 20:31:19 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id B276C6230F; Tue, 10 Jun 2003 20:31:07 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19Pnti-0000SG-00; Tue, 10 Jun 2003 18:31:06 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19Pntg-0006DO-Hy; Wed, 11 Jun 2003 03:31:04 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 11 Jun 2003 03:31:03 +0900 To: John C Klensin References: <3EE5E81A.7060704@iprg.nokia.com> <86204445.1055240898@p3.JCK.COM> Message-Id: Cc: Harald Tveit Alvestrand Cc: Charlie Perkins Cc: "problem-statement@alvestrand.no" Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > -- The IESG has tended to approve ... note that this kind of phrasing is part of the polarization game. the wgs also approve or not. there is ietf last call where all sorts of "but it does not interoperate with X, has a horrible security hole Y, ..." are, or used to be and probably should be, raised. randy From problem-statement-bounces@alvestrand.no Tue Jun 10 14:44:42 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12141 for ; Tue, 10 Jun 2003 14:44:42 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8A30362590; Tue, 10 Jun 2003 20:44:11 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A79A6230F for ; Tue, 10 Jun 2003 20:44:02 +0200 (CEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA18537 for ; Tue, 10 Jun 2003 11:44:00 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5AIhxr21736 for ; Tue, 10 Jun 2003 11:43:59 -0700 X-mProtect: <200306101843> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdueELVo; Tue, 10 Jun 2003 11:43:58 PDT Message-ID: <3EE626EF.53ED7487@iprg.nokia.com> Date: Tue, 10 Jun 2003 11:43:59 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: problem-statement@alvestrand.no Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Two document stages: Proposed and Full X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hello folks, I think this has been suggested before. I'd like to suggest it again. Maybe we can get some mileage out of having two stages of standardization: Proposed Standard: requires working group approval. IESG comments taken into account, but full IESG approval not needed before publication. Interoperability testing completed, no known flaws that present danger to the Internet. Component protocols are O.K., as long as applicability (usefulness) is documented. Full Standard: Full IESG approval required, according to current procedures. Component protocols published as part of document suites, or separately, according to IESG discretion. Since the IESG still controls charters and chair selection, one may presume that generally sensible people will be involved. In this model, for instance, a working group might publish a component protocol, and another working group with more relevant expertise might publish another associated component protocol that could fit together into a larger system. Maybe this is too much "solution space" -- if so, I'll try to bring it up whenever I can find that forum. It's gotta be around here somewhere. Regards, Charlie P. From problem-statement-bounces@alvestrand.no Tue Jun 10 16:44:59 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17115 for ; Tue, 10 Jun 2003 16:44:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5CF8062571; Tue, 10 Jun 2003 22:44:29 +0200 (CEST) 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 C5DD66230F; Tue, 10 Jun 2003 22:44:18 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h5AKl8F26040; Tue, 10 Jun 2003 13:47:08 -0700 Date: Tue, 10 Jun 2003 13:42:09 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/10) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <7815354758.20030610134209@brandenburg.com> To: Randy Bush In-Reply-To: References: <3EE5E81A.7060704@iprg.nokia.com> <86204445.1055240898@p3.JCK.COM> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: John C Klensin Cc: Harald Tveit Alvestrand Cc: Charlie Perkins Cc: "problem-statement@alvestrand.no" Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Randy, >> -- The IESG has tended to approve ... RB> note that this kind of phrasing is part of the polarization game. actually, challenging it in this way has more to do with polarization than does the original statement. how is it possible to sustain constructive discussion about perceptions and problems if people are not able to state their perceptions in a simple and direct fashion? There is nothing rude or even challenging in the tone of the original language. Whether it is correct is independent of whether it is reasonable to make such a statement. If anyone offering their understanding of the situation, who happens to include in that statement some assertion about the iesg, is going to be treated to such a challenge -- particular from an AD -- then we are faced with what can only be classed as a hostile work environment. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue Jun 10 17:16:03 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18302 for ; Tue, 10 Jun 2003 17:16:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6984B6233E; Tue, 10 Jun 2003 23:15:32 +0200 (CEST) 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 E49526233E for ; Tue, 10 Jun 2003 23:15:05 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h5ALI4F27671; Tue, 10 Jun 2003 14:18:04 -0700 Date: Tue, 10 Jun 2003 14:14:58 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/10) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <13517324551.20030610141458@brandenburg.com> To: "Charles E. Perkins" In-Reply-To: <3EE626EF.53ED7487@iprg.nokia.com> References: <3EE626EF.53ED7487@iprg.nokia.com> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Two document stages: Proposed and Full X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Charles, First, many thanks for your earlier thread and the exchange with John K. I think that you've developed an issue that is serious and poses a real dilemma. One thought on component-vs-system is that we might want to make that distinction more explicitly and even formally, making it relatively easy to do component specifications, but still difficult to do system specifications. With respect to your suggestion on standards classifications: CEP> Proposed Standard: requires working group approval. IESG comments CEP> taken into account, but full IESG approval not needed before CEP> publication. Interoperability testing completed, no known CEP> flaws that present danger to the Internet. Component protocols CEP> are O.K., as long as applicability (usefulness) is documented. This is rather interesting. Most Proposed specs, today, are not required to demonstrate interoperability, whereas Draft is. The question is whether the working group's reliably exert enough quality control on their output. For all that one might express legitimate concern about IESG push-back, there is also a legitimate concern about some working groups that produce poor work. CEP> Full Standard: Full IESG approval required, according to current CEP> procedures. Component protocols published as part of CEP> document suites, or separately, according to IESG discretion. What is the market motivation for anyone to pursue this classification? Note that the world lives on Proposed Standard now. Though we might want to change the meaning of the term, so that it carries less import, but we have no assurance that the market will notice or respond to that change. What about using existing language for Proposed, but adding the interoperability requirement, and changing the enforcement back to "no known bugs" rather than "no known bugs and contains full system features". And for Full, simply require only: 1) substantial deployment and use, and 2) the specification accurately documents what is deployed. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue Jun 10 17:26:02 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18768 for ; Tue, 10 Jun 2003 17:25:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6F37E6230F; Tue, 10 Jun 2003 23:25:27 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8F4AC6230A for ; Tue, 10 Jun 2003 23:25:16 +0200 (CEST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) h5ALPDPM019177 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 10 Jun 2003 14:25:14 -0700 (PDT) Received: from [205.214.163.73] (vpn-10-50-0-27.qualcomm.com [10.50.0.27]) h5ALOjsh009778 for ; Tue, 10 Jun 2003 14:24:54 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: Date: Tue, 10 Jun 2003 14:14:42 -0700 To: problem-statement@alvestrand.no From: hardie@qualcomm.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Fwd: Document categories X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Howdy, I've sent the draft included below to the drafts editor, but since Charlie just brought the issue up again, I thought I would go ahead and send it along. I think the question to the group is: do these categories map the ideas _underlying_ our current document series? if so, do the current methods of marking the document series reflect these categories well enough a) for IETF participants b) for those using IETF output? If not, what are the categories underlying the document series? I agree with Charlie that this might not be the best place to discuss this issue, but I'm not sure where else to take the discussion. If the chairs wish to ask that it move elsewhere, I will comply. Also, to reinforce a point made in the draft, the names used for these categories (both informal and formal) avoid the term RFC not because I am trying to comment on the RFC series, but because I want to get at the categories below the surface. regards, Ted Hardie Network Working Group T. Hardie Internet-Draft Qualcomm, Inc. June 2003 A proposal describing categories of IETF documents: unbaked, baking, baked, eaten, and boiled. draft-hardie-category-descriptions-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Over time, the document series associated with the IETF has grown and changed. One such change is the increase in the use of secondary markers to identify when documents fit specific categories and, especially, when they are or are not the product of specific IETF processes. The author believes that these secondary markers have largely failed but that the distinctions they were meant to draw remain valuable. A new set of category labels is proposed to re-emphasize these distinctions. The formal categories proposed are Internet Note, Candidate Specification, Proposed IETF Standard, Confirmed IETF Standard, and External Internet Engineering Document. These may be informally understood as ideas which are unbaked, baking, baked, eaten, and boiled. 1. Introduction. In recent discussions of reform in the IETF, a consensus seems to be emerging that the fundamental categories used by long time IETF participants to understand the document series remain valuable, but that the indicators used to delineate those categories have ceased to be sufficient as markers for those outside the process. To test that consensus, the author has put together this very flammable straw proposal to determine whether there is agreement on the categories underneath today's terms. A set of entirely disposable formal names is also proposed, for the benefit of those who would otherwise feel hungry when entering the discussion. Note that the term RFC is not used in either the formal or informal names; this does not imply anything about the author's view of the RFC series, but reflects the authors attempt to get at the categories underlying the current series. 2. Unbaked/Internet Note. The community needs a document series which has a very low barrier to entry and which can be used to float ideas, make proposals, comment on existing specifications, or carry on a public dialog on some topic of interest to the community. This function is currently carried out in the Internet Drafts series, with a common secondary marker of draft-. 3. Baking/Candidate Specification. The community needs a document series for those items which it has taken on as candidates for IETF specifications. These documents might be the product of working groups or they might be the product of some other IETF standards process. This function is currently carried out in the Internet Drafts series, commonly using a a secondary marker of draft-ietf, draft-iab, or draft-irtf. The author personally believes that making Candidate Specifications archival would be valuable for the community, as it would increase the ability of engineers working on related problems to identify work already attempted within the IETF and would eliminate the temptation to publish imperfect work through other channels in order to retain a record of it. 4. Baked/Proposed IETF Standard. The community needs a category to identify those specifications which it believes are reasonably complete. Documents in this category would still be subject to update or abandonment if experience with implementation or deployment showed flaws in the original design or specification. Nominally, this maps to current standards track documents, with a secondary marker of "Proposed Standard". In practice, the bar for the current category has been raised through experience that specifications rarely move beyond it, which has created a self-fulfilling prophecy for later documents advancing. In the author's opinion, supporting documents for specifications (e.g. requirements documents) and documents describing best current practices belong in this category, as the community considers them "baked" when published. 5. Eaten/Confirmed IETF Standard. The informal name for this category derives from the phrase "eating one's own dog food" which means to use one's own product. Substantively, it means that the community has used this specification and found it good. This maps onto the current standards track with secondary markers of "Draft Standard" and "Full standard". The author personally believes that the collapse of those categories to a single category is appropriate and in line with the emerging consensus. 6. Boiled/External Internet Engineering Document. The community needs an archival document series for technically reviewed documents which relate to the work of Internet engineering but do not fit into the current set of IETF standards. These documents might describe proposed experiments, indicate the results of experiments conducted, describe alternate views of engineering trade-offs made by a working group or other IETF standards process, contain reflections on existing protocols, or, indeed, take on any other task within the broader discipline of Internet Engineering. This category maps broadly onto the current "Informational" and "Experimental" categories of RFCs, with the caveat that some documents currently using those markers are actually supporting documents for the standards in the categories "baked" or "eaten". 7. Conclusions. The author does not know when to let go of a metaphor. Other than that, this document is not meant to draw conclusions, but to elicit comments on whether there is a broader agreement on the underlying categories currently understood by the IETF community. 8. IANA Considerations. There are no IANA actions described in this document. 9. Security Considerations. Were the community to change formal category names for its document series, it would need to ensure that this did not create an opportunity for a generalized "downgrade attack", through confusion over the new categories. 10. Normative References Bradner, Scott. "Internet Standards Process -- Revision 3". RFC2026. 11. Non-Normative References None. 12. Acknowledgements. Leslie Daigle supplied the original "baked, unbaked, baking, and boiled" formulation, which the author then augmented and beat to death. 13. Authors' Addresses Ted Hardie Qualcomm, Inc. 675 Campbell Technology Parkway Suite 200 Campbell, CA U.S.A. EMail: hardie@qualcomm.com Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. From problem-statement-bounces@alvestrand.no Tue Jun 10 17:40:45 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19181 for ; Tue, 10 Jun 2003 17:40:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E237D6230F; Tue, 10 Jun 2003 23:40:15 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2AB236230A for ; Tue, 10 Jun 2003 23:40:08 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19PqqW-000DmZ-00; Tue, 10 Jun 2003 16:40:00 -0500 Date: Tue, 10 Jun 2003 17:40:00 -0400 From: John C Klensin To: "Charles E. Perkins" Message-ID: <112105869.1055266800@p3.JCK.COM> In-Reply-To: <3EE61A65.B8EF9E8A@iprg.nokia.com> References: <3EE5E81A.7060704@iprg.nokia.com> <86204445.1055240898@p3.JCK.COM> <3EE61A65.B8EF9E8A@iprg.nokia.com> X-Mailer: Mulberry/3.0.3 (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: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On Tuesday, 10 June, 2003 10:50 -0700 "Charles E. Perkins" wrote: > I think your reformulation will help to refine the problem. > Comments below. > > John C Klensin wrote: > >> .......... I think there is >> another, balancing, problem. Perhaps there are differences by >> area or topic, but I think it would be equally accurate to >> say: >> >> -- The IESG has tended to approve simple component >> protocol specifications without an adequate >> understanding of the systems and contexts in which >> those protocols will be used. If vendors or users >> adopt the protocols without adequate consideration of >>... >> There is obviously a balance that should be found and kept >> here. > > Exactly. This is an engineering problem, not a mathematical > problem, and I have tried to emphasize the need for balance. > > Your suggested solution (eek! solution space!) Sorry. Too much experience/context in optimization-related techniques, which were, in my experience, engineering tools and disciplines (see below). > seems workable > to me, but notably it does NOT imply that the partcular > contexts are codified as necessary parts of the base > specification. Indeed, once again we may be asked to upgrade > the "applicability" part of the specfication. This should be > understood as a _possible_ application of the protocol, and > not the _only_ application of the protocol. Absolutely. But that formulation, which I think is the correct one, suggests that we ought to be prepared to update statements about applicability (or lack thereof) as often, or more often, than we update the protocols themselves. >> Slogans like "complete systems only" and "small components >> only" are unlikely to lead us to progress, quality, or >> understanding. > > One person's "slogan" is another person's "engineering > guideline". I do not believe that understanding good > engineering guidelines is a hindrance. Perhaps you meant to > suggest that no such guidelines are immutable, but have to > reflect current practice and understanding. I can accept that definition. Part of the tension I'm feeling is that I heard what was, for me, a wonderful definition of "the engineering discipline" many years ago, and it featured "tinkering" as the key element. "Tinkering"-based definitions are entirely consistent with "smaller pieces" models and incremental development of many sorts. The author believed that, if a problem had a single possible solution that could be derived uniquely from well-established (or provable) principles, it might be "science" or "mathematics", but it wasn't engineering. Engineering problems, in that view, were characterized by collections of goals and constraints and the processed used to find a solution that was a reasonable match to them (with "economics" and "how long do we really have to do this, and how much does more time 'cost'?" typically being part of the constraint set). The difficulty is that, while many of those same issues apply to standardization processes, they are intrinsically a bit different. In some ways, standardization is about determining a constraint set --or part of it-- against which engineering can occur. If that wasn't the case, we wouldn't need to worry as much about interoperable implementations, because only one narrowly-defined class of implementation solutions would be possible for a given standard. So, in writing a standard, we need to determine how to define an acceptable solution, at least partially in terms of the constraints on it. That is a bit different from "engineering problem" and even more different from "engineering solution". And I think we need to keep the differences and similarities clear, lest we accidentally go too far in one direction or the other and find ourselves hamstrung. > I am suggesting that the current trend towards demanding > complete system specifications is itself a mighty hindrance. And we agree about that as well. regards, john From problem-statement-bounces@alvestrand.no Tue Jun 10 17:42:06 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19336 for ; Tue, 10 Jun 2003 17:42:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 05EC162571; Tue, 10 Jun 2003 23:41:37 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7719E6230A; Tue, 10 Jun 2003 23:41:33 +0200 (CEST) Date: Tue, 10 Jun 2003 23:41:33 +0200 From: Harald Tveit Alvestrand To: "Charles E. Perkins" , problem-statement@alvestrand.no Message-ID: <29120000.1055281293@askvoll.hjemme.alvestrand.no> In-Reply-To: <3EE626EF.53ED7487@iprg.nokia.com> References: <3EE626EF.53ED7487@iprg.nokia.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: Two document stages: Proposed and Full X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 actually think it might be useful to have a couple of people draft their thoughts about specific classification schemes/thoughts (as Ted has done) and kick the specifics around on the solutions mailing list.... the problem that there's a mismatch between our nomenclature and the needs of the community has been well discussed, and just needs to be wordsmithed - the specifics on how we solve it is a separable issue.... Harald --On tirsdag, juni 10, 2003 11:43:59 -0700 "Charles E. Perkins" wrote: > > Hello folks, > > I think this has been suggested before. I'd like to > suggest it again. Maybe we can get some mileage out of > having two stages of standardization: > > Proposed Standard: requires working group approval. IESG comments > taken into account, but full IESG approval not needed before > publication. Interoperability testing completed, no known > flaws that present danger to the Internet. Component protocols > are O.K., as long as applicability (usefulness) is documented. > > Full Standard: Full IESG approval required, according to current > procedures. Component protocols published as part of > document suites, or separately, according to IESG discretion. > > Since the IESG still controls charters and chair selection, one may > presume that generally sensible people will be involved. In this > model, for instance, a working group might publish a component > protocol, and another working group with more relevant expertise > might publish another associated component protocol that could fit > together into a larger system. > > Maybe this is too much "solution space" -- if so, I'll try to > bring it up whenever I can find that forum. It's gotta be > around here somewhere. > > Regards, > Charlie P. > From problem-statement-bounces@alvestrand.no Tue Jun 10 17:51:46 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19480 for ; Tue, 10 Jun 2003 17:51:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 424A16233E; Tue, 10 Jun 2003 23:51:14 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 35AB06230A for ; Tue, 10 Jun 2003 23:50:34 +0200 (CEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA27022; Tue, 10 Jun 2003 14:50:31 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5ALoVa16598; Tue, 10 Jun 2003 14:50:31 -0700 X-mProtect: <200306102150> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdPIkPfn; Tue, 10 Jun 2003 14:50:29 PDT Message-ID: <3EE652A5.FBF09738@iprg.nokia.com> Date: Tue, 10 Jun 2003 14:50:29 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Dave Crocker References: <3EE626EF.53ED7487@iprg.nokia.com> <13517324551.20030610141458@brandenburg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Two document stages: Proposed and Full X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hello Dave, Dave Crocker wrote: > One thought on component-vs-system is that we might want to make that > distinction more explicitly and even formally, making it relatively easy > to do component specifications, but still difficult to do system > specifications. I'm not exactly sure why it has to be difficult to do system specifications, even though it's bound to be more complicated than simple component protocols. For the cases I had in mind, it would be more the case that vendors could expect to get a pretty full set of instructions on how to build the systems they wanted to build, at least from the networking standpoint. APIs and so on would still have to be done separately. The difference would be that a vendor using only a component protocol would be left somewhat to their own devices when it comes to filling in the missing pieces. > With respect to your suggestion on standards classifications: > > CEP> Proposed Standard: requires working group approval. IESG comments > CEP> taken into account, but full IESG approval not needed before > CEP> publication. Interoperability testing completed, no known > CEP> flaws that present danger to the Internet. Component protocols > CEP> are O.K., as long as applicability (usefulness) is documented. > > This is rather interesting. Most Proposed specs, today, are not > required to demonstrate interoperability, whereas Draft is. I think that's a mistake. I'd rather have it that Proposed Standard requires interoperability. Do you happen to know when the interoperability requirement was relaxed? > The question is whether the working group's reliably exert enough > quality control on their output. For all that one might express > legitimate concern about IESG push-back, there is also a legitimate > concern about some working groups that produce poor work. I don't imagine that the ADs will suddenly stop paying attention to the working groups in their area. Their contribution to the discussion would be valued. If something is going horribly wrong and the working group is on the road to perdition, then maybe a process of dechartering could be initiated before publication of the offending document. I don't think this would happen, though. Furthermore, it is conceivable even that working groups would take more pride in their work if their documents had to stand on their own merits before ever getting to full IESG consideration. I'm sure that is debatable, but maybe we ought to at least try to change things for the better. I think if working groups are indeed producing poor work, then it's better to recharter or disband instead of haggling over ill-fated documents. But, again, work with limited scope, or even incomplete work, is not necessarily poor quality work. > CEP> Full Standard: Full IESG approval required, according to current > CEP> procedures. Component protocols published as part of > CEP> document suites, or separately, according to IESG discretion. > > What is the market motivation for anyone to pursue this classification? I'm projecting here, but the motivation would be that building to the full protocol suite is more guaranteed to not have any missing features (from the networking perspective). > Note that the world lives on Proposed Standard now. Though we might > want to change the meaning of the term, so that it carries less import, > but we have no assurance that the market will notice or respond to that > change. Assurances about the market seem scarce as hens' teeth. > What about using existing language for Proposed, but adding the > interoperability requirement, and changing the enforcement back to "no > known bugs" rather than "no known bugs and contains full system > features". This would be a good subject for discussion when we get to solution space. I honestly don't know. I thought that working group approval would galvanize the interest, and free up the IESG for focussing on the more global aspects of promulgating full standards, reducing their workload. They might again become more functional working group members, and in this their experience would be very, very useful. Regards, Charlie P. From problem-statement-bounces@alvestrand.no Tue Jun 10 18:51:04 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21871 for ; Tue, 10 Jun 2003 18:51:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DE3D56233E; Wed, 11 Jun 2003 00:50:34 +0200 (CEST) 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 EDC9A6230F for ; Wed, 11 Jun 2003 00:50:31 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h5AMrXF32547; Tue, 10 Jun 2003 15:53:33 -0700 Date: Tue, 10 Jun 2003 15:49:03 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/10) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <15022969338.20030610154903@brandenburg.com> To: "Charles E. Perkins" In-Reply-To: <3EE652A5.FBF09738@iprg.nokia.com> References: <3EE626EF.53ED7487@iprg.nokia.com> <3EE652A5.FBF09738@iprg.nokia.com> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Two document stages: Proposed and Full X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Charles, (Harald's request the this solution discussion be moved to the solutions list is duly noted. So the reply on this list is non-solution related.) CEP> I think that's a mistake. I'd rather have it that Proposed Standard CEP> requires interoperability. Do you happen to know when the interoperability CEP> requirement was relaxed? It was never 'relaxed'. When Proposed/Draft were first defined, Draft called for interoperability and Proposed mostly did not. The "mostly" is the interesting part. The language I recall for requiring interoperability at Proposed was something like: The specification pertains to essential (ie, fragile) Internet infrastructure, or the specification is sufficient complex (ie, its physic are poorly understand) so that an interoperability demonstration is needed to provide a degree of comfort about basic viability and/or safety of the specification. For most specification, we rely on a static review of the document, to convince us that we understand how it behave and that it will not damage the infrastucture. When we can't develop that code just from reading, we require implementation. A separate point that Marshall Rose has been good at pointing out is, essentially, a marketing issue for a specification: If it's been implemented, it is much more difficult for people to make abstract claims about failings of the spec. Hence it is more difficult to reject a request for Proposed status. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue Jun 10 19:05:11 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22155 for ; Tue, 10 Jun 2003 19:05:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B34346233E; Wed, 11 Jun 2003 01:04:41 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 922CC6230F for ; Wed, 11 Jun 2003 01:04:36 +0200 (CEST) Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5AN4WLU017416 for ; Tue, 10 Jun 2003 19:04:32 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-349.cisco.com [10.82.225.93]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id TAA17544 for ; Tue, 10 Jun 2003 19:04:31 -0400 (EDT) Message-Id: <4.3.2.7.2.20030610190009.02052490@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Jun 2003 19:04:25 -0400 To: problem-statement@alvestrand.no From: Ralph Droms In-Reply-To: <15022969338.20030610154903@brandenburg.com> References: <3EE652A5.FBF09738@iprg.nokia.com> <3EE626EF.53ED7487@iprg.nokia.com> <3EE652A5.FBF09738@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Two document stages: Proposed and Full X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 At 03:49 PM 6/10/2003 -0700, Dave Crocker wrote: >[...] >A separate point that Marshall Rose has been good at pointing out is, >essentially, a marketing issue for a specification: If it's been >implemented, it is much more difficult for people to make abstract >claims about failings of the spec. Hence it is more difficult to reject >a request for Proposed status. I agree, and I wrote earlier: My recent experience with specifications in the dhc WG has been that "running (prototype) code" trumps (potentially ad infinitum) speculative discussion about whether the protocol is correct and completely specified. Running code can't, of course, address *every* claim about the failing of a spec. But it does rule out a lot of claims... So, it seems we need some way to allow and enforce implementation experience. - Ralph From problem-statement-bounces@alvestrand.no Tue Jun 10 19:58:19 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23253 for ; Tue, 10 Jun 2003 19:58:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DBD4D6233E; Wed, 11 Jun 2003 01:57:44 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1D9926220B for ; Wed, 11 Jun 2003 01:57:41 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19Pszk-000Hpb-00; Tue, 10 Jun 2003 23:57:40 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19Psmp-0006eP-NX; Wed, 11 Jun 2003 08:44:19 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 11 Jun 2003 08:44:19 +0900 To: Dave Crocker References: <3EE626EF.53ED7487@iprg.nokia.com> <3EE652A5.FBF09738@iprg.nokia.com> <15022969338.20030610154903@brandenburg.com> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: Two document stages: Proposed and Full X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > A separate point that Marshall Rose has been good at pointing out is, > essentially, a marketing issue for a specification: If it's been > implemented, it is much more difficult for people to make abstract > claims about failings of the spec. [ aside from that it is always easy to raise abstract claims, but can be hard to substantiate them ] if and only if it has multiple, separately developed from only the spec, interoperable implementations. there are a fair number of critical protocols where one could not really do an implementation from the spec, and it required 'inside knowledge' and this was used, let's be kind and say unintentionally, to raise a bar against new market entries. randy From problem-statement-bounces@alvestrand.no Tue Jun 10 20:34:46 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24348 for ; Tue, 10 Jun 2003 20:34:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0B21B6230A; Wed, 11 Jun 2003 02:34:15 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1220F6220B for ; Wed, 11 Jun 2003 02:34:08 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h5B0Y0k29962; Tue, 10 Jun 2003 20:34:02 -0400 (EDT) Date: Tue, 10 Jun 2003 20:34:00 -0400 From: Keith Moore To: "Charles E. Perkins" Message-Id: <20030610203400.33c9d959.moore@cs.utk.edu> In-Reply-To: <3EE626EF.53ED7487@iprg.nokia.com> References: <3EE626EF.53ED7487@iprg.nokia.com> X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Subject: Re: Two document stages: Proposed and Full X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > Maybe we can get some mileage out of > having two stages of standardization: can we please avoid discussion of solutions? it's not in scope for this group. it's one thing to offer a strawman solution to help people understand the problem description you are proposing, but we shouldn't dig in. because I really want to tear into this half-baked proposal, but this is not the place to do so, and silence should not be taken as consent. fair is fair. please withdraw the proposal until we can fight over if fairly. From problem-statement-bounces@alvestrand.no Tue Jun 10 23:45:00 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28198 for ; Tue, 10 Jun 2003 23:44:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1C4C56230F; Wed, 11 Jun 2003 05:44:29 +0200 (CEST) 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 2A9036230A for ; Wed, 11 Jun 2003 05:44:26 +0200 (CEST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])h5B3iP927275 for ; Wed, 11 Jun 2003 06:44:25 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com ; Wed, 11 Jun 2003 06:44:25 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 11 Jun 2003 06:44:24 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 11 Jun 2003 06:44:24 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 11 Jun 2003 06:44:23 +0300 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" Date: Wed, 11 Jun 2003 06:44:22 +0300 Message-ID: Thread-Topic: Wording of Engineering Processes Problem Thread-Index: AcMvZ5GyxdTpiK5zR8KQMIMR4tfGfgAY9THA From: To: X-OriginalArrivalTime: 11 Jun 2003 03:44:23.0620 (UTC) FILETIME=[BF9E6040:01C32FCB] Cc: mrw@windriver.com Cc: problem-statement@alvestrand.no Subject: RE: Wording of Engineering Processes Problem X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA28198 Hi Eric, > > > Solutions to this problem might include: adoption of > > > quality processes, training, better review during document > > > production, flogging WG chairs who produce crap, etc. > > > > Or how about simple checks & balances? > > I don't think so. The main function of checks and balances in > most political systems is to stop things from getting done. Checks and balances are used to avoid a situation where one group asserts too strong of an influence over a situation. Well, one could call the IESG a check and NONCOM a balance, though there would be those who beg to differ, but that is not my point. > If we actually want to produce work that's good, I think we'll > have to orient ourselves more towards that goal. I agree. Looking at Margaret's list above, if taken to an extreme, the solution could be so heavy-weight that it becomes more important than the actual work itself. John From problem-statement-bounces@alvestrand.no Wed Jun 11 00:50:10 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29112 for ; Wed, 11 Jun 2003 00:50:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7B1DA6230F; Wed, 11 Jun 2003 06:49:40 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0D1DD6230A for ; Wed, 11 Jun 2003 06:49:37 +0200 (CEST) Received: by romeo.rtfm.com (Postfix, from userid 556) id C41BBABAF; Tue, 10 Jun 2003 21:55:47 -0700 (PDT) To: References: From: Eric Rescorla Date: 10 Jun 2003 21:55:47 -0700 In-Reply-To: Message-ID: Lines: 27 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mrw@windriver.com Cc: problem-statement@alvestrand.no Subject: Re: Wording of Engineering Processes Problem X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: EKR 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 writes: > Hi Eric, > > > > > Solutions to this problem might include: adoption of > > > > quality processes, training, better review during document > > > > production, flogging WG chairs who produce crap, etc. > > > > > > Or how about simple checks & balances? > > > > I don't think so. The main function of checks and balances in > > most political systems is to stop things from getting done. > > Checks and balances are used to avoid a situation where one > group asserts too strong of an influence over a situation. > Well, one could call the IESG a check and NONCOM a balance, > though there would be those who beg to differ, but that is not > my point. Agreed. All I meant was that usually when you have a check/balance situation, the check consists of the ability to block work. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From problem-statement-bounces@alvestrand.no Wed Jun 11 01:32:25 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29752 for ; Wed, 11 Jun 2003 01:32:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 76EC46233E; Wed, 11 Jun 2003 07:31:51 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by eikenes.alvestrand.no (Postfix) with ESMTP id DEF9A62207; Wed, 11 Jun 2003 07:31:47 +0200 (CEST) Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 11 Jun 2003 07:30:48 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) h5B5T2V0017199; Wed, 11 Jun 2003 07:29:47 +0200 (MET DST) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Jun 2003 07:31:40 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Jun 2003 07:31:40 +0200 Date: Wed, 11 Jun 2003 07:31:36 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Dave Crocker From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <7815354758.20030610134209@brandenburg.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 11 Jun 2003 05:31:40.0446 (UTC) FILETIME=[BC4413E0:01C32FDA] Cc: Randy Bush Cc: "problem-statement@alvestrand.no" Cc: John C Klensin Cc: Charlie Perkins Cc: Harald Tveit Alvestrand Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit The overall problem I think is that in general people in the IETF don't spend enough time reviewing documents and architectures. One small group of people which soooo much want something done, something which makes sense from their perspective write a draft, and "push it through the system". The only real pushing today which is needed is the creation of a working group. When the working group is created, the pushing is within the working group. Either we have an active wg chair which ensure review and proper document OR the small group keep pushing. When the wg is "ready" with the document (either the document is really ready, or the small group has pushed enough to make the wg chair tired) the document end up with IESG. What are the different paths to here? (from my perspective after being 5 years AD, 1998-2003): (1) The document is really good, as it should. (2) The small group of active people is still active. The wg chair was tired and no one in the wg except the small group has reviewed the document. The document in reality because of this comes to the IESG from the small group without any other review. (3) The small group ended up being so tired after pushing for the wg and pushing the wg chair that they faded away. The wg chair (maybe not even the same as from the beginning of the wg) has more with whip than carrot managed to get some other doc editor to finally produce the document. The document is quite good quality, but, the original idea is lost, and possibly the final document is not the bright idea as originally (and it is normally _very_ late). (4) The document never reach the IESG at all. During my years, I saw fewer and fewer documents in the (1) category. The only category where IESG can "rubberstamp" an I-D. As area director I didn't want anything else than just rubberstamp something. More and more drafts ended up in category (3). A few in (2). As (2) and (3) has to be treated so differently, it is hard as AD to find a good mechanism for how to work efficiently. Also, an increase of documents in the (2) and (3) category increases the workload of the AD. I feel Charlie talks about more category (2) documents be classified by the AD as (1). This means the AD should "trust" the wg doing a good job. This is exactly what the AD want as well, BUT, part from being the last line of defence against crap, the AD is also the one which decides whether proper review has actually happened. Personally, I looked for a few things to make the decision whether a document was (1) or (2). Simple things which is in the I-D Nits list. They include: - Do grep for the following strings "UTF-8", "Unicode", "Character", "ASII". If any of these are included, are they described correctly? - Check if normal domain names are used, or "example.com" style. etc... If the document fail on any of the above, the document is clearly a category (2) document. However I wanted it to be a category (1). Category (3) is the hardest though. A document finally arrives at the IESG. If the AD find some bugs, a message is sent back to the wg chair (and in some cases the wg). Nothing. A few weeks later, one might remember to ping the wg which in reality is in what I would call zombie state. Finally something comes back, and then the AD doesn't remember what happened, and the mental/thinking-process needs to restart. VERY expensive. When reading this list, I find _all_ people seems to think we should have more documents move from category (2) -> (1), and possibly more (3) -> (4). That will definitely decrease the workload of the AD, we get rid of boring crap (which possibly will not be used on the Internet anyway). The wg will get more power as the number of category (1) documents increase. BUT, it will be hard to get there. The reason why I as AD felt more documents ended up in (2) or (3) include: - I found more and more documents with bugs which could have been fixed by doc editor just by reading I-D Nits (see above) - I almost _never_ got any reaction what so ever (positive or negative) on IETF Last Call In this situation, and being the last line of defence, I feel I have to do a more detailed review. I feel I can not, however I would like to, trust the wg. At the same time, this leads to the AD being questioned doing micro-management, requiring too much from the document, etc etc which I see between the lines in what many have said. And, I really understand this complaint. I really do. Really really really! I feel the meta-question is how to start turning the wheel the other way around. How do we make sure the wg produce documents which can be rubberstamped by the AD, documents which are not crap? How do we make wg's produce better documents? How do we make sure Last Call is happening? I state it this way because I don't think the problem is what level of quality IETF in the current process require. I think the problem is really that we don't know where it is evaluated whether the document has reached this level. Whatever the level is. Many many people agree it is better if this review happen early in the process. How? How do we know it has happened? I know the only way to convince an AD that it has happened is to give documents to IESG which does NOT fail any of the things in the I-D nits document. Claiming it has got review, and then failing I-D nits is not good. At the same time, having an AD late in the process require changes is not good either? It polarises things. It ends up being a "we" and "them". Not good. We have the timeline in the wg charters. Maybe what we need is an objective way of forcing documents through the process. We create real steps the doc have to go through, and each step has a deadline. If the deadline is not met -- start from the beginning again. The deadlines are set by the wg like today. That way we at least remove all category (3) documents from the IESG load, but we might also be able to "force" the wg to do more proper review? It might be easier for both a wg chair and AD to "just say no" and then spend time on things which need real help, like synchronisation across areas _during_ the creation of a document and not after. I don't know. But, I definitely think we need to talk more carefully about where the review is done, and how we make sure it is done. As AD, I found it very very hard in problematic wg's to both review process and document quality. Very often these two roles are fighting each other. paf From problem-statement-bounces@alvestrand.no Wed Jun 11 04:12:49 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29127 for ; Wed, 11 Jun 2003 04:12:48 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 83E266233E; Wed, 11 Jun 2003 10:12:17 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from agitator.ibr.cs.tu-bs.de (agitator.ibr.cs.tu-bs.de [134.169.34.18]) by eikenes.alvestrand.no (Postfix) with ESMTP id 789296230A for ; Wed, 11 Jun 2003 10:12:04 +0200 (CEST) Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) h5B8C2gB027787 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 11 Jun 2003 10:12:02 +0200 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) h5B8C1ru027847; Wed, 11 Jun 2003 10:12:01 +0200 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) id h5B8C1Ko027844; Wed, 11 Jun 2003 10:12:01 +0200 Date: Wed, 11 Jun 2003 10:12:01 +0200 Message-Id: <200306110812.h5B8C1Ko027844@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: paf@cisco.com In-reply-to: (message from =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= on Wed, 11 Jun 2003 07:31:36 +0200) References: X-IBRFilter-SpamReport: -9.9 () IN_REP_TO,REFERENCES X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Cc: problem-statement@alvestrand.no Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 >>>>> =?ISO-8859-1?Q?Patrik F=E4ltstr=F6m?= writes: [...] Thanks for your note - I appreciate it. Patrik> But, I definitely think we need to talk more carefully about Patrik> where the review is done, and how we make sure it is done. Serious document reviews take time (a) for the review itself plus (b) for the followup discussions (and in my experience b >> a). The only reward for such a time investment is (perhaps) being mentioned in the acknowledgements section. To achieve more and better reviews, we simply have to make it more attractive for people to spend their time on serious reviews. [I am repeating this statement here, which I have made in the past, because I feel that the importance of this is still overlooked.] /js -- Juergen Schoenwaelder International University Bremen Phone: +49 421 200 3587 P.O. Box 750 561, 28725 Bremen, Germany Fax: +49 421 200 3103 From problem-statement-bounces@alvestrand.no Wed Jun 11 05:09:47 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00035 for ; Wed, 11 Jun 2003 05:09:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 095CD6233E; Wed, 11 Jun 2003 11:09:18 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by eikenes.alvestrand.no (Postfix) with ESMTP id 83C4F6230A for ; Wed, 11 Jun 2003 11:09:14 +0200 (CEST) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196])h5B990Ie051526 for ; Wed, 11 Jun 2003 11:09:05 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h5B97XD3232638 for ; Wed, 11 Jun 2003 11:07:33 +0200 Received: from dhcp222-56.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA67170 from ; Wed, 11 Jun 2003 11:07:32 +0200 Message-Id: <3EE6F16B.E647AC3D@hursley.ibm.com> Date: Wed, 11 Jun 2003 11:07:55 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: problem-statement@alvestrand.no References: <3EE626EF.53ED7487@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Two document stages: Proposed and Full X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Problem related comment: We have ample evidence that WGs don't consistently produce documents that meet even today's criteria for PS. I am strongly against giving WGs the ability to approve PSs without enforced peer review that is specifically independent of the WG and specifically consider IETF-wide and Internet-wide issues. This proposal would only make the problem worse than today, by allowing WGs to ignore peer review. Brian "Charles E. Perkins" wrote: > > Hello folks, > > I think this has been suggested before. I'd like to > suggest it again. Maybe we can get some mileage out of > having two stages of standardization: > > Proposed Standard: requires working group approval. IESG comments > taken into account, but full IESG approval not needed before > publication. Interoperability testing completed, no known > flaws that present danger to the Internet. Component protocols > are O.K., as long as applicability (usefulness) is documented. > > Full Standard: Full IESG approval required, according to current > procedures. Component protocols published as part of > document suites, or separately, according to IESG discretion. > > Since the IESG still controls charters and chair selection, one may > presume that generally sensible people will be involved. In this > model, for instance, a working group might publish a component > protocol, and another working group with more relevant expertise > might publish another associated component protocol that could fit > together into a larger system. > > Maybe this is too much "solution space" -- if so, I'll try to > bring it up whenever I can find that forum. It's gotta be > around here somewhere. > > Regards, > Charlie P. From problem-statement-bounces@alvestrand.no Wed Jun 11 05:16:29 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00136 for ; Wed, 11 Jun 2003 05:16:29 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6414F62581; Wed, 11 Jun 2003 11:15:59 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2A86B6230A for ; Wed, 11 Jun 2003 11:15:50 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180])h5B9FfIe058986 for ; Wed, 11 Jun 2003 11:15:43 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h5B9FWlf169536 for ; Wed, 11 Jun 2003 11:15:32 +0200 Received: from dhcp222-56.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA58082 from ; Wed, 11 Jun 2003 11:15:31 +0200 Message-Id: <3EE6F349.A5B7B231@hursley.ibm.com> Date: Wed, 11 Jun 2003 11:15:53 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: problem-statement@alvestrand.no References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Fwd: Document categories X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Well, I think we have the problem that we don't really know the difference between baked, eaten and boiled in enough detail to be operationally useful. The running code proof of that is that most specs stay at 'baked' status. I'm not allowed to mention on this list that my preferred solution is to abolish the distinction between them, as being useless in practice. Brian hardie@qualcomm.com wrote: > > Howdy, > I've sent the draft included below to the drafts > editor, but since Charlie just brought the issue up again, > I thought I would go ahead and send it along. I think > the question to the group is: do these categories map > the ideas _underlying_ our current document series? > if so, do the current methods of marking the document > series reflect these categories well enough a) for > IETF participants b) for those using IETF output? > If not, what are the categories underlying the document > series? > I agree with Charlie that this might not be > the best place to discuss this issue, but I'm not sure > where else to take the discussion. If the chairs wish > to ask that it move elsewhere, I will comply. > Also, to reinforce a point made in the draft, > the names used for these categories (both informal > and formal) avoid the term RFC not because I am trying > to comment on the RFC series, but because I want to > get at the categories below the surface. > regards, > Ted Hardie > From problem-statement-bounces@alvestrand.no Wed Jun 11 05:24:44 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00307 for ; Wed, 11 Jun 2003 05:24:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A438C62598; Wed, 11 Jun 2003 11:24:14 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from netcore.fi (netcore.fi [193.94.160.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 73A5C6230A for ; Wed, 11 Jun 2003 11:24:03 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h5B9NrJ31346; Wed, 11 Jun 2003 12:23:53 +0300 Date: Wed, 11 Jun 2003 12:23:53 +0300 (EEST) From: Pekka Savola To: Juergen Schoenwaelder In-Reply-To: <200306110812.h5B8C1Ko027844@hansa.ibr.cs.tu-bs.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: problem-statement@alvestrand.no Cc: paf@cisco.com Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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, 11 Jun 2003, Juergen Schoenwaelder wrote: > >>>>> =?ISO-8859-1?Q?Patrik F=E4ltstr=F6m?= writes: > > [...] > > Thanks for your note - I appreciate it. Also totally agree; very well written note, and one I agree with :-). > Patrik> But, I definitely think we need to talk more carefully about > Patrik> where the review is done, and how we make sure it is done. > > Serious document reviews take time (a) for the review itself plus (b) > for the followup discussions (and in my experience b >> a). The only > reward for such a time investment is (perhaps) being mentioned in the > acknowledgements section. > > To achieve more and better reviews, we simply have to make it more > attractive for people to spend their time on serious reviews. I agree. My experience is that even if you very detailed reviews, people don't always acknowledge you. Many don't even have the acknowledgements sections in the drafts. -- 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 Wed Jun 11 05:29:12 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00362 for ; Wed, 11 Jun 2003 05:29:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 138FE62594; Wed, 11 Jun 2003 11:28:42 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by eikenes.alvestrand.no (Postfix) with ESMTP id 320FC6230A for ; Wed, 11 Jun 2003 11:28:34 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180])h5B9SLsn046030 for ; Wed, 11 Jun 2003 11:28:24 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h5B9Ralf221952 for ; Wed, 11 Jun 2003 11:27:36 +0200 Received: from dhcp222-56.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA20184 from ; Wed, 11 Jun 2003 11:27:35 +0200 Message-Id: <3EE6F61D.FB8ADAE8@hursley.ibm.com> Date: Wed, 11 Jun 2003 11:27:57 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: problem-statement@alvestrand.no References: <200306110812.h5B8C1Ko027844@hansa.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 And see http://graybeards.net/sirs/ for the prototype solutions effort. Brian Juergen Schoenwaelder wrote: > > >>>>> =?ISO-8859-1?Q?Patrik F=E4ltstr=F6m?= writes: > > [...] > > Thanks for your note - I appreciate it. > > Patrik> But, I definitely think we need to talk more carefully about > Patrik> where the review is done, and how we make sure it is done. > > Serious document reviews take time (a) for the review itself plus (b) > for the followup discussions (and in my experience b >> a). The only > reward for such a time investment is (perhaps) being mentioned in the > acknowledgements section. > > To achieve more and better reviews, we simply have to make it more > attractive for people to spend their time on serious reviews. > > [I am repeating this statement here, which I have made in the past, > because I feel that the importance of this is still overlooked.] > > /js > > -- > Juergen Schoenwaelder International University Bremen > Phone: +49 421 200 3587 P.O. Box 750 561, 28725 Bremen, Germany > Fax: +49 421 200 3103 From problem-statement-bounces@alvestrand.no Wed Jun 11 08:41:09 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06338 for ; Wed, 11 Jun 2003 08:41:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B366E6230A; Wed, 11 Jun 2003 14:40:37 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5964E62251 for ; Wed, 11 Jun 2003 14:40:34 +0200 (CEST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5BCeVVI012816; Wed, 11 Jun 2003 14:40:31 +0200 (CEST) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 9FFE696498; Wed, 11 Jun 2003 14:27:21 +0200 (CEST) Date: Wed, 11 Jun 2003 14:40:33 +0200 From: Marcus Brunner To: Brian E Carpenter , problem-statement@alvestrand.no Message-ID: <16565640.1055342433@[10.1.1.130]> In-Reply-To: <3EE6F16B.E647AC3D@hursley.ibm.com> References: <3EE626EF.53ED7487@iprg.nokia.com> <3EE6F16B.E647AC3D@hursley.ibm.com> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: Two document stages: Proposed and Full X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Marcus Brunner List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Brian, If we accept that the core value is ".. and running code" the document and how it is written does not really matter. Peer review is naturally very useful for the final spec, but do we need it before we have implementation experience? The problem is the crap sitting in PS and being happy with this. (Which from a marketing perspective is enough, getting and market products with RFC numbers) Marcus --On Mittwoch, 11. Juni 2003 11:07 +0200 Brian E Carpenter wrote: > Problem related comment: > > We have ample evidence that WGs don't consistently produce > documents that meet even today's criteria for PS. I am strongly > against giving WGs the ability to approve PSs without enforced peer > review that is specifically independent of the WG and specifically > consider IETF-wide and Internet-wide issues. This proposal would > only make the problem worse than today, by allowing WGs to ignore > peer review. > > Brian > > "Charles E. Perkins" wrote: >> >> Hello folks, >> >> I think this has been suggested before. I'd like to >> suggest it again. Maybe we can get some mileage out of >> having two stages of standardization: >> >> Proposed Standard: requires working group approval. IESG comments >> taken into account, but full IESG approval not needed before >> publication. Interoperability testing completed, no known >> flaws that present danger to the Internet. Component protocols >> are O.K., as long as applicability (usefulness) is documented. >> >> Full Standard: Full IESG approval required, according to current >> procedures. Component protocols published as part of >> document suites, or separately, according to IESG discretion. >> >> Since the IESG still controls charters and chair selection, one may >> presume that generally sensible people will be involved. In this >> model, for instance, a working group might publish a component >> protocol, and another working group with more relevant expertise >> might publish another associated component protocol that could fit >> together into a larger system. >> >> Maybe this is too much "solution space" -- if so, I'll try to >> bring it up whenever I can find that forum. It's gotta be >> around here somewhere. >> >> Regards, >> Charlie P. From problem-statement-bounces@alvestrand.no Wed Jun 11 09:01:38 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07340 for ; Wed, 11 Jun 2003 09:01:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1FBF56230A; Wed, 11 Jun 2003 15:01:08 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 541DD62251 for ; Wed, 11 Jun 2003 15:00:58 +0200 (CEST) Date: Wed, 11 Jun 2003 15:00:58 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <75920000.1055336458@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: MINOR ISSUE: Change focus from image to effectiveness X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Section 2.1 of -issue-, last paragraph, says: 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. Externally, the IETF is often placed in the same bracket as these conventional SDOs, especially by detractors, because the differentiation in the IETF's mission and processes and the rationale for those differences are not clear. This can lead to the IETF being shown in a poor light or communications between SDOs not being effective. ISSUE: This paragraph brings the IETF "being shown in a poor light" as a problem. This should not be a core problem. SUGGESTED RESOLUTION: Reformulate the last sentence to say that "This can lead to the IETF being misunderstood by other SDOs, which can make communication with other SDOs less effective, harming the IETF's ability to achieve its mission". From problem-statement-bounces@alvestrand.no Wed Jun 11 09:11:19 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07569 for ; Wed, 11 Jun 2003 09:11:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 654F16233E; Wed, 11 Jun 2003 15:10:48 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4F01262251 for ; Wed, 11 Jun 2003 15:10:42 +0200 (CEST) Date: Wed, 11 Jun 2003 15:10:42 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <76080000.1055337042@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ISSUE: Timeframes shold be focused on IETF purposes, not markets X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit The second of my 2 issues of the day - this may be slightly more controversial.... Section 2.2 of -issue- says: The frequent inability of the IETF to deliver specifications within the timeframe that the markets need and the excessive perfectionism that is exhibited in some cases could both be improved if appropriate Engineering Practices were in use. ISSUE: This sentence presupposes that the "timeframe the markets need" and the "appropriate quality" are relatively quantifiable quantities. I think they aren't. SUGGESTED RESOLUTION: Replace "the timeframe that the markets need" with "the timeframe in which IETF particpants think they are needed to further the mission of the IETF". I've got no particular bones to pick with the basic sentiment of the paragraph. But I think that the ratholes we can get into when debating what it means that the market "needs" something is even deeper than the ratholes we get into when we debate what the IETF participants think is needed. Let's keep it simple (when we can). From problem-statement-bounces@alvestrand.no Wed Jun 11 10:25:08 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11019 for ; Wed, 11 Jun 2003 10:25:06 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9DE566230A; Wed, 11 Jun 2003 16:24:31 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by eikenes.alvestrand.no (Postfix) with ESMTP id 79A2562251 for ; Wed, 11 Jun 2003 16:24:28 +0200 (CEST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5BEOPCL000370 for ; Wed, 11 Jun 2003 07:24:25 -0700 (PDT) Received: from cisco.com (sjc-vpn2-173.cisco.com [10.21.112.173]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AHB21239; Wed, 11 Jun 2003 07:21:52 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Wed, 11 Jun 2003 10:24:19 -0400 Date: Wed, 11 Jun 2003 10:24:19 -0400 From: Scott W Brim To: "problem-statement@alvestrand.no" Message-ID: <20030611142419.GI2592@sbrim-w2k01> Mail-Followup-To: Scott W Brim , "problem-statement@alvestrand.no" References: <7815354758.20030610134209@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4i Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit On Wed, Jun 11, 2003 07:31:36AM +0200, Patrik Fältström allegedly wrote: > The overall problem I think is that in general people in the IETF don't > spend enough time reviewing documents and architectures. One small > group of people which soooo much want something done, something which > makes sense from their perspective write a draft, and "push it through > the system". The only real pushing today which is needed is the > creation of a working group. \${leadsto} ... SIRS From problem-statement-bounces@alvestrand.no Wed Jun 11 10:26:31 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11081 for ; Wed, 11 Jun 2003 10:26:30 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 45C6D6230A; Wed, 11 Jun 2003 16:26:01 +0200 (CEST) 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 D049062251; Wed, 11 Jun 2003 16:25:47 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h5BESoF05861; Wed, 11 Jun 2003 07:28:50 -0700 Date: Wed, 11 Jun 2003 07:25:41 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/10) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <13079167146.20030611072541@brandenburg.com> To: Harald Tveit Alvestrand In-Reply-To: <76080000.1055337042@askvoll.hjemme.alvestrand.no> References: <76080000.1055337042@askvoll.hjemme.alvestrand.no> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: ISSUE: Timeframes shold be focused on IETF purposes, not markets X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Harald, The existing text is intended to precisely highlight the IETF's tendency to ignore its customers. Your suggested change eliminates that point entirely. While one might develop a logic chain that puts it back, one can easily instead develop a logic chain that says that the timeframe can whatever any particular IETF participant believes it should be. Hence, the direct reference to the needs of the market is the key point in this problem statement. d/ HTA> The frequent inability of the IETF to deliver specifications within HTA> the timeframe that the markets need and the excessive perfectionism HTA> that is exhibited in some cases could both be improved if appropriate HTA> Engineering Practices were in use. HTA> ISSUE: This sentence presupposes that the "timeframe the markets need" and HTA> the "appropriate quality" are relatively quantifiable quantities. I think HTA> they aren't. HTA> SUGGESTED RESOLUTION: Replace "the timeframe that the markets need" with HTA> "the timeframe in which IETF particpants think they are needed to further HTA> the mission of the IETF". d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Wed Jun 11 10:27:52 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11142 for ; Wed, 11 Jun 2003 10:27:52 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2DB0062581; Wed, 11 Jun 2003 16:27:22 +0200 (CEST) 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 A9E2E62251; Wed, 11 Jun 2003 16:27:18 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h5BEULF05957; Wed, 11 Jun 2003 07:30:21 -0700 Date: Wed, 11 Jun 2003 07:27:12 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/10) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <13379258227.20030611072712@brandenburg.com> To: Harald Tveit Alvestrand In-Reply-To: <75920000.1055336458@askvoll.hjemme.alvestrand.no> References: <75920000.1055336458@askvoll.hjemme.alvestrand.no> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: MINOR ISSUE: Change focus from image to effectiveness X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Harald, HTA> SUGGESTED RESOLUTION: Reformulate the last sentence to say that "This can HTA> lead to the IETF being misunderstood by other SDOs, which can make HTA> communication with other SDOs less effective, harming the IETF's ability to HTA> achieve its mission". yes. much better. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Wed Jun 11 10:46:11 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11962 for ; Wed, 11 Jun 2003 10:46:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C64B76230A; Wed, 11 Jun 2003 16:45:41 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 84E396220B; Wed, 11 Jun 2003 16:45:39 +0200 (CEST) Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5BEjZLU003504; Wed, 11 Jun 2003 10:45:36 -0400 (EDT) Message-Id: <200306111445.h5BEjZLU003504@rtp-core-1.cisco.com> To: Dave Crocker In-reply-to: Your message of Wed, 11 Jun 2003 07:25:41 -0700. <13079167146.20030611072541@brandenburg.com> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Wed, 11 Jun 2003 10:45:35 -0400 From: Eric Rosen Cc: Harald Tveit Alvestrand Cc: problem-statement@alvestrand.no Subject: Re: ISSUE: Timeframes shold be focused on IETF purposes, not markets X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: erosen@cisco.com 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 HTA> SUGGESTED RESOLUTION: Replace "the timeframe that the markets need" with HTA> "the timeframe in which IETF particpants think they are needed to further HTA> the mission of the IETF". I agree with Dave, this resolution really waters down the intention of the original text. And who knows what "further the mission of the IETF means" anyway? From problem-statement-bounces@alvestrand.no Wed Jun 11 10:47:33 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11989 for ; Wed, 11 Jun 2003 10:47:33 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 58C6A62594; Wed, 11 Jun 2003 16:47:04 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7DD8E6230A for ; Wed, 11 Jun 2003 16:47:02 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.19]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA07549; Wed, 11 Jun 2003 07:45:49 -0700 (PDT) Message-Id: <5.1.0.14.2.20030611103941.04361e90@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 Jun 2003 10:41:58 -0400 To: Scott W Brim From: Margaret Wasserman In-Reply-To: <20030611142419.GI2592@sbrim-w2k01> References: <7815354758.20030610134209@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Cc: "problem-statement@alvestrand.no" Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA11989 Hi Scott, At 10:24 AM 6/11/2003 -0400, Scott W Brim wrote: >On Wed, Jun 11, 2003 07:31:36AM +0200, Patrik Fältström allegedly wrote: > > The overall problem I think is that in general people in the IETF don't > > spend enough time reviewing documents and architectures. One small > > group of people which soooo much want something done, something which > > makes sense from their perspective write a draft, and "push it through > > the system". The only real pushing today which is needed is the > > creation of a working group. > >\${leadsto} ... SIRS How so? Do you have some reason to believe that there are small groups of people that can effectively push something through the IETF that don't include a few SIRs? If a few positive SIR reviews lead to lower scrutiny by the IESG, then SIRs might actually make it easier for a small group of people to push something through. Note that I don't necessarily consider this to be a bad thing... Margaret From problem-statement-bounces@alvestrand.no Wed Jun 11 11:01:07 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12715 for ; Wed, 11 Jun 2003 11:01:06 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7762262595; Wed, 11 Jun 2003 17:00:37 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9EB9B6233E for ; Wed, 11 Jun 2003 17:00:33 +0200 (CEST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5BF0RCP000261 for ; Wed, 11 Jun 2003 08:00:30 -0700 (PDT) Received: from cisco.com (sjc-vpn2-173.cisco.com [10.21.112.173]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AHB23298; Wed, 11 Jun 2003 07:57:54 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Wed, 11 Jun 2003 11:00:21 -0400 Date: Wed, 11 Jun 2003 11:00:21 -0400 From: Scott W Brim To: "problem-statement@alvestrand.no" Message-ID: <20030611150021.GP2592@sbrim-w2k01> Mail-Followup-To: Scott W Brim , "problem-statement@alvestrand.no" References: <7815354758.20030610134209@brandenburg.com> <5.1.0.14.2.20030611103941.04361e90@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030611103941.04361e90@mail.windriver.com> User-Agent: Mutt/1.4i Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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, Jun 11, 2003 10:41:58AM -0400, Margaret Wasserman allegedly wrote: > How so? > > Do you have some reason to believe that there are small groups of > people that can effectively push something through the IETF that > don't include a few SIRs? > > If a few positive SIR reviews lead to lower scrutiny by the IESG, > then SIRs might actually make it easier for a small group of > people to push something through. Note that I don't necessarily > consider this to be a bad thing... [swb inches his way around the solutions lagoon ...] I tend to trust the IESG, and I have yet to see an incarnation of it which I would call stupid. If the SIRS reviewers are selected from a narrow pool, perhaps all participants in the WG in the first place, that might lead to even more scrutiny. In any case it wouldn't be less. I agree with the problem as originally stated, that many documents don't get enough review, especially with what they expect from other technologies. From problem-statement-bounces@alvestrand.no Wed Jun 11 11:03:12 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12753 for ; Wed, 11 Jun 2003 11:03:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D15526259F; Wed, 11 Jun 2003 17:02:22 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by eikenes.alvestrand.no (Postfix) with ESMTP id BF4946230A; Wed, 11 Jun 2003 17:01:33 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19Q76N-0006OM-00; Wed, 11 Jun 2003 08:01:27 -0700 Date: Wed, 11 Jun 2003 10:59:02 -0400 From: Keith Moore To: Dave Crocker Message-Id: <20030611105902.7996e40b.moore@cs.utk.edu> In-Reply-To: <13079167146.20030611072541@brandenburg.com> References: <76080000.1055337042@askvoll.hjemme.alvestrand.no> <13079167146.20030611072541@brandenburg.com> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: harald@alvestrand.no Cc: moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: ISSUE: excessive perfectionism (was Re: ISSUE: Timeframes shold be focused on IETF purposes, not markets) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 reading this, I'm convinced that "excessive perfectionism" is not an accurate statement of the forces that delay our standards. It might seem like excessive perfectionism to the person who thinks it's "good enough" or who doesn't recognize the reason that the change is being requested. But I think the real problem is more subtle (and more insidious) than that - e.g. - When a protocol affects a large span of interests, we have trouble getting a widespread understanding of the issues. The folks who are "pushing" the protocol often represent a narrow set of those interests, and they might even be reluctant to try to understand those issues that don't affect them directly; seeing them as distractions rather than genuine issues that need to affect the design. - Often we have trouble even identifying some of those issues in a WG before the design is considered to be mature and frozen, but this is usually because the WG hasn't tried to do so. - Even if we have the issues on the table, many groups have a difficult time making decisions in a timely fashion. Those who want those pesky issues to go away may hope that the ones pushing those issues can be considered irrelevant to the rough consensus, so (perhaps out of fear of delay should the issue be found to be valid and require a change to the protocol) they will do anything to discredit the issue (or those raising the issue) rather than look at it. Those who want the issues to get fixed may try to delay the proceeedings merely in the hope that someone will eventually start taking it seriously (sometimes this even works, but rarely). I also agree with Harald that neither "the timeframe that markets need" nor "appropriate quality" are objectively identifiable with any accuracy. So I suggest that this be reworded: The frequent inability of the IETF to deliver specifications within the timeframe expected by those "pushing" the specifications could be improved if appropriate Engineering Practices were in use and in particular, if IETF working groups could recognize issues associated with their specifications early in the development process, and once the issues were identified, if they could make design decisions and have review on those decisions in a timely fashion. Now I also agree with Dave that IETF has some tendency to ignore its customers; but I believe that the customers of a WG are all of those affected by the WG output, not merely those who want that particular WG's output to be finalized. Those customers are often very distant from the WG, they have little idea about what the WG is actually doing because what little they know comes from the trade press, speculation on slashdot, or other rumor mills. So I don't think it's realistic to give customers what they want or expect; instead, we need to try to give customers what they need. In this sense we are different from an organization that derives income (and existence) from sales and which is content to give customers whatever they will pay for (as long as it has sufficient margin). > The existing text is intended to precisely highlight the IETF's tendency > to ignore its customers. > > Your suggested change eliminates that point entirely. > > While one might develop a logic chain that puts it back, one can easily > instead develop a logic chain that says that the timeframe can whatever > any particular IETF participant believes it should be. Hence, the direct > reference to the needs of the market is the key point in this problem > statement. > > > d/ > > HTA> The frequent inability of the IETF to deliver specifications within > HTA> the timeframe that the markets need and the excessive perfectionism > HTA> that is exhibited in some cases could both be improved if > HTA> appropriate Engineering Practices were in use. > > HTA> ISSUE: This sentence presupposes that the "timeframe the markets need" > HTA> and the "appropriate quality" are relatively quantifiable quantities. I > HTA> think they aren't. > HTA> SUGGESTED RESOLUTION: Replace "the timeframe that the markets need" > HTA> with"the timeframe in which IETF particpants think they are needed to > HTA> further the mission of the IETF". > > > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > From problem-statement-bounces@alvestrand.no Wed Jun 11 11:26:30 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13314 for ; Wed, 11 Jun 2003 11:26:29 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 54F8C6233E; Wed, 11 Jun 2003 17:25:54 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from cbibipnt03.HC.BT.COM (saturn.bt.com [193.113.57.20]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6F3C86230A for ; Wed, 11 Jun 2003 17:25:51 +0200 (CEST) Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Wed, 11 Jun 2003 16:26:07 +0100 Message-ID: <3D67CCA7D63E714B980D21A038EEA08E059275E1@i2km02-ukbr.domain1.systemhost.net> From: graham.travers@bt.com To: problem-statement@alvestrand.no Date: Wed, 11 Jun 2003 16:25:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="ISO-8859-1" Subject: RE: ISSUE: excessive perfectionism (was Re: ISSUE: Timeframes sho ld be focused on IETF purposes, not markets) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Apologies if somebody's already addressed this, as I've been away and missed some of the discussion. It's been said of I-D's, and it's true of these wider issues too: give the definitions before starting to discuss them. Do we have any working IETF definitions of *current* customers, mission, etc ? If not, I think we should solve that problem before trying to understand *customers' requirements*, *furthering the mission of the IETF*, etc. Regards, Graham Travers International Standards Manager BT Exact e-mail: graham.travers@bt.com tel: +44(0) 1359 235086 mobile: +44(0) 7808 502536 fax: +44(0) 1359 235087 HWB279, PO Box 200,London, N18 1ZF, UK BTexact Technologies is a trademark of British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: 11 June 2003 15:59 To: Dave Crocker Cc: harald@alvestrand.no; moore@cs.utk.edu; problem-statement@alvestrand.no Subject: ISSUE: excessive perfectionism (was Re: ISSUE: Timeframes shold be focused on IETF purposes, not markets) On reading this, I'm convinced that "excessive perfectionism" is not an accurate statement of the forces that delay our standards. It might seem like excessive perfectionism to the person who thinks it's "good enough" or who doesn't recognize the reason that the change is being requested. But I think the real problem is more subtle (and more insidious) than that - e.g. - When a protocol affects a large span of interests, we have trouble getting a widespread understanding of the issues. The folks who are "pushing" the protocol often represent a narrow set of those interests, and they might even be reluctant to try to understand those issues that don't affect them directly; seeing them as distractions rather than genuine issues that need to affect the design. - Often we have trouble even identifying some of those issues in a WG before the design is considered to be mature and frozen, but this is usually because the WG hasn't tried to do so. - Even if we have the issues on the table, many groups have a difficult time making decisions in a timely fashion. Those who want those pesky issues to go away may hope that the ones pushing those issues can be considered irrelevant to the rough consensus, so (perhaps out of fear of delay should the issue be found to be valid and require a change to the protocol) they will do anything to discredit the issue (or those raising the issue) rather than look at it. Those who want the issues to get fixed may try to delay the proceeedings merely in the hope that someone will eventually start taking it seriously (sometimes this even works, but rarely). I also agree with Harald that neither "the timeframe that markets need" nor "appropriate quality" are objectively identifiable with any accuracy. So I suggest that this be reworded: The frequent inability of the IETF to deliver specifications within the timeframe expected by those "pushing" the specifications could be improved if appropriate Engineering Practices were in use and in particular, if IETF working groups could recognize issues associated with their specifications early in the development process, and once the issues were identified, if they could make design decisions and have review on those decisions in a timely fashion. Now I also agree with Dave that IETF has some tendency to ignore its customers; but I believe that the customers of a WG are all of those affected by the WG output, not merely those who want that particular WG's output to be finalized. Those customers are often very distant from the WG, they have little idea about what the WG is actually doing because what little they know comes from the trade press, speculation on slashdot, or other rumor mills. So I don't think it's realistic to give customers what they want or expect; instead, we need to try to give customers what they need. In this sense we are different from an organization that derives income (and existence) from sales and which is content to give customers whatever they will pay for (as long as it has sufficient margin). > The existing text is intended to precisely highlight the IETF's tendency > to ignore its customers. > > Your suggested change eliminates that point entirely. > > While one might develop a logic chain that puts it back, one can easily > instead develop a logic chain that says that the timeframe can whatever > any particular IETF participant believes it should be. Hence, the direct > reference to the needs of the market is the key point in this problem > statement. > > > d/ > > HTA> The frequent inability of the IETF to deliver specifications within > HTA> the timeframe that the markets need and the excessive perfectionism > HTA> that is exhibited in some cases could both be improved if > HTA> appropriate Engineering Practices were in use. > > HTA> ISSUE: This sentence presupposes that the "timeframe the markets need" > HTA> and the "appropriate quality" are relatively quantifiable quantities. I > HTA> think they aren't. > HTA> SUGGESTED RESOLUTION: Replace "the timeframe that the markets need" > HTA> with"the timeframe in which IETF particpants think they are needed to > HTA> further the mission of the IETF". > > > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > From problem-statement-bounces@alvestrand.no Wed Jun 11 11:39:06 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13933 for ; Wed, 11 Jun 2003 11:39:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3761B62594; Wed, 11 Jun 2003 17:38:37 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8BA3F6230A for ; Wed, 11 Jun 2003 17:38:35 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19Q7gF-0002ps-00; Wed, 11 Jun 2003 08:38:32 -0700 Date: Wed, 11 Jun 2003 11:36:07 -0400 From: Keith Moore To: graham.travers@bt.com Message-Id: <20030611113607.5121e28e.moore@cs.utk.edu> In-Reply-To: <3D67CCA7D63E714B980D21A038EEA08E059275E1@i2km02-ukbr.domain1.systemhost.net> References: <3D67CCA7D63E714B980D21A038EEA08E059275E1@i2km02-ukbr.domain1.systemhost.net> X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Subject: Re: ISSUE: excessive perfectionism (was Re: ISSUE: Timeframes sho ld be focused on IETF purposes, not markets) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > It's been said of I-D's, and it's true of these wider issues too: give the > definitions before starting to discuss them. makes sense. > Do we have any working IETF definitions of *current* customers, mission, etc > ? If not, I think we should solve that problem before trying to understand > *customers' requirements*, *furthering the mission of the IETF*, etc. As I said earlier, I think IETF's "customers" are all of those affected by something that IETF does. It strikes me as counterproductive to think that our goal is to benefit some subset of those people without regard to the harm that we're doing to some other subset of those people. But maybe "customer" is a poor word to use, because it invites confusion of IETF's motives with those of a business whose motive is profit, and which doesn't need to be very concerned with the interests of those who don't buy its products or services. From problem-statement-bounces@alvestrand.no Wed Jun 11 11:42:09 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14072 for ; Wed, 11 Jun 2003 11:42:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3E7546259B; Wed, 11 Jun 2003 17:41:26 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0873E6259F for ; Wed, 11 Jun 2003 17:40:07 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180])h5BFe5ZX044908; Wed, 11 Jun 2003 17:40:05 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h5BFe1lf156956; Wed, 11 Jun 2003 17:40:01 +0200 Received: from dhcp22-128.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA51550 from ; Wed, 11 Jun 2003 17:40:00 +0200 Message-Id: <3EE74D66.BC6CA78@hursley.ibm.com> Date: Wed, 11 Jun 2003 17:40:22 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Marcus Brunner References: <3EE626EF.53ED7487@iprg.nokia.com> <16565640.1055342433@[10.1.1.130]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Two document stages: Proposed and Full X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Having documents sitting at PS that either need revision or need to become Historic is certainly a problem. My view is that by having a high barrier to going "up" from PS causes most authors to simply not bother about this problem. (That is certainly true of myself, so I am guilty of some sleeping PS's.) Brian Marcus Brunner wrote: > > Brian, > > If we accept that the core value is ".. and running code" the document and > how it is written does not really matter. Peer review is naturally very > useful for the final spec, but do we need it before we have implementation > experience? The problem is the crap sitting in PS and being happy with > this. (Which from a marketing perspective is enough, getting and market > products with RFC numbers) > > Marcus > > --On Mittwoch, 11. Juni 2003 11:07 +0200 Brian E Carpenter > wrote: > > > Problem related comment: > > > > We have ample evidence that WGs don't consistently produce > > documents that meet even today's criteria for PS. I am strongly > > against giving WGs the ability to approve PSs without enforced peer > > review that is specifically independent of the WG and specifically > > consider IETF-wide and Internet-wide issues. This proposal would > > only make the problem worse than today, by allowing WGs to ignore > > peer review. > > > > Brian > > > > "Charles E. Perkins" wrote: > >> > >> Hello folks, > >> > >> I think this has been suggested before. I'd like to > >> suggest it again. Maybe we can get some mileage out of > >> having two stages of standardization: > >> > >> Proposed Standard: requires working group approval. IESG comments > >> taken into account, but full IESG approval not needed before > >> publication. Interoperability testing completed, no known > >> flaws that present danger to the Internet. Component protocols > >> are O.K., as long as applicability (usefulness) is documented. > >> > >> Full Standard: Full IESG approval required, according to current > >> procedures. Component protocols published as part of > >> document suites, or separately, according to IESG discretion. > >> > >> Since the IESG still controls charters and chair selection, one may > >> presume that generally sensible people will be involved. In this > >> model, for instance, a working group might publish a component > >> protocol, and another working group with more relevant expertise > >> might publish another associated component protocol that could fit > >> together into a larger system. > >> > >> Maybe this is too much "solution space" -- if so, I'll try to > >> bring it up whenever I can find that forum. It's gotta be > >> around here somewhere. > >> > >> Regards, > >> Charlie P. From problem-statement-bounces@alvestrand.no Wed Jun 11 11:42:52 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14107 for ; Wed, 11 Jun 2003 11:42:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1CFDF62594; Wed, 11 Jun 2003 17:42:23 +0200 (CEST) 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 E5A886230A for ; Wed, 11 Jun 2003 17:42:09 +0200 (CEST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])h5BFg9901055 for ; Wed, 11 Jun 2003 18:42:09 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com ; Wed, 11 Jun 2003 18:42:09 +0300 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 11 Jun 2003 18:42:09 +0300 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 11 Jun 2003 10:41:59 -0500 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" Date: Wed, 11 Jun 2003 10:41:58 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44017536FF@daebe007.americas.nokia.com> Thread-Topic: Two document stages: Proposed and Full Thread-Index: AcMwFrEVU78lYI6IRi6PB0N6L8dTbgAGTdDw From: To: , , X-OriginalArrivalTime: 11 Jun 2003 15:41:59.0351 (UTC) FILETIME=[FED58C70:01C3302F] Subject: RE: Two document stages: Proposed and Full X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA14107 The document quality does matter. Running code is obviously much more valuable than having a document that is well written and is clear but is not sufficient by itself. While well written I-Ds help implementers, its only running code that catches the bugs and implementation issues. One of the problems with the current process is that it is okay for an I-D to be advanced to PS simply by having "rough consensus" without any "running code". One suggestion is that I-Ds that are intended for standards track be assigned Experimental status unless "running code" exists. This is another vote for raising the bar which has been dicussed at length. -Basavaraj >Brian, > >If we accept that the core value is ".. and running code" the document and >how it is written does not really matter. Peer review is naturally very >useful for the final spec, but do we need it before we have implementation >experience? The problem is the crap sitting in PS and being happy with >this. (Which from a marketing perspective is enough, getting and market >products with RFC numbers) > >Marcus > >--On Mittwoch, 11. Juni 2003 11:07 +0200 Brian E Carpenter > wrote: > >> Problem related comment: >> >> We have ample evidence that WGs don't consistently produce >> documents that meet even today's criteria for PS. I am strongly >> against giving WGs the ability to approve PSs without enforced peer >> review that is specifically independent of the WG and specifically >> consider IETF-wide and Internet-wide issues. This proposal would >> only make the problem worse than today, by allowing WGs to ignore >> peer review. >> >> Brian >> From problem-statement-bounces@alvestrand.no Wed Jun 11 11:43:53 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14178 for ; Wed, 11 Jun 2003 11:43:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8B71162594; Wed, 11 Jun 2003 17:43:24 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by eikenes.alvestrand.no (Postfix) with ESMTP id E49886230A for ; Wed, 11 Jun 2003 17:43:20 +0200 (CEST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h5BFhIwc001945 for ; Wed, 11 Jun 2003 08:43:18 -0700 (PDT) Received: from cisco.com (sjc-vpn2-173.cisco.com [10.21.112.173]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AHB26268; Wed, 11 Jun 2003 08:40:44 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Wed, 11 Jun 2003 11:43:12 -0400 Date: Wed, 11 Jun 2003 11:43:12 -0400 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030611154312.GT2592@sbrim-w2k01> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: <3D67CCA7D63E714B980D21A038EEA08E059275E1@i2km02-ukbr.domain1.systemhost.net> <20030611113607.5121e28e.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030611113607.5121e28e.moore@cs.utk.edu> User-Agent: Mutt/1.4i Subject: Re: ISSUE: excessive perfectionism (was Re: ISSUE: Timeframes sho ld be focused on IETF purposes, not markets) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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, Jun 11, 2003 11:36:07AM -0400, Keith Moore allegedly wrote: > But maybe "customer" is a poor word to use, because it invites > confusion of IETF's motives with those of a business whose motive is > profit, and which doesn't need to be very concerned with the interests > of those who don't buy its products or services. stakeholders From problem-statement-bounces@alvestrand.no Wed Jun 11 11:49:04 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14752 for ; Wed, 11 Jun 2003 11:49:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2385E62595; Wed, 11 Jun 2003 17:48:34 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5589162594; Wed, 11 Jun 2003 17:48:20 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19Q7pj-0001xJ-00; Wed, 11 Jun 2003 08:48:19 -0700 Date: Wed, 11 Jun 2003 11:45:54 -0400 From: Keith Moore To: Harald Tveit Alvestrand Message-Id: <20030611114554.15af8255.moore@cs.utk.edu> In-Reply-To: <37960000.1055226404@askvoll.hjemme.alvestrand.no> References: <37960000.1055226404@askvoll.hjemme.alvestrand.no> X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Subject: Re: MINOR ISSUE: Desired level of architectural view X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > MINOR ISSUE: There is not consensus that an archtiectural view is desirable > - see introduction to "architectural principles of the Internet" (RFC > 1958), which emphasizes the ability to change more than the grand plan. I guess it depends on how you define "architecture". I don't think "architecture" needs to be static, but neither do I think "roadmaps" are sufficient. From problem-statement-bounces@alvestrand.no Wed Jun 11 11:49:17 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14773 for ; Wed, 11 Jun 2003 11:49:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 569C76259B; Wed, 11 Jun 2003 17:48:47 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from cbibipnt03.HC.BT.COM (saturn.bt.com [193.113.57.20]) by eikenes.alvestrand.no (Postfix) with ESMTP id F11EC6230A for ; Wed, 11 Jun 2003 17:48:32 +0200 (CEST) Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Wed, 11 Jun 2003 16:48:44 +0100 Message-ID: <3D67CCA7D63E714B980D21A038EEA08E059275E2@i2km02-ukbr.domain1.systemhost.net> From: graham.travers@bt.com To: moore@cs.utk.edu Date: Wed, 11 Jun 2003 16:48:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="ISO-8859-1" Cc: problem-statement@alvestrand.no Subject: RE: ISSUE: excessive perfectionism (was Re: ISSUE: Timeframes sho ld be focused on IETF purposes, not markets) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Keith, I'm not suggesting that we favour a sub-set; rather that we try to include all the *customers* ( stakeholders or users, if you prefer ) that we can identify - e.g. vendors, ISPs, researchers, end-users..... I realise that such a list can not be comprehensive forever, as new types of user will emerge; but it does at least give us a checklist of who we should currently be considering. Regards, Graham Travers International Standards Manager BT Exact e-mail: graham.travers@bt.com tel: +44(0) 1359 235086 mobile: +44(0) 7808 502536 fax: +44(0) 1359 235087 HWB279, PO Box 200,London, N18 1ZF, UK BTexact Technologies is a trademark of British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: 11 June 2003 16:36 To: Travers,G,Graham,XVT TRAVERG R Cc: moore@cs.utk.edu; problem-statement@alvestrand.no Subject: Re: ISSUE: excessive perfectionism (was Re: ISSUE: Timeframes sho ld be focused on IETF purposes, not markets) > It's been said of I-D's, and it's true of these wider issues too: give the > definitions before starting to discuss them. makes sense. > Do we have any working IETF definitions of *current* customers, mission, etc > ? If not, I think we should solve that problem before trying to understand > *customers' requirements*, *furthering the mission of the IETF*, etc. As I said earlier, I think IETF's "customers" are all of those affected by something that IETF does. It strikes me as counterproductive to think that our goal is to benefit some subset of those people without regard to the harm that we're doing to some other subset of those people. But maybe "customer" is a poor word to use, because it invites confusion of IETF's motives with those of a business whose motive is profit, and which doesn't need to be very concerned with the interests of those who don't buy its products or services. From problem-statement-bounces@alvestrand.no Wed Jun 11 12:00:42 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15233 for ; Wed, 11 Jun 2003 12:00:41 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A999E6233E; Wed, 11 Jun 2003 18:00:10 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by eikenes.alvestrand.no (Postfix) with ESMTP id D64A46230A for ; Wed, 11 Jun 2003 18:00:03 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19Q80z-0001TQ-00; Wed, 11 Jun 2003 08:59:57 -0700 Date: Wed, 11 Jun 2003 11:57:32 -0400 From: Keith Moore To: graham.travers@bt.com Message-Id: <20030611115732.48915edc.moore@cs.utk.edu> In-Reply-To: <3D67CCA7D63E714B980D21A038EEA08E059275E2@i2km02-ukbr.domain1.systemhost.net> References: <3D67CCA7D63E714B980D21A038EEA08E059275E2@i2km02-ukbr.domain1.systemhost.net> X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Subject: Re: ISSUE: excessive perfectionism (was Re: ISSUE: Timeframes sho ld be focused on IETF purposes, not markets) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > I'm not suggesting that we favour a sub-set; rather that we try to include > all the *customers* ( stakeholders or users, if you prefer ) that we can > identify - e.g. vendors, ISPs, researchers, end-users..... I agree that if we're going to think in terms of "our job is to serve our customers" we need to define it in this way. And I think you're entirely correct to point out that we need to define the term, because I suspect there's been a substantial divergence in how people have been thinking about it. I've often had the impression that the individuals pushing a particular protocol considered the protocol's "customers" to be only those who would be making commercial products using the protocol - or essentially, their employers. And given that the employers are the ones paying them for their work on the protocol, it's easy to see how they'd get that view. Getting back to the market timeliness concern, it might be that we should try to separate concepts like "having the protocol finalized while there's still a market opportunity for deployment" from "providing sufficient motivation to potential implementors to work on the protocol specification" from "making sure that the protocol does useful things while minimizing harm". A concept like "giving customers what they want" could encompass all of these if you define "customer" broadly enough, but it masks the underlying conflicts. From problem-statement-bounces@alvestrand.no Wed Jun 11 16:28:00 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18846 for ; Wed, 11 Jun 2003 16:28:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3C0796259C; Wed, 11 Jun 2003 22:27:30 +0200 (CEST) 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 78A416259B for ; Wed, 11 Jun 2003 22:27:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 6F440141E4; Wed, 11 Jun 2003 16:27:25 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17400-09; Wed, 11 Jun 2003 16:27:25 -0400 (EDT) Received: from cs.utk.edu (laptop13.cs.utk.edu [160.36.57.4]) by smtp.cs.utk.edu (Postfix) with ESMTP id 24DD1141E3; Wed, 11 Jun 2003 16:27:25 -0400 (EDT) Date: Wed, 11 Jun 2003 16:27:33 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: "Bound, Jim" From: Keith Moore In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0324132E@tayexc13.americas.cpqcorp.net> Message-Id: <22164F7B-9C4B-11D7-96AD-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Cc: Melinda Shore Cc: problem-statement@alvestrand.no Cc: Keith Moore Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > PROBLEM: The IETF process to reach PS cannot support time-to-market > requirements. can you defend this statement? it's not clear to me why this should be the case, or at least is seems too vague as written. what is it about either the 2026 criteria for PS or our current practice that inherently "cannot" support such requirements? (now it should be clear that it's not always possible to develop a standard in time to suit a deployment window - sometimes the market has unreasonable demands - but that doesn' t mean that we "cannot" do so in general) > PROBLEM: The IETF process to complete specifications puts to many > features in those initial specifications. again - what is it about our process that does this? I've seen several WGs manage to avoid putting features in their initial specifications when they could be added later, so as far as I can tell, the IETF process has no problems with this. From problem-statement-bounces@alvestrand.no Wed Jun 11 16:39:42 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00971 for ; Wed, 11 Jun 2003 16:39:42 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8C6C76259C; Wed, 11 Jun 2003 22:39:12 +0200 (CEST) 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 7199F62595; Wed, 11 Jun 2003 22:39:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id C8586141DB; Wed, 11 Jun 2003 16:39:08 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18386-11; Wed, 11 Jun 2003 16:39:08 -0400 (EDT) Received: from cs.utk.edu (laptop13.cs.utk.edu [160.36.57.4]) by smtp.cs.utk.edu (Postfix) with ESMTP id 722E2141E3; Wed, 11 Jun 2003 16:39:08 -0400 (EDT) Date: Wed, 11 Jun 2003 16:39:16 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Charlie Perkins From: Keith Moore In-Reply-To: <3EE4FAD2.2020303@iprg.nokia.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Cc: problem-statement@alvestrand.no Cc: Keith Moore Cc: Harald Tveit Alvestrand Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > My belief is that the IESG demands full-blown system specifications > because anything less "could" be implemented inside systems that > have features they don't like. I don't think this is true in general. To the extent that it is true, I suspect it has something to do with the expectations that the IESG (and perhaps the public) have for that particular technology. I'll give an example not involving IESG. Once I had lunch with the person who was then the head networking official for the University of Tennessee. He complained to me about the limitations of Mobile IP. I replied that Mobile IP was just fine as long as you understood its limitations and didn't expect it to solve every version of the "I want my host to be able to be mobile and still talk to the network" problem. (note, this conversation was a few years ago, so it's not a statement about the state of mobile IP today). But the natural expectation of something called "mobile IP" is that it _will_ solve your version of the mobile IP access problem (which given the number of different versions of that problem, essentially means that mobile IP is expected to solve all versions of that problem). Now actually I think it's perfectly reasonable if IESG declares that something that calls itself "mobile IP" needs to solve a fairly general version of the "mobile IP network access" problem, including security etc. But sometimes the right action might be to change the name or otherwise make it clear that this isn't a general solution, and approve it for use in the more narrow set of circumstances in which it works well - especially if deployment of the 'limited' solution would not preclude a later migration to a more general solution. Other technologies that might be implicitly over-stating their applicability include IPsec, DHCP, zeroconf / linklocal addressing for IPv4. (and we're used to thinking that marketing isn't important...) From problem-statement-bounces@alvestrand.no Wed Jun 11 17:06:11 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03138 for ; Wed, 11 Jun 2003 17:06:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 197086259B; Wed, 11 Jun 2003 23:05:41 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 69A9C622BB for ; Wed, 11 Jun 2003 23:05:31 +0200 (CEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA28145; Wed, 11 Jun 2003 14:05:30 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5BL5TU23900; Wed, 11 Jun 2003 14:05:29 -0700 X-mProtect: <200306112105> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdekGYGd; Wed, 11 Jun 2003 14:05:26 PDT Message-ID: <3EE79997.9DFE8DD@iprg.nokia.com> Date: Wed, 11 Jun 2003 14:05:27 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Keith Moore References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hello Keith Keith Moore wrote: >> My belief is that the IESG demands full-blown system specifications >> because anything less "could" be implemented inside systems that >> have features they don't like. > > I don't think this is true in general. To the extent that it is true, > I suspect it has something to do with the expectations that the IESG > (and perhaps the public) have for that particular technology. Your story, while interesting, is far afield from my point. I mentioned several areas which I believe the IESG has mistakenly required for inclusion in base protocols, among them key distribution when authentication is a part of the protocol. If the IESG wants assurances for a particular technology, then those assurances should be in the charter statement. They should not be articulated for the first time during Last Call. Regards, Charlie P. From problem-statement-bounces@alvestrand.no Wed Jun 11 17:13:01 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03325 for ; Wed, 11 Jun 2003 17:13:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 765616259B; Wed, 11 Jun 2003 23:12:31 +0200 (CEST) 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 774DB622BB for ; Wed, 11 Jun 2003 23:12:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id D1CE4141EB; Wed, 11 Jun 2003 17:12:27 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21439-12; Wed, 11 Jun 2003 17:12:27 -0400 (EDT) Received: from cs.utk.edu (laptop13.cs.utk.edu [160.36.57.4]) by smtp.cs.utk.edu (Postfix) with ESMTP id 867D9140F3; Wed, 11 Jun 2003 17:12:27 -0400 (EDT) Date: Wed, 11 Jun 2003 17:12:36 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: "Charles E. Perkins" From: Keith Moore In-Reply-To: <3EE79997.9DFE8DD@iprg.nokia.com> Message-Id: <6CB8C4CE-9C51-11D7-96AD-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Cc: problem-statement@alvestrand.no Cc: Keith Moore Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > Your story, while interesting, is far afield from my point. > I mentioned several areas which I believe the IESG has > mistakenly required for inclusion in base protocols, among > them key distribution when authentication is a part of > the protocol. > > If the IESG wants assurances for a particular technology, > then those assurances should be in the charter statement. > They should not be articulated for the first time during > Last Call. I suspect we'd agree that having WGs carefully define the scope of the problem they are trying to solve, and the applicability of their solutions, would help a lot. IMHO, this should start with the charter and continue through a WG "problem statement" phase (what we often call "requirements" today) and eventually result in an applicability statement that is part of the standard. Now if we could just stop WGs from claiming vastly more applicability than their protocols deserve... From problem-statement-bounces@alvestrand.no Wed Jun 11 17:20:03 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03550 for ; Wed, 11 Jun 2003 17:20:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 598FD6259C; Wed, 11 Jun 2003 23:19:34 +0200 (CEST) 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 369846259B for ; Wed, 11 Jun 2003 23:19:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 897F0141E1; Wed, 11 Jun 2003 17:19:26 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22505-03; Wed, 11 Jun 2003 17:19:26 -0400 (EDT) Received: from cs.utk.edu (laptop13.cs.utk.edu [160.36.57.4]) by smtp.cs.utk.edu (Postfix) with ESMTP id 37702141EB; Wed, 11 Jun 2003 17:19:26 -0400 (EDT) Date: Wed, 11 Jun 2003 17:19:35 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Dave Crocker From: Keith Moore In-Reply-To: <15925741524.20030606161535@brandenburg.com> Message-Id: <66768442-9C52-11D7-96AD-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Cc: Melinda Shore Cc: problem-statement@alvestrand.no Cc: Keith Moore Subject: Re: Staying on Track (Re: Documenting pilots (RE: pausable explanation for the Document Series)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > Rather than being worried that it has occurred, perhaps we should be > worried that more such efforts have not? I think Melinda's concern is reasonable. I don't have a big problem with SIRS specifically because according to my understanding of this organization I don't think SIRS is likely to usurp any real authority. (A big part of this is knowing the individuals involved.) But I'd hate to see thousands of flowers bloom in this space. From problem-statement-bounces@alvestrand.no Wed Jun 11 17:26:50 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03870 for ; Wed, 11 Jun 2003 17:26:49 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7AC216259C; Wed, 11 Jun 2003 23:26:20 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id CF3966259B for ; Wed, 11 Jun 2003 23:26:11 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19QD6g-000LXw-00; Wed, 11 Jun 2003 21:26:10 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19QD6f-000JeZ-8J; Thu, 12 Jun 2003 06:26:09 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 12 Jun 2003 06:26:08 +0900 To: Keith Moore References: <15925741524.20030606161535@brandenburg.com> <66768442-9C52-11D7-96AD-000393DB5366@cs.utk.edu> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: Staying on Track (Re: Documenting pilots (RE: pausable explanation for the Document Series)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit the big question about the sirs (and 'greybeards'? what, no women?) effort is whether it will produce solid useful reviews. we need such badly. and the proof is in the pudding. randy From problem-statement-bounces@alvestrand.no Thu Jun 12 03:45:17 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29433 for ; Thu, 12 Jun 2003 03:45:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 770E26238C; Thu, 12 Jun 2003 09:44:43 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by eikenes.alvestrand.no (Postfix) with ESMTP id D5D7A62251 for ; Thu, 12 Jun 2003 09:44:40 +0200 (CEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 2DB506A907 for ; Thu, 12 Jun 2003 10:44:39 +0300 (EEST) Message-ID: <3EE82F00.1040608@piuha.net> Date: Thu, 12 Jun 2003 10:42:56 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: problem-statement@alvestrand.no References: <9C422444DE99BC46B3AD3C6EAFC9711B0324132C@tayexc13.americas.cpqcorp.net> <3EE5E81A.7060704@iprg.nokia.com> In-Reply-To: <3EE5E81A.7060704@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jari.arkko@piuha.net 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 Charlie et al, thanks for raising this issue. I believe large specifications are a significant problem in the IETF currently, and good points have been made in the discussion. I'd like to add a few thoughts about the reasons why we are ending up with large specifications. The discussion has mainly concentrated on the IESG's requirements, but in my opinion there are significant other causes for this. In fact, I wouldn't blame the IESG for this at all... [Let me add that I have been personally involved in the creation of several too large specifications, so I know what I'm talking about ;-) ] o We (as in all of us) tend to be too optimistic about the complexity of our projects at the beginning. We are not very good in estimating how big a specification will eventually need to be when it handles all error cases, security, etc. Still, document structure stays generally fixed from the -00 document. So if the problem looked like an easy idea for a 10 page -00 I-D, you might have wanted to split the document and protocols into subfunctions if you knew it was going to be 100 pages at the end. o Perceived need for speed at the beginning. Can't split the document because it would slow us down and require multiple WG LCs etc. o Working groups generally try to appear as attractive as possible towards potential customers of their specifications and other stakeholders. For instance, there's a need to show that the WG in the first place is needed because all these wonderful functions need to get done. Or an existing WG wants to ensure that it doesn't "lose" against a competing approach. o Similarly, if a "beauty contest" is run between two approaches in the WG, both approaches end up having a lot of features. o Requirement processes that we nowadays tend to run don't deal well with the prioritization of features. If someone can invent a requirement, it generally gets fulfilled in the solutions. We don't think about cost-benefit analysis enough. o Our quality control functions ensure that specifications are complete (with all error, multi-version support, different network scenarios, security, scalability functions). So, it looks very much like all of us are trying to do a perfect job. Trouble is, if you multiply all requirements, all network scenarios, and completeness you get a large spec. So what should we do about it? I think the right thing is to take a serious look at fulfilling all requirements, and to use modular specification approaches, and roadmaps / architecture to show interested parties that you will eventually support all components. And for whatever we do produce in the smaller specifications, I think its fine to require it to be complete in the sense of not breaking the Internet, handling all error situations, having security (even key management - its often very application specific), and so on. --Jari From problem-statement-bounces@alvestrand.no Thu Jun 12 04:21:20 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00445 for ; Thu, 12 Jun 2003 04:21:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AA5BE6230D; Thu, 12 Jun 2003 10:20:49 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id E053162251; Thu, 12 Jun 2003 10:20:47 +0200 (CEST) Date: Thu, 12 Jun 2003 10:20:48 +0200 From: Harald Tveit Alvestrand To: graham.travers@bt.com, moore@cs.utk.edu Message-ID: <152090000.1055406048@askvoll.hjemme.alvestrand.no> In-Reply-To: <3D67CCA7D63E714B980D21A038EEA08E059275E2@i2km02-ukbr.domain1.systemhost.net> References: <3D67CCA7D63E714B980D21A038EEA08E059275E2@i2km02-ukbr.domain1.sy stemhost.net> X-Mailer: Mulberry/2.2.1 (Linux/x86) 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: ISSUE: excessive perfectionism (was Re: ISSUE: Timeframes sho ld be focused on IETF purposes, not markets) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 onsdag, juni 11, 2003 16:48:14 +0100 graham.travers@bt.com wrote: > Keith, > > I'm not suggesting that we favour a sub-set; rather that we try to include > all the *customers* ( stakeholders or users, if you prefer ) that we can > identify - e.g. vendors, ISPs, researchers, end-users..... > > I realise that such a list can not be comprehensive forever, as new types > of user will emerge; but it does at least give us a checklist of who we > should currently be considering. In a very real sense, I believe the customers of the IETF process are us - the IETF participants. *Our* customers are the ISPs and the end-users, the researchers, the enterprises, the governments and the fabric of society itself. But I think it's *our* responsibility to set our targets; abdicating that responsibility to an abstract, unquantifiable notion like "market need" will not give us quality, relevant specifications for the Internet. Abusing random people's names.... I want to accept as vaild input into the target-setting process Jim Bound saying "I need the XYZ specification to be completed by August 27, 2004, because I have a Sept 1 spec freeze, a 3-month QA cycle, and product shipments planned for February 2005 that intend to incorporate that functionality". And I want to also accept as valid input John Loughney saying "XYZ cannot be completed by August 27, because ABC is barely going to meet its deadline of completing its spec by July, so XYZ cannot possibly incorporate that in less than 3 months; we can't make a good spec before October". But I don't want to accept as valid input someone saying "XYZ is urgently needed in the market (no background given), so we have to abandon the ABC dependency and publish the spec in February 2004 whether it works or not". See the difference? Harald From problem-statement-bounces@alvestrand.no Thu Jun 12 09:27:29 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09685 for ; Thu, 12 Jun 2003 09:27:27 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 98B386238C; Thu, 12 Jun 2003 15:26:53 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id B2A40621FA; Thu, 12 Jun 2003 15:26:44 +0200 (CEST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])h5CDQea18823; Thu, 12 Jun 2003 16:26:40 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com ; Thu, 12 Jun 2003 16:26:39 +0300 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 12 Jun 2003 16:26:39 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 12 Jun 2003 16:26:39 +0300 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" Date: Thu, 12 Jun 2003 16:26:38 +0300 Message-ID: Thread-Topic: Announcement of COACHES BOF Thread-Index: AcMw5kBsrgd7KyfuRUO4PooBQB2c9g== From: To: , , X-OriginalArrivalTime: 12 Jun 2003 13:26:39.0399 (UTC) FILETIME=[4160F370:01C330E6] Cc: ietf-quality@bogus.com Subject: Announcement of COACHES BOF X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA09685 Hello all, I would like to announce a BOF which we are trying to get time for in Vienna. We have a mailing list & we respectfully ask for people to join to discuss this further. We are working on an agenda, which, when it is more firm, we will send along. thanks, John & Bernard BOF NAME & ACRONYM: Comprehensive apprOACH to quality (COACH) AREA: General BOF CHAIR(S): Bernard Aboba, John Loughney MAILING LIST: List: ietf-quality@bogus.com Subscribe: majordomo@psg.com Body: subscribe ietf-quality@bogus.com Archive: http://psg.com/lists/ietf-quality FULL DESCRIPTION: This BOF will focus on proposals for quality improvement within the IETF process, and determine if there is enough substance to work on a framework within which these proposals are evaluated. The outcome of the BOF will be to determine how best to proceed with these issues in the IETF. There are concerns about the quality and timeliness of IETF output. These problems are enumerated in the IETF Problem Statement, currently under development in the Problem Statement Working Group. The current IETF Problem Resolution Process document suggests that a Working Group be formed to improve the quality processes, including review processes, used by IETF Working Groups. The goals of this BOF will be to determine a basic approach that the IETF could take to WG process improvement, examine some of the documented proposal for process improvement, and determine if there is enough interest and content to warrant the creation of a WG to improve the quality processes used by Working Groups. One goal is to write one or more documents on aspects of a WG quality plan. For example, a document on tracking tools - what's available, and more importantly, how to use them to improve quality. Another document on reviews - how they might be conducted, the rules for reviewing, choosing reviewers, etc. The benefit of this is that it while it requires Working Groups to think about the issue, it doesn't require that all working groups come up with the same plan. READING LIST: http://www.ietf.org/internet-drafts/draft-ietf-problem-issue-statement-01.txt http://www.ietf.org/internet-drafts/draft-ietf-problem-process-00.txt http://www.ietf.org/internet-drafts/draft-klensin-overload-00.txt http://www.ietf.org/internet-drafts/draft-carpenter-solution-sirs-00.txt From problem-statement-bounces@alvestrand.no Thu Jun 12 10:02:44 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10837 for ; Thu, 12 Jun 2003 10:02:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 944C2625A3; Thu, 12 Jun 2003 16:02:07 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from cbibipnt05.hc.bt.com (saturn.bt.com [193.113.57.20]) by eikenes.alvestrand.no (Postfix) with ESMTP id A9B226256B; Thu, 12 Jun 2003 16:02:01 +0200 (CEST) Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Thu, 12 Jun 2003 15:02:03 +0100 Message-ID: <3D67CCA7D63E714B980D21A038EEA08E059275E4@i2km02-ukbr.domain1.systemhost.net> From: graham.travers@bt.com To: harald@alvestrand.no, moore@cs.utk.edu Date: Thu, 12 Jun 2003 15:01:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Cc: problem-statement@alvestrand.no Subject: RE: ISSUE: excessive perfectionism (was Re: ISSUE: Timeframes sho ld be focused on IETF purposes, not markets) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Harald, I see that you are seeking precision, rather than vague allusions, - which is what I would prefer too. I don't propose that we abdicate our responsibility; rather that we analyse and record to whom we owe that responsibility. This must be particularly pertinent in cases where a specific requirement ( target ) must be considered in the light of competing/complementary requirements from other Areas or WGs. However, given the turnover in IETF participants and their attendant interests, if *we* set *our* targets, I believe it has implications for the mission of the IETF. There are certainly some these days who want to use IETF standards for targets other than the Internet per se ( e.g. VPNs ) - targets which were probably unforeseen when the IETF originally assumed its mission for the Internet. Does this mean that the mission of the IETF will be subject to change to meet *our targets* ? A changing mission strikes me as very difficult to fulfil. Regards, Graham Travers International Standards Manager BT Exact e-mail: graham.travers@bt.com tel: +44(0) 1359 235086 mobile: +44(0) 7808 502536 fax: +44(0) 1359 235087 HWB279, PO Box 200,London, N18 1ZF, UK BTexact Technologies is a trademark of British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. -----Original Message----- From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] Sent: 12 June 2003 09:21 To: Travers,G,Graham,XVT TRAVERG R; moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: RE: ISSUE: excessive perfectionism (was Re: ISSUE: Timeframes sho ld be focused on IETF purposes, not markets) --On onsdag, juni 11, 2003 16:48:14 +0100 graham.travers@bt.com wrote: > Keith, > > I'm not suggesting that we favour a sub-set; rather that we try to include > all the *customers* ( stakeholders or users, if you prefer ) that we can > identify - e.g. vendors, ISPs, researchers, end-users..... > > I realise that such a list can not be comprehensive forever, as new types > of user will emerge; but it does at least give us a checklist of who we > should currently be considering. In a very real sense, I believe the customers of the IETF process are us - the IETF participants. *Our* customers are the ISPs and the end-users, the researchers, the enterprises, the governments and the fabric of society itself. But I think it's *our* responsibility to set our targets; abdicating that responsibility to an abstract, unquantifiable notion like "market need" will not give us quality, relevant specifications for the Internet. Abusing random people's names.... I want to accept as vaild input into the target-setting process Jim Bound saying "I need the XYZ specification to be completed by August 27, 2004, because I have a Sept 1 spec freeze, a 3-month QA cycle, and product shipments planned for February 2005 that intend to incorporate that functionality". And I want to also accept as valid input John Loughney saying "XYZ cannot be completed by August 27, because ABC is barely going to meet its deadline of completing its spec by July, so XYZ cannot possibly incorporate that in less than 3 months; we can't make a good spec before October". But I don't want to accept as valid input someone saying "XYZ is urgently needed in the market (no background given), so we have to abandon the ABC dependency and publish the spec in February 2004 whether it works or not". See the difference? Harald From problem-statement-bounces@alvestrand.no Thu Jun 12 14:23:44 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21818 for ; Thu, 12 Jun 2003 14:23:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4417A625A8; Thu, 12 Jun 2003 20:22:58 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5A502625A4; Thu, 12 Jun 2003 20:22:56 +0200 (CEST) Date: Thu, 12 Jun 2003 20:22:57 +0200 From: Harald Tveit Alvestrand To: graham.travers@bt.com, moore@cs.utk.edu Message-ID: <214430000.1055442177@askvoll.hjemme.alvestrand.no> In-Reply-To: <3D67CCA7D63E714B980D21A038EEA08E059275E4@i2km02-ukbr.domain1.systemhost.net> References: <3D67CCA7D63E714B980D21A038EEA08E059275E4@i2km02-ukbr.domain1.sy stemhost.net> X-Mailer: Mulberry/2.2.1 (Linux/x86) 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: ISSUE: excessive perfectionism (was Re: ISSUE: Timeframes sho ld be focused on IETF purposes, not markets) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On torsdag, juni 12, 2003 15:01:39 +0100 graham.travers@bt.com wrote: > Harald, > > I see that you are seeking precision, rather than vague allusions, - which > is what I would prefer too. > > I don't propose that we abdicate our responsibility; rather that we > analyse and record to whom we owe that responsibility. This must be > particularly pertinent in cases where a specific requirement ( target ) > must be considered in the light of competing/complementary requirements > from other Areas or WGs. > > However, given the turnover in IETF participants and their attendant > interests, if *we* set *our* targets, I believe it has implications for > the mission of the IETF. There are certainly some these days who want to > use IETF standards for targets other than the Internet per se ( e.g. VPNs > ) - targets which were probably unforeseen when the IETF originally > assumed its mission for the Internet. Does this mean that the mission of > the IETF will be subject to change to meet *our targets* ? A changing > mission strikes me as very difficult to fulfil. that's an issue that I think any open, member-controlled organization has to grapple with.... if the membership really, truly wants something different from the current stated purposes of the organization, it's nearly impossible to prevent them from achieving it. However, I do think the IETF has a fairly stable core mission and core population.... and if we manage to be clearer and more effective in our mission, we'll attract more people who agree with that mission, too.... From problem-statement-bounces@alvestrand.no Thu Jun 12 14:39:29 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22493 for ; Thu, 12 Jun 2003 14:39:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5C2A16238C; Thu, 12 Jun 2003 20:38:53 +0200 (CEST) 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 1CDF16223F for ; Thu, 12 Jun 2003 20:38:43 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h5CIfgF17264; Thu, 12 Jun 2003 11:41:42 -0700 Date: Thu, 12 Jun 2003 11:38:35 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/10) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <192180732769.20030612113835@brandenburg.com> To: Randy Bush In-Reply-To: References: <15925741524.20030606161535@brandenburg.com> <66768442-9C52-11D7-96AD-000393DB5366@cs.utk.edu> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Staying on Track (Re: Documenting pilots (RE: pausable explanation for the Document Series)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Randy, RB> the big question about the sirs (and 'greybeards'? what, no RB> women?) 1. It's odd, Randy, that you appear to be unaware of the history of the term. For your edification, a note is on the home page for the site. 2. Given the workload on area directors, one would think that they have better things to do with their time than to level irrelevant, critical witticisms against the names of sites that are donating resources to IETF activities. No doubt such cleverness will encourage others to donate their resources. RB> effort is whether it will produce solid useful reviews. RB> we need such badly. and the proof is in the pudding. No kidding. One would almost think that is the reason for initiating the effort, wouldn't one? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Thu Jun 12 16:44:18 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26419 for ; Thu, 12 Jun 2003 16:44:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 135C8625A5; Thu, 12 Jun 2003 22:43:43 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 86FCC625A4 for ; Thu, 12 Jun 2003 22:43:40 +0200 (CEST) Date: Thu, 12 Jun 2003 22:43:41 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <220820000.1055450621@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: MINOR ISSUE: "improvements on the status quo" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 No, I'm not finished yet :-) Section 2.2 of -issue- reads: Engineering requires appropriate trade-offs: Engineering success needs refinement only to the point of 'fitness for purpose' which should help to balance the tension between time to market and perfectionism. The use of appropriate Engineering Practices should, for example, prevent specifications being recycled in pursuit of perfection when they are already adequate improvements on the status quo. ISSUE: "improvements on the status quo" is not the best formulation - for new specs, it's unmeasurable; in other cases, it is debatable whether the improvements are "adequate". SUGGESTED RESOLUTION: Use the language from 2026 section 4.1.1: adequate "with respect to the requirements placed upon it." Of course, appropriate Engineering Practices would be to make sure we know what requirements we are placing upon it before evaluating this... From problem-statement-bounces@alvestrand.no Thu Jun 12 16:47:51 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26494 for ; Thu, 12 Jun 2003 16:47:49 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7964C625A5; Thu, 12 Jun 2003 22:47:17 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 08E13625A4 for ; Thu, 12 Jun 2003 22:47:09 +0200 (CEST) Date: Thu, 12 Jun 2003 22:47:10 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <220930000.1055450830@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: MINOR ISSUE: Putting auditing before criteria X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Section 2.2 of -issue- reads: Some of the key areas where the IETF's practices appear to need tightening up include: o Lack of explicit quality auditing throughout the standards development process. o Lack of written guidelines or templates for the content of documents (as opposed to the overall layout) and matching lists of review criteria. o Poorly defined success criteria for WGs and individual documents. ISSUE: Quality auditing can only be done by auditing to criteria or guidelines. You can't make good guidelines without knowing your success criteria. SUGGESTED RESOLUTION: Swap the first and third bullets in the list, and change "quality auditing" to "auditing against criteria for success". Might want to reword the sequence so that "quality" still appears. From problem-statement-bounces@alvestrand.no Thu Jun 12 18:27:31 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29981 for ; Thu, 12 Jun 2003 18:27:30 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 08EF2625A5; Fri, 13 Jun 2003 00:27:01 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B3EAB625A7 for ; Fri, 13 Jun 2003 00:26:58 +0200 (CEST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h5CMQvn26206; Thu, 12 Jun 2003 15:26:57 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Thu, 12 Jun 2003 15:26:56 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: problem-statement@alvestrand.no In-Reply-To: <75888662.1055230582@p3.JCK.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: IETF mission (RE: pausable explanation for the Document Series) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Tue, 10 Jun 2003, John C Klensin wrote: > [ ... ] what were groups like the IETF doing that they needed > to imitate, co-opt, or defeat? > > There were several answers: > > (1) We didn't standardize fantasies about where the industry was > likely to go, or where we wanted it to go. No "anticipatory > standards" here. Documents didn't advance to full standard, or > even draft standard, unless there was solid implementation > experience. This is (or was) a good thing about the IETF, and we should try to keep it (or reinstate it). A two-grade process (Experimental and Standard) along the lines I proposed a few days ago, viz: % - specs start out in life as Experimental, recycling there % [as] necessary until % % - there are no known problems and at least two interoperable % implementations, at which point they would be eligible for % elevation to Standard (and could stay there on subsequent % revisions, if the changes were not "too drastic") would allow us to do that, and at least has the possibility of being better geared to reality than our current three-grade system. > (2) We didn't have a mandatory five-year (or other) review cycle > that led to permanent WGs dedicated to each [group of] > standards, provided a full-employment situation for WG chairs, > and virtually guaranteed second-system effects (while the > initial development WG often contained solid engineering > expertise and was usually in touch with real customer and > product requirements, and the first review cycle might contain > some of those people in order to fix bugs that had been > discovered, by the time of the second review (third time around) > sponsoring companies had almost always pulled out the useful > designers, replacing them with people whose fantasies about > improvements usually exceeded their experience and knowledge). Hmm. I've often thought that the lack of mandatory review for standards (especially full standards) is a big PROBLEM in the way the IETF works. It hurts in several ways: - we don't update specs to remove things that are clearly obsolete. An excellent example is the TOS stuff that peppers RFC 791, RFC 1112, and RFC 1812 ... all this was officially retired when the DiffServ stuff was launched. The specs should be brought up-to-date to match the reality. - we don't do maintenance revisions that are probably necessary. An example of this is the SMIv2 specs. We found some ambiguities and errata in the SMIv2 RFCs in the course of developing "Guidelines for MIB Authors and Reviewers." In addition, there are some known omissions (i.e., lack of 64-bit data types) that we are using kludges to work around. If we want this stuff to last for a while, a maintenance revision to fix the bugs and small omissions would, I think, be in order. - we don't retire obsolete stuff as soon as we should. RFC 1643 is an example of this. In fairness, these problems are not entirely due to the lack of mandatory periodic review; I think they are also attributable in part to a reluctance to make small changes to an Internet Standard, since it forces a recycling back to Proposed Standard. This can hit at any stage of the process ... if I remember correctly, that was one reason why adding 64-bit data types to SMIv2 was ruled out-of-scope in the 1998-1999 time frame when the specs were being updated for advancement from Draft Standard to (full) Standard. > (3) We were reluctant to simply declare an old standard obsolete > and replace it. Instead, we worried a great deal about > compatibility and interoperability between old versions and new > ones. And we didn't "withdraw" the old documents from the > marketplace, making copies of it essentially unavailable. Good point ... in adopting a proposal such as the two-grade proposal above, changes that break backward compatibility in a significant way should be deemed "too drastic" to permit recycling in grade. But the current doctrine of permitting nothing new at all is counterproductive, IMHO. //cmh From problem-statement-bounces@alvestrand.no Thu Jun 12 18:58:17 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00726 for ; Thu, 12 Jun 2003 18:58:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 60053625A4; Fri, 13 Jun 2003 00:57:47 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8E6D56223F for ; Fri, 13 Jun 2003 00:57:44 +0200 (CEST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h5CMvhM03458 for ; Thu, 12 Jun 2003 15:57:43 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Thu, 12 Jun 2003 15:57:42 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: problem-statement@alvestrand.no In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: The need for smaller protocol specifications X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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, 11 Jun 2003, Pekka Savola wrote: > On Wed, 11 Jun 2003, Juergen Schoenwaelder wrote: > > Serious document reviews take time (a) for the review itself plus (b) > > for the followup discussions (and in my experience b >> a). The only > > reward for such a time investment is (perhaps) being mentioned in the > > acknowledgements section. > > > > To achieve more and better reviews, we simply have to make it more > > attractive for people to spend their time on serious reviews. > > I agree. My experience is that even if you very detailed reviews, people > don't always acknowledge you. Many don't even have the acknowledgements > sections in the drafts. Speaking for myself: (a) I don't care one way or another whether I end up in the acknowledgments section. If, when I do a review, I am able to help provide the polish that makes a specification with the potential to be really good actually achive that potential, then I have more than enough reward. What I don't want is to work (as a reviewer or in any other capacity) on stuff that has no chance whatsoever to be good. (b) I've found that when I get the reward I want -- i.e. of being able to contribute to a quality piece of work -- people are eager to acknowledge my review efforts in the Acknowlegments section. What would make it more sttractive to me to do reviews is greater assurance that at then end of the day a quality spec will result from the work. That seems to happen when (and only when) the raw material that goes in is basically good to start with. YMMV, of course. //cmh From problem-statement-bounces@alvestrand.no Fri Jun 13 08:51:59 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00650 for ; Fri, 13 Jun 2003 08:51:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2CFE2625BC; Fri, 13 Jun 2003 14:51:27 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9245161C78; Fri, 13 Jun 2003 10:12:12 +0200 (CEST) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196])h5D8Busn013028; Fri, 13 Jun 2003 10:11:59 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])h5D88unm145602; Fri, 13 Jun 2003 10:08:57 +0200 Received: from gsine02.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA61850 from ; Fri, 13 Jun 2003 10:08:51 +0200 Message-Id: <3EE986A6.27943343@hursley.ibm.com> Date: Fri, 13 Jun 2003 10:09:10 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: john.loughney@nokia.com References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Cc: ietf-quality@bogus.com Cc: solutions@alvestrand.no Cc: wgchairs@ietf.org Subject: Re: [Solutions] Announcement of COACHES BOF X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > http://www.ietf.org/internet-drafts/draft-carpenter-solution-sirs-00.txt There will be an extensively revised version of this early next week. I would advise people to wait for that rather than commenting on the -00 version. Brian From problem-statement-bounces@alvestrand.no Fri Jun 13 14:29:11 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16929 for ; Fri, 13 Jun 2003 14:29:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7234961C73; Fri, 13 Jun 2003 20:28:38 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0DCFF61A93; Fri, 13 Jun 2003 20:28:36 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19QtHu-0004VB-00; Fri, 13 Jun 2003 13:28:34 -0500 Date: Fri, 13 Jun 2003 14:28:34 -0400 From: John C Klensin To: Harald Tveit Alvestrand Message-ID: <85280637.1055514514@p3.JCK.COM> In-Reply-To: <220930000.1055450830@askvoll.hjemme.alvestrand.no> References: <220930000.1055450830@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/3.0.3 (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: MINOR ISSUE: Putting auditing before criteria X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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, 12 June, 2003 22:47 +0200 Harald Tveit Alvestrand wrote: > Section 2.2 of -issue- reads: > > Some of the key areas where the IETF's practices appear to > need tightening up include: > > o Lack of explicit quality auditing throughout the > standards development process. > > o Lack of written guidelines or templates for the content > of documents (as opposed to the overall layout) and > matching lists of review criteria. > > o Poorly defined success criteria for WGs and individual > documents. > > ISSUE: Quality auditing can only be done by auditing to > criteria or guidelines. You can't make good guidelines without > knowing your success criteria. SUGGESTED RESOLUTION: Swap the > first and third bullets in the list, and change "quality > auditing" to "auditing against criteria for success". Might > want to reword the sequence so that "quality" still appears. Harald, I think this suggestion is correct, but want to caution about another aspect of it. In the "quality improvement" and "quality assurance" communities, a distinction is often made between those activities and "quality auditing". The cynics suggest that quality auditing is about being able to identify the point at which something went wrong, sometimes to more efficiently cast blame, but not about either better quality or guarantees of quality. Unless we have a rather specific plan about what to do with the audits and how to incorporate their results into an improvement process, such audits are likely to rapidly deteriorate into meaningless, time-wasting, bureaucracy and improvements in blame-casting processes. We don't, IMO, need either of those. So, if your change is made, I suggest that a fourth bullet is needed, which might read something like: o Lack of adequate processes for feeding the results of quality audits forward into process improvements and success criteria. In plain English, "quality audits", at their very best, have to do with understanding the nature of the mistakes we have made and when those mistakes occur in the process; if we are going to do them, we need to improve the mechanisms for _learning_ from those mistakes. My personal preference, I think, would be to get rid of the notion of "explicit quality auditing" entirely and to focus this subsection on the need for processes that iteratively improve our criteria for success and for measuring progress and for mechanisms for measuring performance (of WGs, WG Chairs, Editors, ADs, etc) against those criteria. As an example (possibly pointing toward solutions, but intended only to illustrate what I'm talking about), the IESG often has a clear sense of WGs that have gone very well and others that have gone badly. Sometimes the Chairs of those WGs share that perspective, sometimes they rate things differently. But it is, I think, rare for an AD to sit down with the leadership of a WG that has reached its end (or earlier) for an in-depth conversation and analysis of what went well, what went poorly, and what can be learned about how to better facilitate WG work in the future. I think that is a problem. But it isn't about "quality audits" as that term is used by professionals in those fields. regards, john From problem-statement-bounces@alvestrand.no Fri Jun 13 15:02:26 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18781 for ; Fri, 13 Jun 2003 15:02:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 99EB661C73; Fri, 13 Jun 2003 21:01:54 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id C7BDC61A93; Fri, 13 Jun 2003 21:01:52 +0200 (CEST) Date: Fri, 13 Jun 2003 21:01:53 +0200 From: Harald Tveit Alvestrand To: John C Klensin Message-ID: <70860000.1055530913@askvoll.hjemme.alvestrand.no> In-Reply-To: <85280637.1055514514@p3.JCK.COM> References: <220930000.1055450830@askvoll.hjemme.alvestrand.no> <85280637.1055514514@p3.JCK.COM> X-Mailer: Mulberry/2.2.1 (Linux/x86) 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: MINOR ISSUE: Putting auditing before criteria X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 fredag, juni 13, 2003 14:28:34 -0400 John C Klensin wrote: > In plain English, "quality audits", at their very best, have to do with > understanding the nature of the mistakes we have made and when those > mistakes occur in the process; if we are going to do them, we need to > improve the mechanisms for _learning_ from those mistakes. hmm... actually you point at something that touches on a lot of perspective..... > My personal preference, I think, would be to get rid of the notion of > "explicit quality auditing" entirely and to focus this subsection on the > need for processes that iteratively improve our criteria for success and > for measuring progress and for mechanisms for measuring performance (of > WGs, WG Chairs, Editors, ADs, etc) against those criteria. > > As an example (possibly pointing toward solutions, but intended only to > illustrate what I'm talking about), the IESG often has a clear sense of > WGs that have gone very well and others that have gone badly. Sometimes > the Chairs of those WGs share that perspective, sometimes they rate > things differently. But it is, I think, rare for an AD to sit down with > the leadership of a WG that has reached its end (or earlier) for an > in-depth conversation and analysis of what went well, what went poorly, > and what can be learned about how to better facilitate WG work in the > future. I think that is a problem. But it isn't about "quality audits" > as that term is used by professionals in those fields. I left this long quote in because I think it illustrates a point.... there are really multiple purposes at work, at multiple different levels. One limitation/advantage of our WG process is that it tends to bite off reasonable-sized chunks of problem space, chew on them for a while, and spit out documents. *Inside* that process, the purpose of auditing, reviews or whatever we choose to call it is to make sure the result comes out right - and the watchword seems to be "early clue injection" and "no late surprises"; the review process needs to be rapidly fed back to chairs, WGs and document editors, and written reviews are just so many scraps of electronic paper. However, the WG is always a component in a much *larger* process, dealing with the formation, relation, dissolution and retargeting of working groups and activities - and it is that landscape of activity that at the moment has very little explicit management at any level between the IESG and the WG. It is at this level that "learning from the mistakes of the previous WG" comes in - not so much as feedback to *this* WG, but as a lesson in what to do or not do next time. It's a level where I believe the IETF has been flailing for a long time - the phenomenon of "permanent area-like WGs" is one symptom of one attempt to solve the problem without being explicit about it. At this level, recording history may become important - storing not only reviews, but the drafts they were commenting on, as examples of what to avoid and why not.... (if anyone ever bothers reading them.....)? Because the purpose of this review is not to correct *this* action; it is to guide the *next* action. An entirely different kettle of fish. From problem-statement-bounces@alvestrand.no Fri Jun 13 17:28:35 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23789 for ; Fri, 13 Jun 2003 17:28:34 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 76EE762205; Fri, 13 Jun 2003 23:28:03 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail04.zma.compaq.com (mailout.zma.compaq.com [161.114.64.104]) by eikenes.alvestrand.no (Postfix) with ESMTP id 52B9661A96; Fri, 13 Jun 2003 23:28:01 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 1D5D3BABC; Fri, 13 Jun 2003 17:27:59 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 13 Jun 2003 17:27:57 -0400 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="us-ascii" Date: Fri, 13 Jun 2003 17:27:55 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04284A7B@tayexc13.americas.cpqcorp.net> Thread-Topic: MINOR ISSUE: "improvements on the status quo" Thread-Index: AcMxI1ckDxKoU+YJSsGBsHUv2rc/aAAz0F+w From: "Bound, Jim" To: "Harald Tveit Alvestrand" , X-OriginalArrivalTime: 13 Jun 2003 21:27:57.0632 (UTC) FILETIME=[A88F5C00:01C331F2] Subject: RE: MINOR ISSUE: "improvements on the status quo" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA23789 I disagree 2026 does not get at the root problem 2.2 states. the wording now is accurate and correct. my input. /jim > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: Thursday, June 12, 2003 4:44 PM > To: problem-statement@alvestrand.no > Subject: MINOR ISSUE: "improvements on the status quo" > > > No, I'm not finished yet :-) > > Section 2.2 of -issue- reads: > > Engineering requires appropriate trade-offs: Engineering success > needs refinement only to the point of 'fitness for purpose' which > should help to balance the tension between time to market and > perfectionism. The use of appropriate Engineering Practices should, > for example, prevent specifications being recycled in pursuit of > perfection when they are already adequate improvements on > the status > quo. > > ISSUE: "improvements on the status quo" is not the best > formulation - for > new specs, it's unmeasurable; in other cases, it is debatable > whether the > improvements are "adequate". > SUGGESTED RESOLUTION: Use the language from 2026 section > 4.1.1: adequate > "with respect to the requirements placed upon it." > > Of course, appropriate Engineering Practices would be to make > sure we know > what requirements we are placing upon it before evaluating this... > > From problem-statement-bounces@alvestrand.no Sat Jun 14 04:43:12 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21762 for ; Sat, 14 Jun 2003 04:43:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 944756238A; Sat, 14 Jun 2003 10:42:40 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7FCBC62278 for ; Sat, 14 Jun 2003 10:42:38 +0200 (CEST) Date: Sat, 14 Jun 2003 10:42:38 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <113990000.1055580158@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ISSUE: Charter assumed to be only planning document for WGs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit In -issue- section 2.2, this bullet occurs: o Charters regularly fail to set sufficiently granular milestones at which progress of WGs, individuals and documents can be evaluated. ISSUE: This sentence presumes that the charter's job is to be the only plan for the WG. SUGGESTED RESOLUTION: Add ", and more detailed plans are not made" to the end of the sentence. From problem-statement-bounces@alvestrand.no Sat Jun 14 04:45:22 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21793 for ; Sat, 14 Jun 2003 04:45:21 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 55C256238A; Sat, 14 Jun 2003 10:44:51 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5585A62278 for ; Sat, 14 Jun 2003 10:44:49 +0200 (CEST) Date: Sat, 14 Jun 2003 10:44:49 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <114110000.1055580289@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ISSUE: Estimation procedures versus acceptable timeframes unclear X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit In -issue- section 2.2, this bullet occurs: o Better estimation procedures need to be used to determine what the expected delivery timescale for Working Group outputs should be. These estimates must be compared with the acceptable market and customer time frames for the work to be ready, and the scope of the work adjusted if timely delivery appears impossible. This process must be repeated from time to time during the project. ISSUE: This bullet point is framed in terms of solution space. SUGGESTED RESOLUTION: Rephrase as o The acceptable timeframes for finishing a piece of work, and the criteria used to determine them, are rarely if ever explicitly documented. Also, the estimates of the time required to complete the work is often very far from the result. The combination of these sources of error makes adjusting the work to fit the timeframe requirements a very difficult exercise. From problem-statement-bounces@alvestrand.no Sun Jun 15 01:38:21 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11824 for ; Sun, 15 Jun 2003 01:38:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4031762573; Sun, 15 Jun 2003 07:37:42 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id C73B8623CD for ; Sun, 15 Jun 2003 07:37:40 +0200 (CEST) Received: from bs.jck.com ([209.187.148.211] helo=localhost) by bs.jck.com with esmtp (Exim 4.10) id 19RQCw-000DF8-00; Sun, 15 Jun 2003 00:37:38 -0500 Date: Sun, 15 Jun 2003 01:32:31 -0400 From: John C Klensin To: problem-statement@alvestrand.no Message-ID: <14555470.1055640751@localhost> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: rfc-editor@rfc-editor.org Subject: ISSUE: Document subseries name for IETF Administration X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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. I've been studying the most recent draft of 2223bis (draft-rfc-editor-rfc2223bis-05.txt) and it is becoming clear to me that having a document with as much procedural impact as that one published as "informational" is a distortion. Similarly, it seems to me that, despite a number of precedents to the contrary, we should be reserving "BCP" for _network_ Best Practices and not using it for IETF dministrative documents. So... Problem: there is no appropriate document series into which to put IETF Administrative documents so that they can be conveniently located and properly identified without creating confusion with documents that describe, or specify best practices for, the network. And, while I'm at it, having IESG policy statements that have great impact on how the IETF operates available only on a web page that changes seems unsanitary and likely to get us into trouble. So... Problem: IESG "statements" are not published archivally. That is undesirable, and some system of recording them, such as rounding them up annually and publishing them (or the last year's additions and modifications) as an RFC, would be helpful and wise. john From problem-statement-bounces@alvestrand.no Mon Jun 16 06:35:24 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07706 for ; Mon, 16 Jun 2003 06:35:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4E8B962590; Mon, 16 Jun 2003 12:34:53 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 937CD62207 for ; Mon, 16 Jun 2003 12:34:51 +0200 (CEST) Date: Mon, 16 Jun 2003 12:34:51 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <268460000.1055759691@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ISSUE: Misrepresentation of application focus X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 -issue- section 2.3 states: The IETF has historically standardized protocol components rather than complete systems but the current greater emphasis on work in the Applications area tends to require more engineering in the large. ISSUE: The "current greater emphasis" on applications is probably false. SUGGESTED RESOLUTION: Change text to "but as we have learned more about the ways in which systems on the Internet interact, design of components needs to take into account more and more external restraints, and the understanding of these restraints tends to require more engineering in the large." Background: Having watched the applications area pretty carefully over many years, I would say that at the moment, the IETF places a good deal less emphasis on the applications area than it did 3 years ago - mostly because the people doing applications place less emphasis on the IETF; they've gone elsewhere. This may be good or this may be bad (I personally think it's bad, but your mileage may vary) - but I think the document should be corrected on this point. I agree with the statement that we've tended to need more engineering in the large, but I don't think it's correct to "blame" Applications for it. From problem-statement-bounces@alvestrand.no Mon Jun 16 06:36:21 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07738 for ; Mon, 16 Jun 2003 06:36:21 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 58B0D62590; Mon, 16 Jun 2003 12:35:52 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2458E62207 for ; Mon, 16 Jun 2003 12:35:50 +0200 (CEST) Date: Mon, 16 Jun 2003 12:35:50 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <268520000.1055759750@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: MINOR ISSUE: Wording of inter-WG communication mechanisms X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 -issue- section 2.3 says: o The IETF does not posess effective mechanisms for inter-WG cooperation or communication. ISSUE: The informal mechanisms that exist (talk to each other!) are often effective when they work, but invisible to the formal structures. SUGGESTED RESOLUTION: Insert "formal" after "effective". From problem-statement-bounces@alvestrand.no Mon Jun 16 08:27:17 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10365 for ; Mon, 16 Jun 2003 08:27:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5A051625CD; Mon, 16 Jun 2003 14:26:45 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mx-out.daemonmail.net (mx-out.daemonmail.net [216.104.160.39]) by eikenes.alvestrand.no (Postfix) with ESMTP id E94C162207 for ; Mon, 16 Jun 2003 14:26:42 +0200 (CEST) Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.9.3p2/8.9.3) with SMTP id FAA88128 for ; Mon, 16 Jun 2003 05:26:41 -0700 (PDT) (envelope-from spencer@mcsr-labs.org) Received: from (12.237.229.250 [12.237.229.250]) by mail.varaha.com with SMTP id LvM0rzS2 Mon, 16 Jun 2003 05:26:40 -0700 (PDT) Message-ID: <07b301c33402$8b3ac790$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <268520000.1055759750@askvoll.hjemme.alvestrand.no> Date: Mon, 16 Jun 2003 07:26:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: MINOR ISSUE: Wording of inter-WG communication mechanisms X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Dear Harald, I agree with your issue, but your resolution is too subtle. My suggestion is o The IETF does not posess effective mechanisms for inter-WG cooperation or communication beyond expecting people to talk to each other. Spencer ----- Original Message ----- From: "Harald Tveit Alvestrand" To: Sent: Monday, June 16, 2003 5:35 AM Subject: MINOR ISSUE: Wording of inter-WG communication mechanisms > -issue- section 2.3 says: > > o The IETF does not posess effective mechanisms for inter-WG > cooperation or communication. > > ISSUE: The informal mechanisms that exist (talk to each other!) are often > effective when they work, but invisible to the formal structures. > SUGGESTED RESOLUTION: Insert "formal" after "effective". From problem-statement-bounces@alvestrand.no Mon Jun 16 10:15:38 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15420 for ; Mon, 16 Jun 2003 10:15:37 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 960DC625DC; Mon, 16 Jun 2003 16:15:06 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1CD0F625D6; Mon, 16 Jun 2003 16:15:04 +0200 (CEST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id E535DDE28; Mon, 16 Jun 2003 10:14:58 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 16 Jun 2003 10:14:58 -0400 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="us-ascii" Date: Mon, 16 Jun 2003 10:14:57 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04284AEE@tayexc13.americas.cpqcorp.net> Thread-Topic: ISSUE: Estimation procedures versus acceptable timeframes unclear Thread-Index: AcMyUTzfzIzv+QHwQBmNfNQReRvHdwBwGr2Q From: "Bound, Jim" To: "Harald Tveit Alvestrand" , X-OriginalArrivalTime: 16 Jun 2003 14:14:58.0844 (UTC) FILETIME=[AB3C25C0:01C33411] Subject: RE: ISSUE: Estimation procedures versus acceptable timeframes unclear X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA15420 I really like this wording change. /jim > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: Saturday, June 14, 2003 4:45 AM > To: problem-statement@alvestrand.no > Subject: ISSUE: Estimation procedures versus acceptable > timeframes unclear > > > In -issue- section 2.2, this bullet occurs: > > o Better estimation procedures need to be used to > determine what the > expected delivery timescale for Working Group outputs should be. > These estimates must be compared with the acceptable market and > customer time frames for the work to be ready, and the scope of > the work adjusted if timely delivery appears impossible. This > process must be repeated from time to time during the project. > > ISSUE: This bullet point is framed in terms of solution space. > > SUGGESTED RESOLUTION: Rephrase as > o The acceptable timeframes for finishing a piece of work, and the > criteria used to determine them, are rarely if ever > explicitly documented. > Also, the estimates of the time required to complete the work > is often very > far from the result. The combination of these sources of error makes > adjusting the work to fit the timeframe requirements a very difficult > exercise. > > From problem-statement-bounces@alvestrand.no Mon Jun 16 10:56:54 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17034 for ; Mon, 16 Jun 2003 10:56:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 85477625D0; Mon, 16 Jun 2003 16:56:23 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by eikenes.alvestrand.no (Postfix) with ESMTP id 532EA625CD for ; Mon, 16 Jun 2003 16:56:22 +0200 (CEST) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196])h5GEuDPO087532; Mon, 16 Jun 2003 16:56:16 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])h5GEu68j242102; Mon, 16 Jun 2003 16:56:09 +0200 Received: from dhcp22-128.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA55622 from ; Mon, 16 Jun 2003 16:56:03 +0200 Message-Id: <3EEDDA97.DBDCA12F@hursley.ibm.com> Date: Mon, 16 Jun 2003 16:56:23 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: problem-statement@alvestrand.no References: <14555470.1055640751@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: rfc-editor@rfc-editor.org Subject: Re: ISSUE: Document subseries name for IETF Administration X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 John, However, "there are too many document subseries and it's confusing everybody" is not a problem we want to create. So while your point is completely valid, I would like to see simplification elsewehere to go with this complicattion. Brian John C Klensin wrote: > > Hi. > > I've been studying the most recent draft of 2223bis > (draft-rfc-editor-rfc2223bis-05.txt) and it is becoming clear to > me that having a document with as much procedural impact as that > one published as "informational" is a distortion. Similarly, it > seems to me that, despite a number of precedents to the > contrary, we should be reserving "BCP" for _network_ Best > Practices and not using it for IETF dministrative documents. > > So... > > Problem: there is no appropriate document series into which to > put IETF Administrative documents so that they can be > conveniently located and properly identified without creating > confusion with documents that describe, or specify best > practices for, the network. > > And, while I'm at it, having IESG policy statements that have > great impact on how the IETF operates available only on a web > page that changes seems unsanitary and likely to get us into > trouble. So... > > Problem: IESG "statements" are not published archivally. That > is undesirable, and some system of recording them, such as > rounding them up annually and publishing them (or the last > year's additions and modifications) as an RFC, would be helpful > and wise. > > john From problem-statement-bounces@alvestrand.no Mon Jun 16 15:12:02 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26600 for ; Mon, 16 Jun 2003 15:12:01 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1EAB0625E5; Mon, 16 Jun 2003 21:11:30 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id D03E1625D6; Mon, 16 Jun 2003 21:11:27 +0200 (CEST) Date: Mon, 16 Jun 2003 21:11:28 +0200 From: Harald Tveit Alvestrand To: Brian E Carpenter , problem-statement@alvestrand.no Message-ID: <296350000.1055790688@askvoll.hjemme.alvestrand.no> In-Reply-To: <3EEDDA97.DBDCA12F@hursley.ibm.com> References: <14555470.1055640751@localhost> <3EEDDA97.DBDCA12F@hursley.ibm.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: rfc-editor@rfc-editor.org Subject: Re: ISSUE: Document subseries name for IETF Administration X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 mandag, juni 16, 2003 16:56:23 +0200 Brian E Carpenter wrote: > John, > > However, "there are too many document subseries and it's confusing > everybody" is not a problem we want to create. So while your > point is completely valid, I would like to see simplification > elsewehere to go with this complicattion. > > Brian > peeking over into solution space.... part of the problem may be that we're so used to using the RFC series for *everything* that needs to be permanently archived and identifiable. That might not be an optimal strategy going forward.... From problem-statement-bounces@alvestrand.no Mon Jun 16 15:45:17 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27971 for ; Mon, 16 Jun 2003 15:45:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 16EFA625E4; Mon, 16 Jun 2003 21:44:46 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id C1155625D0; Mon, 16 Jun 2003 21:44:43 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19RzuE-000Lw7-00; Mon, 16 Jun 2003 14:44:42 -0500 Date: Mon, 16 Jun 2003 15:44:42 -0400 From: John C Klensin To: Harald Tveit Alvestrand , Brian E Carpenter , "problem-statement@alvestrand.no" Message-ID: <28018358.1055778282@p3.JCK.COM> In-Reply-To: <296350000.1055790688@askvoll.hjemme.alvestrand.no> References: <14555470.1055640751@localhost> <3EEDDA97.DBDCA12F@hursley.ibm.com> <296350000.1055790688@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: "rfc-editor@rfc-editor.org" Subject: Re: ISSUE: Document subseries name for IETF Administration X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On Monday, 16 June, 2003 21:11 +0200 Harald Tveit Alvestrand wrote: > --On mandag, juni 16, 2003 16:56:23 +0200 Brian E Carpenter > wrote: > >> John, >> >> However, "there are too many document subseries and it's >> confusing everybody" is not a problem we want to create. So >> while your point is completely valid, I would like to see >> simplification elsewehere to go with this complicattion. >> >> Brian >> > > peeking over into solution space.... > > part of the problem may be that we're so used to using the RFC > series for *everything* that needs to be permanently archived > and identifiable. > > That might not be an optimal strategy going forward.... I wasn't thinking in terms of taking any of these things out of the RFC Series -- that is a separate topic, at best. Instead, I was suggesting that we consider a subseries, parallel to BCP, for IETF-related administrative or procedural documents. As Scott pointed out in a private note, this would require a change to 2026, both to create the new series and to remove IETF procedural documents from BCP. And we would then presumably have a reclassify the old ones... probably not a big deal --there aren't _that_ many of them although this effort and the IPR WG seem likely to add several more. Borrowing from my response to Scott... The reason for separating them should be [...] obvious. We have had a long-standing tradition (predating the IETF, if I recall) that the RFC Editor and IANA can issue documents that normatively describe their processes and rules for accepting submissions and requests. As long as "not a protocol standard" implied "informational", it wasn't an issue -- everything was in the same subseries. But now we have two problems. The first is that people who are looking for "best practices" documents about network protocols find clutter in the BCP series in the form of IETF administrative procedures. I note, fwiw, that no other SDO I'm aware of merges/ confuses its internal operating procedure documents with its [technical] standards... that just isn't considered mature behavior. The second is that the role and position of IANA and the RFC Editor are significantly changed because we are telling people that informational documents don't count and BCPs do. But BCPs are published only through a Last Call and IESG approval procedure. That doesn't seem right for bodies that are responsible to the IAB and not to the IESG. It is a separate issue whether such documents should require IAB signoff, or IAB signoff with IESG approval, or they should be able to do them on their own as they have in the past, but that issue is impossible to sort out in the BCP context. I don't know whether this is hugely important or not, but it is a "problem" or "issue". If we are going to [re]open the kinds of document categories we have, such as to reduce the number of standards-track maturity levels, it makes sense to examine other categories of RFCs (or whatever) as well, and this one, IMO, belongs on that list of things to be examined. And, of course, if we were to start publishing IESG-produced policy or processing rule statements to provide archival snapshots and a good referencing base at regular intervals (as we do STD1 and for the reasons), this possible series would be a good place to put those statements as well. john From problem-statement-bounces@alvestrand.no Mon Jun 16 15:45:27 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27991 for ; Mon, 16 Jun 2003 15:45:27 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D271D625E9; Mon, 16 Jun 2003 21:44:56 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 95299625D0; Mon, 16 Jun 2003 21:44:50 +0200 (CEST) Date: Mon, 16 Jun 2003 21:44:50 +0200 From: Harald Tveit Alvestrand To: Bob Braden , brian@hursley.ibm.com, problem-statement@alvestrand.no Message-ID: <304540000.1055792690@askvoll.hjemme.alvestrand.no> In-Reply-To: <200306161927.MAA14737@gra.isi.edu> References: <200306161927.MAA14737@gra.isi.edu> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: ISSUE: Document subseries name for IETF Administration X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 mandag, juni 16, 2003 12:27:53 -0700 Bob Braden wrote: > > *> > *> peeking over into solution space.... > *> > *> part of the problem may be that we're so used to using the RFC > series for *> *everything* that needs to be permanently archived and > identifiable. *> > *> That might not be an optimal strategy going forward.... > *> > > > Uh oh. We got here from bad experience with the alternative. > Careful...! Bob, you know more than me about the bad experience (when, where, what and why). Can you share? From problem-statement-bounces@alvestrand.no Mon Jun 16 19:16:12 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08217 for ; Mon, 16 Jun 2003 19:16:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E4D0662595; Tue, 17 Jun 2003 01:15:41 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by eikenes.alvestrand.no (Postfix) with ESMTP id 72BB26230A for ; Mon, 16 Jun 2003 19:21:46 +0200 (CEST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6p2/8.11.2) with ESMTP id h5GHLhi15610; Mon, 16 Jun 2003 10:21:43 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id KAA14554; Mon, 16 Jun 2003 10:19:12 -0700 (PDT) Date: Mon, 16 Jun 2003 10:19:12 -0700 (PDT) Message-Id: <200306161719.KAA14554@gra.isi.edu> To: problem-statement@alvestrand.no, john-ietf@jck.com X-Sun-Charset: US-ASCII X-Mailman-Approved-At: Tue, 17 Jun 2003 01:15:40 +0200 Cc: rfc-editor@rfc-editor.org Subject: Re: ISSUE: Document subseries name for IETF Administration X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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've been studying the most recent draft of 2223bis *> (draft-rfc-editor-rfc2223bis-05.txt) and it is becoming clear to *> me that having a document with as much procedural impact as that *> one published as "informational" is a distortion. Similarly, it *> seems to me that, despite a number of precedents to the *> contrary, we should be reserving "BCP" for _network_ Best *> Practices and not using it for IETF dministrative documents. *> *> *> Problem: there is no appropriate document series into which to *> put IETF Administrative documents so that they can be *> conveniently located and properly identified without creating *> confusion with documents that describe, or specify best *> practices for, the network. *> John, speaking strictly for myself, I find this issue at most unimportant. I don't see that we have a problem with the present situation, and I wonder why the IETF should spend any of its cycles trying to fix something that is not broken. Goodness knows, there are lots of (technical) things that ARE broken in the IETF sphere. Bob Braden From problem-statement-bounces@alvestrand.no Mon Jun 16 19:16:18 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08232 for ; Mon, 16 Jun 2003 19:16:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 87D35625D6; Tue, 17 Jun 2003 01:15:42 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9AFF3625D6; Mon, 16 Jun 2003 21:36:45 +0200 (CEST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6p2/8.11.2) with ESMTP id h5GJaii07230; Mon, 16 Jun 2003 12:36:44 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id MAA14737; Mon, 16 Jun 2003 12:27:53 -0700 (PDT) Date: Mon, 16 Jun 2003 12:27:53 -0700 (PDT) Message-Id: <200306161927.MAA14737@gra.isi.edu> To: brian@hursley.ibm.com, problem-statement@alvestrand.no, harald@alvestrand.no X-Sun-Charset: US-ASCII X-Mailman-Approved-At: Tue, 17 Jun 2003 01:15:40 +0200 Cc: rfc-editor@rfc-editor.org Subject: Re: ISSUE: Document subseries name for IETF Administration X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 *> *> peeking over into solution space.... *> *> part of the problem may be that we're so used to using the RFC series for *> *everything* that needs to be permanently archived and identifiable. *> *> That might not be an optimal strategy going forward.... *> Uh oh. We got here from bad experience with the alternative. Careful...! Bob Braden From problem-statement-bounces@alvestrand.no Mon Jun 16 19:16:28 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08247 for ; Mon, 16 Jun 2003 19:16:27 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5842E625DA; Tue, 17 Jun 2003 01:15:43 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by eikenes.alvestrand.no (Postfix) with ESMTP id E13016233E; Mon, 16 Jun 2003 22:36:44 +0200 (CEST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6p2/8.11.2) with ESMTP id h5GKaii11605; Mon, 16 Jun 2003 13:36:44 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id NAA14756; Mon, 16 Jun 2003 13:33:11 -0700 (PDT) Date: Mon, 16 Jun 2003 13:33:11 -0700 (PDT) Message-Id: <200306162033.NAA14756@gra.isi.edu> To: braden@ISI.EDU, brian@hursley.ibm.com, problem-statement@alvestrand.no, harald@alvestrand.no X-Sun-Charset: US-ASCII X-Mailman-Approved-At: Tue, 17 Jun 2003 01:15:40 +0200 Subject: Re: ISSUE: Document subseries name for IETF Administration X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 *> *> Bob, *> you know more than me about the bad experience (when, where, what and why). *> Can you share? *> Sure. In 1977, the RFC series, which was already 8 years old, dealt mostly with the ARPAnet. In 1977 [D]ARPA began funding research to develop a catenet (internet) of networks, based upon the TCP[/IP] defined in the Kahn/Cerf paper. Jon (and others?) decided that the new project should have a new document series, so they began the Internet Experiment Notes (IEN) series. This continued until 1982; Jon Postel was the editor of both RFCs and IENs. During the 5 year period, he published approximately 200 IENs and 100 RFCs. But Jon found it increasingly difficult to decide which series to use to publish a given document, and the two series caused a lot of confusion in the community. In 1982 he gave up on the IENs and did all further publication related to networking only in the RFC series. Jon came to the conclusion that having a primary numbering space that is mult-dimensional is bound to lead to confusion. There ought to be a single master index sequence number -- the RFC #s -- for all documents in the archive. For secondary categorization, to establish sub-collections, he invented the subseries (STD, FYI, BCP). (I see little reason to restrict the growth of such subseries, BTW, as long as you have the single unique index of RFC #). Bob Braden From problem-statement-bounces@alvestrand.no Mon Jun 16 21:25:47 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12019 for ; Mon, 16 Jun 2003 21:25:46 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6260B62598; Tue, 17 Jun 2003 03:25:15 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id D4B1F61BA7; Tue, 17 Jun 2003 03:25:12 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19S5Dg-0004EH-00; Mon, 16 Jun 2003 18:25:08 -0700 Date: Mon, 16 Jun 2003 21:22:22 -0400 From: Keith Moore To: Bob Braden Message-Id: <20030616212222.48e5788c.moore@cs.utk.edu> In-Reply-To: <200306162033.NAA14756@gra.isi.edu> References: <200306162033.NAA14756@gra.isi.edu> X-Mailer: Sylpheed version 0.8.11 (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 Cc: braden@ISI.EDU Cc: moore@cs.utk.edu Cc: brian@hursley.ibm.com Cc: harald@alvestrand.no Subject: Re: ISSUE: Document subseries name for IETF Administration X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > Sure. In 1977, the RFC series, which was already 8 years old, dealt > mostly with the ARPAnet. In 1977 [D]ARPA began funding research to > develop a catenet (internet) of networks, based upon the TCP[/IP] > defined in the Kahn/Cerf paper. Jon (and others?) decided that the new > project should have a new document series, so they began the Internet > Experiment Notes (IEN) series. This continued until 1982; Jon Postel > was the editor of both RFCs and IENs. During the 5 year period, he > published approximately 200 IENs and 100 RFCs. > > But Jon found it increasingly difficult to decide which series to use > to publish a given document, and the two series caused a lot of > confusion in the community. In 1982 he gave up on the IENs and did all > further publication related to networking only in the RFC series. > > Jon came to the conclusion that having a primary numbering space that > is mult-dimensional is bound to lead to confusion. There ought to be a > single master index sequence number -- the RFC #s -- for all documents > in the archive. For secondary categorization, to establish > sub-collections, he invented the subseries (STD, FYI, BCP). > (I see little reason to restrict the growth of such subseries, > BTW, as long as you have the single unique index of RFC #). A conclusion that was valid in 1982 with ~900 documents in the library might not be valid 21 years later with ~3500 documents in the library. We have some single protocols now with more pages of specification, and more documents, than the entire Internet protocol suite had in 1982. To be sure, there's nothing wrong with assigning a serial number to each document, any more than assigning an ISBN to each book published. But we don't tend to refer to such works by their ISBNs except in very specific contexts. And we do find other kinds of document classification useful. From problem-statement-bounces@alvestrand.no Tue Jun 17 11:55:42 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23905 for ; Tue, 17 Jun 2003 11:55:41 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 38F846256B; Tue, 17 Jun 2003 17:55:10 +0200 (CEST) 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 2BD62622AF; Tue, 17 Jun 2003 17:55:07 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h5HFwGF03958; Tue, 17 Jun 2003 08:58:16 -0700 Date: Tue, 17 Jun 2003 08:54:11 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/10) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <18734256087.20030617085411@brandenburg.com> To: Harald Tveit Alvestrand In-Reply-To: <296350000.1055790688@askvoll.hjemme.alvestrand.no> References: <14555470.1055640751@localhost> <3EEDDA97.DBDCA12F@hursley.ibm.com> <296350000.1055790688@askvoll.hjemme.alvestrand.no> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Cc: Brian E Carpenter Cc: rfc-editor@rfc-editor.org Subject: Document Retention X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 HTA> part of the problem may be that we're so used to using the RFC series for HTA> *everything* that needs to be permanently archived and identifiable. In fact we should consider carefully what purposes there are in retention, and should consider responding to them differentially. Example purposes that might warrant different retention policies: - scientific posterity - use in current operational systems - aid research on prior art - use in legal challenges of IETF process - general education of participants - specific review of wg discussion and decision history We currently have 3 retention policies: 1. Permanaent / Ready access -- RFCs 2. Officially short term / Actually maybe permanent / Obscure access -- I-Ds 3. Random -- WG mailing lists Gaining some agreement on our needs and then gaining some agreement on the ways to satisfy them would seem to be quite helpful. I have come to believe that we need two different sets of permanant archives. One for official publications, namely RFCs. The other is for use in the various research efforts, both legal and technical, that crop up. For these latter efforts, wg mailing lists, I-Ds, and the like should be accessible, but lack any formal status. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue Jun 17 12:22:22 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25277 for ; Tue, 17 Jun 2003 12:22:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8CE366256B; Tue, 17 Jun 2003 18:21:51 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by eikenes.alvestrand.no (Postfix) with ESMTP id 30232622AF; Tue, 17 Jun 2003 18:21:49 +0200 (CEST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6p2/8.11.2) with ESMTP id h5HGLli12403; Tue, 17 Jun 2003 09:21:47 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id JAA15135; Tue, 17 Jun 2003 09:13:41 -0700 (PDT) Date: Tue, 17 Jun 2003 09:13:41 -0700 (PDT) Message-Id: <200306171613.JAA15135@gra.isi.edu> To: braden@ISI.EDU, moore@cs.utk.edu X-Sun-Charset: US-ASCII Cc: problem-statement@alvestrand.no Cc: brian@hursley.ibm.com Cc: harald@alvestrand.no Subject: Re: ISSUE: Document subseries name for IETF Administration X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 *> To be sure, there's nothing wrong with assigning a serial number to *> each document, any more than assigning an ISBN to each book published. *> But we don't tend to refer to such works by their ISBNs except in very *> specific contexts. And we do find other kinds of document classification *> useful. *> Keith, Maybe it would be different if there were a total of about 3500 books in the ISBN series. Bob Braden From problem-statement-bounces@alvestrand.no Tue Jun 17 12:42:51 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25918 for ; Tue, 17 Jun 2003 12:42:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 684CA6256B; Tue, 17 Jun 2003 18:42:20 +0200 (CEST) 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 3AEDF622AF; Tue, 17 Jun 2003 18:42:17 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h5HGjRF06674; Tue, 17 Jun 2003 09:45:27 -0700 Date: Tue, 17 Jun 2003 09:42:09 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/10) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <12737134015.20030617094209@brandenburg.com> To: Harald Tveit Alvestrand In-Reply-To: <296350000.1055790688@askvoll.hjemme.alvestrand.no> References: <14555470.1055640751@localhost> <3EEDDA97.DBDCA12F@hursley.ibm.com> <296350000.1055790688@askvoll.hjemme.alvestrand.no> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Cc: rfc-editor@rfc-editor.org Subject: Document Retention X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 HTA> part of the problem may be that we're so used to using the RFC series for HTA> *everything* that needs to be permanently archived and identifiable. In fact we should consider carefully what purposes there are in retention, and should consider responding to them differentially. Example purposes that might warrant different retention policies: - scientific posterity - use in current operational systems - aid research on prior art - use in legal challenges of IETF process - general education of participants - specific review of wg discussion and decision history We currently have 3 retention policies: 1. Permanaent / Ready access -- RFCs 2. Officially short term / Actually maybe permanent / Obscure access -- I-Ds 3. Random -- WG mailing lists Gaining some agreement on our needs and then gaining some agreement on the ways to satisfy them would seem to be quite helpful. I have come to believe that we need two different sets of permanant archives. One for official publications, namely RFCs. The other is for use in the various research efforts, both legal and technical, that crop up. For these latter efforts, wg mailing lists, I-Ds, and the like should be accessible, but lack any formal status. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Thu Jun 19 03:33:24 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03353 for ; Thu, 19 Jun 2003 03:33:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9CFAD625BA; Thu, 19 Jun 2003 09:32:53 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2C5C8625A5 for ; Thu, 19 Jun 2003 09:32:52 +0200 (CEST) Date: Thu, 19 Jun 2003 09:32:52 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <598210000.1056007972@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: MINOR ISSUE: Perception of Kobe X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 -issue- says: 2.5 The IETF Management Structure is not Matched to the Current Size and Complexity of the IETF The management and technical review processes currently in place were adequate for the older, smaller organization, but are apparently not scalable to the current size of the organization. One set of changes has already been made with the Internet Engineering Steering Group (IESG) taking over some of the functions of the Internet Architecture Board (IAB) as a result of the Kobe agreement in 1992, but that is now a long time ago, and the organization has undergone considerable further growth as well as extending the scope of its activities as the Internet has become more complex. ISSUE: The Kobe changes did not address scaling at all (see Crocker's description) SUGGESTED RESOLUTION: Replace "One set of changes.....1992" with "The form of the organization has not been significantly modified since 1992". (BTW, it was not the "Kobe agreement" - the events at Kobe provided the trigger for the process that led to the POISED WG and its output) From problem-statement-bounces@alvestrand.no Thu Jun 19 03:35:40 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03409 for ; Thu, 19 Jun 2003 03:35:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 89EB6625BA; Thu, 19 Jun 2003 09:35:09 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id A9496625A5 for ; Thu, 19 Jun 2003 09:35:08 +0200 (CEST) Date: Thu, 19 Jun 2003 09:35:09 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <598360000.1056008109@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: MISSING ISSUE: Overload on IESG not mentioned X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit In -issues- section 2.5, I think there is data missing. The most closely related section is 2.5.1, "Span of authority". ISSUE: The problem raised in [WRONG] as "The AD's job can't be done well", pointing out that the jobs currently assigned to the AD role are more than one can reasonably expect people to handle, is not reflected here. This has a number of damaging effects. SUGGESTED RESOLUTION: Add a new subsection called "Workload on the IESG", stealing liberally from [WRONG] for specific words. [WRONG] = http://www.alvestrand.no/ietf/chair/what-is-wrong.html From problem-statement-bounces@alvestrand.no Thu Jun 19 03:37:54 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03474 for ; Thu, 19 Jun 2003 03:37:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 253F6625C1; Thu, 19 Jun 2003 09:37:23 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 55B7D625A5 for ; Thu, 19 Jun 2003 09:37:21 +0200 (CEST) Date: Thu, 19 Jun 2003 09:37:21 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <598500000.1056008241@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ISSUE: Do not agree with "formal recognition" section X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit In -issue- section 2.5.4, I read: 2.5.4 Lack of Formal Recognition outside IESG and IAB The small number of formally recognized 'preferred' positions within the IETF, also limits the (intangible) rewards for participants. This can lead to useful and effective participants leaving because they cannot obtain any recognition (the only currency the IETF has to pay participants), which they use to fuel their own enthusiasm and help justify their continued attendance at IETF meetings to cost constrained employers. ISSUE: This section does not mention the recognition of authorship, directorate membership or being a WG chair. Nor does it recognize "thank you" sections. It is also probably not at all healthy for the IETF if one were to hand out positions of authority as rewards for good conduct. SUGGESTED RESOLUTION: Move the section out of 2.5. Drop "outside IESG and IAB" from title. Change the first sentence to "Beyond RFC authorship, WG chair positions, Directorate positions or IESG and IAB membership positions, the IETF does not offer formal recognition of contributions to the IETF." Add a last sentence saying "Note: Using leadership positions as rewards for good work would probably be damaging to the IETF. This paragraph is meant to indicate the need for other types of rewards." From problem-statement-bounces@alvestrand.no Thu Jun 19 03:43:17 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03536 for ; Thu, 19 Jun 2003 03:43:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F3A21625BA; Thu, 19 Jun 2003 09:42:45 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2E39C625A5 for ; Thu, 19 Jun 2003 09:42:44 +0200 (CEST) Date: Thu, 19 Jun 2003 09:42:44 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <598880000.1056008564@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 [Yes, I'm posting more than my usual quota of two issues per day today. But I've been lax in keeping up, and I DO want the discussion on issues, if any, to have a chance of converging before Vienna. But this is it for today.] [Note: This message has two issues, but they concern the same paragraph.] -issue- reads: 2.5.5 Concentration of Influence in Too Few Hands Until the last couple of years, successive IETF Nominating Committees have chosen to give heavy weighting to continuity of IESG and IAB membership. Thus, the IETF appeared to have created a 'ruling class' system which tended to re-select the same leaders from a limited pool of people who had proved competent and committed in the past. Members of this 'ruling class' tend to talk more freely to each other and former members of the 'ruling class' - this may be because the 'ruling class' has also come to share a cultural outlook which matches the dominant ethos of the IETF. Newcomers to the organization and others outside the 'ruling class' are reluctant to challenge the apparent authority of the extended 'ruling class' during debates and consequently influence remains concentrated in a relatively small group of people. This reluctance may also be exacerbated if participants come from a different cultural background than the dominant one. ISSUE: Yes, I have issues with this paragraph. I percieve the distinction more in terms of trust networks than in terms of classes - and the trust networks of most of the percieved "ruling class" described here are, as far as I can percieve, rarely if ever inclusive of the whole class, are quite changeable, and have lots of members who are not members of any unified "class". This is related to my problem stated as "the IETF runs on personal networks". SUGGESTED RESOLUTION: None. This appears to be a viewpoint held by others. So I'll just state that I disagree. ISSUE: The problem identified in [WRONG] as excessive reliance on personal relationships is not reflected anywhere in section 2.5. Its closest relation is 2.5.5, but the focus seems different. SUGGESTED RESOLUTION: Adapt text from [WRONG]. [WRONG] = http://www.alvestrand.no/ietf/chair/what-is-wrong.html From problem-statement-bounces@alvestrand.no Thu Jun 19 07:36:43 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09743 for ; Thu, 19 Jun 2003 07:36:42 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D5C036256C; Thu, 19 Jun 2003 13:36:09 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2BAA86238A for ; Thu, 19 Jun 2003 13:36:07 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h5JBa276083606 for ; Thu, 19 Jun 2003 13:36:02 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])h5JBZvKs241046 for ; Thu, 19 Jun 2003 13:36:00 +0200 Received: from dhcp22-128.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA93056 from ; Thu, 19 Jun 2003 13:35:55 +0200 Message-Id: <3EF1A02F.A604D2AC@hursley.ibm.com> Date: Thu, 19 Jun 2003 13:36:15 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: problem-statement@alvestrand.no References: <598880000.1056008564@askvoll.hjemme.alvestrand.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 agree with Harald's slant on this. The new wording is much better than in the previous draft, but it still seems to state a perception as if were were an objective fact. A fairly liberal addition of "perceived" to the text would help, starting with the title: 2.5.5. Perceived Concentration of Influence in Too Few Hands Also, let me focus on one sentence: > ...this may be because the > 'ruling class' has also come to share a cultural outlook which > matches the dominant ethos of the IETF. It's hard to see why this is a problem. It says that the leadership shares the dominant view. That is a compliment in any democracy. Apart from that, the paragraph describes characteristics of human society, not those specific to the IETF. Brian Harald Tveit Alvestrand wrote: > > [Yes, I'm posting more than my usual quota of two issues per day today. > But I've been lax in keeping up, and I DO want the discussion on issues, if > any, to have a chance of converging before Vienna. But this is it for > today.] > [Note: This message has two issues, but they concern the same paragraph.] > > -issue- reads: > > 2.5.5 Concentration of Influence in Too Few Hands > > Until the last couple of years, successive IETF Nominating Committees > have chosen to give heavy weighting to continuity of IESG and IAB > membership. Thus, the IETF appeared to have created a 'ruling class' > system which tended to re-select the same leaders from a limited pool > of people who had proved competent and committed in the past. > > Members of this 'ruling class' tend to talk more freely to each other > and former members of the 'ruling class' - this may be because the > 'ruling class' has also come to share a cultural outlook which > matches the dominant ethos of the IETF. Newcomers to the organization > and others outside the 'ruling class' are reluctant to challenge the > apparent authority of the extended 'ruling class' during debates and > consequently influence remains concentrated in a relatively small > group of people. This reluctance may also be exacerbated if > participants come from a different cultural background than the > dominant one. > > ISSUE: Yes, I have issues with this paragraph. I percieve the distinction > more in terms of trust networks than in terms of classes - and the trust > networks of most of the percieved "ruling class" described here are, as far > as I can percieve, rarely if ever inclusive of the whole class, are quite > changeable, and have lots of members who are not members of any unified > "class". This is related to my problem stated as "the IETF runs on personal > networks". > SUGGESTED RESOLUTION: None. This appears to be a viewpoint held by others. > So I'll just state that I disagree. > > ISSUE: The problem identified in [WRONG] as excessive reliance on personal > relationships is not reflected anywhere in section 2.5. Its closest > relation is 2.5.5, but the focus seems different. > SUGGESTED RESOLUTION: Adapt text from [WRONG]. > > [WRONG] = http://www.alvestrand.no/ietf/chair/what-is-wrong.html From problem-statement-bounces@alvestrand.no Thu Jun 19 07:46:26 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10302 for ; Thu, 19 Jun 2003 07:46:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 802F36256F; Thu, 19 Jun 2003 13:45:54 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8B4DA6238A for ; Thu, 19 Jun 2003 13:45:52 +0200 (CEST) Date: Thu, 19 Jun 2003 13:45:53 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <640300000.1056023153@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Erik Nordmark: stepping down (fwd) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 thought this statement was worthy of the problem WG's attention. Harald ---------- Forwarded Message ---------- Date: mandag, juni 09, 2003 16:26:11 -0400 From: Erik Nordmark To: IETF-Announce Cc: Subject: stepping down I've chosen to step down from the IESG early - my term would normally end at the spring IETF 2004. This was not an easy decision to make, especially since I really enjoy the learning aspects - being exposed to a much wider range of issues than I would otherwise - as well as being able to help and guide working groups and WG chairs. However, I feel that over the last 6 months or so I've become less and less able to make forward progress, with even my simple tasks taking months to complete. Due to the workload I've also lost the ability to make significant contributions to the IETF on technical issues that I think are quite important for the future of the Internet, which I find frustrating. Considering this, I feel that the community would be better served by having the opportunity to find someone else to hold the AD post for the remainder of my term. The only realistic alternative would have been to sacrifice more of nights and weekends to try to make some forward progress, but I'd prefer to not encroach further on the time I have for family and friends. To make sure there isn't any confusion: this is a personal decision. My management at Sun has provided full support for my being on the IESG and they would be very willing to continue to do so. I'll continue being active in the IETF - being able to spend more time on important technical issues. Finally I'd like to thank my co-AD Thomas, all of the IESG and IAB members, WG chairs, and other participants I've had a pleasure to work with; it's been a very rewarding experience and if there were only more hours in a day I would have liked to continue. Erik ---------- End Forwarded Message ---------- From problem-statement-bounces@alvestrand.no Thu Jun 19 07:53:45 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10451 for ; Thu, 19 Jun 2003 07:53:44 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 17EB8625A5; Thu, 19 Jun 2003 13:53:13 +0200 (CEST) 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 4EADE6238A; Thu, 19 Jun 2003 13:53:11 +0200 (CEST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])h5JBrA922126; Thu, 19 Jun 2003 14:53:10 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com ; Thu, 19 Jun 2003 14:53:08 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 19 Jun 2003 14:53:09 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 19 Jun 2003 14:53:08 +0300 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" Date: Thu, 19 Jun 2003 14:53:01 +0300 Message-ID: Thread-Topic: Erik Nordmark: stepping down (fwd) Thread-Index: AcM2WGnNh0gf6kl+TQiPatnQfmJIMQAAHY4w From: To: , X-OriginalArrivalTime: 19 Jun 2003 11:53:08.0880 (UTC) FILETIME=[5A23F100:01C33659] Cc: Erik.Nordmark@sun.com Subject: RE: Erik Nordmark: stepping down (fwd) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA10451 Harald & Erik, It seems that Erik's message is carefully worded to avoid placing blame. As such, I have some trouble understanding the implications of Erik's statement below. Would an 'exit interview' be appropriate or at least some comments wrt the problem statement to help us to improve the process? It is a shame to lose talented and committed folks from the IETF leadership. thanks, John > -----Original Message----- > From: ext Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: 19 June, 2003 14:46 > To: problem-statement@alvestrand.no > Subject: Erik Nordmark: stepping down (fwd) > > > I thought this statement was worthy of the problem WG's attention. > > Harald > > ---------- Forwarded Message ---------- > Date: mandag, juni 09, 2003 16:26:11 -0400 > From: Erik Nordmark > To: IETF-Announce > Cc: > Subject: stepping down > > I've chosen to step down from the IESG early - my term would normally > end at the spring IETF 2004. > > This was not an easy decision to make, especially since I really > enjoy the learning aspects - being exposed to a much wider range > of issues than I would otherwise - as well as being able to > help and guide > working groups and WG chairs. > > However, I feel that over the last 6 months or so I've > become less and > less able to make forward progress, with even my simple > tasks taking months > to complete. Due to the workload I've also lost the ability to make > significant contributions to the IETF on technical issues > that I think are > quite important for the future of the Internet, which I find > frustrating. > > Considering this, I feel that the community would be better served by > having the opportunity to find someone else to hold the AD > post for the > remainder of my term. > > The only realistic alternative would have been to sacrifice more of > nights and weekends to try to make some forward progress, > but I'd prefer > to not encroach further on the time I have for family and friends. > > To make sure there isn't any confusion: this is a personal decision. > My management at Sun has provided full support for my being > on the IESG > and they would be very willing to continue to do so. > > I'll continue being active in the IETF - being able to spend > more time > on important technical issues. > > Finally I'd like to thank my co-AD Thomas, all of the IESG > and IAB members, > WG chairs, and other participants I've had a pleasure to > work with; it's > been a very rewarding experience and if there were only more > hours in a day > I would have liked to continue. > > Erik > > > > > ---------- End Forwarded Message ---------- > > > From problem-statement-bounces@alvestrand.no Thu Jun 19 08:08:48 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11258 for ; Thu, 19 Jun 2003 08:08:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DA5446256C; Thu, 19 Jun 2003 14:08:16 +0200 (CEST) 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 6AB676238A for ; Thu, 19 Jun 2003 14:08:14 +0200 (CEST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])h5JC8D904576 for ; Thu, 19 Jun 2003 15:08:13 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com ; Thu, 19 Jun 2003 15:08:11 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 19 Jun 2003 15:08:13 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 19 Jun 2003 15:08:13 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 19 Jun 2003 15:08:12 +0300 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" Date: Thu, 19 Jun 2003 15:08:11 +0300 Message-ID: Thread-Topic: MAJOR ISSUE: "Concentration of power" Thread-Index: AcM2VwmSQnIcstChSU27HjpSuhDskwAAlo1w From: To: , X-OriginalArrivalTime: 19 Jun 2003 12:08:12.0762 (UTC) FILETIME=[74E563A0:01C3365B] Subject: RE: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA11258 Hi all, I agree with Harald's 'slant' as well, but not with the wording which Brian has also commented. In particular: > > ...this may be because the > > 'ruling class' has also come to share a cultural outlook which > > matches the dominant ethos of the IETF. The problem I have with the above statement is that it is implying that there is a dominant ethos. Refering to a definition of 'ethos': The character, sentiment, or disposition of a community or people, considered as a natural endowment; the spirit which actuates manners and customs; I would suggest that several folks actually have 'accused' the IESG of believing that their cultural outlook IS the dominant ethos of the IETF (said accusers implying that the IESG's outlook does not match the outlook of the rank & file IETFer). Therefore, I humbly request that you strike the sentence as it is potentially loaded with implications which there may not be a consensus for. Also, in light of the fact that the IETF's mission is not clear, I am unsure if we could agree on the IETF's ethos either. However, I think what might have been trying to be said about the percieved concentration of power is that 'birds of a feather flock together' ... The other side of the coin may be to say that concentration of the gene pool is not benefitial for long-term survial. br, John > -----Original Message----- > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: 19 June, 2003 14:36 > To: problem-statement@alvestrand.no > Subject: Re: MAJOR ISSUE: "Concentration of power" > > > I agree with Harald's slant on this. The new wording is much better > than in the previous draft, but it still seems to state a > perception as > if were were an objective fact. A fairly liberal addition of > "perceived" > to the text would help, starting with the title: > > 2.5.5. Perceived Concentration of Influence in Too Few Hands > > Also, let me focus on one sentence: > > > ...this may be because the > > 'ruling class' has also come to share a cultural outlook which > > matches the dominant ethos of the IETF. > > It's hard to see why this is a problem. It says that the leadership > shares the dominant view. That is a compliment in any democracy. > > Apart from that, the paragraph describes characteristics of human > society, not those specific to the IETF. > > Brian > > Harald Tveit Alvestrand wrote: > > > > [Yes, I'm posting more than my usual quota of two issues > per day today. > > But I've been lax in keeping up, and I DO want the > discussion on issues, if > > any, to have a chance of converging before Vienna. But this > is it for > > today.] > > [Note: This message has two issues, but they concern the > same paragraph.] > > > > -issue- reads: > > > > 2.5.5 Concentration of Influence in Too Few Hands > > > > Until the last couple of years, successive IETF > Nominating Committees > > have chosen to give heavy weighting to continuity of IESG and IAB > > membership. Thus, the IETF appeared to have created a > 'ruling class' > > system which tended to re-select the same leaders from a > limited pool > > of people who had proved competent and committed in the past. > > > > Members of this 'ruling class' tend to talk more freely > to each other > > and former members of the 'ruling class' - this may be > because the > > 'ruling class' has also come to share a cultural outlook which > > matches the dominant ethos of the IETF. Newcomers to the > organization > > and others outside the 'ruling class' are reluctant to > challenge the > > apparent authority of the extended 'ruling class' during > debates and > > consequently influence remains concentrated in a relatively small > > group of people. This reluctance may also be exacerbated if > > participants come from a different cultural background than the > > dominant one. > > > > ISSUE: Yes, I have issues with this paragraph. I percieve > the distinction > > more in terms of trust networks than in terms of classes - > and the trust > > networks of most of the percieved "ruling class" described > here are, as far > > as I can percieve, rarely if ever inclusive of the whole > class, are quite > > changeable, and have lots of members who are not members of > any unified > > "class". This is related to my problem stated as "the IETF > runs on personal > > networks". > > SUGGESTED RESOLUTION: None. This appears to be a viewpoint > held by others. > > So I'll just state that I disagree. > > > > ISSUE: The problem identified in [WRONG] as excessive > reliance on personal > > relationships is not reflected anywhere in section 2.5. Its closest > > relation is 2.5.5, but the focus seems different. > > SUGGESTED RESOLUTION: Adapt text from [WRONG]. > > > > [WRONG] = http://www.alvestrand.no/ietf/chair/what-is-wrong.html > From problem-statement-bounces@alvestrand.no Thu Jun 19 10:49:48 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22647 for ; Thu, 19 Jun 2003 10:49:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 65FC96256F; Thu, 19 Jun 2003 16:49:17 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by eikenes.alvestrand.no (Postfix) with ESMTP id 786516238A for ; Thu, 19 Jun 2003 16:49:15 +0200 (CEST) Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4845053 for problem-statement@alvestrand.no; Thu, 19 Jun 2003 10:49:12 -0400 Message-Id: <5.1.0.14.0.20030619104326.0206c2c0@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 19 Jun 2003 10:49:05 -0400 To: problem-statement@alvestrand.no From: "Joel M. Halpern" In-Reply-To: <598880000.1056008564@askvoll.hjemme.alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 agree with both of Harald's characterizations below. Some folks will argue that the "tend to talk more freely" covers what might be called the corner cases Harald refers to. However, I think that by its structure this section misses the point. If, as I suspect, the folks who have talked about the IETF operating on personal trust are correct, then this ('ruling class' tending to talk to itself) is merely a symptom. Folks who have worked together extensively will tend to develop an understanding of each other, and this fosters a useful trust model which encourages personal communication. I will tend to talk more with folks I have worked with even when I disagree with them because I know how to interact with them. I think that the core issue is the reliance on inter-personal trust and inter-personal communication rather than an actual concentration of power as described. I will also note that when the argument about reappointment of the same people was raised (as described in the paragraph) I reviewed the data. It is quite clear that for the last 10 years the turnover rate has been quite reasonable and would meet any sensible statistical standard. Yours, Joel M. Halpern At 09:42 AM 6/19/2003 +0200, Harald Tveit Alvestrand wrote: >[Yes, I'm posting more than my usual quota of two issues per day today. >But I've been lax in keeping up, and I DO want the discussion on issues, >if any, to have a chance of converging before Vienna. But this is it for >today.] >[Note: This message has two issues, but they concern the same paragraph.] > >-issue- reads: > >2.5.5 Concentration of Influence in Too Few Hands > > Until the last couple of years, successive IETF Nominating Committees > have chosen to give heavy weighting to continuity of IESG and IAB > membership. Thus, the IETF appeared to have created a 'ruling class' > system which tended to re-select the same leaders from a limited pool > of people who had proved competent and committed in the past. > > Members of this 'ruling class' tend to talk more freely to each other > and former members of the 'ruling class' - this may be because the > 'ruling class' has also come to share a cultural outlook which > matches the dominant ethos of the IETF. Newcomers to the organization > and others outside the 'ruling class' are reluctant to challenge the > apparent authority of the extended 'ruling class' during debates and > consequently influence remains concentrated in a relatively small > group of people. This reluctance may also be exacerbated if > participants come from a different cultural background than the > dominant one. > >ISSUE: Yes, I have issues with this paragraph. I percieve the distinction >more in terms of trust networks than in terms of classes - and the trust >networks of most of the percieved "ruling class" described here are, as >far as I can percieve, rarely if ever inclusive of the whole class, are >quite changeable, and have lots of members who are not members of any >unified "class". This is related to my problem stated as "the IETF runs on >personal networks". >SUGGESTED RESOLUTION: None. This appears to be a viewpoint held by others. >So I'll just state that I disagree. > > >ISSUE: The problem identified in [WRONG] as excessive reliance on personal >relationships is not reflected anywhere in section 2.5. Its closest >relation is 2.5.5, but the focus seems different. >SUGGESTED RESOLUTION: Adapt text from [WRONG]. > >[WRONG] = http://www.alvestrand.no/ietf/chair/what-is-wrong.html From problem-statement-bounces@alvestrand.no Thu Jun 19 10:59:11 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22912 for ; Thu, 19 Jun 2003 10:59:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EFBE76256F; Thu, 19 Jun 2003 16:58:40 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by eikenes.alvestrand.no (Postfix) with ESMTP id 21C0F6238A for ; Thu, 19 Jun 2003 16:58:39 +0200 (CEST) Received: from cisco.com (sjc-vpn2-391.cisco.com [10.21.113.135]) by sj-core-3.cisco.com (8.12.6/8.12.6) with SMTP id h5JEwZlQ023905 for ; Thu, 19 Jun 2003 07:58:36 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Thu, 19 Jun 2003 10:58:33 -0400 Date: Thu, 19 Jun 2003 10:58:33 -0400 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030619145832.GM2044@sbrim-w2k01> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: <598880000.1056008564@askvoll.hjemme.alvestrand.no> <5.1.0.14.0.20030619104326.0206c2c0@mail.stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.0.20030619104326.0206c2c0@mail.stevecrocker.com> User-Agent: Mutt/1.4i Subject: Re: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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, Jun 19, 2003 10:49:05AM -0400, Joel M. Halpern allegedly wrote: > If, as I suspect, the folks who have talked about the IETF operating > on personal trust are correct, then this ('ruling class' tending to > talk to itself) is merely a symptom. Folks who have worked together > extensively will tend to develop an understanding of each other, and > this fosters a useful trust model which encourages personal > communication. I will tend to talk more with folks I have worked with > even when I disagree with them because I know how to interact with > them. I think that the core issue is the reliance on inter-personal > trust and inter-personal communication rather than an actual > concentration of power as described. I would say the problem is not even reliance on personal trust, since that is essential. How about: there are no explicit IETF mechanisms which make it easy for newer people to enter into those webs of personal trust. The reliance on personal communication is a problem, and especially as Harald pointed out, the reliance on personal knowledge for institutional memory. .swb From problem-statement-bounces@alvestrand.no Thu Jun 19 16:05:54 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15913 for ; Thu, 19 Jun 2003 16:05:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BCD14625A5; Thu, 19 Jun 2003 22:05:23 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5BCFE62577; Thu, 19 Jun 2003 22:05:20 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h5JK5GN00250; Thu, 19 Jun 2003 16:05:18 -0400 (EDT) Date: Thu, 19 Jun 2003 16:05:16 -0400 From: Keith Moore To: Harald Tveit Alvestrand Message-Id: <20030619160516.3506015d.moore@cs.utk.edu> In-Reply-To: <598880000.1056008564@askvoll.hjemme.alvestrand.no> References: <598880000.1056008564@askvoll.hjemme.alvestrand.no> X-Mailer: Sylpheed version 0.9.2 (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 Cc: moore@cs.utk.edu Subject: Re: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit I'm very much in agreement with Harald's model of trust networks within IETF. I'm not so sure about excessive reliance on personal relationships, but I think it's an interesting viewpoint which is worthy of further examination. Keith > I percieve the > distinction more in terms of trust networks than in terms of classes - > and the trust networks of most of the percieved "ruling class" > described here are, as far as I can percieve, rarely if ever inclusive > of the whole class, are quite changeable, and have lots of members who > are not members of any unified "class". This is related to my problem > stated as "the IETF runs on personal networks". > SUGGESTED RESOLUTION: None. This appears to be a viewpoint held by > others. So I'll just state that I disagree. > > > ISSUE: The problem identified in [WRONG] as excessive reliance on > personal relationships is not reflected anywhere in section 2.5. Its > closest relation is 2.5.5, but the focus seems different. > SUGGESTED RESOLUTION: Adapt text from [WRONG]. > > [WRONG] = http://www.alvestrand.no/ietf/chair/what-is-wrong.html From problem-statement-bounces@alvestrand.no Thu Jun 19 16:07:20 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16012 for ; Thu, 19 Jun 2003 16:07:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 55720625A5; Thu, 19 Jun 2003 22:06:51 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 40E5A62577; Thu, 19 Jun 2003 22:06:49 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h5JK6lN00255; Thu, 19 Jun 2003 16:06:47 -0400 (EDT) Date: Thu, 19 Jun 2003 16:06:47 -0400 From: Keith Moore To: Harald Tveit Alvestrand Message-Id: <20030619160647.12e814b2.moore@cs.utk.edu> In-Reply-To: <598360000.1056008109@askvoll.hjemme.alvestrand.no> References: <598360000.1056008109@askvoll.hjemme.alvestrand.no> X-Mailer: Sylpheed version 0.9.2 (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 Cc: moore@cs.utk.edu Subject: Re: MISSING ISSUE: Overload on IESG not mentioned X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 strongly agree. this is a huge omission in the current document. Keith > In -issues- section 2.5, I think there is data missing. > The most closely related section is 2.5.1, "Span of authority". > > ISSUE: The problem raised in [WRONG] as "The AD's job can't be done > well", pointing out that the jobs currently assigned to the AD role > are more than one can reasonably expect people to handle, is not > reflected here. This has a number of damaging effects. > > SUGGESTED RESOLUTION: Add a new subsection called "Workload on the > IESG", stealing liberally from [WRONG] for specific words. > > [WRONG] = http://www.alvestrand.no/ietf/chair/what-is-wrong.html From problem-statement-bounces@alvestrand.no Thu Jun 19 20:28:54 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26612 for ; Thu, 19 Jun 2003 20:28:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2626262577; Fri, 20 Jun 2003 02:28:22 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from apocalypse.org (apocalypse.org [192.48.232.17]) by eikenes.alvestrand.no (Postfix) with ESMTP id 826696238A for ; Fri, 20 Jun 2003 02:28:20 +0200 (CEST) Received: from apocalypse.org (IDENT:FK6FQEZe+pAjDFdm7x7BPFwTHBeSik6+@apocalypse.org [192.48.232.17]) by apocalypse.org (8.11.6/8.11.6) with ESMTP id h5K0SIG31771 for ; Thu, 19 Jun 2003 20:28:18 -0400 Date: Fri, 20 Jun 2003 09:26:17 +0900 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: avri To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit In-Reply-To: <20030619160516.3506015d.moore@cs.utk.edu> Message-Id: X-Mailer: Apple Mail (2.552) Subject: Re: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 There have been several notes in support of the thesis that it is not a case of a power disparity based on class, e.g. membership past or present in an I* body, but rather that is it based on trust networks where it is concentrated based on personal relationships (if i understand it correctly). Since this was a controversial theme, and since I have heard privately from many who were originally supportive of the class notion, I would like to hear more voices on this theme to determine if there is consensus on the shift from the terminology of class to the terminology of 'trust networks.' My perception, so far, has been that those within the trust networks see them as trust networks, while those who are not in trust networks tend to see them as a class, for some definition of class. My perception may be wrong, and that is why I am asking for more people to speak on this theme. Also it is possible, that it is just a semantic issue, and that 'trust network' is a gentler more acceptable term then 'class'. a. From problem-statement-bounces@alvestrand.no Thu Jun 19 20:51:37 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27125 for ; Thu, 19 Jun 2003 20:51:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2EFBC6257A; Fri, 20 Jun 2003 02:51:06 +0200 (CEST) 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 88C9762577 for ; Fri, 20 Jun 2003 02:51:03 +0200 (CEST) Received: from employees.org (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 19 Jun 2003 17:49:07 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5K0p0IX018045 for ; Thu, 19 Jun 2003 17:51:00 -0700 (PDT) Received: from cisco.com (sjc-vpn1-160.cisco.com [10.21.96.160]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AHH88832; Thu, 19 Jun 2003 17:46:17 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Thu, 19 Jun 2003 20:50:58 -0400 Date: Thu, 19 Jun 2003 20:50:58 -0400 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030620005058.GI2092@sbrim-w2k01> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: <20030619160516.3506015d.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Subject: Re: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Fri, Jun 20, 2003 09:26:17AM +0900, avri allegedly wrote: > My perception, so far, has been that those within the trust networks > see them as trust networks, while those who are not in trust > networks tend to see them as a class, for some definition of class. > My perception may be wrong, and that is why I am asking for more > people to speak on this theme. > Also it is possible, that it is just a semantic issue, and that 'trust > network' is a gentler more acceptable term then 'class'. "class" is intentionally polarizing, fissiparous rhetoric. What's the real problem? What are the qualities that distinguish the classes? If it's trust, then say trust. In any case, get to the distinction, skip the labeling. From problem-statement-bounces@alvestrand.no Thu Jun 19 20:58:09 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27278 for ; Thu, 19 Jun 2003 20:58:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B54436257A; Fri, 20 Jun 2003 02:57:37 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by eikenes.alvestrand.no (Postfix) with ESMTP id C72FD62577 for ; Fri, 20 Jun 2003 02:57:35 +0200 (CEST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) h5K0vWBd010194 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 19 Jun 2003 17:57:32 -0700 (PDT) Received: from [205.214.163.81] (vpn-10-50-0-88.qualcomm.com [10.50.0.88]) h5K0vQix009236; Thu, 19 Jun 2003 17:57:28 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Thu, 19 Jun 2003 17:57:29 -0700 To: avri , problem-statement@alvestrand.no From: hardie@qualcomm.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Avri, I recently wrote a draft that touches on this (submitted today as draft-hardie-12-2-1-00.txt, but not yet available). The salient text is: The author believes that the IETF has traditionally been integrated in two different ways, one formal and one informal. The formal integration relates to the steps of the standards process and the precursor steps of working group formation and chartering. The informal integration is an overlapping set of personal relationships that allows participants to identify skills, perspectives, or energy needed to complete the efforts identified in the formal processes. During a period of rapid growth and a follow-on period of contraction, the second system has been strained to the point of failure. Though the IETF retains a large pool of skilled professionals with energy and needed perspectives, the overlap in personal networks is now not sufficient to associate those with the efforts the IETF has taken on. This has led to delay, lowered quality, and frustration, both among those whose skills and perspectives are not appropriately connected to salient efforts and among those whose efforts have stalled for lack of energy or early input by those with relevant expertise. In other words, I also see this in terms of personal relationships, though I would not use the term trust network. I think, though, that it is better than the term "class", which is overburdened with economic ("owning class") and social ("lower class") connotations. I think the heart of the matter, though, is that some significant population that wants to participate in the IETF feels excluded. Further, the basis of that exclusion is such that the participant has no immediate way of determining either the cause of the exclusion or the method for achieving inclusion. Whatever terms we use, this needs to be captured as an issue. As a side note, my personal experience is that this is very common as a side effect of rapid growth. Having been part of several start ups that went through periods of rapid hiring, going in one case from 7 to 300 in under 18 months, this seems familiar. In the cases I have personally been through, the original staff tended to go again and again to the same people for expertise or energy, because they simply had not been able to expand their personal relationships to the other staff in ways that made them confident of their skill or commitment. This is, of course, only my personal view and others' analysis or belief in this parallel may differ, regards, Ted Hardie At 9:26 AM +0900 6/20/03, avri wrote: >There have been several notes in support of the thesis >that it is not a case of a power disparity based on class, >e.g. membership past or present in an I* body, but rather >that is it based on trust networks where it is concentrated >based on personal relationships (if i understand it correctly). > >Since this was a controversial theme, and since I have heard >privately from many who were originally supportive of the >class notion, I would like to hear more voices on this theme to >determine if there is consensus on the shift from the terminology >of class to the terminology of 'trust networks.' > >My perception, so far, has been that those within the trust networks >see them as trust networks, while those who are not in trust >networks tend to see them as a class, for some definition of class. >My perception may be wrong, and that is why I am asking for more >people to speak on this theme. >Also it is possible, that it is just a semantic issue, and that 'trust >network' is a gentler more acceptable term then 'class'. > >a. From problem-statement-bounces@alvestrand.no Thu Jun 19 21:22:03 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27985 for ; Thu, 19 Jun 2003 21:22:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6EF566257A; Fri, 20 Jun 2003 03:21:32 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7135262577 for ; Fri, 20 Jun 2003 03:21:26 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.50]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id SAA29333; Thu, 19 Jun 2003 18:20:50 -0700 (PDT) Message-Id: <5.1.0.14.2.20030619210436.0467d5b8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 19 Jun 2003 21:13:56 -0400 To: hardie@qualcomm.com From: Margaret Wasserman In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 At 05:57 PM 6/19/2003 -0700, hardie@qualcomm.com wrote: > I think the heart of the matter, though, is that >some significant population that wants to participate >in the IETF feels excluded. Further, the basis of that >exclusion is such that the participant has no immediate >way of determining either the cause of the exclusion >or the method for achieving inclusion. Whatever terms >we use, this needs to be captured as an issue. This resonates with me. I felt this way during my early IETF involvement. I could see places where I could contribute, and I believed that I had the ability and commitment to make a real contribution to the IETF (opinions may still differ on that ;-)), but I didn't understand how to sign-up... At the current moment, I believe that the IETF has a small, ridiculously overworked, core group of contributors, and a much larger, underutilized group of potential contributors. How do we fix that? Margaret From problem-statement-bounces@alvestrand.no Thu Jun 19 21:44:10 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28525 for ; Thu, 19 Jun 2003 21:44:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 014FE6257A; Fri, 20 Jun 2003 03:43:39 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id E908F62577 for ; Fri, 20 Jun 2003 03:43:36 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19TAwA-000MD4-4Y; Thu, 19 Jun 2003 18:43:34 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 19 Jun 2003 18:43:33 -0700 To: Margaret Wasserman References: <5.1.0.14.2.20030619210436.0467d5b8@mail.windriver.com> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 felt this way during my early IETF involvement. I > could see places where I could contribute, and I believed > that I had the ability and commitment to make a real > contribution to the IETF (opinions may still differ on > that ;-)), but I didn't understand how to sign-up... please find an example of some organization where you were a newbie and did not have that problem. now see if you can distill why not. would be a good example for the solution space. randy From problem-statement-bounces@alvestrand.no Thu Jun 19 21:55:00 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28869 for ; Thu, 19 Jun 2003 21:54:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8E13A6257A; Fri, 20 Jun 2003 03:54:29 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mallard.mail.pas.earthlink.net (mallard.mail.pas.earthlink.net [207.217.120.48]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2DDEC62577 for ; Fri, 20 Jun 2003 03:54:28 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19TB6Z-0002Vv-00; Thu, 19 Jun 2003 18:54:19 -0700 Date: Thu, 19 Jun 2003 21:51:22 -0400 From: Keith Moore To: Margaret Wasserman Message-Id: <20030619215122.669d7e2a.moore@cs.utk.edu> In-Reply-To: <5.1.0.14.2.20030619210436.0467d5b8@mail.windriver.com> References: <5.1.0.14.2.20030619210436.0467d5b8@mail.windriver.com> X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Subject: Re: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 felt this way during my early IETF involvement. I > could see places where I could contribute, and I believed > that I had the ability and commitment to make a real > contribution to the IETF (opinions may still differ on > that ;-)), but I didn't understand how to sign-up... when I was an AD one newbie actually took the trouble to politely ask me how to sign up. I told him he didn't need any permission to submit internet-drafts, and that if he tried to recognize problems that needed solving and work on them, could demonstrate that he knew what he was doing, and could work to get consensus within a group of people with varied interests, that most working groups would be happy to have his help. it seemed to work for him. From problem-statement-bounces@alvestrand.no Fri Jun 20 00:18:11 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03071 for ; Fri, 20 Jun 2003 00:18:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 12EFB6257A; Fri, 20 Jun 2003 06:17:41 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from episteme-software.com (champdsl-25-66.mcleodusa.net [216.43.25.66]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8E8C962577 for ; Fri, 20 Jun 2003 06:17:38 +0200 (CEST) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.2b1) for ; Thu, 19 Jun 2003 23:17:30 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: <5.1.0.14.2.20030619210436.0467d5b8@mail.windriver.com> X-Mailer: Eudora [Macintosh version 6.0a23] Date: Thu, 19 Jun 2003 23:17:34 -0500 To: problem-statement@alvestrand.no From: Pete Resnick Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 6/19/03 at 6:43 PM -0700, Randy Bush wrote: >On 6/19/03 at 9:13 PM -0400, Margaret Wasserman wrote: > >>At 05:57 PM 6/19/2003 -0700, Ted Hardie wrote: >> >>>I think the heart of the matter, though, is that some significant >>>population that wants to participate in the IETF feels excluded. >> >>I felt this way during my early IETF involvement. > >please find an example of some organization where you were a newbie >and did not have that problem. I don't think it's just about being a newbie (or perhaps "newbieness" lasts longer in this organization than in others) and I don't think it's just about feeling excluded. I do think it's about trust, and I do think it's about a perceived difference between those in the I* and "everyone else" (and I'm even including WG chairs in the "everyone else"). Let me give two examples: - My understanding is that in the IESG, a shepherding AD does a write-up of each document that is to come up for ballot. Some of the other ADs often just read the write-up, trusting it to be a fair evaluation of the document. ADs trust each other's opinions of the technical quality of the document, often voting "no objection" to a document that's out of their area of expertise because they trust that the shepherding AD or other ADs who are more familiar with the document. Assuming my perception is correct of how things work on the IESG, I think that's all good stuff. However, working group chairs are *not* routinely expected to do something like an AD write-up of a document. In fact, I've been directly told by some folks who've been on the IESG that the idea that a working group chair could do something like a good technical write-up that could be trusted by the IESG is absurd. (I have been told by some IESG folk that a chair write-up is a really good idea.) That means to me that the IESG does not, at least as a general rule, trust even working group chairs, not just random newbies. If the view that chairs cannot be trusted is widespread, that's a really bad thing. - I've been in multiple working groups in which I've heard things from the chair like, "That's never going to get by the IESG." (When I was still young and impressionable, I've heard such words come out of my mouth.) Often, I don't think these words are used just to pass off blame onto the IESG for a technical issue that the chair thinks is a dog (although that's clearly one of the uses). I think the chair often means, "No matter how important we think this feature is, no matter how technically sound our argument is to have our protocol do this, the IESG (or some particular AD) is going to balk at this and it will take us forever to make them happy, so let's do it a different way that they won't complain about." That is, working group chairs do not feel like they and their working groups are trusted by the IESG to make good technical judgements, and they equally feel that they don't trust the IESG to listen open-mindedly to them. Both kinds of distrust above are self-perpetuating: If the IESG never puts significant trust in chairs to direct their working groups appropriately, the chairs feel no responsibility to do so and the IESG ends up with work product that they must go through with a fine tooth comb because nobody will have done the proper vetting. That convinces the IESG that chairs cannot be trusted to produce good output, and round we go. If the working groups and chairs don't trust the IESG to listen to them, they will continue to use the IESG as a backstop, not evaluating problems on their own, and end up with crappy output that has to be dealt with late in the game. This then causes the IESG to push back late in the game, which the working groups perceive as arbitrary and capricious, and are therefore convinced that the IESG cannot be trusted, and round we go. I don't know if you want to call that a "trust network" or a "class" problem, but either way, I don't think it's about newbies feeling unwelcome. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From problem-statement-bounces@alvestrand.no Fri Jun 20 01:37:12 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05896 for ; Fri, 20 Jun 2003 01:37:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 64CBE62586; Fri, 20 Jun 2003 07:36:39 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from turkey.mail.pas.earthlink.net (turkey.mail.pas.earthlink.net [207.217.120.126]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5762062577 for ; Fri, 20 Jun 2003 07:36:37 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19TEZZ-0000qQ-00; Thu, 19 Jun 2003 22:36:30 -0700 Date: Fri, 20 Jun 2003 01:33:32 -0400 From: Keith Moore To: Pete Resnick Message-Id: <20030620013332.59b3f321.moore@cs.utk.edu> In-Reply-To: References: <5.1.0.14.2.20030619210436.0467d5b8@mail.windriver.com> X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Subject: Re: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 it's just about being a newbie (or perhaps "newbieness" > lasts longer in this organization than in others) and I don't think > it's just about feeling excluded. I do think it's about trust, I think it's actually closer to "calibration" than "trust". Let me use your examples to explain. > - My understanding is that in the IESG, a shepherding AD does a > write-up of each document that is to come up for ballot. Some of the > other ADs often just read the write-up, trusting it to be a fair > evaluation of the document. ADs trust each other's opinions of the > technical quality of the document, often voting "no objection" to a > document that's out of their area of expertise because they trust > that the shepherding AD or other ADs who are more familiar with the > document. Actually I'd say that ADs know each other well enough to know the areas in which they agree with one another (and trust the others' expertise) but also, the areas in which they don't. So they are able to evaluate one anothers' comments more effeciently - they know where to concentrate their energies looking for details and where it's not necessary to do so. By contrast, the AD doesn't know the a typical document author or WG chair that well so he needs to spend more energy reviewing those documents. Also, ADs write reviews for other ADs, and they do so knowing what those other ADs are looking for. > Assuming my perception is correct of how things work on the > IESG, I think that's all good stuff. However, working group chairs > are *not* routinely expected to do something like an AD write-up of a > document. In fact, I've been directly told by some folks who've been > on the IESG that the idea that a working group chair could do > something like a good technical write-up that could be trusted by the > IESG is absurd. I don't share that opinion in the absolute sense, and I used to ask some of my chairs (those who I had calibrated and who had earned my confidence) to do those writeups. The problems that I see with doing this in general are several: first, often the AD doesn't have the WG chair calibrated so the AD doesn't know how much he can trust the WG chair's writeup (remember that the shepherding AD is expected to vote YES for the document when he submits the writeup, so it's even more important that the AD trust the WG chair for this to work than that IESG people trust one another). Second, the WG chair doesn't know the ADs who will be reviewing the writeup and so doesn't know what will satisfy them and what will bring extra scrutiny. Third, WGs have frequently been known to disregard their charters regarding the scope of their activity, to violate basic design constraints on their protocols, and to fail to consider the valid interests of other parties who their protocols affect. So some WGs are clearly not trustworthy enough to do their own reviews. > - I've been in multiple working groups in which I've heard things > from the chair like, "That's never going to get by the IESG." when I was on the IESG, I often heard it said when I was sure it was erroneous. it results when people try to predict the IESG's behavior without having its members calibrated (i.e. without knowing them well enough to understand what considerations are important to them) > That is, working group > chairs do not feel like they and their working groups are trusted by > the IESG to make good technical judgements, and the chairs are often right about this, and often IESG is right to not trust them. > and they equally feel > that they don't trust the IESG to listen open-mindedly to them. and it might be because they haven't tried to explain. I used to tell WGs that they shouldn't try to guess what IESG was going to do with something - they should ask. For some reason they seemed to be reluctant to do that. > Both kinds of distrust above are self-perpetuating: If the IESG never > puts significant trust in chairs to direct their working groups > appropriately, the chairs feel no responsibility to do so and the > IESG ends up with work product that they must go through with a fine > tooth comb because nobody will have done the proper vetting. That > convinces the IESG that chairs cannot be trusted to produce good > output, and round we go. well, the chairs tend to see themselves as advocates for the group's narrow interests to the IESG rather than as advocates for the community's wide interests to the group. as long as that's the case, I don't see how the chairs can be trusted (in general) to do due diligence either. From problem-statement-bounces@alvestrand.no Fri Jun 20 04:18:04 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20954 for ; Fri, 20 Jun 2003 04:18:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BAAC76258D; Fri, 20 Jun 2003 10:17:32 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 75DAD62278; Fri, 20 Jun 2003 10:17:30 +0200 (CEST) Date: Fri, 20 Jun 2003 10:17:30 +0200 From: Harald Tveit Alvestrand To: Scott W Brim , problem-statement@alvestrand.no Message-ID: <725820000.1056097050@askvoll.hjemme.alvestrand.no> In-Reply-To: <20030620005058.GI2092@sbrim-w2k01> References: <20030619160516.3506015d.moore@cs.utk.edu> <20030620005058.GI2092@sbrim-w2k01> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On torsdag, juni 19, 2003 20:50:58 -0400 Scott W Brim wrote: > On Fri, Jun 20, 2003 09:26:17AM +0900, avri allegedly wrote: >> My perception, so far, has been that those within the trust networks >> see them as trust networks, while those who are not in trust >> networks tend to see them as a class, for some definition of class. >> My perception may be wrong, and that is why I am asking for more >> people to speak on this theme. >> Also it is possible, that it is just a semantic issue, and that 'trust >> network' is a gentler more acceptable term then 'class'. > > "class" is intentionally polarizing, fissiparous rhetoric. What's the > real problem? What are the qualities that distinguish the classes? If > it's trust, then say trust. In any case, get to the distinction, skip > the labeling. > "fissiparous" required a trip to dictionary.com for me :-) for other people with a similarly limited vocabulary, here's the definition from the American Heritage Dictionary: 1) Reproducing by biological fission. 2) Tending to break up into parts or break away from a main body; factious. "Trust networks" may be the wrong term too; while I don't trust Dave Crocker's proposals for action that much (I disagree with him too often!), I do trust him to care about many of the same things I do - and we do have a long history together. So he's part of my "network" in a way that many others aren't - but calling it a "trust network" may be simplistic. (apologies for using you as a named example again, Dave!) The reason why I think terminology matters is that it biases the solution space. If the problem is called "class", the likely-to-be-proposed solution is "break the class boundary" - such as by forcibly injecting members of one "class" into the other, or by removing one "class" en block from power (a la China's "cultural revolution"). If the problem is called "network", the likely-to-be-proposed solutions involve finding ways to extend the networks, lessen the reliance on the networks, or to formalize the networks so that they can be more visible and easier to control. Short version: I think we should keep "network" and throw away "class"; I'm not sure about "trust", but "trust" is definitely somewhere in problem space. Harald From problem-statement-bounces@alvestrand.no Fri Jun 20 13:22:20 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18140 for ; Fri, 20 Jun 2003 13:22:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7E564621FB; Fri, 20 Jun 2003 19:21:50 +0200 (CEST) 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 36927621B8 for ; Fri, 20 Jun 2003 19:21:48 +0200 (CEST) Message-ID: <01e601c3374f$aeeb0dd0$476015ac@dclkempt40> From: "James Kempf" To: "avri" , References: Date: Fri, 20 Jun 2003 10:16:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Avri, I believe that both phrasings, trust networks and class, are actually red herrings. In my opinion, the real issue involves responsibility, authority, and who gets to exercise both. Despite the "no kings and princes" slogan, IETF is like any organization, in that it requires a collection of managers to make sure the work gets done and that the work which does get done is of sufficient quality and timeliness to be useful to the Internet community. This function requires that these managers have the ability to exercise power and authority appropriate to their responsibility, including the assignment of people to positions of lesser power and authority. And, like any human organization, these managers are going to depend on people they know and trust for opinions about who to assign to actually perform the work of the organization. In the IETF, through circumstances and deliberate choice, we are now in a situation where much of the responsibility for seeing that work gets done lies with one group of lower level managers (the WG chairs), while much of the authority for enforcing quality and timeliness and the ultimate power for decision making lies with the top management (the IESG). This kind of situation is one in which power and authority is concentrated, while responsibility is delegated. Most US corporations gave up on this model in the 1980's, in favor of a model where lower level managers were empowered to make decisions and enforce them commiserate with their responsibility. In that sense, there is a concentration of power, but it has nothing to do with class or trust networks. In some sense, the reality of this situation is at odds with the IETF "press release" (I mean this in a figurative sense as what we believe about ourselves) that there really is no authority or power going on and everybody's opinion is equal. That disconnect has led to phrasing of the problem as involving class or trust networks. My 0.02 euro. jak From problem-statement-bounces@alvestrand.no Fri Jun 20 14:20:39 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22099 for ; Fri, 20 Jun 2003 14:20:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8A761621FB; Fri, 20 Jun 2003 20:20:07 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mgw-dax2.ext.nokia.com (unknown [63.78.179.217]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A9AA621B8 for ; Fri, 20 Jun 2003 20:20:00 +0200 (CEST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])h5KIJvG17557 for ; Fri, 20 Jun 2003 13:19:57 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com ; Fri, 20 Jun 2003 13:18:49 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 20 Jun 2003 11:18:15 -0700 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" Date: Fri, 20 Jun 2003 13:18:15 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DB2B2@daebe007.americas.nokia.com> Thread-Topic: MAJOR ISSUE: "Concentration of power" Thread-Index: AcM3UHSiclTyclj8TqC8UHGfBksdZAAB83Yw From: To: , , X-OriginalArrivalTime: 20 Jun 2003 18:18:15.0872 (UTC) FILETIME=[5164DC00:01C33758] Subject: RE: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA22099 Hello, The issue of "concentration of power" seems to be taking on far more complex connotations than it really is. Concentration of power means just that. A very few *select* people in the IETF wield the enormous power to decide what in their opinion is right for standardization and what is not. The select few get to decide what WGs are created, what BoFs are approved, and what WGs are terminated etc. As in any organization there needs to be a system of checks and balances. At this time there does not seem to be any such for the power of the IESG. That is what the key issue is. Its okay to have a body that is responsible for all the tasks that the IESG handles today. But remember the old adage: "Power corrupts and absolute power... " I do not believe that "concentration of power" has anything to do with classes and trusted networks. I completely agree with James that this idea of classes etc. is indeed a red herring. -Basavaraj >Avri, > >I believe that both phrasings, trust networks and class, are actually red >herrings. In my opinion, the real issue involves responsibility, authority, >and who gets to exercise both. Despite the "no kings and princes" slogan, >IETF is like any organization, in that it requires a collection of managers >to make sure the work gets done and that the work which does get done is of >sufficient quality and timeliness to be useful to the Internet community. >This function requires that these managers have the ability to exercise >power and authority appropriate to their responsibility, including the >assignment of people to positions of lesser power and authority. And, like >any human organization, these managers are going to depend on people they >know and trust for opinions about who to assign to actually perform the work >of the organization. > >In the IETF, through circumstances and deliberate choice, we are now in a >situation where much of the responsibility for seeing that work gets done >lies with one group of lower level managers (the WG chairs), while much of >the authority for enforcing quality and timeliness and the ultimate power >for decision making lies with the top management (the IESG). This kind of >situation is one in which power and authority is concentrated, while >responsibility is delegated. Most US corporations gave up on this model in >the 1980's, in favor of a model where lower level managers were empowered to >make decisions and enforce them commiserate with their responsibility. In >that sense, there is a concentration of power, but it has nothing to do with >class or trust networks. > >In some sense, the reality of this situation is at odds with the IETF "press >release" (I mean this in a figurative sense as what we believe about >ourselves) that there really is no authority or power going on and >everybody's opinion is equal. That disconnect has led to phrasing of the >problem as involving class or trust networks. > >My 0.02 euro. > > jak > From problem-statement-bounces@alvestrand.no Fri Jun 20 15:19:14 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01362 for ; Fri, 20 Jun 2003 15:19:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 820D5622A1; Fri, 20 Jun 2003 21:18:42 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 39654621B8; Fri, 20 Jun 2003 21:18:41 +0200 (CEST) Date: Fri, 20 Jun 2003 21:18:41 +0200 From: Harald Tveit Alvestrand To: Basavaraj.Patil@nokia.com, problem-statement@alvestrand.no Message-ID: <815250000.1056136721@askvoll.hjemme.alvestrand.no> In-Reply-To: <697DAA22C5004B4596E033803A7CEF44024DB2B2@daebe007.americas.nokia.com> References: <697DAA22C5004B4596E033803A7CEF44024DB2B2@daebe007.americas.noki a.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: RE: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 fredag, juni 20, 2003 13:18:15 -0500 Basavaraj.Patil@nokia.com wrote: > > Hello, > > The issue of "concentration of power" seems to be taking on far more > complex connotations than it really is. > > Concentration of power means just that. A very few *select* people in > the IETF wield the enormous power to decide what in their opinion is > right for standardization and what is not. The select few get to > decide what WGs are created, what BoFs are approved, and what WGs are > terminated etc. > > As in any organization there needs to be a system of checks and > balances. At this time there does not seem to be any such for the > power of the IESG. That is what the key issue is. Its okay to have a > body that is responsible for all the tasks that the IESG handles > today. But remember the old adage: "Power corrupts and absolute > power... " > > I do not believe that "concentration of power" has anything to do with > classes and trusted networks. I completely agree with James that this > idea of classes etc. is indeed a red herring. You may be right.... but this is the problem described in section 2.5.1 of the draft - "Span of Authority". And I think the WG has rough consensus on that section (including me!) This thread started out discussing section 2.5.5 - "Concentration of Influence in Too Few Hands" - which talks about the set of people that the IESG and IAB people talk to, not just the currently-sitting IESG/IAB members. Let's not confuse the two issues.... Harald From problem-statement-bounces@alvestrand.no Fri Jun 20 15:28:18 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02587 for ; Fri, 20 Jun 2003 15:28:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1C674622A1; Fri, 20 Jun 2003 21:27:47 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 77625621FB for ; Fri, 20 Jun 2003 21:27:45 +0200 (CEST) Date: Fri, 20 Jun 2003 21:27:46 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <819030000.1056137266@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: MINOR ISSUE: Linkage between training and lack of clear mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 -issue- section 2.7 says: 2.7 IETF Participants and Leaders are Inadequately Prepared for their Roles Participants and leaders at all levels in the IETF need to be taught the principles of the organization (Mission and Architecture(s)) and trained in carrying out the processes which they have to use in developing specifications, etc. ISSUE: The lack of training in missison and architecture needs to be linked explicitly to the lack of an explicit mission and architecture - it is very hard to train people in what has not been made explicit. SUGGESTED RESOLUTION: Insert a reference to section 2.1 - "Part of the reason for the lack of training in these principles is that explicit formulation of the principles are not generally agreed - see section 2.1" From problem-statement-bounces@alvestrand.no Fri Jun 20 15:31:05 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03001 for ; Fri, 20 Jun 2003 15:31:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AA0F4622A1; Fri, 20 Jun 2003 21:30:34 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id C6490621FB for ; Fri, 20 Jun 2003 21:30:33 +0200 (CEST) Date: Fri, 20 Jun 2003 21:30:33 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <819090000.1056137433@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ISSUE: Recognizing that conflict over the IETF principles can exist X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Section 2.7 of -issue- says: The IETF currently has voluntary and inconsistent processes for educating its participants which may be why significant numbers of participants seem to fail to conform to the proper principles when working in the IETF context. The people in authority have generally been steeped in the principles of the IETF (as they see them) and first-time non-compliance by newer participants is sometimes treated as an opportunity for abuse rather than by recognition of a training failure. ISSUE: This paragraph ignores the fact that some participants understand the principles, but disagree with them; the openness principle says that we do not exclude such people. So we need to expect conflict. SUGGESTED RESOLUTION: Not clear..... From problem-statement-bounces@alvestrand.no Fri Jun 20 15:32:58 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03062 for ; Fri, 20 Jun 2003 15:32:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 50C4862597; Fri, 20 Jun 2003 21:32:27 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id BBDB6621FB; Fri, 20 Jun 2003 21:32:24 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h5KJWLN21086; Fri, 20 Jun 2003 15:32:22 -0400 (EDT) Date: Fri, 20 Jun 2003 15:32:21 -0400 From: Keith Moore To: Harald Tveit Alvestrand Message-Id: <20030620153221.1e8f5442.moore@cs.utk.edu> In-Reply-To: <819090000.1056137433@askvoll.hjemme.alvestrand.no> References: <819090000.1056137433@askvoll.hjemme.alvestrand.no> X-Mailer: Sylpheed version 0.9.2 (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 Cc: moore@cs.utk.edu Subject: Re: ISSUE: Recognizing that conflict over the IETF principles can exist X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > ISSUE: This paragraph ignores the fact that some participants > understand the principles, but disagree with them; the openness > principle says that we do not exclude such people. So we need to > expect conflict. I'm not sure whether the openness principle extends to those who do not work for the good of the Internet as a whole. IMHO, it does not. That doesn't mean we have a objective means of deciding who is doing so... Keith From problem-statement-bounces@alvestrand.no Fri Jun 20 15:36:24 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03440 for ; Fri, 20 Jun 2003 15:36:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F31A862597; Fri, 20 Jun 2003 21:35:51 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id EFBF0621FB; Fri, 20 Jun 2003 21:35:49 +0200 (CEST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])h5KJZna29626; Fri, 20 Jun 2003 22:35:49 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com ; Fri, 20 Jun 2003 22:35:47 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 20 Jun 2003 22:35:49 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 20 Jun 2003 22:35:42 +0300 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" Date: Fri, 20 Jun 2003 22:35:34 +0300 Message-ID: Thread-Topic: MINOR ISSUE: Linkage between training and lack of clear mission Thread-Index: AcM3YgylKKi9TztdRz+wOwlVeQIf+AAAPGLQ From: To: , X-OriginalArrivalTime: 20 Jun 2003 19:35:42.0423 (UTC) FILETIME=[22F44670:01C33763] Subject: RE: MINOR ISSUE: Linkage between training and lack of clear mission X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA03440 Hi Harald, I agree. John > -----Original Message----- > From: ext Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: 20 June, 2003 22:28 > To: problem-statement@alvestrand.no > Subject: MINOR ISSUE: Linkage between training and lack of > clear mission > > > -issue- section 2.7 says: > > 2.7 IETF Participants and Leaders are Inadequately Prepared for their > Roles > > Participants and leaders at all levels in the IETF need to > be taught > the principles of the organization (Mission and > Architecture(s)) and > trained in carrying out the processes which they have to use in > developing specifications, etc. > > ISSUE: The lack of training in missison and architecture > needs to be linked > explicitly to the lack of an explicit mission and > architecture - it is very > hard to train people in what has not been made explicit. > > SUGGESTED RESOLUTION: Insert a reference to section 2.1 - > "Part of the > reason for the lack of training in these principles is that explicit > formulation of the principles are not generally agreed - see > section 2.1" > From problem-statement-bounces@alvestrand.no Fri Jun 20 15:53:30 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05097 for ; Fri, 20 Jun 2003 15:53:30 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AFDB7622A1; Fri, 20 Jun 2003 21:52:59 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id AAA61621FB for ; Fri, 20 Jun 2003 21:52:58 +0200 (CEST) Date: Fri, 20 Jun 2003 21:52:58 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <823110000.1056138778@askvoll.hjemme.alvestrand.no> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: No more problems..... X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 it will no doubt come as a relief to the editors to know that I've now mentioned all my concerns with draft-ietf-problem-issue-statement-01. If the WG comes to a consensus on all the points I've mentioned, I'll be happy to support the document going forward. NOTE - in case anyone's in doubt: I'm happy to support the document going forward if the WG agrees not to agree with me - it's the WG's document, not mine, and it's the WG's consensus that counts! Harald From problem-statement-bounces@alvestrand.no Fri Jun 20 16:57:01 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08339 for ; Fri, 20 Jun 2003 16:57:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2EDFE622A1; Fri, 20 Jun 2003 22:56:30 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by eikenes.alvestrand.no (Postfix) with ESMTP id CDD8C621FB for ; Fri, 20 Jun 2003 22:56:27 +0200 (CEST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5KKuQxr177604; Fri, 20 Jun 2003 16:56:26 -0400 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) h5KKuPUZ097066; Fri, 20 Jun 2003 16:56:25 -0400 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) h5KKv58k026594; Fri, 20 Jun 2003 16:57:05 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) h5KKv589026589; Fri, 20 Jun 2003 16:57:05 -0400 Message-Id: <200306202057.h5KKv589026589@rotala.raleigh.ibm.com> To: Pete Resnick In-Reply-To: Message from presnick@qualcomm.com of "Thu, 19 Jun 2003 23:17:34 CDT." Date: Fri, 20 Jun 2003 16:57:05 -0400 From: Thomas Narten Cc: problem-statement@alvestrand.no Subject: Re: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 A few thoughts about trust... One thing IMO that complicates the discussion about trust is that some of the postings could be read to imply "trust in WG chairs" is an all or nothing thing. I.e., "we don't trust chairs" (by implication for anything). For me, trust is earned. That goes for everyone, not just for "some" folk, or for WG chairs. Even fellow IESG members have (or have had to) earn my trust. And even then, one trusts certain things, not necessarily everything. I.e., I trust person A in area X, but not necessarily in area Y. And this isn't necessarily bad or an indication of flaws. People have different strengths and weaknesses, and one places trust accordingly. > - My understanding is that in the IESG, a shepherding AD does a > write-up of each document that is to come up for ballot. Some of the > other ADs often just read the write-up, trusting it to be a fair > evaluation of the document. ADs trust each other's opinions of the > technical quality of the document, often voting "no objection" to a > document that's out of their area of expertise because they trust > that the shepherding AD or other ADs who are more familiar with the > document. Assuming my perception is correct of how things work on the > IESG, I think that's all good stuff. However, working group chairs > are *not* routinely expected to do something like an AD write-up of a > document. I've never asked or expected my WG chairs to do the writeup. I guess partly this is for historical reasons (it wasn't done that way when I started). Also, I don't really see this as a place where offloading the chairs gets much bang for the buck. > In fact, I've been directly told by some folks who've been > on the IESG that the idea that a working group chair could do > something like a good technical write-up that could be trusted by the > IESG is absurd. I think one would need to look at this on a case-by-case basis. And it's not just about "trust" in some good/bad sense, it also has to do with experience. Better writeups come with experience, not on the first try. And whether this is something that needs to be pushed down the chairs. > (I have been told by some IESG folk that a chair > write-up is a really good idea.) That means to me that the IESG does > not, at least as a general rule, trust even working group chairs, not > just random newbies. If the view that chairs cannot be trusted is > widespread, that's a really bad thing. To me, it's not really about "trust". I'm just not sure why the WG chairs should be doing this (except maybe under the "offload as much work as possible" theory). In practice, doing the writeup doesn't take that much time and I suspect that if I asked the chairs to do it, I'd end up spending as much time in the end just in iterating on the text and going back and forth. Often (and this is _really_ an important point), there is no time for that, because I'm trying to get the writeup finished in time for a deadline in order to get the document on the agenda for the next telechat. In such cases, one may not have a few hours or days to iterate. For me, this just isn't a place where it seems to make sense to try and off load to the chairs that much. Others may feel differently. > - I've been in multiple working groups in which I've heard things > from the chair like, "That's never going to get by the IESG." (When I > was still young and impressionable, I've heard such words come out of > my mouth.) I've heard that said too. And I've also too often heard things said that are a misintepretation or oversimplification of what the IESG (or an IESG member) has actually said. And I've also heard random people _assert_ things in the name of the IESG that are just plain rubbish. Questioning is good. ADs need to be able to explain their reasoning to everyone. When that is not happening, and folks do things because "the AD just says so", the system is broken and we all lose. Note though, that this point is also touching on the same point discussed earlier about cryptic one liners vs. explaining points in detail so everyone can understand. But it's even more complicated sometimes. In one WG document recently, I raised issues on a document, and the author ended up responding by saying the equivalent of "I'm going to take this out, because that's what it will take to get it through the IESG". This is despite my raising what IMO were real technical issues, *and* a willingness to talk about them and work through them. But there was simply (from my perspective) an unwillingness to discuss the actual issues. I really hate that when it happens (and I pushed on the WG to remove the text because it was not needed rather than just because I was asking for it). But I'm sure that for at least some people, the message that will be relayed will be "removed to satisfy AD" rather than "because it was the right thing to do". I don't know what to do about that. > Often, I don't think these words are used just to pass off > blame onto the IESG for a technical issue that the chair thinks is a > dog (although that's clearly one of the uses). I think the chair > often means, "No matter how important we think this feature is, no > matter how technically sound our argument is to have our protocol do > this, the IESG (or some particular AD) is going to balk at this and > it will take us forever to make them happy, so let's do it a > different way that they won't complain about." That is, working group > chairs do not feel like they and their working groups are trusted by > the IESG to make good technical judgements, and they equally feel > that they don't trust the IESG to listen open-mindedly to them. I'm not going to deny the above happens. But there are two sides to the coin. Sometimes, it's just the easiest way (unfortunately) to deal with an issue. As a (real) example. One of the too-common themes I've heard before in WGs is "TCP is too much overhead, we need to invent our own reliable datagram/UDP transport protocol that is more efficient than TCP". The above comment is just the simplest way to deal with issue (in one sentence) when this topic comes up after a while. The real answer is longer and complex, and it was (in cases I can think of) extremely hard to get buy-in from those advocating using something other than TCP. So, when sound-bite "IESG" reasons are given for not doing something, we also need to look at the specifics of the issue, because sometimes what appears to be a "because the AD says so" is actually a bit more complicated. When in doubt, question further. Thomas From problem-statement-bounces@alvestrand.no Fri Jun 20 17:28:20 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09561 for ; Fri, 20 Jun 2003 17:28:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 02C5D62597; Fri, 20 Jun 2003 23:27:50 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id 01C34621FB; Fri, 20 Jun 2003 23:27:48 +0200 (CEST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])h5KLRla16866; Sat, 21 Jun 2003 00:27:47 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com ; Sat, 21 Jun 2003 00:27:47 +0300 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 21 Jun 2003 00:27:47 +0300 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 20 Jun 2003 16:25:45 -0500 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" Date: Fri, 20 Jun 2003 16:25:45 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DB2BC@daebe007.americas.nokia.com> Thread-Topic: MAJOR ISSUE: "Concentration of power" Thread-Index: AcM3YMSnovxFUosYTtiuy/FzICgxFwAEaxyg From: To: , X-OriginalArrivalTime: 20 Jun 2003 21:25:45.0612 (UTC) FILETIME=[82C2F4C0:01C33772] Subject: RE: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA09561 >> ----8xcut-------- >> I do not believe that "concentration of power" has anything to do with >> classes and trusted networks. I completely agree with James that this >> idea of classes etc. is indeed a red herring. > >You may be right.... but this is the problem described in section 2.5.1 of >the draft - "Span of Authority". And I think the WG has rough consensus on >that section (including me!) I concur. > >This thread started out discussing section 2.5.5 - "Concentration of >Influence in Too Few Hands" - which talks about the set of people that the >IESG and IAB people talk to, not just the currently-sitting IESG/IAB >members. With the evolution of the thread, I lost track of the reference to the section in the document mentioned in your first email. Thanks for bringing it back to the forefront. I agree that the two issues are separate and should be dealt as such. > >Let's not confuse the two issues.... > > Harald > -Basavaraj From problem-statement-bounces@alvestrand.no Fri Jun 20 21:07:08 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15936 for ; Fri, 20 Jun 2003 21:07:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 16999622A1; Sat, 21 Jun 2003 03:06:36 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from apocalypse.org (apocalypse.org [192.48.232.17]) by eikenes.alvestrand.no (Postfix) with ESMTP id 10B8361C73 for ; Sat, 21 Jun 2003 03:06:33 +0200 (CEST) Received: from apocalypse.org (IDENT:NLdlbNRNu8ZrNl/LPtm7LbRoZJhNlu99@apocalypse.org [192.48.232.17]) by apocalypse.org (8.11.6/8.11.6) with ESMTP id h5L16SG22779 for ; Fri, 20 Jun 2003 21:06:28 -0400 Date: Sat, 21 Jun 2003 10:06:26 +0900 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: avri To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit Message-Id: <957F9544-A384-11D7-8159-000393CC2112@apocalypse.org> X-Mailer: Apple Mail (2.552) Subject: trust networks and class X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 a personal opinion. while reading the list on this topic, i have been having trouble with the word 'trust'. just as others have issues with the word 'class'. when i hear that a certain set of tasks were given to those the AD trusts, i immediately hear that those not chosen were not trusted. it does not take much of a jump, at least for me, to then believe that the reason someone did not get an editorship, a chair or a seat on a directorate is because they were not trusted, i.e. either did not earn the trust of those in a position to grant positions or did something to render themselves untrustworthy. and while i am well aware of the fact that this is a logical fallacy, i believe it is an emotional fact. so the term trust network hits me very badly every time i hear it. btw, network makes me wonder too, i start wondering about the topology of someone's trust network, it is hub and spoke, is it a ring or is it a mesh of some sort? while somewhat fanciful, i do believe it is baggage. it is funny about words. when i think of class, i think of membership in a group with certain attributes. the kind of class being defined by some modifier. but others have a set of baggage of attached to it that makes it problematic - they hear class and think warfare. my personal opinion is that we should avoid both terms. while it may be an awkward term in this setting, i believe we are talking about an affinity group, where the members of the group are grouped based on shared experience, similar identity and common challenges. as with classes and trust networks, affinity groups are sometimes relatively closed and take energy, sometimes a lot, to enter. and hopefully the term has not yet gathered any baggage in the IETF. a. From problem-statement-bounces@alvestrand.no Fri Jun 20 21:12:46 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16044 for ; Fri, 20 Jun 2003 21:12:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 64316622A1; Sat, 21 Jun 2003 03:12:14 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id E3EA861C73 for ; Sat, 21 Jun 2003 03:12:11 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19TWvJ-0006H7-5W; Fri, 20 Jun 2003 18:12:09 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 20 Jun 2003 18:12:08 -0700 To: avri References: <957F9544-A384-11D7-8159-000393CC2112@apocalypse.org> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: trust networks and class X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > when i hear that a certain set of tasks were given to those > the AD trusts do you actually hear that? often? sounds like something the nomcom should fix. but if it is given to someone the AD and others have reason to trust will do a quality job, then, to me, that seems to be their duty. randy From problem-statement-bounces@alvestrand.no Fri Jun 20 21:36:57 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16368 for ; Fri, 20 Jun 2003 21:36:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 550C9622A1; Sat, 21 Jun 2003 03:36:26 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from apocalypse.org (apocalypse.org [192.48.232.17]) by eikenes.alvestrand.no (Postfix) with ESMTP id EFC7961C73 for ; Sat, 21 Jun 2003 03:36:23 +0200 (CEST) Received: from acm.org (IDENT:f8816wMPsvv9R0986YnxR/j2qNaYY8GQ@apocalypse.org [192.48.232.17]) by apocalypse.org (8.11.6/8.11.6) with ESMTP id h5L1aMG24422 for ; Fri, 20 Jun 2003 21:36:22 -0400 Date: Sat, 21 Jun 2003 10:36:19 +0900 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Avri Doria To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Subject: Open Process Issue: Improvement WG Chair Selection X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 While reviewing issues for an upcoming release of the process document, the issue of how the chair(s) of the improvement group were to be chosen stood out as having not been discussed to any length. There was recommendation that it be done by the General Area AD. And there was one voice of concurrence. So, is it safe to conclude that this reflects WG consensus? Or do the topic get lost in the shuffle? Opinions please. If it is consensus, a further question is, does the WG want to recommend a process by which the AD will choose the chair? E.g. does the WG want to recommend an open process similar to that used by Harald in selecting the chairs for this WG group. Or, should the manner of selection it be left to the AD as is currently the rule? Thanks a. From problem-statement-bounces@alvestrand.no Sat Jun 21 01:59:23 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20854 for ; Sat, 21 Jun 2003 01:59:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4BF82622A1; Sat, 21 Jun 2003 07:58:50 +0200 (CEST) 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 6C69D621B8; Sat, 21 Jun 2003 07:58:43 +0200 (CEST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])h5L5wg910769; Sat, 21 Jun 2003 08:58:42 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com ; Sat, 21 Jun 2003 08:58:42 +0300 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 21 Jun 2003 08:58:42 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 21 Jun 2003 08:58:42 +0300 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: Sat, 21 Jun 2003 08:58:41 +0300 Message-ID: Thread-Topic: ISSUE: Recognizing that conflict over the IETF principles can exist Thread-Index: AcM3YnA0qTr+1QXyRF6r1uD2jlU6XgAV0uyA From: To: , X-OriginalArrivalTime: 21 Jun 2003 05:58:42.0177 (UTC) FILETIME=[2B061710:01C337BA] Subject: RE: ISSUE: Recognizing that conflict over the IETF principles can exist X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Hi Harald, While not explicitly stated in the text below, I think another factor is that the IETF does not do a good job at conflict management. I am not sure if this deserves a separate issue or not, but perhaps it may be sufficient to add it to section 2.7 as an aggravating factor. John > -----Original Message----- > From: ext Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: 20 June, 2003 22:31 > To: problem-statement@alvestrand.no > Subject: ISSUE: Recognizing that conflict over the IETF principles can > exist >=20 >=20 > Section 2.7 of -issue- says: >=20 > The IETF currently has voluntary and inconsistent processes for > educating its participants which may be why significant numbers of > participants seem to fail to conform to the proper principles when > working in the IETF context. >=20 > The people in authority have generally been steeped in the=20 > principles > of the IETF (as they see them) and first-time=20 > non-compliance by newer > participants is sometimes treated as an opportunity for=20 > abuse rather > than by recognition of a training failure. >=20 > ISSUE: This paragraph ignores the fact that some participants=20 > understand=20 > the principles, but disagree with them; the openness=20 > principle says that we=20 > do not exclude such people. So we need to expect conflict. >=20 > SUGGESTED RESOLUTION: Not clear.....=20 >=20 From problem-statement-bounces@alvestrand.no Sat Jun 21 04:14:32 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04058 for ; Sat, 21 Jun 2003 04:14:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4C89F6230F; Sat, 21 Jun 2003 10:14:01 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4B87B62205; Sat, 21 Jun 2003 10:13:59 +0200 (CEST) Date: Sat, 21 Jun 2003 09:55:14 +0200 From: Harald Tveit Alvestrand To: john.loughney@nokia.com, problem-statement@alvestrand.no Message-ID: <1759580.1056189314@localhost> In-Reply-To: References: X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: RE: ISSUE: Recognizing that conflict over the IETF principles can exist X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 21. juni 2003 08:58 +0300 john.loughney@nokia.com wrote: > Hi Harald, > > While not explicitly stated in the text below, I think another factor > is that the IETF does not do a good job at conflict management. I am > not sure if this deserves a separate issue or not, but perhaps > it may be sufficient to add it to section 2.7 as an aggravating factor. Yes, I think you're right. And it probably aggravates more issues than this. From problem-statement-bounces@alvestrand.no Sat Jun 21 04:14:40 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04078 for ; Sat, 21 Jun 2003 04:14:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED5B26258D; Sat, 21 Jun 2003 10:14:01 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BFE48622A1; Sat, 21 Jun 2003 10:13:59 +0200 (CEST) Date: Sat, 21 Jun 2003 10:06:02 +0200 From: Harald Tveit Alvestrand To: avri , problem-statement@alvestrand.no Message-ID: <2407051.1056189962@localhost> In-Reply-To: <957F9544-A384-11D7-8159-000393CC2112@apocalypse.org> References: <957F9544-A384-11D7-8159-000393CC2112@apocalypse.org> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: trust networks and class X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 21. juni 2003 10:06 +0900 avri wrote: > while reading the list on this topic, i have been having > trouble with the word 'trust'. just as others have issues > with the word 'class'. > > when i hear that a certain set of tasks were given to those > the AD trusts, i immediately hear that those not chosen > were not trusted. I didn't think of it this way..... in many (most) cases, there is either one obvious candidate (the original proposer, the person who drafted the first version) or many qualified people, one of which gets picked. In the process of picking chairs for this WG, for instance, I had about 17 candidates suggested to me; all of them were people I trusted to try to do the right thing for the IETF - in one or two cases, I doubted their competence to perform the job, and in some cases, I felt that I had too little information to evaluate their probable performance. In the end, it came down to choosing the ones I thought best qualified for the job, based on the information available to me, among a set of good people willing to serve. (it's a nice example since the process is already public.... there's no other reason to pick that process in particular....) > while it may be an awkward term in this setting, i believe > we are talking about an affinity group, where the members > of the group are grouped based on shared experience, > similar identity and common challenges. as with classes > and trust networks, affinity groups are sometimes relatively > closed and take energy, sometimes a lot, to enter. Yes! It also gets around the problem of having multiple kinds of affinities, of which "trust" is only one aspect. I like that term! From problem-statement-bounces@alvestrand.no Sat Jun 21 07:15:56 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06150 for ; Sat, 21 Jun 2003 07:15:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 30D4D6230F; Sat, 21 Jun 2003 13:15:24 +0200 (CEST) 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 05E9862205 for ; Sat, 21 Jun 2003 13:15:22 +0200 (CEST) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h5LBFIDw009254; Sat, 21 Jun 2003 07:15:18 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h5LBFItp009253; Sat, 21 Jun 2003 07:15:18 -0400 (EDT) Date: Sat, 21 Jun 2003 07:15:18 -0400 (EDT) From: Scott Bradner Message-Id: <200306211115.h5LBFItp009253@newdev.harvard.edu> To: avri@acm.org, problem-statement@alvestrand.no In-Reply-To: Subject: Re: Open Process Issue: Improvement WG Chair Selection X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 think the process used to select the chairs of the problem group should be used to select the chair(s) of the solution WG Scott --- >From problem-statement-bounces@alvestrand.no Fri Jun 20 21:36:34 2003 Delivered-To: problem-statement@alvestrand.no Date: Sat, 21 Jun 2003 10:36:19 +0900 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Avri Doria To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Subject: Open Process Issue: Improvement WG Chair Selection X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 While reviewing issues for an upcoming release of the process document, the issue of how the chair(s) of the improvement group were to be chosen stood out as having not been discussed to any length. There was recommendation that it be done by the General Area AD. And there was one voice of concurrence. So, is it safe to conclude that this reflects WG consensus? Or do the topic get lost in the shuffle? Opinions please. If it is consensus, a further question is, does the WG want to recommend a process by which the AD will choose the chair? E.g. does the WG want to recommend an open process similar to that used by Harald in selecting the chairs for this WG group. Or, should the manner of selection it be left to the AD as is currently the rule? Thanks a. From problem-statement-bounces@alvestrand.no Sat Jun 21 07:28:17 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06287 for ; Sat, 21 Jun 2003 07:28:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E71976230F; Sat, 21 Jun 2003 13:27:45 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id 569AB62205 for ; Sat, 21 Jun 2003 13:27:43 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.4]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id EAA27108; Sat, 21 Jun 2003 04:27:02 -0700 (PDT) Message-Id: <5.1.0.14.2.20030621072249.0407abf0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 21 Jun 2003 07:23:01 -0400 To: Scott Bradner From: Margaret Wasserman In-Reply-To: <200306211115.h5LBFItp009253@newdev.harvard.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: Open Process Issue: Improvement WG Chair Selection X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 At 07:15 AM 6/21/2003 -0400, Scott Bradner wrote: >I think the process used to select the chairs of the problem >group should be used to select the chair(s) of the solution WG I agree. Margaret From problem-statement-bounces@alvestrand.no Sat Jun 21 08:03:57 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06618 for ; Sat, 21 Jun 2003 08:03:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AD33B6230F; Sat, 21 Jun 2003 14:03:25 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mx-out.daemonmail.net (mx-out.daemonmail.net [216.104.160.39]) by eikenes.alvestrand.no (Postfix) with ESMTP id E2C2062205 for ; Sat, 21 Jun 2003 14:03:23 +0200 (CEST) Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.9.3p2/8.9.3) with SMTP id FAA55657 for ; Sat, 21 Jun 2003 05:03:22 -0700 (PDT) (envelope-from spencer@mcsr-labs.org) Received: from (12.237.229.250 [12.237.229.250]) by mail.varaha.com with SMTP id dTE09YK2 Sat, 21 Jun 2003 05:03:21 -0700 (PDT) Message-ID: <011a01c337ed$1d362390$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <5.1.0.14.2.20030621072249.0407abf0@mail.windriver.com> Date: Sat, 21 Jun 2003 07:03:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: Open Process Issue: Improvement WG Chair Selection X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Speaking as one of the 17, I thought the process used to select the chairs was refreshingly helpful. My only negative thought was that it was so different from the way other chairs have been chosen that it took me a few minutes to figure out that Harald was "interviewing" me. But I can be slow sometimes. I also note that, like SIR, this is a change we made that did not require formal approval, and we now have some implementation experience to base further refinements on. In summary, one of the best process improvements I've seen this year. Spencer ----- Original Message ----- From: "Margaret Wasserman" To: "Scott Bradner" Cc: Sent: Saturday, June 21, 2003 6:23 AM Subject: Re: Open Process Issue: Improvement WG Chair Selection > > At 07:15 AM 6/21/2003 -0400, Scott Bradner wrote: > >I think the process used to select the chairs of the problem > >group should be used to select the chair(s) of the solution WG > > I agree. > > Margaret > > From problem-statement-bounces@alvestrand.no Sat Jun 21 10:14:05 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08928 for ; Sat, 21 Jun 2003 10:14:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CE8BB623CD; Sat, 21 Jun 2003 16:13:34 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8E5D062205 for ; Sat, 21 Jun 2003 16:13:33 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19Tj7R-000Pc2-LC; Sat, 21 Jun 2003 07:13:29 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 21 Jun 2003 07:13:29 -0700 To: Scott Bradner References: <200306211115.h5LBFItp009253@newdev.harvard.edu> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: Open Process Issue: Improvement WG Chair Selection X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > I think the process used to select the chairs of the problem > group should be used to select the chair(s) of the solution WG works for me From problem-statement-bounces@alvestrand.no Sat Jun 21 12:40:18 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10978 for ; Sat, 21 Jun 2003 12:40:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B9A11625A3; Sat, 21 Jun 2003 18:39:47 +0200 (CEST) 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 36B1662577 for ; Sat, 21 Jun 2003 18:39:46 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h5LGh1703271 for ; Sat, 21 Jun 2003 09:43:01 -0700 Date: Sat, 21 Jun 2003 09:39:41 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/10) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <451200021.20030621093941@brandenburg.com> To: problem-statement@alvestrand.no In-Reply-To: <200306211115.h5LBFItp009253@newdev.harvard.edu> References: <200306211115.h5LBFItp009253@newdev.harvard.edu> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Subject: Re: Open Process Issue: Improvement WG Chair Selection X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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, SB> I think the process used to select the chairs of the problem SB> group should be used to select the chair(s) of the solution WG sounds good. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Sat Jun 21 14:23:37 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12029 for ; Sat, 21 Jun 2003 14:23:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 68903625A5; Sat, 21 Jun 2003 20:23:05 +0200 (CEST) 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 81B1C62571 for ; Sat, 21 Jun 2003 20:23:03 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h5LIQG706735; Sat, 21 Jun 2003 11:26:17 -0700 Date: Sat, 21 Jun 2003 11:22:58 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/10) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <12457395079.20030621112258@brandenburg.com> To: avri In-Reply-To: <957F9544-A384-11D7-8159-000393CC2112@apocalypse.org> References: <957F9544-A384-11D7-8159-000393CC2112@apocalypse.org> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: trust networks and class X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 avri, a> when i hear that a certain set of tasks were given to those a> the AD trusts, i immediately hear that those not chosen a> were not trusted. ... and while i am a> well aware of the fact that this is a logical fallacy, i believe a> it is an emotional fact. There is always someone, somewhere, who is able and likely to take a meaning from a statement that was not intended. So we need to be careful about creating fear of a word on the off-chance that someone, somewhere, might misunderstand. With that caveat, I have to agree with your concern over the word 'trust' in most IETF process discussions. To use the word is to make the opposite relevant. As you note, it is a powerful, emotional term. Let's not pretend otherwise. Perhaps the real problem is that it conveys no useful information. Would someone be selected who is *not* trusted? Hence saying that they are trusted provides no insight. In all likelihood, the word is used in place of working a bit harder to say something that really *is* meaningful and distinctive about that person, in this particular context. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Sun Jun 22 10:06:19 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11719 for ; Sun, 22 Jun 2003 10:06:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 00381625AC; Sun, 22 Jun 2003 16:05:18 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1D353625A5 for ; Sun, 22 Jun 2003 16:05:16 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19U5T0-0007L6-00; Sun, 22 Jun 2003 09:05:14 -0500 Date: Sun, 22 Jun 2003 10:05:14 -0400 From: John C Klensin To: Thomas Narten Message-ID: <49208097.1056276314@p3.JCK.COM> In-Reply-To: <200306202057.h5KKv589026589@rotala.raleigh.ibm.com> References: <200306202057.h5KKv589026589@rotala.raleigh.ibm.com> X-Mailer: Mulberry/3.1.0b2 (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: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Friday, 20 June, 2003 16:57 -0400 Thomas Narten wrote: >> - My understanding is that in the IESG, a shepherding AD does >> a write-up of each document that is to come up for ballot. >> Some of the other ADs often just read the write-up, trusting >> it to be a fair evaluation of the document. ADs trust each >> other's opinions of the technical quality of the document, >> often voting "no objection" to a document that's out of >> their area of expertise because they trust that the >> shepherding AD or other ADs who are more familiar with the >> document. Assuming my perception is correct of how things >> work on the IESG, I think that's all good stuff. However, >> working group chairs are *not* routinely expected to do >> something like an AD write-up of a document. > > I've never asked or expected my WG chairs to do the writeup. I > guess partly this is for historical reasons (it wasn't done > that way when I started). Also, I don't really see this as a > place where offloading the chairs gets much bang for the buck. Thomas, I think this is a matter of style, rather than any trust issues (except as in the second bullet below), but I have always felt that requiring WG chairs to do those writeups would be extremely useful (separately or as a component of a general "explicit checkoff" process). Some reasons: * At least in the past, a lot of documents have appeared to be stalled between "WG thinks it is finished" and "IESG is processing" because the AD hasn't gotten around to doing the ballot writeup. Pushing that responsibility toward the WG would appropriately shift the locus of the timing problems. * Having the WG chair responsible for the writeup also helps to educate that person, and the WG, as to the issues the IESG considers important. And IESG understanding that there are people there who understand how to do a writeup, highlight important issues for the IESG to consider, etc., could be useful tools for leadership development and expansion of "trust networks" or whatever we are calling them today. For those who don't know, the "general explicit checkoff" idea would be to expect a WG chair to prepare a writeup (or sign off on a check list) that identifies issues the WG has, and has not, discussed and what resolution was reached. A draft writeup would probably be part of it. Its origins lay in wanting to be sure that, e.g., a WG had considered whether a particular section was needed in a draft: the AD shouldn't need to run around trying to figure out whether the absence of an "IANA Considerations" sections is because the WG considered the question and decided it wasn't needed versus "it fell through the cracks". But, at various times, the suggestion has expanded to include a WG summary of significant alternatives that were considered and rejected and shy -- the more the IESG understands about what the WG considered carefully, the more likely it is to trust WG consensus about the outcome. Those are not solution proposals, just observations about the "who does the writeup" question and its broader implications some of which are, IMO, symptomatic of deeper problems of procedure and maybe attitude. >> In fact, I've been directly told by some folks who've been >> on the IESG that the idea that a working group chair could do >> something like a good technical write-up that could be >> trusted by the IESG is absurd. > > I think one would need to look at this on a case-by-case > basis. And it's not just about "trust" in some good/bad sense, > it also has to do with experience. Better writeups come with > experience, not on the first try. And whether this is > something that needs to be pushed down the chairs. And, unless we push this stuff onto the chairs, we expect people to learn? How? A flash of revelation from on high upon being seated on the IESG? Seriously, we make entries on the problem list that amount to * Not enough leadership development. * Poor mechanisms for getting into the IESG's trust network. * Too long startup time for new members of the IESG. * Too little visibility into how the IESG is actually thinking in the WGs. * Too little visibility by the IESG into what the WG actually considered carefully versus what it let slip by. * IESG overload and so on. And then we ignore a class of possibility that would probably help with all of those issues because, e.g., the WG Chairs don't already have the necessary experience. That, to me, is a Problem. > To me, it's not really about "trust". I'm just not sure why > the WG chairs should be doing this (except maybe under the > "offload as much work as possible" theory). In practice, doing > the writeup doesn't take that much time and I suspect that if > I asked the chairs to do it, I'd end up spending as much time > in the end just in iterating on the text and going back and > forth. Often (and this is _really_ an important point), there > is no time for that, because I'm trying to get the writeup > finished in time for a deadline in order to get the document > on the agenda for the next telechat. In such cases, one may > not have a few hours or days to iterate. For me, this just > isn't a place where it seems to make sense to try and off load > to the chairs that much. Others may feel differently. But that pressure is, I think, artificial. The WG chair has to write you a note to say "start processing this". Until you get that note, presumably nothing happens (although, presumably, you have been following the WG's work all alone, identifying problems and discussing them). If you require a writeup, or a checklist, or both, as part of that note, its impact on the IESG schedule and deadlines is zero. Yes, if you don't find the writeup satisfactory and have to iterate on it, some time gets lost. But the WG chair gets some education, you might find out things about the WG's perspective that you didn't appreciate, and the WG gets a better understanding about the issues you (and the IESG) are concerned about even before the document(s) go into the "ballot" process. regards, john From problem-statement-bounces@alvestrand.no Sun Jun 22 12:20:56 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13782 for ; Sun, 22 Jun 2003 12:20:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B9131625B2; Sun, 22 Jun 2003 18:20:25 +0200 (CEST) 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 0D0E5625AC for ; Sun, 22 Jun 2003 18:20:22 +0200 (CEST) Received: (qmail 21556 invoked from network); 22 Jun 2003 16:27:23 -0000 Received: from unknown (HELO pobox.org.sg) (207.253.236.137) by sentosa.post1.com with SMTP; 22 Jun 2003 16:27:23 -0000 Message-ID: <3EF5D71E.7090709@pobox.org.sg> Date: Mon, 23 Jun 2003 00:19:42 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: "problem-statement@alvestrand.no" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 was going thru draft-ietf-problem-issue-statement and found something missing... For those of us who have chair IETF WG, I am sure we have encountered, one time or another, members of the group whom we considered "trouble maker". While the term "trouble maker" is a usually a matter of individual opinion, the type which I particularly have problem with are the ones who are extremely disruptive in the working group repeating issues usually with the attempt to derail the progress or having the attitute that "i-will-not-close-this-issue-unless-you-agree-with-me". It become even more painful when these "trouble makers" are well-verse in "IETF appeal process" and not hesitant to use these rules to achieve their goal. It is a painful and waste of time for the chairs and the ADs who are already overworked. It is not unusual for a single "trouble maker" derailing the progress for as long as a year or more. While we can debate over what is the appropriate solution to deal with "trouble makers", at least pls capture this issue in the problem statement. -James Seng From problem-statement-bounces@alvestrand.no Sun Jun 22 14:45:56 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15355 for ; Sun, 22 Jun 2003 14:45:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 355E3625AC; Sun, 22 Jun 2003 20:45:24 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 88A2062595; Sun, 22 Jun 2003 20:45:21 +0200 (CEST) Date: Sun, 22 Jun 2003 14:28:53 -0400 From: Harald Tveit Alvestrand To: Avri Doria , problem-statement@alvestrand.no Message-ID: <126179526.1056292133@localhost> In-Reply-To: References: X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: Open Process Issue: Improvement WG Chair Selection X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 while it would probably be improper for me to try to influence the advice of the group too much..... please try to provide what you think in terms of advice and "what you are trying to achieve" rather than "this is the exact procedure that must be followed". The difference is the amount of flexibility one has when trying to in fact implement the "protocol". For example.... During the process of selecting the problem-statement chair, it became clear that two chairs was a better idea than one; if I had (for instance) been confined to "filling the positions originally advertised", I wouldn't have been able to do the Right Thing and pick two. It's so easy to get a process into silly states... Harald --On 21. juni 2003 10:36 +0900 Avri Doria wrote: > > While reviewing issues for an upcoming release of the > process document, the issue of how the chair(s) of the > improvement group were to be chosen stood out > as having not been discussed to any length. > > There was recommendation that it be done by the General > Area AD. And there was one voice of concurrence. > > So, is it safe to conclude that this reflects WG consensus? > Or do the topic get lost in the shuffle? Opinions please. > > If it is consensus, a further question is, does the WG want > to recommend a process by which the AD will choose the > chair? E.g. does the WG want to recommend an open process > similar to that used by Harald in selecting the chairs for this > WG group. Or, should the manner of selection it be left to the > AD as is currently the rule? > > Thanks > a. > > > From problem-statement-bounces@alvestrand.no Sun Jun 22 15:08:27 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16000 for ; Sun, 22 Jun 2003 15:08:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E444B625C8; Sun, 22 Jun 2003 21:07:55 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0881A625BD for ; Sun, 22 Jun 2003 21:07:54 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19UABs-0008WL-00; Sun, 22 Jun 2003 14:07:52 -0500 Date: Sun, 22 Jun 2003 15:07:52 -0400 From: John C Klensin To: "avri@acm.org" , "problem-statement@alvestrand.no" Message-ID: <10505315.1056294472@p3.JCK.COM> In-Reply-To: <200306211115.h5LBFItp009253@newdev.harvard.edu> References: <200306211115.h5LBFItp009253@newdev.harvard.edu> X-Mailer: Mulberry/3.1.0b2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Scott Bradner Subject: Re: Open Process Issue: Improvement WG Chair Selection X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On Saturday, 21 June, 2003 07:15 -0400 Scott Bradner wrote: > I think the process used to select the chairs of the problem > group should be used to select the chair(s) of the solution WG Since you seem to be collecting "votes", I concur with Scott and other. I'd state it differently, e.g., as "I think the General AD" should do this according to normal process and what makes sense to him, with the recommendation that the procedure used to select the chairs of this group seems to have worked well enough to make a process norm for this sort of thing. john From problem-statement-bounces@alvestrand.no Sun Jun 22 17:20:10 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18994 for ; Sun, 22 Jun 2003 17:20:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1205E6238C; Sun, 22 Jun 2003 23:19:39 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from grouse.mail.pas.earthlink.net (grouse.mail.pas.earthlink.net [207.217.120.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id E55EE6230D for ; Sun, 22 Jun 2003 23:19:37 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19UCFI-0002HV-00; Sun, 22 Jun 2003 14:19:32 -0700 Date: Sun, 22 Jun 2003 17:16:25 -0400 From: Keith Moore To: James Seng Message-Id: <20030622171625.3f1eb432.moore@cs.utk.edu> In-Reply-To: <3EF5D71E.7090709@pobox.org.sg> References: <3EF5D71E.7090709@pobox.org.sg> X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > For those of us who have chair IETF WG, I am sure we have encountered, > one time or another, members of the group whom we considered "trouble > maker". The flip side of this is the WG that just won't get it - no matter how valid the issues that are raised, the group brands the individual a "trouble maker" and refuses to do anything about them other than to try to marginalize him or her. No matter how well-supported that individual's arguments are, they are dismissed as specious - or the group will even claim that the arguments or evidence have not been presented. This is most likely to happen when the group sees the individual as "not one of us" - e.g. not an employee of a vendor of the products that the group is trying to standardize. So if we're going to mention the troublemaker issue in the document (and I agree it's a valid issue), we should mention this issue also. I've also seen groups get hung up for months because they couldn't make a decision to stop arguing. They'll blame it on the troublemaker, but the troublemaker isn't the real problem - the problem is that the group isn't willing or able to make a decision in the presence of any controversy. Sometimes the right thing for a group to do is to document the controversy and move on. And sometimes the right thing is to ask for wider review of a design decision. From problem-statement-bounces@alvestrand.no Sun Jun 22 17:33:51 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19185 for ; Sun, 22 Jun 2003 17:33:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DB911625BD; Sun, 22 Jun 2003 23:33:20 +0200 (CEST) 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 9136E6238C for ; Sun, 22 Jun 2003 23:33:19 +0200 (CEST) Received: from cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 22 Jun 2003 14:35:07 -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 h5MLXFGe005525; Sun, 22 Jun 2003 14:33:16 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIR51074; Sun, 22 Jun 2003 14:33:14 -0700 (PDT) Message-Id: <200306222133.AIR51074@mira-sjc5-c.cisco.com> To: Keith Moore From: Melinda Shore In-Reply-To: Message from moore@cs.utk.edu <20030622171625.3f1eb432.moore@cs.utk.edu> Date: Sun, 22 Jun 2003 17:33:13 -0400 Cc: James Seng Cc: problem-statement@alvestrand.no Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > > For those of us who have chair IETF WG, I am sure we have encountered, > > one time or another, members of the group whom we considered "trouble > > maker". > The flip side of this is the WG that just won't get it - > no matter how valid the issues that are raised, the group > brands the individual a "trouble maker" and refuses to do > anything about them other than to try to marginalize him > or her. I've certainly seen both happen, both within the IETF and elsewhere. But this working group is focused on identifying problems with IETF structures and processes, and it seems to me that the issues that both of you are raising have to do with decision-making and dispute resolution, two areas where I believe we've got some really serious problems. Does anyone feel like proposing some specific text for the draft? Melinda From problem-statement-bounces@alvestrand.no Sun Jun 22 17:39:02 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19223 for ; Sun, 22 Jun 2003 17:39:01 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ACE04625BD; Sun, 22 Jun 2003 23:38:31 +0200 (CEST) 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 A79E96238C for ; Sun, 22 Jun 2003 23:38:28 +0200 (CEST) Received: (qmail 23443 invoked from network); 22 Jun 2003 21:45:41 -0000 Received: from unknown (HELO pobox.org.sg) (207.253.236.138) by sentosa.post1.com with SMTP; 22 Jun 2003 21:45:41 -0000 Message-ID: <3EF621D9.3060406@pobox.org.sg> Date: Mon, 23 Jun 2003 05:38:33 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Keith Moore References: <3EF5D71E.7090709@pobox.org.sg> <20030622171625.3f1eb432.moore@cs.utk.edu> In-Reply-To: <20030622171625.3f1eb432.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > The flip side of this is the WG that just won't get it - no matter how valid > the issues that are raised, the group brands the individual a "trouble maker" > and refuses to do anything about them other than to try to marginalize him or > her. No matter how well-supported that individual's arguments are, they are > dismissed as specious - or the group will even claim that the arguments or > evidence have not been presented. This is most likely to happen when the > group sees the individual as "not one of us" - e.g. not an employee of a > vendor of the products that the group is trying to standardize. This is where the "fuzziness" of "trouble maker" comes in, especially no one likes to be label as such. We need a careful definition. (btw, imho, someone who provides constructive counterview is a *not* a trouble maker) > So if we're going to mention the troublemaker issue in the document (and I > agree it's a valid issue), we should mention this issue also. > > I've also seen groups get hung up for months because they couldn't make a > decision to stop arguing. They'll blame it on the troublemaker, but the > troublemaker isn't the real problem - the problem is that the group isn't > willing or able to make a decision in the presence of any controversy. > Sometimes the right thing for a group to do is to document the controversy > and move on. And sometimes the right thing is to ask for wider review of a > design decision. But lets not forget the core principle of IETF are "running code" and "rough consensus". So in the event of arguments of "technical merits" vs "rough consensus", "rough consensus" *should* win. (Unless there are "technical failure" in the proposed solution.) In other words, so long a solution 'works' and have majority support from the community, it wins. The existence or non-existance of any other 'better solution' is irrelevant. But as you said, WG chairs are in difficult position to declare "rough consensus" in the event of controversy (aka, "someone still complaining about it") especially worried over appeal. This effectively put a halt on the progress in many working groups. And personally, I find this is a serious problem which slows down IETF drastically. -James Seng From problem-statement-bounces@alvestrand.no Sun Jun 22 18:05:27 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19715 for ; Sun, 22 Jun 2003 18:05:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8EF67625CD; Mon, 23 Jun 2003 00:04:57 +0200 (CEST) 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 5F7336238C for ; Mon, 23 Jun 2003 00:04:54 +0200 (CEST) Received: (qmail 23504 invoked from network); 22 Jun 2003 22:12:07 -0000 Received: from unknown (HELO pobox.org.sg) (207.253.236.138) by sentosa.post1.com with SMTP; 22 Jun 2003 22:12:07 -0000 Message-ID: <3EF6280B.5050108@pobox.org.sg> Date: Mon, 23 Jun 2003 06:04:59 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Melinda Shore References: <200306222133.AIR51074@mira-sjc5-c.cisco.com> In-Reply-To: <200306222133.AIR51074@mira-sjc5-c.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Cc: Keith Moore Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 According to the charter of this group at, the group are looking at the problems with "the ways IETF operates". This is not limited to structure and processes only. (is this an example of Problem 2.1 Participants in the IETF do not share a common understanding of its mission?) For wordings, I proposed to add a sub section to 2.6, as follows: 2.6.1 Vocal individual have ability to stall the rough consensus building process In some working groups, a vocal individual could stall the working group progress for many months or indefinately by repeatively re-opening closed issues. This, coupled with the threat with appeal on technical and process ground, effectively prevented the working group chair to declare a rough consensus on the group. -James Seng Melinda Shore wrote: >>>For those of us who have chair IETF WG, I am sure we have encountered, >>>one time or another, members of the group whom we considered "trouble >>>maker". > > >>The flip side of this is the WG that just won't get it - >>no matter how valid the issues that are raised, the group >>brands the individual a "trouble maker" and refuses to do >>anything about them other than to try to marginalize him >>or her. > > > I've certainly seen both happen, both within the IETF and > elsewhere. But this working group is focused on identifying > problems with IETF structures and processes, and it seems to > me that the issues that both of you are raising have to do > with decision-making and dispute resolution, two areas where > I believe we've got some really serious problems. Does > anyone feel like proposing some specific text for the draft? > > Melinda > > From problem-statement-bounces@alvestrand.no Sun Jun 22 18:38:51 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21235 for ; Sun, 22 Jun 2003 18:38:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 38E29625CD; Mon, 23 Jun 2003 00:38:21 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by eikenes.alvestrand.no (Postfix) with ESMTP id EEF696238C for ; Mon, 23 Jun 2003 00:38:18 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19UDTQ-0000RP-00; Sun, 22 Jun 2003 15:38:12 -0700 Date: Sun, 22 Jun 2003 18:35:04 -0400 From: Keith Moore To: James Seng Message-Id: <20030622183504.4ba27a07.moore@cs.utk.edu> In-Reply-To: <3EF6280B.5050108@pobox.org.sg> References: <200306222133.AIR51074@mira-sjc5-c.cisco.com> <3EF6280B.5050108@pobox.org.sg> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: mshore@cisco.com Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > For wordings, I proposed to add a sub section to 2.6, as follows: > > 2.6.1 Vocal individual have ability to stall the rough consensus > building process > > In some working groups, a vocal individual could stall the working group > progress for many months or indefinately by repeatively re-opening > closed issues. This, coupled with the threat with appeal on technical > and process ground, effectively prevented the working group chair to > declare a rough consensus on the group. but it *doesn't* prevent a WG chair from declaring rough consensus. From problem-statement-bounces@alvestrand.no Sun Jun 22 18:40:31 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21275 for ; Sun, 22 Jun 2003 18:40:30 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3C87D625D0; Mon, 23 Jun 2003 00:40:01 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from albatross.mail.pas.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9B86C625CD for ; Mon, 23 Jun 2003 00:39:59 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19UDV1-0002gF-00; Sun, 22 Jun 2003 15:39:52 -0700 Date: Sun, 22 Jun 2003 18:36:44 -0400 From: Keith Moore To: James Seng Message-Id: <20030622183644.590e35e6.moore@cs.utk.edu> In-Reply-To: <3EF621D9.3060406@pobox.org.sg> References: <3EF5D71E.7090709@pobox.org.sg> <20030622171625.3f1eb432.moore@cs.utk.edu> <3EF621D9.3060406@pobox.org.sg> X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > So in the event of arguments of "technical merits" vs > "rough consensus", "rough consensus" *should* win. if it's just a question of the best way to do things - agree. the best is the enemy of the good. if the proposal doesn't meet the qualifications in 2026 - disagree. From problem-statement-bounces@alvestrand.no Sun Jun 22 18:42:26 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21305 for ; Sun, 22 Jun 2003 18:42:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 285C1625CD; Mon, 23 Jun 2003 00:41:57 +0200 (CEST) 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 50F2F6238C for ; Mon, 23 Jun 2003 00:41:55 +0200 (CEST) Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 22 Jun 2003 15:40:41 -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 h5MMfqqd011725; Sun, 22 Jun 2003 15:41:53 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIR53117; Sun, 22 Jun 2003 15:41:52 -0700 (PDT) Message-Id: <200306222241.AIR53117@mira-sjc5-c.cisco.com> To: James Seng From: Melinda Shore In-Reply-To: Message from jseng@pobox.org.sg of "Mon, 23 Jun 2003 06:04:59 +0800." <3EF6280B.5050108@pobox.org.sg> Date: Sun, 22 Jun 2003 18:41:51 -0400 Cc: problem-statement@alvestrand.no Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > According to the charter of this group at, the group are looking at the > problems with "the ways IETF operates". This is not limited to structure > and processes only. [Taking off my chair hat] Of course, but it seems clear to me that the problem isn't that there are a few obstructive people but that we don't have (or don't use) mechanisms to deal with that very well. I don't think that there's much that we can do about human nature or human motivation, but there are things we can do about how we operate. For example, I've seen exactly what you describe (repeated re-opening of closed issues) and I think that if WG chairs refuse allow decisions to be revisited without new information or a new argument being presented that problem can be addressed without fundamentally re-engineering human nature. I'd strongly prefer to see this problem you're describing, which I absolutely agree is a problem, framed in terms of the IETF rather than in terms of the individual. Melinda From problem-statement-bounces@alvestrand.no Sun Jun 22 18:53:25 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21520 for ; Sun, 22 Jun 2003 18:53:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A5732625CD; Mon, 23 Jun 2003 00:52:55 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from grouse.mail.pas.earthlink.net (grouse.mail.pas.earthlink.net [207.217.120.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2105A6238C for ; Mon, 23 Jun 2003 00:52:54 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19UDhY-0004uU-00; Sun, 22 Jun 2003 15:52:48 -0700 Date: Sun, 22 Jun 2003 18:49:41 -0400 From: Keith Moore To: Melinda Shore Message-Id: <20030622184941.3bdef26f.moore@cs.utk.edu> In-Reply-To: <200306222241.AIR53117@mira-sjc5-c.cisco.com> References: <3EF6280B.5050108@pobox.org.sg> <200306222241.AIR53117@mira-sjc5-c.cisco.com> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: jseng@pobox.org.sg Cc: moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 very much in agreement. Keith > For example, I've seen exactly what > you describe (repeated re-opening of closed issues) and I > think that if WG chairs refuse allow decisions to be > revisited without new information or a new argument being > presented that problem can be addressed without > fundamentally re-engineering human nature. I'd strongly > prefer to see this problem you're describing, which I > absolutely agree is a problem, framed in terms of the IETF > rather than in terms of the individual. From problem-statement-bounces@alvestrand.no Sun Jun 22 19:03:21 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21649 for ; Sun, 22 Jun 2003 19:03:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3216E625C8; Mon, 23 Jun 2003 01:02:51 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from relay3.kornet.net (relay3.kornet.net [211.48.62.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9518B6238C for ; Mon, 23 Jun 2003 01:02:44 +0200 (CEST) Received: from [220.89.169.75] (avri@apocalypse.org) by relay3.kornet.net (Terrace Internet Messaging Server) with ESMTP id 2003062308:02:38:728956.25704.221 for ; Mon, 23 Jun 2003 08:02:38 +0900 (KST) Date: Mon, 23 Jun 2003 08:02:36 +0900 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: avri To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit In-Reply-To: <20030622184941.3bdef26f.moore@cs.utk.edu> Message-Id: <9D89023C-A505-11D7-8159-000393CC2112@apocalypse.org> X-Mailer: Apple Mail (2.552) Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 personally] the problem i end up having, is how does one know there is new information or a new argument until after that argument is given. the tendency is often to rephrase the argument in new language. but the speaker if asked, will certainly claim it is a new argument or info. this is where i think a procedural mechanism may be helpful. a. On Monday, Jun 23, 2003, at 07:49 Asia/Seoul, Keith Moore wrote: > very much in agreement. > > Keith > >> For example, I've seen exactly what >> you describe (repeated re-opening of closed issues) and I >> think that if WG chairs refuse allow decisions to be >> revisited without new information or a new argument being >> presented that problem can be addressed without >> fundamentally re-engineering human nature. I'd strongly >> prefer to see this problem you're describing, which I >> absolutely agree is a problem, framed in terms of the IETF >> rather than in terms of the individual. > From problem-statement-bounces@alvestrand.no Sun Jun 22 19:11:00 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21731 for ; Sun, 22 Jun 2003 19:10:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 42B41625C8; Mon, 23 Jun 2003 01:10:30 +0200 (CEST) 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 6B31B6238C for ; Mon, 23 Jun 2003 01:10:27 +0200 (CEST) Received: from employees.org (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 22 Jun 2003 16:13:28 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5MNAQGe001627 for ; Sun, 22 Jun 2003 16:10:26 -0700 (PDT) Received: from cisco.com (sjc-vpn4-484.cisco.com [10.21.81.228]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AHJ35211; Sun, 22 Jun 2003 16:04:56 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Sun, 22 Jun 2003 19:10:20 -0400 Date: Sun, 22 Jun 2003 19:10:19 -0400 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030622231019.GC1352@sbrim-w2k01> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: <3EF6280B.5050108@pobox.org.sg> <200306222241.AIR53117@mira-sjc5-c.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200306222241.AIR53117@mira-sjc5-c.cisco.com> User-Agent: Mutt/1.4i Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Sun, Jun 22, 2003 06:41:51PM -0400, Melinda Shore allegedly wrote: > Of course, but it seems clear to me that the problem isn't > that there are a few obstructive people but that we don't > have (or don't use) mechanisms to deal with that very well. Yes. > I'd strongly > prefer to see this problem you're describing, which I > absolutely agree is a problem, framed in terms of the IETF > rather than in terms of the individual. From problem-statement-bounces@alvestrand.no Sun Jun 22 21:23:28 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23518 for ; Sun, 22 Jun 2003 21:23:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E9761625C8; Mon, 23 Jun 2003 03:22:16 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from turkey.mail.pas.earthlink.net (turkey.mail.pas.earthlink.net [207.217.120.126]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6C3DE625A5 for ; Mon, 23 Jun 2003 03:22:15 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19UG25-0007e2-00; Sun, 22 Jun 2003 18:22:10 -0700 Date: Sun, 22 Jun 2003 21:19:01 -0400 From: Keith Moore To: avri Message-Id: <20030622211901.3a3999d8.moore@cs.utk.edu> In-Reply-To: <9D89023C-A505-11D7-8159-000393CC2112@apocalypse.org> References: <20030622184941.3bdef26f.moore@cs.utk.edu> <9D89023C-A505-11D7-8159-000393CC2112@apocalypse.org> X-Mailer: Sylpheed version 0.8.11 (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 Cc: moore@cs.utk.edu Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > the problem i end up having, is how does one know there > is new information or a new argument until after that argument > is given. the tendency is often to rephrase the argument in > new language. but the speaker if asked, will certainly claim > it is a new argument or info. > > this is where i think a procedural mechanism may be helpful. yes, I agree we would benefit from having explicit procedures to resolve these problems. From problem-statement-bounces@alvestrand.no Mon Jun 23 00:46:35 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26622 for ; Mon, 23 Jun 2003 00:46:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9A95D625A5; Mon, 23 Jun 2003 06:46:05 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mta1.wss.scd.yahoo.com (mta1.wss.scd.yahoo.com [66.218.85.32]) by eikenes.alvestrand.no (Postfix) with ESMTP id F39626238C for ; Mon, 23 Jun 2003 06:46:03 +0200 (CEST) Received: from AwducheHPlapt (207.87.51.124) by mta1.wss.scd.yahoo.com (7.0.016) (authenticated as awduche@awduche.com) id 3EDCE7E00076FF25; Sun, 22 Jun 2003 21:45:55 -0700 From: "Daniel O. Awduche" To: "'James Seng'" , Date: Mon, 23 Jun 2003 00:45:35 -0400 Message-ID: <003101c33942$4968b710$7c3357cf@awduche.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3EF5D71E.7090709@pobox.org.sg> Subject: RE: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: awduche@awduche.com 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 a matter of principle, the process needs to focus on the merits of arguments, not some characterization of the individuals involved. Often times, people in authority have a tendency to portray others with dissenting views as "trouble makers," thereby precluding the diligence of applying basic management skills to resolve contentious issues and/or drive towards rough consensus. i.e. there should be no place for the term "trouble maker" in IETF documents. Cheers, /Dan -----Original Message----- From: problem-statement-bounces@alvestrand.no [mailto:problem-statement-bounces@alvestrand.no] On Behalf Of James Seng Sent: Sunday, June 22, 2003 12:20 PM To: problem-statement@alvestrand.no Subject: "trouble maker" I was going thru draft-ietf-problem-issue-statement and found something missing... For those of us who have chair IETF WG, I am sure we have encountered, one time or another, members of the group whom we considered "trouble maker". While the term "trouble maker" is a usually a matter of individual opinion, the type which I particularly have problem with are the ones who are extremely disruptive in the working group repeating issues usually with the attempt to derail the progress or having the attitute that "i-will-not-close-this-issue-unless-you-agree-with-me". It become even more painful when these "trouble makers" are well-verse in "IETF appeal process" and not hesitant to use these rules to achieve their goal. It is a painful and waste of time for the chairs and the ADs who are already overworked. It is not unusual for a single "trouble maker" derailing the progress for as long as a year or more. While we can debate over what is the appropriate solution to deal with "trouble makers", at least pls capture this issue in the problem statement. -James Seng From problem-statement-bounces@alvestrand.no Mon Jun 23 01:21:38 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27034 for ; Mon, 23 Jun 2003 01:21:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8A1F2625E0; Mon, 23 Jun 2003 07:21:07 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mta1.wss.scd.yahoo.com (mta1.wss.scd.yahoo.com [66.218.85.32]) by eikenes.alvestrand.no (Postfix) with ESMTP id 28DE56238C; Mon, 23 Jun 2003 07:21:06 +0200 (CEST) Received: from AwducheHPlapt (207.87.51.124) by mta1.wss.scd.yahoo.com (7.0.016) (authenticated as awduche@awduche.com) id 3EDCE7E00077143D; Sun, 22 Jun 2003 22:18:58 -0700 From: "Daniel O. Awduche" To: , , Date: Mon, 23 Jun 2003 01:18:38 -0400 Message-ID: <003401c33946$e7404a30$7c3357cf@awduche.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Cc: Erik.Nordmark@sun.com Subject: RE: Erik Nordmark: stepping down (fwd) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: awduche@awduche.com List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit I think Rob Coltun made similar (perhaps more pointed) comments when he resigned from the IESG -- based on widely published reports in the popular technical press at the time -- see, e.g., http://www.lightreading.com/document.asp?doc_id=9933&site=lightreading Cheers, /Dan -----Original Message----- From: problem-statement-bounces@alvestrand.no [mailto:problem-statement-bounces@alvestrand.no] On Behalf Of john.loughney@nokia.com Sent: Thursday, June 19, 2003 7:53 AM To: harald@alvestrand.no; problem-statement@alvestrand.no Cc: Erik.Nordmark@sun.com Subject: RE: Erik Nordmark: stepping down (fwd) Harald & Erik, It seems that Erik's message is carefully worded to avoid placing blame. As such, I have some trouble understanding the implications of Erik's statement below. Would an 'exit interview' be appropriate or at least some comments wrt the problem statement to help us to improve the process? It is a shame to lose talented and committed folks from the IETF leadership. thanks, John From problem-statement-bounces@alvestrand.no Mon Jun 23 07:02:05 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15947 for ; Mon, 23 Jun 2003 07:02:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6570762577; Mon, 23 Jun 2003 12:59:58 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 13AFF622BB; Mon, 23 Jun 2003 12:59:52 +0200 (CEST) Date: Mon, 23 Jun 2003 06:59:48 -0400 From: Harald Tveit Alvestrand To: awduche@awduche.com, problem-statement@alvestrand.no Message-ID: <185634628.1056351588@HALVESTR-W2K1.cisco.com> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: RE: Erik Nordmark: stepping down (fwd) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 23. juni 2003 01:18 -0400 "Daniel O. Awduche" wrote: > I think Rob Coltun made similar (perhaps more pointed) comments > when he resigned from the IESG -- based on widely published reports > in the popular technical press at the time -- see, e.g., > http://www.lightreading.com/document.asp?doc_id=9933&site=lightreading Some of Rob's comments had an entirely different slant, in my reading. But there are similarities too. His resignation note was also sent to the ietf-announce list (November 26, 2001); I have copied it below. But yes, there are similarities. And I've been trying to come to grips with some of the problems he pointed out for a LONG time..... Harald ------------------------------------------------------------------ I'll be resigning as Routing AD as of this coming IETF, four months prior to my term ending. Before the passing of our dear Abha, we discussed my resignation; she encouraged me to send a note to the IETF explaining my reasons for resigning. I've been around the IETF since the late 80s and have always been excited by the technology. For me, our work on Internet technology has been about evolving the technology in the context of our relationships; collaborating, trusting, challenging and encouraging each other. I took on the job as AD to continue building upon this premise. Over the last couple of years I have found it exceedingly difficult to work within the IESG. So much so, that my enthusiasm for the work and my energy for support of working groups have greatly diminished. Some of the infrastructure work that had support within the community, would get mangled, interpreted through personal prejudice and generally dragged through the muck when brought before the IESG. It has been draining to work within an environment that undermines both community consensus and my own vision. This is not to point to anyone in particular within the IESG; certainly the IESG is made up of many well-meaning, intelligent and overworked folks. But it seems that the system within the current IESG has become very nit-picky; the IESG seems to have lost the big picture. The "just do the right thing" principal that seemed to be there for so long is hard to come by. In my opinion, part of the problem is that the IESG's model of "management by body" worked when a few hundred people showed up for IETF meetings and the scope and quantity of our work was much less, but this model is now antiquated. To give a couple of specific examples: ADs should be open to input from anyone offering good ideas but a single AD's objection should not be allowed to override the responsible AD's view. An AD should be responsible for the complete scope of the work and not rely on ADs from other areas to overly influence particular work, especially after a working group deems the work to be complete. The roles of the members of the IESG and IAB should be well defined; the role of the IESG should be well defined and the relationship between the IESG and IAB should be well defined. IETF meetings must be smaller to be more productive. One suggestion is to formalize the private meetings that happen between authors and co-chairs and provide tutorials and updates for the masses. The conversations of whether or not particular work should be taken on by the IETF are very important but should last at most a few months, not years. It is no coincidence that as the factors that are driving the current phase of the evolution of the Internet changes, restructuring of the management of the IETF becomes inevitable. So many issues... I could go on and on for another... four months, but I won't :-) Time for an AD reboot, some new ideas, new energy and for me to move on. It's been an honor to share in this nanosecond of the evolution... See you on the net... ---rob From problem-statement-bounces@alvestrand.no Mon Jun 23 08:48:29 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18563 for ; Mon, 23 Jun 2003 08:48:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A71EA625E3; Mon, 23 Jun 2003 14:47:46 +0200 (CEST) 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 A215A625C9 for ; Mon, 23 Jun 2003 14:47:43 +0200 (CEST) Received: (qmail 35436 invoked from network); 23 Jun 2003 12:54:51 -0000 Received: from unknown (HELO pobox.org.sg) (207.253.236.138) by sentosa.post1.com with SMTP; 23 Jun 2003 12:54:51 -0000 Message-ID: <3EF6F6F3.40204@pobox.org.sg> Date: Mon, 23 Jun 2003 20:47:47 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Melinda Shore References: <200306222241.AIR53117@mira-sjc5-c.cisco.com> In-Reply-To: <200306222241.AIR53117@mira-sjc5-c.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 It appears to me that people has not disagreed with my suggestion of the problem (P1) that a few individual is capable of stalling the process almost indefinately and yes, I also agree with you that the other problem (P2) is we have no process to deal with P1. (Note, P1 & P2 are two separate problem altho they are related). I have already made my proposed wordings for the framing of this problem without using degrading term like "trouble maker". If you feel that my wording are not sufficiently politically correct, then please propose your wording. --- CUT HERE --- 2.6.1 Vocal individual have ability to stall the rough consensus building process In some working groups, a vocal individual could stall the working group progress for many months or indefinately by repeatively re-opening closed issues. This, coupled with the threat with appeal on technical and process ground, effectively prevented the working group chair to declare a rough consensus on the group. --- CUT HERE --- -James Seng Melinda Shore wrote: >>According to the charter of this group at, the group are looking at the >>problems with "the ways IETF operates". This is not limited to structure >>and processes only. > > > [Taking off my chair hat] > > Of course, but it seems clear to me that the problem isn't > that there are a few obstructive people but that we don't > have (or don't use) mechanisms to deal with that very well. > I don't think that there's much that we can do about human > nature or human motivation, but there are things we can do > about how we operate. For example, I've seen exactly what > you describe (repeated re-opening of closed issues) and I > think that if WG chairs refuse allow decisions to be > revisited without new information or a new argument being > presented that problem can be addressed without > fundamentally re-engineering human nature. I'd strongly > prefer to see this problem you're describing, which I > absolutely agree is a problem, framed in terms of the IETF > rather than in terms of the individual. > > Melinda > > From problem-statement-bounces@alvestrand.no Mon Jun 23 08:53:11 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18699 for ; Mon, 23 Jun 2003 08:53:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 619D2625E9; Mon, 23 Jun 2003 14:52:40 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 323E9625E7; Mon, 23 Jun 2003 14:52:37 +0200 (CEST) Date: Mon, 23 Jun 2003 08:48:58 -0400 From: Harald Tveit Alvestrand To: avri , problem-statement@alvestrand.no Message-ID: <192184967.1056358138@localhost> In-Reply-To: <9D89023C-A505-11D7-8159-000393CC2112@apocalypse.org> References: <9D89023C-A505-11D7-8159-000393CC2112@apocalypse.org> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 23. juni 2003 08:02 +0900 avri wrote: > [speaking personally] > > the problem i end up having, is how does one know there > is new information or a new argument until after that argument > is given. the tendency is often to rephrase the argument in > new language. but the speaker if asked, will certainly claim > it is a new argument or info. > > this is where i think a procedural mechanism may be helpful. a related problem is getting the group to remember what the previous decision was, and what the compelling arguments for that decision were. This is especially a problem when it's not possible to read the decision out of the drafts - for instance, where a decision was to *remove* stuff from a draft - or where there is a large turnover of WG membership. record-keeping in a form other than the list archive and the end product of the WG might be a good idea; I've occasionally seen meeting minutes used this way, but it's more difficult for decisions reached on the mailing list. Harald From problem-statement-bounces@alvestrand.no Mon Jun 23 08:59:48 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18824 for ; Mon, 23 Jun 2003 08:59:48 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EFBEC625E7; Mon, 23 Jun 2003 14:59:17 +0200 (CEST) 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 E1BBA625C9 for ; Mon, 23 Jun 2003 14:59:15 +0200 (CEST) Received: (qmail 35551 invoked from network); 23 Jun 2003 13:06:26 -0000 Received: from unknown (HELO pobox.org.sg) (207.253.236.138) by sentosa.post1.com with SMTP; 23 Jun 2003 13:06:26 -0000 Message-ID: <3EF6F9AA.5040408@pobox.org.sg> Date: Mon, 23 Jun 2003 20:59:22 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Keith Moore References: <200306222133.AIR51074@mira-sjc5-c.cisco.com> <3EF6280B.5050108@pobox.org.sg> <20030622183504.4ba27a07.moore@cs.utk.edu> In-Reply-To: <20030622183504.4ba27a07.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mshore@cisco.com Cc: problem-statement@alvestrand.no Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 It shouldnt. But it does. -James Seng Keith Moore wrote: >>For wordings, I proposed to add a sub section to 2.6, as follows: >> >>2.6.1 Vocal individual have ability to stall the rough consensus >>building process >> >>In some working groups, a vocal individual could stall the working group >>progress for many months or indefinately by repeatively re-opening >>closed issues. This, coupled with the threat with appeal on technical >>and process ground, effectively prevented the working group chair to >>declare a rough consensus on the group. > > > but it *doesn't* prevent a WG chair from declaring rough consensus. > > From problem-statement-bounces@alvestrand.no Mon Jun 23 09:12:17 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19253 for ; Mon, 23 Jun 2003 09:12:14 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 76FB262594; Mon, 23 Jun 2003 15:11:42 +0200 (CEST) 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 EF97662594 for ; Mon, 23 Jun 2003 15:11:37 +0200 (CEST) Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 23 Jun 2003 06:10:27 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5NDBRQx025678; Mon, 23 Jun 2003 06:11:28 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIR84206; Mon, 23 Jun 2003 06:11:24 -0700 (PDT) Message-Id: <200306231311.AIR84206@mira-sjc5-c.cisco.com> To: James Seng From: Melinda Shore In-Reply-To: Message from jseng@pobox.org.sg of "Mon, 23 Jun 2003 20:59:22 +0800." <3EF6F9AA.5040408@pobox.org.sg> Date: Mon, 23 Jun 2003 09:11:23 -0400 Cc: problem-statement@alvestrand.no Cc: Keith Moore Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > > but it *doesn't* prevent a WG chair from declaring rough consensus. > It shouldnt. But it does. Then isn't that a problem with how our chairs operate? I think that to a very great extent working groups face a prisoner's dilemma situation and not all self-interest is enlightened. There are countless, I suspect, aspects to this problem, ranging from consensus process really being fairly ill-suited to situations in which there's not a shared commitment to the process itself to working group chairs not being sure how much authority we've got. I think it's extremely useful to talk about how our processes are failing to deal with participants who refuse to take "no" for an answer, but for the purposes of the working group and its follow-on (the solutions group) it's more useful to focus on how the problem is instantiated within the IETF and less on the fact that there are some people who are just plain difficult. That's a windy way of saying that difficult people aren't a problem if we've got mechanisms to get our work done anyway. Melinda From problem-statement-bounces@alvestrand.no Mon Jun 23 09:23:45 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19642 for ; Mon, 23 Jun 2003 09:23:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2041A6230D; Mon, 23 Jun 2003 15:23:15 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by eikenes.alvestrand.no (Postfix) with ESMTP id A5D976223F for ; Mon, 23 Jun 2003 15:23:13 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19URHj-0001qQ-00; Mon, 23 Jun 2003 06:23:03 -0700 Date: Mon, 23 Jun 2003 09:19:52 -0400 From: Keith Moore To: Melinda Shore Message-Id: <20030623091952.0217bdcf.moore@cs.utk.edu> In-Reply-To: <200306231311.AIR84206@mira-sjc5-c.cisco.com> References: <3EF6F9AA.5040408@pobox.org.sg> <200306231311.AIR84206@mira-sjc5-c.cisco.com> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: jseng@pobox.org.sg Cc: moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > > > but it *doesn't* prevent a WG chair from declaring rough consensus. > > It shouldnt. But it does. > > Then isn't that a problem with how our chairs operate? that, and/or expectations of participants, or limitations of the mailing list as a medium for holding these discussions. From problem-statement-bounces@alvestrand.no Mon Jun 23 09:36:33 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19972 for ; Mon, 23 Jun 2003 09:36:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 903EF625C9; Mon, 23 Jun 2003 15:36:02 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by eikenes.alvestrand.no (Postfix) with ESMTP id 37581625AC for ; Mon, 23 Jun 2003 15:36:01 +0200 (CEST) Received: by romeo.rtfm.com (Postfix, from userid 556) id AE903ABB5; Mon, 23 Jun 2003 06:42:02 -0700 (PDT) To: Melinda Shore References: <200306231311.AIR84206@mira-sjc5-c.cisco.com> From: Eric Rescorla Date: 23 Jun 2003 06:42:02 -0700 In-Reply-To: <200306231311.AIR84206@mira-sjc5-c.cisco.com> Message-ID: Lines: 55 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Portable Code) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: James Seng Cc: Keith Moore Cc: problem-statement@alvestrand.no Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: EKR 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 Shore writes: > > > but it *doesn't* prevent a WG chair from declaring rough consensus. > > It shouldnt. But it does. > > Then isn't that a problem with how our chairs operate? I > think that to a very great extent working groups face a > prisoner's dilemma situation and not all self-interest is > enlightened. There are countless, I suspect, aspects to > this problem, ranging from consensus process really being > fairly ill-suited to situations in which there's not a > shared commitment to the process itself to working group > chairs not being sure how much authority we've got. I think > it's extremely useful to talk about how our processes are > failing to deal with participants who refuse to take "no" > for an answer, but for the purposes of the working group and > its follow-on (the solutions group) it's more useful to > focus on how the problem is instantiated within the IETF and > less on the fact that there are some people who are just > plain difficult. > > That's a windy way of saying that difficult people aren't a > problem if we've got mechanisms to get our work done anyway. Melinda, I think this is a useful formulation of the problem. Unfortunately, it also leads to some pretty depressing conclusions. The game theoretic aspects of parliamentary and voting systems have been pretty extensively studied (see Couter's "The Strategic Constitution" or Buchanan & Tulock's "The Calculus of Consent") and it turns out that a number of the nastier aspects of politics are pretty much the immediate consequence of people pursuing their own interests. [0] In particular, systems that require unanimity and near unanimity are highly susceptible to participants "holding out" in hopes of getting a better deal, which is of course what we're seeing here. It's not known, even in principle, how to get rid of these problems, which is why pretty much all existing political decision making systems have them. -Ekr [0] Yes, I know that we talk about the "good of the Internet" as the goal people are supposed to shoot for, but I don't think that's a particularly useful model of what's happening here. First, people often don't agree on what that is and so are pursuing divergent goals, for whatever reasons. Second, I think it's pretty clear that in a number of cases people are in fact pursuing their own interests. -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From problem-statement-bounces@alvestrand.no Mon Jun 23 09:44:39 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20231 for ; Mon, 23 Jun 2003 09:44:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EFEEA622AF; Mon, 23 Jun 2003 15:44:07 +0200 (CEST) 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 1FC526223F for ; Mon, 23 Jun 2003 15:44:03 +0200 (CEST) Received: (qmail 36173 invoked from network); 23 Jun 2003 13:51:13 -0000 Received: from unknown (HELO pobox.org.sg) (207.253.236.138) by sentosa.post1.com with SMTP; 23 Jun 2003 13:51:13 -0000 Message-ID: <3EF70429.7000507@pobox.org.sg> Date: Mon, 23 Jun 2003 21:44:09 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Melinda Shore References: <200306231311.AIR84206@mira-sjc5-c.cisco.com> In-Reply-To: <200306231311.AIR84206@mira-sjc5-c.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Cc: Keith Moore Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Yes, it is a problem too (or at least I think so..others may disagree). That is a natural of problems...they are all linked together. P1 leads to P2 & P3 which leads to P4, P5, P6, P7 and so on. So, why are we avoiding stating P1 and instead trying to frame it at one/two degree removed problem of P4 to P7? Why? Could someone fill me in or are there reasons which I am not aware? I mean, it is not as if we are naming any individual in the draft. (I hate to think we have lost the candid in our culture.) -James Seng Melinda Shore wrote: >>>but it *doesn't* prevent a WG chair from declaring rough consensus. >> >>It shouldnt. But it does. > > > Then isn't that a problem with how our chairs operate? I > think that to a very great extent working groups face a > prisoner's dilemma situation and not all self-interest is > enlightened. There are countless, I suspect, aspects to > this problem, ranging from consensus process really being > fairly ill-suited to situations in which there's not a > shared commitment to the process itself to working group > chairs not being sure how much authority we've got. I think > it's extremely useful to talk about how our processes are > failing to deal with participants who refuse to take "no" > for an answer, but for the purposes of the working group and > its follow-on (the solutions group) it's more useful to > focus on how the problem is instantiated within the IETF and > less on the fact that there are some people who are just > plain difficult. > > That's a windy way of saying that difficult people aren't a > problem if we've got mechanisms to get our work done anyway. > > Melinda > > From problem-statement-bounces@alvestrand.no Mon Jun 23 10:38:09 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22962 for ; Mon, 23 Jun 2003 10:38:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AB73D62251; Mon, 23 Jun 2003 16:37:38 +0200 (CEST) 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 EDCB86223F for ; Mon, 23 Jun 2003 16:37:36 +0200 (CEST) Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 23 Jun 2003 07:40:41 -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 h5NEbTGe007547; Mon, 23 Jun 2003 07:37:34 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIR90261; Mon, 23 Jun 2003 07:37:28 -0700 (PDT) Message-Id: <200306231437.AIR90261@mira-sjc5-c.cisco.com> To: James Seng From: Melinda Shore In-Reply-To: Message from jseng@pobox.org.sg of "Mon, 23 Jun 2003 21:44:09 +0800." <3EF70429.7000507@pobox.org.sg> Date: Mon, 23 Jun 2003 10:37:28 -0400 Cc: problem-statement@alvestrand.no Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > So, why are we avoiding stating P1 and instead trying to frame it at > one/two degree removed problem of P4 to P7? Why? To be clear, we're not avoiding it. We're talking about it. I'm just really not that sure that it's useful to identify "obstructive individuals" as a problem - to me that feels a little like identifying the considerable distance from Ithaca to Vienna as a problem. Human behavior is pretty much of a given, I think, and it's how well we cope with it that is or is not a problem. It's really not a question of being candid, but of keeping the document focused and producing something that we can act upon. I'm going to create a ticket in the RT database derived from your initial post, but while I agree there's a big problem here I still don't agree with your exact formulation of it. Melinda From problem-statement-bounces@alvestrand.no Mon Jun 23 11:48:08 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25659 for ; Mon, 23 Jun 2003 11:48:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 03E3D625AC; Mon, 23 Jun 2003 17:43:40 +0200 (CEST) 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 2783162595 for ; Mon, 23 Jun 2003 17:43:37 +0200 (CEST) Received: (qmail 38294 invoked from network); 23 Jun 2003 15:50:46 -0000 Received: from unknown (HELO pobox.org.sg) (207.253.236.138) by sentosa.post1.com with SMTP; 23 Jun 2003 15:50:46 -0000 Message-ID: <3EF7202F.6090005@pobox.org.sg> Date: Mon, 23 Jun 2003 23:43:43 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Melinda Shore References: <200306231437.AIR90261@mira-sjc5-c.cisco.com> In-Reply-To: <200306231437.AIR90261@mira-sjc5-c.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Melinda, What you been telling me so far is that you acknowledge the problem but disagreed with the phrasing of my wordings. While it is easy to say "I dont like the wordings", you can be more constructive by putting your counterproposal. There are many ways a "trouble maker" could make life very difficult for the working group (1) They could re-open issues again and again (2) They could make statments to discredit their opponent in public (and the smart one can do it without been libel) (3) When they fail, they nitpick on the wordings ("the wordings is confusing" or "I agree with the concept but I disagree with the wordings") (4) They could hijack the document author (5) they could threaten appeal on process ground (6) they could delay further by carried out their threats (7) they continue the disagreement in other mailing list & forums. And there are many many more ways Unfortunately, Working group, wg chairs & ADs have very few tools to stop these DoS. (so this is yet another problem). Now, we could try to anticipate what the "trouble maker" could do and set procedure & process to deal with the action but you can not capture all possible things they could have done. And I dont believe we should set dragonian policy to deal with a 80/20 problem...it is not worth it. Bottomline, there are trouble makers and they could do 101 things to make life difficult for you, all within whatever rules you can set. What we need is a specific process we can use when and *IF* we can identify them. All we have right now is to revoke posting rights for a period of time and that is not sufficient. ps: No, I dont think we can re-engineer human behavior. -James Seng Melinda Shore wrote: >>So, why are we avoiding stating P1 and instead trying to frame it at >>one/two degree removed problem of P4 to P7? Why? > > > To be clear, we're not avoiding it. We're talking about > it. I'm just really not that sure that it's useful to > identify "obstructive individuals" as a problem - to me that > feels a little like identifying the considerable distance > from Ithaca to Vienna as a problem. Human behavior is > pretty much of a given, I think, and it's how well we > cope with it that is or is not a problem. It's really not a > question of being candid, but of keeping the document > focused and producing something that we can act upon. > > I'm going to create a ticket in the RT database derived from > your initial post, but while I agree there's a big problem > here I still don't agree with your exact formulation of it. > > Melinda > > From problem-statement-bounces@alvestrand.no Mon Jun 23 11:49:21 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25726 for ; Mon, 23 Jun 2003 11:49:21 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 16516625B2; Mon, 23 Jun 2003 17:48:51 +0200 (CEST) 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 0FD2C62595; Mon, 23 Jun 2003 17:48:48 +0200 (CEST) Message-ID: <013701c3399e$2f93d7a0$636015ac@dclkempt40> From: "James Kempf" To: "Harald Tveit Alvestrand" , "avri" , References: <9D89023C-A505-11D7-8159-000393CC2112@apocalypse.org> <192184967.1056358138@localhost> Date: Mon, 23 Jun 2003 08:43:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Harald, > > record-keeping in a form other than the list archive and the end product of > the WG might be a good idea; I've occasionally seen meeting minutes used > this way, but it's more difficult for decisions reached on the mailing list. > > I've started requesting draft editors in WGs where I'm chair to keep an issues list that contains what the current issues with drafts are, proposed solutions, and why the proposed solution was selected. This is a very useful tool in moving work forward and preventing the revisiting of issues. In some cases, people raise issues again not because they want to disrupt work but because either they were not involved in the initial discussion and don't have the context or they have forgottent the original discussion. The issues lists are not meant to be a permanent archive of the WG's work, like mailing list archives and RFCs, however. jak From problem-statement-bounces@alvestrand.no Mon Jun 23 12:02:22 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26350 for ; Mon, 23 Jun 2003 12:02:21 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CCDC1625AF; Mon, 23 Jun 2003 18:01:51 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 51FCD62595 for ; Mon, 23 Jun 2003 18:01:49 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h5NG1VN23411; Mon, 23 Jun 2003 12:01:34 -0400 (EDT) Date: Mon, 23 Jun 2003 12:01:30 -0400 From: Keith Moore To: James Seng Message-Id: <20030623120130.37e22061.moore@cs.utk.edu> In-Reply-To: <3EF7202F.6090005@pobox.org.sg> References: <200306231437.AIR90261@mira-sjc5-c.cisco.com> <3EF7202F.6090005@pobox.org.sg> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: mshore@cisco.com Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > Bottomline, there are trouble makers and they could do 101 things to > make life difficult for you, all within whatever rules you can set. > What we need is a specific process we can use when and *IF* we can > identify them. All we have right now is to revoke posting rights for a > period of time and that is not sufficient. this is a really disturbing suggestion. it's one thing if a "troublemaker" is being personally abusive to other participants or insists on repeatedly bringing up topics that aren't within the scope of the group. in those cases I can imagine that it is sometimes appropriate to revoke posting rights for that individual. but when the individual is citing technical objections to a WG proposal this is not even something that should be considered. From problem-statement-bounces@alvestrand.no Mon Jun 23 12:48:34 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28314 for ; Mon, 23 Jun 2003 12:48:33 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 99E98625B3; Mon, 23 Jun 2003 18:48:03 +0200 (CEST) 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 CFDFA62595 for ; Mon, 23 Jun 2003 18:48:00 +0200 (CEST) Received: (qmail 38966 invoked from network); 23 Jun 2003 16:55:09 -0000 Received: from unknown (HELO pobox.org.sg) (207.253.236.138) by sentosa.post1.com with SMTP; 23 Jun 2003 16:55:09 -0000 Message-ID: <3EF72F46.6090803@pobox.org.sg> Date: Tue, 24 Jun 2003 00:48:06 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Keith Moore References: <200306231437.AIR90261@mira-sjc5-c.cisco.com> <3EF7202F.6090005@pobox.org.sg> <20030623120130.37e22061.moore@cs.utk.edu> In-Reply-To: <20030623120130.37e22061.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mshore@cisco.com Cc: problem-statement@alvestrand.no Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 agree the line are hard to draw. Forget about my suggestion. Honestly, I dont even know what can we do reasonably without overdoing or risk of abuse. (One of the reasons to touch the "solution" of the problem :-P) Regardless, I certainly feel the problem should be captured, in whatever appropriate form. I am waiting for a counterproposal. -James Seng Keith Moore wrote: >>Bottomline, there are trouble makers and they could do 101 things to >>make life difficult for you, all within whatever rules you can set. >>What we need is a specific process we can use when and *IF* we can >>identify them. All we have right now is to revoke posting rights for a >>period of time and that is not sufficient. > > > this is a really disturbing suggestion. it's one thing if a > "troublemaker" is being personally abusive to other participants or > insists on repeatedly bringing up topics that aren't within the scope of > the group. in those cases I can imagine that it is sometimes > appropriate to revoke posting rights for that individual. but when the > individual is citing technical objections to a WG proposal this is not > even something that should be considered. > > From problem-statement-bounces@alvestrand.no Mon Jun 23 12:50:05 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28405 for ; Mon, 23 Jun 2003 12:50:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3FEC9625CA; Mon, 23 Jun 2003 18:49:36 +0200 (CEST) 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 89F6862595 for ; Mon, 23 Jun 2003 18:49:34 +0200 (CEST) Received: from cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 23 Jun 2003 09:51:21 -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 h5NGnVqd026999; Mon, 23 Jun 2003 09:49:32 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIS04047; Mon, 23 Jun 2003 09:49:31 -0700 (PDT) Message-Id: <200306231649.AIS04047@mira-sjc5-c.cisco.com> To: James Seng From: Melinda Shore In-Reply-To: Message from jseng@pobox.org.sg of "Mon, 23 Jun 2003 23:43:43 +0800." <3EF7202F.6090005@pobox.org.sg> Date: Mon, 23 Jun 2003 12:49:30 -0400 Cc: problem-statement@alvestrand.no Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > What you been telling me so far is that you acknowledge the problem but > disagreed with the phrasing of my wordings. While it is easy to say "I > dont like the wordings", you can be more constructive by putting your > counterproposal. That's fair enough, although I'm trying to keep a light hand here. My view of how the problem should be oriented is this: Existing IETF processes do not provide adequate protection against "denial of service" attacks by disgruntled participants. That said, in thinking about what I've seen happen it's almost always been the fault of the WG chair when an individual has become functionally disruptive, so I'm not sure that this is a process problem as much as an implementation problem. Many of the problems you list could be resolved without process changes by the chairs being more decisive. The other thing that concerns me is that I think that the question of whether someone holding firm is being disruptive or is a lone voice of sanity is highly subjective. I've seen people who lost an argument be disruptive out of resentment or personal interest and I've seen people who lost an argument be disruptive because they're right. Melinda From problem-statement-bounces@alvestrand.no Mon Jun 23 12:57:36 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28722 for ; Mon, 23 Jun 2003 12:57:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DFA6A625CB; Mon, 23 Jun 2003 18:57:06 +0200 (CEST) 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 442F162595 for ; Mon, 23 Jun 2003 18:57:04 +0200 (CEST) Received: from employees.org (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 23 Jun 2003 09:58:52 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5NGv1qd003604; Mon, 23 Jun 2003 09:57:01 -0700 (PDT) Received: from employees.org (sjc-vpn4-484.cisco.com [10.21.81.228]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHJ71385; Mon, 23 Jun 2003 09:51:21 -0700 (PDT) Message-ID: <3EF73156.7030409@employees.org> Date: Mon, 23 Jun 2003 12:56:54 -0400 From: Scott W Brim User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Melinda Shore References: <200306231649.AIS04047@mira-sjc5-c.cisco.com> In-Reply-To: <200306231649.AIS04047@mira-sjc5-c.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: James Seng Cc: problem-statement@alvestrand.no Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Melinda Shore wrote: > My view of how the problem should be oriented is this: > Existing IETF processes do not provide adequate protection > against "denial of service" attacks by disgruntled > participants. Disgruntled, or intentionally disruptive. From problem-statement-bounces@alvestrand.no Mon Jun 23 13:20:12 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29692 for ; Mon, 23 Jun 2003 13:20:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7B78962595; Mon, 23 Jun 2003 19:19:42 +0200 (CEST) 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 28BE8622B1 for ; Mon, 23 Jun 2003 19:19:40 +0200 (CEST) Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 23 Jun 2003 10:18:39 -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 h5NHJbqd025375; Mon, 23 Jun 2003 10:19:38 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIS08794; Mon, 23 Jun 2003 10:19:35 -0700 (PDT) Message-Id: <200306231719.AIS08794@mira-sjc5-c.cisco.com> To: Scott W Brim From: Melinda Shore In-Reply-To: Your message of "Mon, 23 Jun 2003 12:56:54 EDT." <3EF73156.7030409@employees.org> Date: Mon, 23 Jun 2003 13:19:34 -0400 Cc: problem-statement@alvestrand.no Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > Disgruntled, or intentionally disruptive. Yes, the latter is an improvement. Melinda From problem-statement-bounces@alvestrand.no Mon Jun 23 13:32:04 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00114 for ; Mon, 23 Jun 2003 13:32:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 19773625CC; Mon, 23 Jun 2003 19:31:33 +0200 (CEST) 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 F076E622B1 for ; Mon, 23 Jun 2003 19:31:30 +0200 (CEST) Received: (qmail 39405 invoked from network); 23 Jun 2003 17:38:40 -0000 Received: from unknown (HELO pobox.org.sg) (207.253.236.138) by sentosa.post1.com with SMTP; 23 Jun 2003 17:38:40 -0000 Message-ID: <3EF73979.6060701@pobox.org.sg> Date: Tue, 24 Jun 2003 01:31:37 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Melinda Shore References: <200306231649.AIS04047@mira-sjc5-c.cisco.com> In-Reply-To: <200306231649.AIS04047@mira-sjc5-c.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > My view of how the problem should be oriented is this: > Existing IETF processes do not provide adequate protection > against "denial of service" attacks by disgruntled > participants. Thank you. It is a reasonable start. > That said, in thinking about what I've seen happen it's > almost always been the fault of the WG chair when an > individual has become functionally disruptive, so I'm not > sure that this is a process problem as much as an > implementation problem. Many of the problems you list could > be resolved without process changes by the chairs being more > decisive. It is not always possible for a wg chair to function without offending somebody. We are not here to earn brownies points. It is not always the fault of the wg chair specifically. Sometimes it is personal, sometimes it is individual behavior, and sometimes it is a wg management problem. I hate to jump to conclusion and write off it off as "it is the wg chair's fault". It is also not always possible for the wg chair to be decisive. Sometimes, these individuals may have a few other support and making sufficient noise that it is difficult to move forward. (aka "I have documented 7 complains against the X draft"). Or worst, the murky case where the individual makes an excellent technical argument but did not get the support. Lastly, wg chairs dont get shoot down for waiting for the dust to settle but you may get an appeal for declaring consensus. Doing your risk analysis, it is easier to say "Lets wait". > The other thing that concerns me is that I think that the > question of whether someone holding firm is being disruptive > or is a lone voice of sanity is highly subjective. I've > seen people who lost an argument be disruptive out of > resentment or personal interest and I've seen people who > lost an argument be disruptive because they're right. Being argumentive is not neccessary disruptive. Neither is been stubborn. Everyone are entitled to their opinion. The wg chairs could probably note the differences in opinion and work it out in the judgement. But there are some individuals who have intentionly disrupt the working group process and their actions are beyond been just argumentive. -James Seng From problem-statement-bounces@alvestrand.no Mon Jun 23 14:17:25 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02239 for ; Mon, 23 Jun 2003 14:17:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BF9436257C; Mon, 23 Jun 2003 20:13:00 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id AECBC622B1 for ; Mon, 23 Jun 2003 20:12:58 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h5NICnN23659; Mon, 23 Jun 2003 14:12:49 -0400 (EDT) Date: Mon, 23 Jun 2003 14:12:48 -0400 From: Keith Moore To: Melinda Shore Message-Id: <20030623141248.2d8207ae.moore@cs.utk.edu> In-Reply-To: <200306231649.AIS04047@mira-sjc5-c.cisco.com> References: <3EF7202F.6090005@pobox.org.sg> <200306231649.AIS04047@mira-sjc5-c.cisco.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: jseng@pobox.org.sg Cc: moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > My view of how the problem should be oriented is this: > Existing IETF processes do not provide adequate protection > against "denial of service" attacks by disgruntled > participants. How about this instead: Many working groups have had trouble making forward progerss in the presence of strident objections to the majority opinion from individual or small numbers of participants. The majority may believe these are "denial of service attacks" that are intended to prevent the group from producing useful output; the minority individuals may see them as "clue donation" to groups suffering from an overly narrow focus or mob mentality, or as "filibusters" - awkward but effective political tools that are sometimes necessary to use to get a group to produce reasonable compromises. Regardless of motivation or point-of-view, the inability of many groups to move past these issues appears to cause significant delays in working group output, and may harm the quality of the output. From problem-statement-bounces@alvestrand.no Tue Jun 24 01:27:49 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21865 for ; Tue, 24 Jun 2003 01:27:48 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E966E6259F; Tue, 24 Jun 2003 07:03:23 +0200 (CEST) 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 69DE36259F for ; Tue, 24 Jun 2003 07:03:21 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h5O56dF14557 for ; Mon, 23 Jun 2003 22:06:39 -0700 Date: Mon, 23 Jun 2003 22:03:17 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/10) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <352069415.20030623220317@brandenburg.com> To: problem-statement@alvestrand.no In-Reply-To: <20030623141248.2d8207ae.moore@cs.utk.edu> References: <3EF7202F.6090005@pobox.org.sg> <200306231649.AIS04047@mira-sjc5-c.cisco.com> <20030623141248.2d8207ae.moore@cs.utk.edu> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Folks, KM> Many working groups have had trouble making forward progerss in the KM> presence of strident objections ...The majority may believe these are KM> ... the minority individuals may see them as ... The thread's exploration of this difficult a topic has been heartening. There *are* obstructionist folk that damage working group activities, sometimes. We all know this and suffer from it. But we will be vastly ahead of the game if we can find a way to deal with it that is more basic -- that is, more generally useful. I think the sequence leading to Keith's proposed text goes in the right direction, namely focusing on the need to make forward progress and (forcefully) manage the working group to achieve it. Sometimes, a working group is stalled by obstructionist folk. Sometimes, a working group is stalled by poor focus, or the like, including poor understanding of goals or just plain bad discussion management. So, I wonder whether there is an essential difference between the two? My guess is that both are solved through the same techniques. Problematic working groups often suffer from a poor understanding of their goal -- what is to be solved? -- or poor discipline at discussing them. This usually leads to endless cycling over the same topics, with no convergence. Frankly I think this is not much different from the individual who constantly harangues the other participants. Well-managed groups have real discussion structure and real enforcement of it, including bringing topics to a close and not revisiting them without a *very* good reason. Clearly the key to this is the working group chair, but the piece that I think is easy to miss is that working group's must actively support such active management. This means that the working group must show rough consensus to empower the chair to enforce the structure. Separately, we need to make sure that there are enough rules and support for enforcement for those special folk who really are disruptive, through personal attack and other offensive behavior. However I believe we are in pretty good shape, in that regard, except possibly for making sure that working group chair use the power they have. Suspending posting priviledges is getting solid, defensible rules and process. And wg chairs have always had the authority to refuse the floor to folks at meetings. (How many wg chairs know this, is another matter.) Rather, perhaps we can focus on the unfocused and undisciplined working groups, and find that we have dealt with overly "tenacious" contributors along the way? With that in mind, let me suggest revision to Keith's text: Working groups can have trouble making forward progress, due to a lack of firm discussion management. This can be due to poor chair management, general lack of working group focus, or problematic participants. Section 3.3, "Session management", of RFC 2418, "IETF Working Group Guidelines and Procedures" provides a useful framework for managing this issue. Regardless of motivation or point-of-view, the failure of wg chairs and participants to work actively to to maintain productive focus and to move past specific topics appears to cause significant delays in working group output, and to harm the quality of the output. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue Jun 24 02:09:27 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02128 for ; Tue, 24 Jun 2003 02:09:27 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 38EFE625D2; Tue, 24 Jun 2003 08:08:43 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4FDF2622B1 for ; Tue, 24 Jun 2003 05:41:33 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h5O3fWch004779 for ; Mon, 23 Jun 2003 20:41:32 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Jun 2003 20:41:32 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D2267@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'problem-statement@alvestrand.no'" Date: Mon, 23 Jun 2003 20:41:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Mailman-Approved-At: Tue, 24 Jun 2003 08:08:41 +0200 Subject: Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Randy Writes: not completely true. increasingly, directorates and less formal constructs are being used as document and srchitecture review teams. this is a massive help, at least for me. The reason that so many people have no confidence in the IETF is exactly this type of closed and unaccountable process by the inner circle. That type of behavior is not open and it is not inclusive. It is an old boys network (and yes they almost always are boys). You can call the IETF what you will, but you cannot defend that as an open process. Why then is it to be considered superior to closed decisions taken behind corporate doors? How are you going to defend your closed decisions in persuit of your private interests against their closed decisions? Phill From problem-statement-bounces@alvestrand.no Tue Jun 24 02:09:15 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01927 for ; Tue, 24 Jun 2003 02:09:15 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B47E9625CD; Tue, 24 Jun 2003 08:08:42 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 731B06257F for ; Tue, 24 Jun 2003 05:30:51 +0200 (CEST) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h5O3Un2Q021103 for ; Mon, 23 Jun 2003 20:30:49 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Jun 2003 20:30:49 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D2266@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'problem-statement@alvestrand.no'" Date: Mon, 23 Jun 2003 20:30:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Mailman-Approved-At: Tue, 24 Jun 2003 08:08:41 +0200 Subject: Trusting the IESG to manage the reform process (was: Re: Doing t he Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 John Klensen writes: but that no one on the IESG has been willing to speak up in public and say "I see a problem here, but it is all those other folks, not me", then there is something hopelessly broken about the nomcom model, probably to the point that we need to discard it and start over. I have been saying for some time that the NOMCON model is broken. Of course I am not on the IESG and the procedures of the NOMCON will make sure that people like myself are never selected, which is of course the point. I have been reading "The Tipping Point", ok so pop-psychology but one point that is made rings very true, the rule of 150. Basically there is a limit to the size organizations can grow without formal structure which seems to be stuck at about 150. That is why every army from the Roman legions onwards has been organized into companies of about 100-200 men. That would explain the problem that the IETF has been facing trying to keep the creative anarchy model going. It simply does not scale beyond a certain size. The parts of the IETF that have been working have been working because they have worked in isolation. The security area for example consists of roughly 100 active participants. It would also explain the generation gap problem. The simple fact is that no matter what anyone under 40 does in the IETF they are never going to get accepted into the inner circle. I want a system with accountability. NOMCON is the type of scheme a bunch of academics cook up to make sure they keep power in their own hands. Democracy is working just fine in OASIS. We elect the WG chairs, it is amazing the difference that simple change alone makes. The IETF does not even believe in announcing upcomming vacancies. The DNSEXT chair just changed with no prior advertisement of a vacancy for the position - unless of course you are a member of the inner circle. IETF processes are not open and not inclusive, the guff about them being so is simply propaganda to fool the proletariat. The generation gap is significant for many reasons, not least the issue of what happens when the establishement chooses to retire. There are some courtiers waiting in the wings for their moment of glory but I doubt that they will carry much influence outside the IETF. The engineering reason the generation gap is significant is that there is a dramatic difference of perspective between people who grew up with the machine and people who watched it being invented. To me the computer is simply another utility, no more deserving of wonder than electricity, gas or running water. It is not enough that something function, it has to function seamlessly. Instead the establishment tolerates Rube Goldberg contraptions that run with the grace and elegance of a pre WWI vintage motor car. The IETF is still attracting younger engineers, but they are by and large the sort who are interested in maintaining vintage communication protocols rather than designing better ones. Phill From problem-statement-bounces@alvestrand.no Tue Jun 24 09:00:47 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14429 for ; Tue, 24 Jun 2003 09:00:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 14460622B1; Tue, 24 Jun 2003 15:00:16 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8FE6A6225B for ; Tue, 24 Jun 2003 15:00:14 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19UnP5-0001n0-00; Tue, 24 Jun 2003 06:00:07 -0700 Date: Tue, 24 Jun 2003 08:56:53 -0400 From: Keith Moore To: Dave Crocker Message-Id: <20030624085653.427a8c7a.moore@cs.utk.edu> In-Reply-To: <352069415.20030623220317@brandenburg.com> References: <3EF7202F.6090005@pobox.org.sg> <200306231649.AIS04047@mira-sjc5-c.cisco.com> <20030623141248.2d8207ae.moore@cs.utk.edu> <352069415.20030623220317@brandenburg.com> X-Mailer: Sylpheed version 0.9.1 (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 Cc: moore@cs.utk.edu Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > With that in mind, let me suggest revision to Keith's text: > > Working groups can have trouble making forward progress, due to a lack > of firm discussion management. This can be due to poor chair management, > general lack of working group focus, or problematic participants. > Section 3.3, "Session management", of RFC 2418, "IETF Working Group > Guidelines and Procedures" provides a useful framework for managing this > issue. Regardless of motivation or point-of-view, the failure of wg > chairs and participants to work actively to to maintain productive focus > and to move past specific topics appears to cause significant delays in > working group output, and to harm the quality of the output. > I almost agree, though I think it presumes the solution a bit too much - and in a way that overly narrows the solution space. And I also think it's a bit of topic drift. I do think these problems can be solved (and sometimes have been solved) by firm discussion management. But I also think we would do well to establish procedures that the management can use to keep the group moving forward, while still giving ample room for dissenting voices to be heard, their views considered, and with the possibility of appeal if the dissenter believes the group is making a serious technical error. From problem-statement-bounces@alvestrand.no Tue Jun 24 10:00:26 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16406 for ; Tue, 24 Jun 2003 10:00:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E21B9625AA; Tue, 24 Jun 2003 15:59:54 +0200 (CEST) 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 D8422625A7 for ; Tue, 24 Jun 2003 15:59:51 +0200 (CEST) Received: (qmail 52667 invoked from network); 24 Jun 2003 14:06:54 -0000 Received: from unknown (HELO pobox.org.sg) (207.253.237.204) by sentosa.post1.com with SMTP; 24 Jun 2003 14:06:54 -0000 Message-ID: <3EF8595B.6060309@pobox.org.sg> Date: Tue, 24 Jun 2003 21:59:55 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Dave Crocker References: <3EF7202F.6090005@pobox.org.sg> <200306231649.AIS04047@mira-sjc5-c.cisco.com> <20030623141248.2d8207ae.moore@cs.utk.edu> <352069415.20030623220317@brandenburg.com> In-Reply-To: <352069415.20030623220317@brandenburg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Dave, While I do not disagree a lot of what you said, I prefer Keith original statement mainly because it does not assume any solution. -James Seng Dave Crocker wrote: > Working groups can have trouble making forward progress, due to a lack > of firm discussion management. This can be due to poor chair management, > general lack of working group focus, or problematic participants. > Section 3.3, "Session management", of RFC 2418, "IETF Working Group > Guidelines and Procedures" provides a useful framework for managing this > issue. Regardless of motivation or point-of-view, the failure of wg > chairs and participants to work actively to to maintain productive focus > and to move past specific topics appears to cause significant delays in > working group output, and to harm the quality of the output. > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > > > From problem-statement-bounces@alvestrand.no Tue Jun 24 10:54:34 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19140 for ; Tue, 24 Jun 2003 10:54:33 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B55126256B; Tue, 24 Jun 2003 16:54:03 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id D23E66225B for ; Tue, 24 Jun 2003 16:54:02 +0200 (CEST) Received: from bs.jck.com ([209.187.148.211] helo=localhost) by bs.jck.com with esmtp (Exim 4.10) id 19UpBK-000JdJ-00 for problem-statement@alvestrand.no; Tue, 24 Jun 2003 09:54:02 -0500 Date: Tue, 24 Jun 2003 10:54:00 -0400 From: John C Klensin To: problem-statement@alvestrand.no Message-ID: <8660173.1056452040@dhcp-c2-196.ICANN.globale.net> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ISSUE: Meeting scheduling X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Some years ago, after a heated set of discussions within the community, the IESG and the Secretariat committed to putting meeting scheduling on a minimum of 18 months, and preferably 24 months, out in the future basis. Lead times like that permit other organizations to work around our schedules, and a number of other useful varieties of advanced planning. With very short lead times, or schedules that try to reserve a choice of several weeks, we end up with important conflicts, people missing either our meetings or other important ones, etc. But we haven't been doing very well. Spring 2004 (8 months out) has dates (good) but no location. Summer 2004 (a year out) has no dates (two separate target weeks), and dates after that are more or less set, but without locations, but we've had some experience with such dates turning out to be tentative when the Secretariat finds sponsors only for another time. And, of course, the last few meetings, including Vienna, were firmed up only with very short (less than six months) lead time. This impresses me as unhealthy and unprofessional. john From problem-statement-bounces@alvestrand.no Tue Jun 24 11:16:09 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19897 for ; Tue, 24 Jun 2003 11:16:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B494A62571; Tue, 24 Jun 2003 17:15:38 +0200 (CEST) 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 71BCF6225B for ; Tue, 24 Jun 2003 17:15:36 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h5OFIjF07281; Tue, 24 Jun 2003 08:18:45 -0700 Date: Tue, 24 Jun 2003 08:15:21 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/10) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <2038792690.20030624081521@brandenburg.com> To: John C Klensin In-Reply-To: <8660173.1056452040@dhcp-c2-196.ICANN.globale.net> References: <8660173.1056452040@dhcp-c2-196.ICANN.globale.net> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: ISSUE: Meeting scheduling X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 John, JCK> Lead times like that JCK> permit other organizations to work around our schedules, and a JCK> number of other useful varieties of advanced planning. ... JCK> we end up with important conflicts, JCK> people missing either our meetings or other important ones, ... JCK> This impresses me as unhealthy and unprofessional. The current approach to scheduling and meeting fee only suit participants who come for the whole week, who have major travel funding -- with little concern for air fair or hotel rates -- and who view the IETF meeting week as the dominant aspect of their schedule. Hence, the current approach is pretty exclusionary. Notably, the current diversity of IETF work means that we need to make it easier for folks who are coming for a particular working group, or two, rather than presuming that they are here for the week. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue Jun 24 11:20:20 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20092 for ; Tue, 24 Jun 2003 11:20:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ACEFD625A7; Tue, 24 Jun 2003 17:19:49 +0200 (CEST) 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 498B96225B for ; Tue, 24 Jun 2003 17:19:47 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h5OFMxF07522; Tue, 24 Jun 2003 08:22:59 -0700 Date: Tue, 24 Jun 2003 08:19:35 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/10) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <11839046856.20030624081935@brandenburg.com> To: James Seng In-Reply-To: <3EF8595B.6060309@pobox.org.sg> References: <3EF7202F.6090005@pobox.org.sg> <200306231649.AIS04047@mira-sjc5-c.cisco.com> <20030623141248.2d8207ae.moore@cs.utk.edu> <352069415.20030623220317@brandenburg.com> <3EF8595B.6060309@pobox.org.sg> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 James, JS> While I do not disagree a lot of what you said, I prefer Keith original JS> statement mainly because it does not assume any solution. Focusing on disruptive individuals assumes the problem. My point is that it is constructive to treat disruptive individuals as a symptom, rather than as a core problem. They are an especially painful symptom, but their effect is altered considerably by working group participant and chair resolve to make forward progress. Focus on the disruptive individuals and we will debate personal issues. We're not very good at that. Focus on the positive need to make forward progress, and we will solve multiple problems. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue Jun 24 11:20:56 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20126 for ; Tue, 24 Jun 2003 11:20:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3C095625C5; Tue, 24 Jun 2003 17:20:27 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3B61D6225B for ; Tue, 24 Jun 2003 17:20:20 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h5OFKIch019560 for ; Tue, 24 Jun 2003 08:20:18 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 08:20:18 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D2269@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'problem-statement@alvestrand.no'" Date: Tue, 24 Jun 2003 08:20:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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.e. there should be no place for the term "trouble maker" in IETF documents. " I agree, I think that the problem here is that it becomes very easy for a partisan chair to further reinforce his power by invoking this phrase. DNSSEC has just produced a spec that cannot be deployed. The WG was in favor of fixing the spec but the chair as we all know had other ideas. Pointing out that the spec was broken resulted in numerous atempts to intimidate me by 'reporting me to my management' as a 'trouble maker'. Like get a clue, who do you think had asked me to push for the protocol changes in the first place? >From my point of view the "trouble maker" was a WG chair acting in a clearly partisan manner. The first time I spoke in a DNSEXT WG the chair in question gave a loud hiss as I gave my name and company. Despite being prompted to do so he has refused to appologise. The is hardly the behavior I expect from an organization claiming to be open and inclusive. It is very easy to get a WG to adopt the consensus you want if you are prepared to drive away supporters of contrary views. This is what happened in ASRG. At the start there were a lot of people interested in authentication based approaches. Then I see that any proposal they make is attacked on non-technical grounds, the proposers insulted, called 'a snake' etc. Pretty soon I am the only person left proposing authentication based approaches so having marginalized my position the faction can now dismiss me as a 'trouble maker' for proposing ideas that are opposed to the consensus they have formed by driving away any supporters. I fail to see the point of the IESG. It does not appear to be providing much in the way of direction or architectural guidance. It is not even providing the most basic guidance one would expect such as "this spec must work for all the Internet". The Internet has major structural security problems that are likely to be tested in the near future. We already have spam senders hijaking unused IP address blocks with BGP spoofing, expect them to shortly start hijacking used address blocks. The proposal on the table for BGP security meanwhile is to replace all routers with new ones that support BGP over IPSEC, a very likely occurrence. At this point there is no deployable security solution for BGP OR DNS. I see little likelihood that the IETF will play a positive role in solving either problem. Phill From problem-statement-bounces@alvestrand.no Tue Jun 24 11:22:37 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20226 for ; Tue, 24 Jun 2003 11:22:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C5966625CF; Tue, 24 Jun 2003 17:22:07 +0200 (CEST) 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 34F7F6225B for ; Tue, 24 Jun 2003 17:22:06 +0200 (CEST) Received: from employees.org (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 24 Jun 2003 08:23:54 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5OFM34v013737 for ; Tue, 24 Jun 2003 08:22:03 -0700 (PDT) Received: from cisco.com (sjc-vpn4-484.cisco.com [10.21.81.228]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AHK60451; Tue, 24 Jun 2003 08:16:09 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Tue, 24 Jun 2003 11:21:54 -0400 Date: Tue, 24 Jun 2003 11:21:53 -0400 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030624152153.GA1748@sbrim-w2k01> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: <8660173.1056452040@dhcp-c2-196.ICANN.globale.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8660173.1056452040@dhcp-c2-196.ICANN.globale.net> User-Agent: Mutt/1.4i Subject: Re: ISSUE: Meeting scheduling X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Tue, Jun 24, 2003 10:54:00AM -0400, John C Klensin allegedly wrote: > This impresses me as unhealthy and unprofessional. Well, yeah, but that's an administrative Secretariat problem, not a problem in the way we create standards. I wouldn't give that to the same group that tries to figure out what authority WG chairs should have. From problem-statement-bounces@alvestrand.no Tue Jun 24 11:48:17 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20943 for ; Tue, 24 Jun 2003 11:48:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C9966625CE; Tue, 24 Jun 2003 17:47:46 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3ACF86225B for ; Tue, 24 Jun 2003 17:47:45 +0200 (CEST) Received: from bs.jck.com ([209.187.148.211] helo=localhost) by bs.jck.com with esmtp (Exim 4.10) id 19Uq1I-000Jt0-00; Tue, 24 Jun 2003 10:47:44 -0500 Date: Tue, 24 Jun 2003 11:47:42 -0400 From: John C Klensin To: Scott W Brim , "problem-statement@alvestrand.no" Message-ID: <11882338.1056455262@dhcp-c2-196.ICANN.globale.net> In-Reply-To: <20030624152153.GA1748@sbrim-w2k01> References: <8660173.1056452040@dhcp-c2-196.ICANN.globale.net> <20030624152153.GA1748@sbrim-w2k01> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: ISSUE: Meeting scheduling X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On Tuesday, 24 June, 2003 11:21 -0400 Scott W Brim wrote: > On Tue, Jun 24, 2003 10:54:00AM -0400, John C Klensin > allegedly wrote: >> This impresses me as unhealthy and unprofessional. > > Well, yeah, but that's an administrative Secretariat > problem, not a problem in the way we create standards. I > wouldn't give that to the same group that tries to figure > out what authority WG chairs should have. Scott, it does interfere with the way we create standards, because it gets in the way of effective attendance. And the IESG generally, and the IETF Chair in particular, have been given (or assumed) the authority and responsibility for managing the Secretariat. If that isn't feasible, or they are too overloaded to do that task well, it seems to me that the topic intrudes into this WG. john From problem-statement-bounces@alvestrand.no Tue Jun 24 12:12:08 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22023 for ; Tue, 24 Jun 2003 12:12:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7B318625D4; Tue, 24 Jun 2003 18:11:37 +0200 (CEST) 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 E1C01625D1 for ; Tue, 24 Jun 2003 18:11:33 +0200 (CEST) Received: (qmail 54628 invoked from network); 24 Jun 2003 16:18:38 -0000 Received: from unknown (HELO pobox.org.sg) (207.253.237.204) by sentosa.post1.com with SMTP; 24 Jun 2003 16:18:38 -0000 Message-ID: <3EF8783D.3010809@pobox.org.sg> Date: Wed, 25 Jun 2003 00:11:41 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D2269@mou1wnexm02.verisign.com> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D2269@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'problem-statement@alvestrand.no'" Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Philip, The fact you failed to convience others of your proposal is not a problem of IETF. Neither is the role of the chair or the IESG to assist you in that regard. If you did not get rough consensus, you lose. Deal with it. For your specific issues with DNSEXT, I am not sure how true "WG was in favour to fixing the spec" but you should deal with that in the DNSEXT or file an appeal to IESG if it is really true. Complaining here dont help you in anyway. For the wg chairs reaction to your company name, while I dont think it is appropriate, I dont see why it would prevent IETF to be open and inclusive. Everyone here represents himself/herself here and being political correct was, AFAIK, not one of IETF core principle. -James Seng Hallam-Baker, Phillip wrote: > "i.e. there should be no place for the term "trouble maker" in IETF > documents. " > > I agree, I think that the problem here is that it becomes very easy for a > partisan chair to further reinforce his power by invoking this phrase. > > DNSSEC has just produced a spec that cannot be deployed. The WG was in favor > of fixing the spec but the chair as we all know had other ideas. > > > Pointing out that the spec was broken resulted in numerous atempts to > intimidate me by 'reporting me to my management' as a 'trouble maker'. Like > get a clue, who do you think had asked me to push for the protocol changes > in the first place? > > >>From my point of view the "trouble maker" was a WG chair acting in a clearly > partisan manner. > > The first time I spoke in a DNSEXT WG the chair in question gave a loud hiss > as I gave my name and company. Despite being prompted to do so he has > refused to appologise. The is hardly the behavior I expect from an > organization claiming to be open and inclusive. > > > It is very easy to get a WG to adopt the consensus you want if you are > prepared to drive away supporters of contrary views. This is what happened > in ASRG. At the start there were a lot of people interested in > authentication based approaches. Then I see that any proposal they make is > attacked on non-technical grounds, the proposers insulted, called 'a snake' > etc. Pretty soon I am the only person left proposing authentication based > approaches so having marginalized my position the faction can now dismiss me > as a 'trouble maker' for proposing ideas that are opposed to the consensus > they have formed by driving away any supporters. > > > I fail to see the point of the IESG. It does not appear to be providing much > in the way of direction or architectural guidance. It is not even providing > the most basic guidance one would expect such as "this spec must work for > all the Internet". > > The Internet has major structural security problems that are likely to be > tested in the near future. We already have spam senders hijaking unused IP > address blocks with BGP spoofing, expect them to shortly start hijacking > used address blocks. The proposal on the table for BGP security meanwhile is > to replace all routers with new ones that support BGP over IPSEC, a very > likely occurrence. > > At this point there is no deployable security solution for BGP OR DNS. I see > little likelihood that the IETF will play a positive role in solving either > problem. > > > Phill > > > > From problem-statement-bounces@alvestrand.no Tue Jun 24 12:16:35 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22273 for ; Tue, 24 Jun 2003 12:16:34 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 40A9B625D7; Tue, 24 Jun 2003 18:16:05 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by eikenes.alvestrand.no (Postfix) with ESMTP id 415C0625D1 for ; Tue, 24 Jun 2003 18:16:04 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19UqSb-0001lb-00; Tue, 24 Jun 2003 09:15:58 -0700 Date: Tue, 24 Jun 2003 12:12:42 -0400 From: Keith Moore To: Dave Crocker Message-Id: <20030624121242.6752ecea.moore@cs.utk.edu> In-Reply-To: <2038792690.20030624081521@brandenburg.com> References: <8660173.1056452040@dhcp-c2-196.ICANN.globale.net> <2038792690.20030624081521@brandenburg.com> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: john-ietf@jck.com Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: ISSUE: Meeting scheduling X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > Notably, the current diversity of IETF work means that we need to make > it easier for folks who are coming for a particular working group, or > two, rather than presuming that they are here for the week. in other words, you want to favor the narrowly focused and narrow-minded. From problem-statement-bounces@alvestrand.no Tue Jun 24 12:24:06 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22538 for ; Tue, 24 Jun 2003 12:24:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B36BF625DE; Tue, 24 Jun 2003 18:23:35 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id DA1F9625DC for ; Tue, 24 Jun 2003 18:23:33 +0200 (CEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA16573; Tue, 24 Jun 2003 09:23:32 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5OGNVC23492; Tue, 24 Jun 2003 09:23:31 -0700 X-mProtect: <200306241623> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFKwyx9; Tue, 24 Jun 2003 09:23:29 PDT Message-ID: <3EF87B02.514D48BD@iprg.nokia.com> Date: Tue, 24 Jun 2003 09:23:30 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: problem-statement@alvestrand.no References: <8660173.1056452040@dhcp-c2-196.ICANN.globale.net> <20030624121242.6752ecea.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Two Stage Standardization Approach X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Hello folks, Spencer Dawkins and I have submitted an Internet Draft proposing that there be two stages in the IETF standardization process. Until it shows up in the usual Internet Draft directories, you can get a copy at the following URL: http://people.nokia.net/~charliep/txt/probstmt/twostage.txt It's a bit rough, but not bad for submissions after midnight. Regards, Charlie P. From problem-statement-bounces@alvestrand.no Tue Jun 24 12:25:38 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22588 for ; Tue, 24 Jun 2003 12:25:37 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 65CC5625EB; Tue, 24 Jun 2003 18:25:09 +0200 (CEST) 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 629A7625E6 for ; Tue, 24 Jun 2003 18:25:06 +0200 (CEST) Received: from employees.org (171.68.223.137) by sj-iport-1.cisco.com with ESMTP; 24 Jun 2003 09:26:53 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5OGP2Qx012736 for ; Tue, 24 Jun 2003 09:25:03 -0700 (PDT) Received: from cisco.com (sjc-vpn4-484.cisco.com [10.21.81.228]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AHK65653; Tue, 24 Jun 2003 09:19:01 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Tue, 24 Jun 2003 12:24:47 -0400 Date: Tue, 24 Jun 2003 12:24:47 -0400 From: Scott W Brim To: "'problem-statement@alvestrand.no'" Message-ID: <20030624162447.GD1748@sbrim-w2k01> Mail-Followup-To: Scott W Brim , "'problem-statement@alvestrand.no'" References: <2A1D4C86842EE14CA9BC80474919782E0D2269@mou1wnexm02.verisign.com> <3EF8783D.3010809@pobox.org.sg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EF8783D.3010809@pobox.org.sg> User-Agent: Mutt/1.4i Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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, Jun 25, 2003 12:11:41AM +0800, James Seng allegedly wrote: > For the wg chairs reaction to your company name, while I dont think it > is appropriate, I dont see why it would prevent IETF to be open and > inclusive. Everyone here represents himself/herself here and being > political correct was, AFAIK, not one of IETF core principle. If the chair hisses when someone stands up to speak that's more than just being "politically incorrect". However, that kind of lack of training in chairs is already covered. From problem-statement-bounces@alvestrand.no Tue Jun 24 12:34:27 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22889 for ; Tue, 24 Jun 2003 12:34:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 74D1C625BA; Tue, 24 Jun 2003 17:58:14 +0200 (CEST) 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 04915625D0 for ; Tue, 24 Jun 2003 17:58:11 +0200 (CEST) Received: (qmail 54519 invoked from network); 24 Jun 2003 16:05:15 -0000 Received: from unknown (HELO pobox.org.sg) (207.253.237.204) by sentosa.post1.com with SMTP; 24 Jun 2003 16:05:15 -0000 Message-ID: <3EF87519.80401@pobox.org.sg> Date: Tue, 24 Jun 2003 23:58:17 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Dave Crocker References: <3EF7202F.6090005@pobox.org.sg> <200306231649.AIS04047@mira-sjc5-c.cisco.com> <20030623141248.2d8207ae.moore@cs.utk.edu> <352069415.20030623220317@brandenburg.com> <3EF8595B.6060309@pobox.org.sg> <11839046856.20030624081935@brandenburg.com> In-Reply-To: <11839046856.20030624081935@brandenburg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Dave, As I said, i did not disagree with you. I just dont think we should have wordings in the problem-statement with assumed solution. What you describe below can go into the problem-process if there is agreement, if there is agreement that is the solution to this problem. -James Seng Dave Crocker wrote: > James, > > JS> While I do not disagree a lot of what you said, I prefer Keith original > JS> statement mainly because it does not assume any solution. > > Focusing on disruptive individuals assumes the problem. > > My point is that it is constructive to treat disruptive individuals as a > symptom, rather than as a core problem. > > They are an especially painful symptom, but their effect is altered > considerably by working group participant and chair resolve to make > forward progress. > > Focus on the disruptive individuals and we will debate personal issues. > We're not very good at that. > > Focus on the positive need to make forward progress, and we will solve > multiple problems. > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > > > From problem-statement-bounces@alvestrand.no Tue Jun 24 12:42:45 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23071 for ; Tue, 24 Jun 2003 12:42:44 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D782D625E4; Tue, 24 Jun 2003 18:42:14 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mx-out.daemonmail.net (mx-out.daemonmail.net [216.104.160.39]) by eikenes.alvestrand.no (Postfix) with ESMTP id A65AC625E1 for ; Tue, 24 Jun 2003 18:42:12 +0200 (CEST) Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.9.3p2/8.9.3) with SMTP id JAA27550 for ; Tue, 24 Jun 2003 09:42:11 -0700 (PDT) (envelope-from spencer@mcsr-labs.org) Received: from (216.62.6.129 [216.62.6.129]) by mail.varaha.com with SMTP id 9A70fED2 Tue, 24 Jun 2003 09:42:10 -0700 (PDT) Message-ID: <014601c33a6f$908fcd30$8100000a@DFNJGL21> From: "Spencer Dawkins" Cc: References: <8660173.1056452040@dhcp-c2-196.ICANN.globale.net> <2038792690.20030624081521@brandenburg.com> Date: Tue, 24 Jun 2003 11:42:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: ISSUE: Meeting scheduling X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 There's probably a micro aspect to this, as well as a macro aspect - http://www.ietf.org/meetings/wg_agenda_57.html has exactly eight WG/BoF agendas listed, including three MobileIP agendas and two general-area agendas. I really do understand our dependence on people who are willing to come for the week, not just for a morning, but how can anyone make an informed decision on what sessions they need to be at, to accommodate part-time attendance plans? Spencer ----- Original Message ----- From: "Dave Crocker" To: "John C Klensin" Cc: Sent: Tuesday, June 24, 2003 10:15 AM Subject: Re: ISSUE: Meeting scheduling > John, > > JCK> Lead times like that > JCK> permit other organizations to work around our schedules, and a > JCK> number of other useful varieties of advanced planning. ... > JCK> we end up with important conflicts, > JCK> people missing either our meetings or other important ones, > ... > JCK> This impresses me as unhealthy and unprofessional. > > The current approach to scheduling and meeting fee only suit > participants who come for the whole week, who have major travel funding > -- with little concern for air fair or hotel rates -- and who view the > IETF meeting week as the dominant aspect of their schedule. > > Hence, the current approach is pretty exclusionary. > > Notably, the current diversity of IETF work means that we need to make > it easier for folks who are coming for a particular working group, or > two, rather than presuming that they are here for the week. > > d/ From problem-statement-bounces@alvestrand.no Tue Jun 24 12:49:28 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23311 for ; Tue, 24 Jun 2003 12:49:27 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5A9DE625E6; Tue, 24 Jun 2003 18:48:58 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 23DB4625E1 for ; Tue, 24 Jun 2003 18:48:56 +0200 (CEST) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h5OGms2Q003658; Tue, 24 Jun 2003 09:48:54 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 09:48:54 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D226B@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'James Seng'" , "Hallam-Baker, Phillip" Date: Tue, 24 Jun 2003 09:48:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: "'problem-statement@alvestrand.no'" Subject: RE: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > The fact you failed to convience others of your proposal is not a > problem of IETF. Neither is the role of the chair or the IESG > to assist > you in that regard. > > If you did not get rough consensus, you lose. Deal with it. But there was consensus in favor of OPT IN, the chair decided to abuse his position and ignore it subsituting his own opinion. Read the WG mailing lists. There was a last call, 12 people were in favor, 2 opposed outright, 7 were not in favor but prepared to accept the proposal. Actually there were in total four last calls. Basically the Chair's strategy was to keep asking the question until he could pretend the result was in his favor. So no, it was not about 'rough consensus' it was about 'Chair's perogative'. > For your specific issues with DNSEXT, I am not sure how true > "WG was in > favour to fixing the spec" but you should deal with that in > the DNSEXT > or file an appeal to IESG if it is really true. Complaining here dont > help you in anyway. I have no confidence in the IESG, why would I waste time on an appeal there? All that would do would be to continue the uncertainty for another year or so. Once I realized that it was about chair's perogative and not consensus my strategy was simply to force the group to come to a final decision. As long as the filibustering and procedural circumlocutions continued the choice was potentially between the undeployable status quo, the OPTIN fix and potentially a new fix that might be proposed, result stalemate that suited the 'kill DNSSEC in large zones' faction. After the chair exercised perogative the choice is now two schemes, the one that cannot be deployed and the one that can, so in effect there is only one scheme. I'd rather take my appeal to the market, fork the spec and tell the press the reason why. Or given the fact that the IETF has abdicated responsibility in this area take a completely fresh DNS Security propoal to an open and democratic forum. The IETF can choose to endorse arbitrary and partisan decision making and even endorse a broken spec if it chooses, but don't think the world is obliged to accept the resulting decision. > For the wg chairs reaction to your company name, while I dont > think it > is appropriate, I dont see why it would prevent IETF to be open and > inclusive. You might not, but I suspect the rest of the world can. Phill From problem-statement-bounces@alvestrand.no Tue Jun 24 12:49:43 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23349 for ; Tue, 24 Jun 2003 12:49:42 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CD221625F0; Tue, 24 Jun 2003 18:49:13 +0200 (CEST) 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 2A871625F0 for ; Tue, 24 Jun 2003 18:49:11 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h5OGqNF11929; Tue, 24 Jun 2003 09:52:23 -0700 Date: Tue, 24 Jun 2003 09:48:59 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/10) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <2944411380.20030624094859@brandenburg.com> To: "Charles E. Perkins" In-Reply-To: <3EF87B02.514D48BD@iprg.nokia.com> References: <8660173.1056452040@dhcp-c2-196.ICANN.globale.net> <20030624121242.6752ecea.moore@cs.utk.edu> <3EF87B02.514D48BD@iprg.nokia.com> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Two Stage Standardization Approach X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Charles, CEP> Spencer Dawkins and I have submitted an Internet Draft CEP> proposing that there be two stages in the IETF CEP> standardization process. A quick read indicates that Proposed stays the same, but Draft and Full are collapsed together. Have I missed anything essential? If not, what is the incentive for seeking the second stage? We already have things stuck at stage 1. What changes the likelihood that anyone will go after stage 2? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue Jun 24 12:54:16 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23493 for ; Tue, 24 Jun 2003 12:54:15 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 441FD625D1; Tue, 24 Jun 2003 18:53:46 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by eikenes.alvestrand.no (Postfix) with ESMTP id 64A8B625D0 for ; Tue, 24 Jun 2003 18:53:44 +0200 (CEST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) h5OGrfZf027362; Tue, 24 Jun 2003 09:53:41 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) h5OGrdsh015654; Tue, 24 Jun 2003 09:53:39 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D2266@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D2266@mou1wnexm02.verisign.com> Date: Tue, 24 Jun 2003 09:53:39 -0700 To: "Hallam-Baker, Phillip" , "'problem-statement@alvestrand.no'" From: hardie@qualcomm.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: Trusting the IESG to manage the reform process (was: Re: Doing t he Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 At 8:30 PM -0700 6/23/03, Hallam-Baker, Phillip wrote: >It would also explain the generation gap problem. The simple fact is that no >matter what anyone under 40 does in the IETF they are never going to get >accepted into the inner circle. > This means that a good portion of the current IESG and IAB are not in the inner circle. It certainly may be true that some of the younger folk are not part of the same affinity groups as some of the more experienced, but the mesh does include lots of folks under 40. The IETF *does* have a problem with integrating the efforts of new folks into the existing mesh of affinity groups. I personally don't believe that age is the critical factor, but that other barriers (lack of shared experience, etc.) make age look more salient than it is. In draft-hardie-12-2-1-00.txt, I put my own take on this problem this way: The author believes that the IETF has traditionally been integrated in two different ways, one formal and one informal. The formal integration relates to the steps of the standards process and the precursor steps of working group formation and chartering. The informal integration is an overlapping set of personal relationships that allows participants to identify skills, perspectives, or energy needed to complete the efforts identified in the formal processes. During a period of rapid growth and a follow-on period of contraction, the second system has been strained to the point of failure. Though the IETF retains a large pool of skilled professionals with energy and needed perspectives, the overlap in personal networks is now not sufficient to associate those with the efforts the IETF has taken on. This has led to delay, lowered quality, and frustration, both among those whose skills and perspectives are not appropriately connected to salient efforts and among those whose efforts have stalled for lack of energy or early input by those with relevant expertise. The solution-space aspect of that was: One path forward for the IETF is to retain much or all of its current formal process, but take the traditionally informal lines of integration and to increase its efforts to create and support them. It may also have to shift some of those lines of integration from the informal to the formal. The SIR proposal, and especially its color-coded variant (SIRS), provides one example of how the IETF might create a formal mechanism (opportunity for early review by those outside an area) to replace the informal mechanism of passing work back and forth among one's colleagues. Beyond that are a host of possible mechanisms. Having an identifiable group of committed participants may create an esprit de corps among those actively participating in a particular working group that will carry on beyond the group's tasks. Initial training sessions can create lines of contact both among a cohort trained together and between those trained and the trainers. That can be extended by fostering round table discussions among participants from different groups, document authors, and chairs. Cross-area and cross-working group integration can be improved by setting up liaison roles. Mentoring programs and peer review systems can be used to create new lines of communication. The connection provided by directorates can also be extended, both by having open-membership directorates for some specific topics and by increasing the amount of inter and intra-group communication expected. None of the changes described above is a magic bullet, and none, at first glance, creates much structural change in the IETF. Each mechanism is, after all, an elaboration of something we already do. It is, instead, a cultural change that suggests the real strength of the IETF is that it brings together folks from substantially different backgrounds who still share a common goal. More importantly, it suggests that to retain that strength the IETF needs to foster mechanisms that brings those folks together early and often. It also presumes that with renewed strength in this core area that the quality problems, delay, and frustration can be addressed within the framework already established. (By the way, I really wish I had said that they will not magically go away and had reinforced the idea that it simply gives the core strength enough to tackle the problems in the existing framework. Unfortunately, I was close enough to the -00 deadline that reissuing a 01 is an unfair burden) There is a long-held belief by some that the real work of any organization gets done in hallways. For the IETF, the right response to that may be to make sure that the networks of folks in those hallways is vibrant, active, and just as open to new membership and participation as its formal processes have always been. That may mean moving some of those meetings out of the hallway and into meeting rooms and mailing lists, but the trade-off might be worth it. There is a real, fundamental question raised by organizational work (the Tipping Point and its more scholarly colleagues)--whether any effort that relies on building networks of this type (formal or informal) can grow past a certain point. I believe it can if it relies on overlapping networks rather than networks with a single focus and if it blends some formalism with the informal networks. But, clearly, there are other ways forward; they may be better. This is simply my view. Ted Hardie From problem-statement-bounces@alvestrand.no Tue Jun 24 12:56:07 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23647 for ; Tue, 24 Jun 2003 12:56:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E4AC2625DB; Tue, 24 Jun 2003 18:55:38 +0200 (CEST) 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 E360E625D0 for ; Tue, 24 Jun 2003 18:55:35 +0200 (CEST) Received: from cisco.com (171.68.223.137) by sj-iport-1.cisco.com with ESMTP; 24 Jun 2003 09:57:22 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5OGtWQx029305; Tue, 24 Jun 2003 09:55:33 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIT38249; Tue, 24 Jun 2003 09:55:31 -0700 (PDT) Message-Id: <200306241655.AIT38249@mira-sjc5-c.cisco.com> To: Dave Crocker From: Melinda Shore In-Reply-To: Message from dcrocker@brandenburg.com <2944411380.20030624094859@brandenburg.com> Date: Tue, 24 Jun 2003 12:55:31 -0400 Cc: problem-statement@alvestrand.no Subject: Re: Two Stage Standardization Approach X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > A quick read indicates that Proposed stays the same, but Draft and Full > are collapsed together. Could we either move this to the solutions mailing list or find some other appropriate home for the discussion? I'm delighted to see a proposal, but this isn't the place to discuss it. Melinda From problem-statement-bounces@alvestrand.no Tue Jun 24 13:02:22 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24054 for ; Tue, 24 Jun 2003 13:02:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A0EED625DC; Tue, 24 Jun 2003 19:01:52 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mx-out.daemonmail.net (mx-out.daemonmail.net [216.104.160.39]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1288C625D0 for ; Tue, 24 Jun 2003 19:01:50 +0200 (CEST) Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.9.3p2/8.9.3) with SMTP id KAA35404 for ; Tue, 24 Jun 2003 10:01:49 -0700 (PDT) (envelope-from spencer@mcsr-labs.org) Received: from (216.62.6.129 [216.62.6.129]) by mail.varaha.com with SMTP id wC90SHF2 Tue, 24 Jun 2003 10:01:48 -0700 (PDT) Message-ID: <016901c33a72$4e5dd1c0$8100000a@DFNJGL21> From: "Spencer Dawkins" To: References: <200306241655.AIT38249@mira-sjc5-c.cisco.com> Date: Tue, 24 Jun 2003 12:01:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: Two Stage Standardization Approach X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Dear Melinda, I pinged Harald a few minutes ago to ask "use solutions, or set up another mailing list?" Given that we've already had one question on this list, my suggestion is that we discuss the proposal on the solutions mailing list... The solutions coordinates are: http://eikenes.alvestrand.no/mailman/listinfo/solutions Spencer ----- Original Message ----- From: "Melinda Shore" To: "Dave Crocker" Cc: Sent: Tuesday, June 24, 2003 11:55 AM Subject: Re: Two Stage Standardization Approach > > A quick read indicates that Proposed stays the same, but Draft and Full > > are collapsed together. > > Could we either move this to the solutions mailing list or > find some other appropriate home for the discussion? I'm > delighted to see a proposal, but this isn't the place to > discuss it. > > Melinda From problem-statement-bounces@alvestrand.no Tue Jun 24 13:13:44 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24911 for ; Tue, 24 Jun 2003 13:13:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DAFC3625EC; Tue, 24 Jun 2003 19:13:13 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2745B625E1 for ; Tue, 24 Jun 2003 19:13:12 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 4.14) id 19UrLy-000MGN-De; Tue, 24 Jun 2003 17:13:10 +0000 To: John C Klensin In-Reply-To: Message from John C Klensin of "Sun, 22 Jun 2003 10:05:14 EDT." <49208097.1056276314@p3.JCK.COM> Date: Tue, 24 Jun 2003 10:13:10 -0700 From: Allison Mankin Message-Id: Cc: Thomas Narten Cc: "problem-statement@alvestrand.no" Subject: Re: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 John, all, >> - My understanding is that in the IESG, a shepherding AD does >> a write-up of each document that is to come up for ballot. >> Some of the other ADs often just read the write-up, trusting >> it to be a fair evaluation of the document. ADs trust each >> other's opinions of the technical quality of the document, >> often voting "no objection" to a document that's out of >> their area of expertise because they trust that the >> shepherding AD or other ADs who are more familiar with the >> document. Assuming my perception is correct of how things >> work on the IESG, I think that's all good stuff. However, >> working group chairs are *not* routinely expected to do >> something like an AD write-up of a document. I have some WG chairs who send a writeup when they ask for Last Call. It does not have all the content that the writeups need to have, so I use it as part of the end writeup. I usually write to the Chairs/authors with some questions about implementation, as this is one of the sections in the writeup. But I think we could change our process and have the WG Chairs do the writeup and have the shepherding AD advise on whether it touches points that will give work best for the purpose described above. I think this would be a very useful thing to do, for the reasons that John describes. Also, the WG Summary (see below) is probably best provided by the Chairs, rather than summarized by the AD from outside. Allison P.S. Here is what we start with for these writeups: ---------------------- > Here's the template: > > The IESG has approved the Internet-Draft 'Enhanced Compressed RTP > (CRTP) for links with high delay, packet loss and reordering' > as a Proposed Standard. > This document is the product of the Audio/Video Transport Working > Group. The IESG contact persons are Allison Manking and Scott > Bradner. > > > Technical Summary > > (What does this protocol do and why does the community need it?) > > Working Group Summary > > (Was there any significant dissent? Was the choice obvious?) > > Protocol Quality > > (Who has reviewed the spec for the IESG? Are there implementations?) From problem-statement-bounces@alvestrand.no Tue Jun 24 13:30:10 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25855 for ; Tue, 24 Jun 2003 13:30:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B6B9D625D0; Tue, 24 Jun 2003 19:29:37 +0200 (CEST) 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 8F6B56257D for ; Tue, 24 Jun 2003 19:29:34 +0200 (CEST) Received: (qmail 55592 invoked from network); 24 Jun 2003 17:36:37 -0000 Received: from unknown (HELO pobox.org.sg) (207.253.237.204) by sentosa.post1.com with SMTP; 24 Jun 2003 17:36:37 -0000 Message-ID: <3EF88A83.1000908@pobox.org.sg> Date: Wed, 25 Jun 2003 01:29:39 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D226B@mou1wnexm02.verisign.com> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D226B@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'problem-statement@alvestrand.no'" Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > But there was consensus in favor of OPT IN, the chair decided to abuse his > position and ignore it subsituting his own opinion. Read the WG mailing > lists. As I said, if you feel the wg chairs is wrong in the determination of the rough consensus, then you should appeal. The process to do so is stated in RFC 2026 Section 6.5. > I'd rather take my appeal to the market, fork the spec and tell > the press the reason why. Or given the fact that the IETF has > abdicated responsibility in this area take a completely fresh > DNS Security propoal to an open and democratic forum. > > The IETF can choose to endorse arbitrary and partisan decision > making and even endorse a broken spec if it chooses, but don't > think the world is obliged to accept the resulting decision. It is your choice not to appeal and it is within your rights. But this does not means there is a problem with IETF nor could I agree with your conclusion. How could there be a problem if you have not put it to a test? -James Seng From problem-statement-bounces@alvestrand.no Tue Jun 24 13:32:35 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26026 for ; Tue, 24 Jun 2003 13:32:34 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 82C88625EF; Tue, 24 Jun 2003 19:32:03 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from vmmr7.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by eikenes.alvestrand.no (Postfix) with ESMTP id 57BEA6257D for ; Tue, 24 Jun 2003 19:32:01 +0200 (CEST) Received: from ms3.verisignmail.com (ms3.verisignmail.com [216.168.230.176] (may be forged)) by vmmr7.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id OXL28747; Tue, 24 Jun 2003 13:31:51 -0400 (EDT) Received: from BOBDEV (pool-162-83-143-229.ny5030.east.verizon.net [162.83.143.229]) by ms3.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AJG79139; Tue, 24 Jun 2003 13:31:50 -0400 (EDT) From: "Bob Wyman" To: "'James Seng'" , "'Hallam-Baker, Phillip'" Date: Tue, 24 Jun 2003 13:32:05 -0400 Message-ID: <005901c33a76$887ab180$660aa8c0@BOBDEV> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3EF8783D.3010809@pobox.org.sg> Importance: Normal Cc: problem-statement@alvestrand.no Subject: RE: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: bob@wyman.us 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 James Seng wrote: > For the wg chairs reaction to your company name, while I=20 > dont think it is appropriate, I dont see why it would prevent > IETF to be open and inclusive. Everyone here represents=20 > himself/herself here and being political correct was, AFAIK,=20 > not one of IETF core principle. WG Chairs should be held to a higher standard of conduct. One of the functions of the chair is to ensure that the process is, in fact, "open and inclusive". It seems difficult to me to imagine how anyone could suggest that a WG Chair who hisses participants could be said to be contributing to an "open and inclusive" process.=20 The mere fact that such WG Chairs continue to exist should be considered a subject for the "Problem Statement." bob wyman From problem-statement-bounces@alvestrand.no Tue Jun 24 13:41:10 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26469 for ; Tue, 24 Jun 2003 13:41:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 25FAF625F1; Tue, 24 Jun 2003 19:40:07 +0200 (CEST) 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 C6F946257D for ; Tue, 24 Jun 2003 19:40:04 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h5OHhLF15709; Tue, 24 Jun 2003 10:43:21 -0700 Date: Tue, 24 Jun 2003 10:39:58 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/11) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <047468025.20030624103958@brandenburg.com> To: hardie@qualcomm.com In-Reply-To: References: <2A1D4C86842EE14CA9BC80474919782E0D2266@mou1wnexm02.verisign.com> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 note that I've changed the Subject line, to purse the cited topic. This note could easily be construed as making statements about a particular contributor. Please avoid the inclination to interpret it that way. I am citing that posting in order to demonstrate some choices in how to evaluate an issue with making working group progress. hqc> At 8:30 PM -0700 6/23/03, Hallam-Baker, Phillip wrote: >>It would also explain the generation gap problem. The simple fact is that no >>matter what anyone under 40 does in the IETF they are never going to get >>accepted into the inner circle. hqc> This means that a good portion of the current IESG and IAB are not in the hqc> inner circle. It certainly may be true that some of the younger folk are hqc> not part of the same affinity groups as some of the more experienced, hqc> but the mesh does include lots of folks under 40. This sub-thread on "Trusting" has a focus on criticizing individuals and re-visiting a number of topics that have been discussed at length. Let's ask whether there is anything constructive that is likely to come out of this sub-thread? My own guess is that there is not. How should we evaluate this sub-thread? What should a diligent discussion participant do, in response to such a posting? What formal mechanisms can work to reduce such postings, in favor of postings that are more likely to be productive? One possibility is to attack the originator of the thread as a troublemaker and seek formal mechanisms for restricting their behaviors. There are several dangerous problems with that approach. First is that it keeps things personal, which is not what we are here to do, and which is certain to keep things uproductive -- it always does. Second is that the criteria for acceptable and unacceptable behavior cannot be subtle; they need to be as objective as we can make them. This necessitates their coming into effect only in the most extreme cases. Third is that the current formal mechanisms are expensive and distracting. Using them further delays making forward progress. So, only extremely objectionable behaviors can reasonably be restricted, formally. Unfortunately, that makes the formal mechanism applicable a long time after productive exchanges have become impractical. I believe that a major strength among IETF participants is also a major weakness, namely the desire to press for mutual understanding -- or, at least, convincing that one's own view is correct. This means that we tend to respond more often than we need to. (Alas, I'm speaking from too much expertise in committing this sin.) If we view this kind of sub-thread as one example of going down an unproductive path, then existing mechanisms are probably sufficient -- if we become more diligent at using them. The two existing mechanisms that are most appropriate are a) the rest of us need to simply ignore the posting; don't take the bait, and b) wg chair management of the discussion can be invoked, in the same way as Melinda (correctly) just pointed out that a separate thread needed to be pursued elsewhere. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue Jun 24 13:41:37 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26494 for ; Tue, 24 Jun 2003 13:41:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9EEAE625F3; Tue, 24 Jun 2003 19:41:06 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7442C625D3 for ; Tue, 24 Jun 2003 19:41:04 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h5OHf3ch028712; Tue, 24 Jun 2003 10:41:03 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 10:41:03 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D226D@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'James Seng'" , "Hallam-Baker, Phillip" Date: Tue, 24 Jun 2003 10:41:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: "'problem-statement@alvestrand.no'" Subject: RE: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > But this does not means there is a problem with IETF nor > could I agree > with your conclusion. How could there be a problem if you > have not put it to a test? The fact that the WG process can break so baddly and the IESG sits by and twiddles its thumbs doing nothing is enough of a test as far as I am concerned. I raised my concerns repeatedly with the AD and got nothing but the wet sock 'process' tosh. So even though the process was being abused left and right there was no recourse. Phill From problem-statement-bounces@alvestrand.no Tue Jun 24 13:56:31 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27583 for ; Tue, 24 Jun 2003 13:56:30 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6FE1C625EE; Tue, 24 Jun 2003 19:55:59 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 68EF2625ED for ; Tue, 24 Jun 2003 19:55:56 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h5OHttch002504; Tue, 24 Jun 2003 10:55:55 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 10:55:55 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D226F@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'hardie@qualcomm.com'" , "Hallam-Baker, Phillip" , "'problem-statement@alvestrand.no'" Date: Tue, 24 Jun 2003 10:55:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Trusting the IESG to manage the reform process (was: Re: Doin g t he Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 means that a good portion of the current IESG and IAB > are not in the > inner circle. It certainly may be true that some of the > younger folk are > not part of the same affinity groups as some of the more experienced, > but the mesh does include lots of folks under 40. My own experience is that I have been involved in two major IETF efforts. In each case the core of the younger engineering team has essentially left the IETF space. In the case of the HTTP effort it is perhaps not surprising that people chose W3C over IETF, but why is that when the W3C is hardly untroubled by bureaucratic process and in theory is a benevolent dictatorship? The PKIX case is more mysterious still, some of the younger engineers still appear at PKIX meetings, but the momentum has moved decisively to OASIS in the space of less than two years. That is where all new commercial crypto specs are going to be proposed in the years to come. The issue is not who holds what office, the issue is whose opinion holds weight and whose does not and even more so whose opinion is solicited and whose is not. The reason the engineers I referred to have left is that they believe that there is no place for them in the IETF, their opinion is never going to count for anything. Phill From problem-statement-bounces@alvestrand.no Tue Jun 24 14:10:11 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28715 for ; Tue, 24 Jun 2003 14:10:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 21A8C625ED; Tue, 24 Jun 2003 20:09:39 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by eikenes.alvestrand.no (Postfix) with ESMTP id 516E8625E1 for ; Tue, 24 Jun 2003 20:09:37 +0200 (CEST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) h5OI9UBd007907 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 24 Jun 2003 11:09:30 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) h5OI9Rsh000915; Tue, 24 Jun 2003 11:09:28 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <047468025.20030624103958@brandenburg.com> References: <2A1D4C86842EE14CA9BC80474919782E0D2266@mou1wnexm02.verisign.com> <047468025.20030624103958@brandenburg.com> Date: Tue, 24 Jun 2003 11:09:25 -0700 To: Dave Crocker From: hardie@qualcomm.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: problem-statement@alvestrand.no Subject: Some other subject X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Dave, I've changed the subject line again, because my comments weren't on the "trouble maker" point; you may be right that they weren't on the point of trusting the IESG to manage reform (though there is an odd resonance). Aside from this, I think you missed my point. I responded to Phillip Hallam-Baker's discussion of age as a criterion for membership in "the inner circle" in order to get back to the idea of "affinity groups" (a.k.a trust networks, personal relationship networks, etc.) and the mesh of such groupings in the IETF. This was not a criticism of Phillip; indeed, I agree that there is a very serious problem here in integrating folks with energy and expertise into the IETF. I believe, however, you need to look past a simple distinction based on age to get at how that integration succeeds or fails. To me, this is a critical part of getting the problem statement here right. I also believe that the point on the size of organizations integrated with personal networks belongs here, and I posted the solutions space aspect of the draft explicitly to raise that point---that the question of the maximum size which can be integrated with a specific mechanism may be a problem in its own right. I hope that clarifies things, Ted Hardie At 10:39 AM -0700 6/24/03, Dave Crocker wrote: >Please note that I've changed the Subject line, to purse the cited >topic. This note could easily be construed as making statements about a >particular contributor. Please avoid the inclination to interpret it >that way. I am citing that posting in order to demonstrate some choices >in how to evaluate an issue with making working group progress. > > >hqc> At 8:30 PM -0700 6/23/03, Hallam-Baker, Phillip wrote: >>>It would also explain the generation gap problem. The simple fact is that no >>>matter what anyone under 40 does in the IETF they are never going to get >>>accepted into the inner circle. >hqc> This means that a good portion of the current IESG and IAB are not in the >hqc> inner circle. It certainly may be true that some of the younger folk are >hqc> not part of the same affinity groups as some of the more experienced, >hqc> but the mesh does include lots of folks under 40. > >This sub-thread on "Trusting" has a focus on criticizing individuals and >re-visiting a number of topics that have been discussed at length. > >Let's ask whether there is anything constructive that is likely to >come out of this sub-thread? My own guess is that there is not. > >How should we evaluate this sub-thread? What should a diligent >discussion participant do, in response to such a posting? What formal >mechanisms can work to reduce such postings, in favor of postings that >are more likely to be productive? > >One possibility is to attack the originator of the thread as a >troublemaker and seek formal mechanisms for restricting their behaviors. >There are several dangerous problems with that approach. First is that >it keeps things personal, which is not what we are here to do, and which >is certain to keep things uproductive -- it always does. Second is that >the criteria for acceptable and unacceptable behavior cannot be subtle; >they need to be as objective as we can make them. This necessitates >their coming into effect only in the most extreme cases. Third is that >the current formal mechanisms are expensive and distracting. Using them >further delays making forward progress. > >So, only extremely objectionable behaviors can reasonably be restricted, >formally. Unfortunately, that makes the formal mechanism applicable a >long time after productive exchanges have become impractical. > >I believe that a major strength among IETF participants is also a major >weakness, namely the desire to press for mutual understanding -- or, at >least, convincing that one's own view is correct. This means that we >tend to respond more often than we need to. (Alas, I'm speaking from >too much expertise in committing this sin.) > >If we view this kind of sub-thread as one example of going down an >unproductive path, then existing mechanisms are probably sufficient -- >if we become more diligent at using them. > >The two existing mechanisms that are most appropriate are a) the rest of >us need to simply ignore the posting; don't take the bait, and b) wg >chair management of the discussion can be invoked, in the same way as >Melinda (correctly) just pointed out that a separate thread needed to >be pursued elsewhere. > > >d/ >-- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue Jun 24 14:23:47 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29834 for ; Tue, 24 Jun 2003 14:22:41 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F0172625D6; Tue, 24 Jun 2003 20:22:09 +0200 (CEST) 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 BA16F625D3 for ; Tue, 24 Jun 2003 20:22:06 +0200 (CEST) Received: (qmail 55971 invoked from network); 24 Jun 2003 18:29:10 -0000 Received: from unknown (HELO pobox.org.sg) (207.253.237.204) by sentosa.post1.com with SMTP; 24 Jun 2003 18:29:10 -0000 Message-ID: <3EF896D6.6010103@pobox.org.sg> Date: Wed, 25 Jun 2003 02:22:14 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D226D@mou1wnexm02.verisign.com> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D226D@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'problem-statement@alvestrand.no'" Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit In other words, you have not formally appeal. You only assume you will fail even if you appeal. And assuming you have fail, the IETF process is broken. The logical chain dont link. Please bring your soap opera somewhere else. -James Seng Hallam-Baker, Phillip wrote: >>But this does not means there is a problem with IETF nor >>could I agree >>with your conclusion. How could there be a problem if you >>have not put it to a test? > > > The fact that the WG process can break so baddly and the IESG > sits by and twiddles its thumbs doing nothing is enough of a test > as far as I am concerned. > > I raised my concerns repeatedly with the AD and got nothing but > the wet sock 'process' tosh. So even though the process was being > abused left and right there was no recourse. > > > Phill > > From problem-statement-bounces@alvestrand.no Tue Jun 24 14:24:35 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00242 for ; Tue, 24 Jun 2003 14:24:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C5B1C625D3; Tue, 24 Jun 2003 20:24:04 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id E1A786257D for ; Tue, 24 Jun 2003 20:24:02 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h5OIO1ch010171 for ; Tue, 24 Jun 2003 11:24:01 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 11:24:01 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D2270@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'problem-statement@alvestrand.no'" Date: Tue, 24 Jun 2003 11:24:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Scott writes "If the chair hisses when someone stands up to speak that's more than just being "politically incorrect". However, that kind of lack of training in chairs is already covered." It should not require training for someone to realize that this type of behavior is unacceptable. Given that the chair in question is a current member of the IESG it seems more likely that he would be choosen to give any training that might occur than attend or take notice of it. The problem is the lack of effective accountability of the chairs to the working groups. The IETF pretends to be open but is an entirely top down organization. There is no accountability of a WG chair to the working group. Even when a sizable proportion of a WG call for the resignation of a chair on the list (and I presume like myself confer with the AD) nothing happens, not even a comment from the AD to the list to state that the concerns have been noted. Of course in this particular case the chair was also a member of the IESG so there was possibly an in built reluctance to challenge a fellow AD, but the result is no effective recourse and no effective appeal. The superficial problem could be addressed through a strict requirement that an AD MUST NOT be a WG chair, even in a different area. But that would not address the fundamental inconsistency of top down authoritarian control in an organization trying to be open and inclusive. Phill From problem-statement-bounces@alvestrand.no Tue Jun 24 14:34:01 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01878 for ; Tue, 24 Jun 2003 14:34:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7CCE9625F2; Tue, 24 Jun 2003 20:33:29 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id BE18B6257D for ; Tue, 24 Jun 2003 20:33:27 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h5OIXIN04912; Tue, 24 Jun 2003 14:33:20 -0400 (EDT) Date: Tue, 24 Jun 2003 14:33:18 -0400 From: Keith Moore To: "Hallam-Baker, Phillip" Message-Id: <20030624143318.4508b4ff.moore@cs.utk.edu> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D2266@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D2266@mou1wnexm02.verisign.com> X-Mailer: Sylpheed version 0.9.2 (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 Cc: moore@cs.utk.edu Subject: Re: Trusting the IESG to manage the reform process (was: Re: Doing t he Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > The simple fact is that no > matter what anyone under 40 does in the IETF they are never going to > get accepted into the inner circle. I was on IESG for four entire years before I turned 40. Before that I was a working group chair, and author of several RFCs. This wasn't very long ago. Keith From problem-statement-bounces@alvestrand.no Tue Jun 24 14:45:56 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02686 for ; Tue, 24 Jun 2003 14:45:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3B917625F4; Tue, 24 Jun 2003 20:45:25 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1753B6257D for ; Tue, 24 Jun 2003 20:45:23 +0200 (CEST) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h5OIjL2Q026686; Tue, 24 Jun 2003 11:45:21 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 11:45:22 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D2271@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'James Seng'" , "Hallam-Baker, Phillip" Date: Tue, 24 Jun 2003 11:45:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: "'problem-statement@alvestrand.no'" Subject: RE: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 No, I am am persuing an alternative appeal route called the market. Given that the individual who was responsible for the conduct being appealed is on the IESG and is unlikely to recuse himself of the appeals process I would be a complete fool to bring an appeal to that forum, thereby endorsing a closed process as the final arbiter. If the IESG is interested in a spec that can actually be deployed it will start the appeals process of its own accord or return the current drafts to the WG because the operators of the largest zones have identified serious technical flaws that prevent deployment. Phill > -----Original Message----- > From: James Seng [mailto:jseng@pobox.org.sg] > Sent: Tuesday, June 24, 2003 2:22 PM > To: Hallam-Baker, Phillip > Cc: 'problem-statement@alvestrand.no' > Subject: Re: "trouble maker" > > > In other words, you have not formally appeal. You only assume > you will > fail even if you appeal. And assuming you have fail, the IETF > process is > broken. > > The logical chain dont link. Please bring your soap opera > somewhere else. > > -James Seng > > Hallam-Baker, Phillip wrote: > >>But this does not means there is a problem with IETF nor > >>could I agree > >>with your conclusion. How could there be a problem if you > >>have not put it to a test? > > > > > > The fact that the WG process can break so baddly and the IESG > > sits by and twiddles its thumbs doing nothing is enough of a test > > as far as I am concerned. > > > > I raised my concerns repeatedly with the AD and got nothing but > > the wet sock 'process' tosh. So even though the process was being > > abused left and right there was no recourse. > > > > > > Phill > > > > > From problem-statement-bounces@alvestrand.no Tue Jun 24 15:10:28 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04224 for ; Tue, 24 Jun 2003 15:10:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AA1C0625FB; Tue, 24 Jun 2003 21:09:57 +0200 (CEST) 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 66024625F6 for ; Tue, 24 Jun 2003 21:09:54 +0200 (CEST) Received: (qmail 56654 invoked from network); 24 Jun 2003 19:16:58 -0000 Received: from unknown (HELO pobox.org.sg) (207.253.237.204) by sentosa.post1.com with SMTP; 24 Jun 2003 19:16:58 -0000 Message-ID: <3EF8A208.5080003@pobox.org.sg> Date: Wed, 25 Jun 2003 03:10:00 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D2271@mou1wnexm02.verisign.com> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D2271@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'problem-statement@alvestrand.no'" Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 If you pursue the appeal process as documented in RFC 2026 and you failed despite having all evidences that you should win, I will agree that you have a case to state this as a problem. But you choose not to use the process. And your decision to pursue an alternative appeal *does not* indicate a failure of the IETF appeal process. -James Seng Hallam-Baker, Phillip wrote: > No, I am am persuing an alternative appeal route called the market. > > Given that the individual who was responsible for the conduct being appealed > is on the IESG and is unlikely to recuse himself of the appeals process I > would be a complete fool to bring an appeal to that forum, thereby endorsing > a closed process as the final arbiter. > > If the IESG is interested in a spec that can actually be deployed it will > start the appeals process of its own accord or return the current drafts to > the WG because the operators of the largest zones have identified serious > technical flaws that prevent deployment. > > Phill > > >>-----Original Message----- >>From: James Seng [mailto:jseng@pobox.org.sg] >>Sent: Tuesday, June 24, 2003 2:22 PM >>To: Hallam-Baker, Phillip >>Cc: 'problem-statement@alvestrand.no' >>Subject: Re: "trouble maker" >> >> >>In other words, you have not formally appeal. You only assume >>you will >>fail even if you appeal. And assuming you have fail, the IETF >>process is >>broken. >> >>The logical chain dont link. Please bring your soap opera >>somewhere else. >> >>-James Seng >> >>Hallam-Baker, Phillip wrote: >> >>>>But this does not means there is a problem with IETF nor >>>>could I agree >>>>with your conclusion. How could there be a problem if you >>>>have not put it to a test? >>> >>> >>>The fact that the WG process can break so baddly and the IESG >>>sits by and twiddles its thumbs doing nothing is enough of a test >>>as far as I am concerned. >>> >>>I raised my concerns repeatedly with the AD and got nothing but >>>the wet sock 'process' tosh. So even though the process was being >>>abused left and right there was no recourse. >>> >>> >>> Phill >>> >>> >> > > From problem-statement-bounces@alvestrand.no Tue Jun 24 15:21:54 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05779 for ; Tue, 24 Jun 2003 15:21:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 51770625FC; Tue, 24 Jun 2003 21:21:23 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0BDDA625F6 for ; Tue, 24 Jun 2003 21:21:21 +0200 (CEST) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h5OJLJ2Q003351; Tue, 24 Jun 2003 12:21:20 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 12:21:20 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D2277@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'James Seng'" , "Hallam-Baker, Phillip" Date: Tue, 24 Jun 2003 12:21:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: "'problem-statement@alvestrand.no'" Subject: RE: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 That is not the point I raised which was a failure of the IETF WG process, not the appeals process. The fact that the same individual can abuse the original WG process and then participate in the appeals process is relevant however. In fact it is even possible in theory for a single individual to chair the original WG and participate in both the original and IAB appeal if the IESG/IAB liason were involved. Phill > -----Original Message----- > From: James Seng [mailto:jseng@pobox.org.sg] > Sent: Tuesday, June 24, 2003 3:10 PM > To: Hallam-Baker, Phillip > Cc: 'problem-statement@alvestrand.no' > Subject: Re: "trouble maker" > > > If you pursue the appeal process as documented in RFC 2026 and you > failed despite having all evidences that you should win, I will agree > that you have a case to state this as a problem. > > But you choose not to use the process. And your decision to pursue an > alternative appeal *does not* indicate a failure of the IETF > appeal process. > > -James Seng From problem-statement-bounces@alvestrand.no Tue Jun 24 15:32:16 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06345 for ; Tue, 24 Jun 2003 15:32:15 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 05D08625FF; Tue, 24 Jun 2003 21:31:45 +0200 (CEST) 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 3AF8D625F6 for ; Tue, 24 Jun 2003 21:31:42 +0200 (CEST) Received: (qmail 56731 invoked from network); 24 Jun 2003 19:38:45 -0000 Received: from unknown (HELO pobox.org.sg) (207.253.237.204) by sentosa.post1.com with SMTP; 24 Jun 2003 19:38:45 -0000 Message-ID: <3EF8A725.2010502@pobox.org.sg> Date: Wed, 25 Jun 2003 03:31:49 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D2277@mou1wnexm02.verisign.com> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D2277@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'problem-statement@alvestrand.no'" Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit The appeal process is a very important aspect of the IETF WG process. It is the safe-guard and check-and-balance against the power of the wg chair. Without the appeal process, the WG process dont make sense. Hence, you cannot conclude the WG process dont work if you dont use the appeal process. This has nothing to do who is chairing or if the same person is on the IESG or IAB. -James Seng Hallam-Baker, Phillip wrote: > That is not the point I raised which was a failure of the IETF WG process, > not the appeals process. > > The fact that the same individual can abuse the original WG process and then > participate in the appeals process is relevant however. In fact it is even > possible in theory for a single individual to chair the original WG and > participate in both the original and IAB appeal if the IESG/IAB liason were > involved. > > Phill > > >>-----Original Message----- >>From: James Seng [mailto:jseng@pobox.org.sg] >>Sent: Tuesday, June 24, 2003 3:10 PM >>To: Hallam-Baker, Phillip >>Cc: 'problem-statement@alvestrand.no' >>Subject: Re: "trouble maker" >> >> >>If you pursue the appeal process as documented in RFC 2026 and you >>failed despite having all evidences that you should win, I will agree >>that you have a case to state this as a problem. >> >>But you choose not to use the process. And your decision to pursue an >>alternative appeal *does not* indicate a failure of the IETF >>appeal process. >> >>-James Seng > > > From problem-statement-bounces@alvestrand.no Tue Jun 24 15:37:49 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06709 for ; Tue, 24 Jun 2003 15:37:48 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 198C9625F8; Tue, 24 Jun 2003 21:04:12 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 027DD625F6 for ; Tue, 24 Jun 2003 21:04:10 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h5OJ45N04951; Tue, 24 Jun 2003 15:04:05 -0400 (EDT) Date: Tue, 24 Jun 2003 15:04:05 -0400 From: Keith Moore To: "Hallam-Baker, Phillip" Message-Id: <20030624150405.20155090.moore@cs.utk.edu> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D2275@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D2275@mou1wnexm02.verisign.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: pbaker@verisign.com Cc: moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: Re: Trusting the IESG to manage the reform process (was: Re: Doin g t he Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 did not say it was a question of age, it is a question of > the inner circle membership having closed many years ago. I don't believe it. if nothing else, too many of the old boys are too burned out to want to do the jobs anymore. From problem-statement-bounces@alvestrand.no Tue Jun 24 15:38:59 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06770 for ; Tue, 24 Jun 2003 15:38:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 90CC762602; Tue, 24 Jun 2003 21:38:28 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 972AD625F6 for ; Tue, 24 Jun 2003 21:38:21 +0200 (CEST) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h5OJcK2Q006095; Tue, 24 Jun 2003 12:38:20 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 12:38:20 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D2278@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'James Seng'" , "Hallam-Baker, Phillip" Date: Tue, 24 Jun 2003 12:38:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: "'problem-statement@alvestrand.no'" Subject: RE: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Pure sophistry, the WG process failed because an individual was allowed to abuse it for three years. The three years delay was the failure of the WG. I want to see evidence the IETF is committed to reform and openness before making any appeal. Phill > -----Original Message----- > From: James Seng [mailto:jseng@pobox.org.sg] > Sent: Tuesday, June 24, 2003 3:32 PM > To: Hallam-Baker, Phillip > Cc: 'problem-statement@alvestrand.no' > Subject: Re: "trouble maker" > > > The appeal process is a very important aspect of the IETF WG > process. It > is the safe-guard and check-and-balance against the power of the wg > chair. Without the appeal process, the WG process dont make sense. > > Hence, you cannot conclude the WG process dont work if you > dont use the > appeal process. > > This has nothing to do who is chairing or if the same person > is on the > IESG or IAB. > > -James Seng > > Hallam-Baker, Phillip wrote: > > That is not the point I raised which was a failure of the > IETF WG process, > > not the appeals process. > > > > The fact that the same individual can abuse the original WG > process and then > > participate in the appeals process is relevant however. In > fact it is even > > possible in theory for a single individual to chair the > original WG and > > participate in both the original and IAB appeal if the > IESG/IAB liason were > > involved. > > > > Phill > > > > > >>-----Original Message----- > >>From: James Seng [mailto:jseng@pobox.org.sg] > >>Sent: Tuesday, June 24, 2003 3:10 PM > >>To: Hallam-Baker, Phillip > >>Cc: 'problem-statement@alvestrand.no' > >>Subject: Re: "trouble maker" > >> > >> > >>If you pursue the appeal process as documented in RFC 2026 and you > >>failed despite having all evidences that you should win, I > will agree > >>that you have a case to state this as a problem. > >> > >>But you choose not to use the process. And your decision to > pursue an > >>alternative appeal *does not* indicate a failure of the IETF > >>appeal process. > >> > >>-James Seng > > > > > > > From problem-statement-bounces@alvestrand.no Tue Jun 24 15:55:28 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07459 for ; Tue, 24 Jun 2003 15:55:27 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 39453625F6; Tue, 24 Jun 2003 21:54:57 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id A4C7B625F6 for ; Tue, 24 Jun 2003 21:54:54 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 4.14) id 19UtsS-0003Kv-Ve; Tue, 24 Jun 2003 19:54:52 +0000 To: "Hallam-Baker, Phillip" In-Reply-To: Message from "Hallam-Baker, Phillip" <2A1D4C86842EE14CA9BC80474919782E0D2275@mou1wnexm02.verisign.com> Date: Tue, 24 Jun 2003 12:54:52 -0700 From: Allison Mankin Message-Id: Cc: problem-statement@alvestrand.no Cc: "'Keith Moore'" Subject: Re: Trusting the IESG to manage the reform process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Phill, > I did not say it was a question of age, it is a question of > the inner circle membership having closed many years ago. The current IESG has members who have been active in IETF for five years or less. My Co-AD, Jon Peterson, is one. This is an excellent development, because the IETF know-how is there, the nomcom made sure of that, and there are fresh perspectives from Jon and the other new folks. There is no question that there are some inner circle effects around the IESG and around processes at IETF. But there is a real commitment by me and IESG colleages to find new talent for WG chairships for one example of avoiding inner circles, and to encourage WG chairs to do the same with editorships, design team leads, and so on. We don't have obvious ways to make this commitment plain, you have to look at the specific results. I have some specific examples from WG selection, but I need to vet them with the individuals involved. Allison From problem-statement-bounces@alvestrand.no Tue Jun 24 15:59:46 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07589 for ; Tue, 24 Jun 2003 15:59:46 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E7A3462601; Tue, 24 Jun 2003 21:59:15 +0200 (CEST) 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 2B234625FA for ; Tue, 24 Jun 2003 21:59:13 +0200 (CEST) Received: (qmail 56820 invoked from network); 24 Jun 2003 20:06:16 -0000 Received: from unknown (HELO pobox.org.sg) (207.253.237.204) by sentosa.post1.com with SMTP; 24 Jun 2003 20:06:16 -0000 Message-ID: <3EF8AD98.9070709@pobox.org.sg> Date: Wed, 25 Jun 2003 03:59:20 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D2278@mou1wnexm02.verisign.com> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D2278@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'problem-statement@alvestrand.no'" Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 see. i guess making noise about the "failure" of the IETF process is more productive then actually participating in the process. its your call. -James Seng Hallam-Baker, Phillip wrote: > Pure sophistry, the WG process failed because an individual was allowed to > abuse it for three years. The three years delay was the failure of the WG. > > I want to see evidence the IETF is committed to reform and openness before > making any appeal. > > > Phill > > >>-----Original Message----- >>From: James Seng [mailto:jseng@pobox.org.sg] >>Sent: Tuesday, June 24, 2003 3:32 PM >>To: Hallam-Baker, Phillip >>Cc: 'problem-statement@alvestrand.no' >>Subject: Re: "trouble maker" >> >> >>The appeal process is a very important aspect of the IETF WG >>process. It >>is the safe-guard and check-and-balance against the power of the wg >>chair. Without the appeal process, the WG process dont make sense. >> >>Hence, you cannot conclude the WG process dont work if you >>dont use the >>appeal process. >> >>This has nothing to do who is chairing or if the same person >>is on the >>IESG or IAB. >> >>-James Seng >> >>Hallam-Baker, Phillip wrote: >> >>>That is not the point I raised which was a failure of the >> >>IETF WG process, >> >>>not the appeals process. >>> >>>The fact that the same individual can abuse the original WG >> >>process and then >> >>>participate in the appeals process is relevant however. In >> >>fact it is even >> >>>possible in theory for a single individual to chair the >> >>original WG and >> >>>participate in both the original and IAB appeal if the >> >>IESG/IAB liason were >> >>>involved. >>> >>> Phill >>> >>> >>> >>>>-----Original Message----- >>>>From: James Seng [mailto:jseng@pobox.org.sg] >>>>Sent: Tuesday, June 24, 2003 3:10 PM >>>>To: Hallam-Baker, Phillip >>>>Cc: 'problem-statement@alvestrand.no' >>>>Subject: Re: "trouble maker" >>>> >>>> >>>>If you pursue the appeal process as documented in RFC 2026 and you >>>>failed despite having all evidences that you should win, I >> >>will agree >> >>>>that you have a case to state this as a problem. >>>> >>>>But you choose not to use the process. And your decision to >> >>pursue an >> >>>>alternative appeal *does not* indicate a failure of the IETF >>>>appeal process. >>>> >>>>-James Seng >>> >>> >>> > > From problem-statement-bounces@alvestrand.no Tue Jun 24 16:08:01 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07952 for ; Tue, 24 Jun 2003 16:08:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 60A1862608; Tue, 24 Jun 2003 22:07:30 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1EB5462606 for ; Tue, 24 Jun 2003 22:07:28 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h5OK7DN05044; Tue, 24 Jun 2003 16:07:14 -0400 (EDT) Date: Tue, 24 Jun 2003 16:07:13 -0400 From: Keith Moore To: Dave Crocker Message-Id: <20030624160713.3ef09588.moore@cs.utk.edu> In-Reply-To: <174132382475.20030607215256@brandenburg.com> References: <3EDDA77F.8050700@piuha.net> <3EDDA77F.8050700@piuha.net> <5.1.0.14.2.20030607123251.047d9aa0@mail.windriver.com> <174132382475.20030607215256@brandenburg.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: mrw@windriver.com Cc: problem-statement@alvestrand.no Cc: dhc@dcrocker.net Cc: moore@cs.utk.edu Subject: Re: Complex Problems (Was: Re: Discipline of Internet Protocol Engineering) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > IETF work has been notably successful only when it has done bite-sized > bits of coherent work. It has attacked complex issues successfully > only when it has attacked the issues piecemeal. I think we have had far more failures than successes by attacking issues piecemeal. From problem-statement-bounces@alvestrand.no Tue Jun 24 16:16:52 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08444 for ; Tue, 24 Jun 2003 16:16:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 20C3762607; Tue, 24 Jun 2003 22:16:21 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6668962606 for ; Tue, 24 Jun 2003 22:16:14 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h5OKGDch004406; Tue, 24 Jun 2003 13:16:13 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 13:16:13 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D2279@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'James Seng'" , "Hallam-Baker, Phillip" Date: Tue, 24 Jun 2003 13:16:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: "'problem-statement@alvestrand.no'" Subject: RE: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 At this point making noise about the failure of the IETF is empirically more productive than actually participating in the broken process. Serious standards work I take to OASIS, a democratic and genuinely open forum. Up until now I have only been taking new XML-based specs there. From this point on I intend to propose modifications to specifications that IETF considers that it holds change control on in other forums. If the IETF wants to influence the future direction of Internet standards I suggest that it consider dismantling the top-down organization and work out ways in which it can live up to the claims it makes for openness, inclusivity and accountability. Phill > -----Original Message----- > From: James Seng [mailto:jseng@pobox.org.sg] > Sent: Tuesday, June 24, 2003 3:59 PM > To: Hallam-Baker, Phillip > Cc: 'problem-statement@alvestrand.no' > Subject: Re: "trouble maker" > > > i see. > > i guess making noise about the "failure" of the IETF process is more > productive then actually participating in the process. > > its your call. > > -James Seng > > Hallam-Baker, Phillip wrote: > > Pure sophistry, the WG process failed because an individual > was allowed to > > abuse it for three years. The three years delay was the > failure of the WG. > > > > I want to see evidence the IETF is committed to reform and > openness before > > making any appeal. > > > > > > Phill > > > > > >>-----Original Message----- > >>From: James Seng [mailto:jseng@pobox.org.sg] > >>Sent: Tuesday, June 24, 2003 3:32 PM > >>To: Hallam-Baker, Phillip > >>Cc: 'problem-statement@alvestrand.no' > >>Subject: Re: "trouble maker" > >> > >> > >>The appeal process is a very important aspect of the IETF WG > >>process. It > >>is the safe-guard and check-and-balance against the power of the wg > >>chair. Without the appeal process, the WG process dont make sense. > >> > >>Hence, you cannot conclude the WG process dont work if you > >>dont use the > >>appeal process. > >> > >>This has nothing to do who is chairing or if the same person > >>is on the > >>IESG or IAB. > >> > >>-James Seng > >> > >>Hallam-Baker, Phillip wrote: > >> > >>>That is not the point I raised which was a failure of the > >> > >>IETF WG process, > >> > >>>not the appeals process. > >>> > >>>The fact that the same individual can abuse the original WG > >> > >>process and then > >> > >>>participate in the appeals process is relevant however. In > >> > >>fact it is even > >> > >>>possible in theory for a single individual to chair the > >> > >>original WG and > >> > >>>participate in both the original and IAB appeal if the > >> > >>IESG/IAB liason were > >> > >>>involved. > >>> > >>> Phill > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: James Seng [mailto:jseng@pobox.org.sg] > >>>>Sent: Tuesday, June 24, 2003 3:10 PM > >>>>To: Hallam-Baker, Phillip > >>>>Cc: 'problem-statement@alvestrand.no' > >>>>Subject: Re: "trouble maker" > >>>> > >>>> > >>>>If you pursue the appeal process as documented in RFC > 2026 and you > >>>>failed despite having all evidences that you should win, I > >> > >>will agree > >> > >>>>that you have a case to state this as a problem. > >>>> > >>>>But you choose not to use the process. And your decision to > >> > >>pursue an > >> > >>>>alternative appeal *does not* indicate a failure of the IETF > >>>>appeal process. > >>>> > >>>>-James Seng > >>> > >>> > >>> > > > > > From problem-statement-bounces@alvestrand.no Tue Jun 24 16:20:46 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08982 for ; Tue, 24 Jun 2003 16:20:44 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1BAD86260B; Tue, 24 Jun 2003 22:20:13 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1262F62606 for ; Tue, 24 Jun 2003 22:20:11 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h5OKK1N05059; Tue, 24 Jun 2003 16:20:02 -0400 (EDT) Date: Tue, 24 Jun 2003 16:20:01 -0400 From: Keith Moore To: "Hallam-Baker, Phillip" Message-Id: <20030624162001.2f43efdf.moore@cs.utk.edu> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D2279@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D2279@mou1wnexm02.verisign.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: jseng@pobox.org.sg Cc: pbaker@verisign.com Cc: moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > At this point making noise about the failure of the IETF is > empirically more productive than actually participating in the broken > process. Phill, you should stop complaining about a lack of openness when you're deliberately making the process closed to you. From problem-statement-bounces@alvestrand.no Tue Jun 24 16:26:39 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06710 for ; Tue, 24 Jun 2003 15:37:48 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 742E5625F7; Tue, 24 Jun 2003 21:03:17 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id C0758625F6 for ; Tue, 24 Jun 2003 21:03:15 +0200 (CEST) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h5OJ3Dch019700; Tue, 24 Jun 2003 12:03:13 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 12:03:13 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D2275@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Keith Moore'" , "Hallam-Baker, Phillip" Date: Tue, 24 Jun 2003 12:03:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: problem-statement@alvestrand.no Subject: RE: Trusting the IESG to manage the reform process (was: Re: Doin g t he Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 did not say it was a question of age, it is a question of the inner circle membership having closed many years ago. > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Tuesday, June 24, 2003 2:33 PM > To: Hallam-Baker, Phillip > Cc: moore@cs.utk.edu; problem-statement@alvestrand.no > Subject: Re: Trusting the IESG to manage the reform process (was: Re: > Doing t he Right Things?) > > > > The simple fact is that no > > matter what anyone under 40 does in the IETF they are never going to > > get accepted into the inner circle. > > I was on IESG for four entire years before I turned 40. > Before that I > was a working group chair, and author of several RFCs. This > wasn't very > long ago. > > Keith > From problem-statement-bounces@alvestrand.no Tue Jun 24 16:46:33 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10486 for ; Tue, 24 Jun 2003 16:46:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B71E062606; Tue, 24 Jun 2003 22:46:02 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id B7349625FA for ; Tue, 24 Jun 2003 22:46:00 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h5OKjxch010314; Tue, 24 Jun 2003 13:45:59 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 13:45:59 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D227A@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Keith Moore'" , "Hallam-Baker, Phillip" Date: Tue, 24 Jun 2003 13:45:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: jseng@pobox.org.sg Cc: "Hallam-Baker, Phillip" Cc: problem-statement@alvestrand.no Subject: RE: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Keith, At what point do you believe I made the process closed? When the chair hissed at me the first time I spoke in a DNSEXT meeting? That is the point at which I formed the opinion the process was closed. Perhaps that may have affected my later actions. Maybee it was at the second DNSEXT meeting when I pointed out that the ability to deploy a DNS spec in dotCOM or the other large zones might be considered an important criteria? When the OPT-IN proposal was diverted into the 'DNS Directorate' and I complained that the process was not open? When the second last call went by with no objections and the chair decided that the fact I had been SILENT was now to be used against me? Bascially the whole process was a farce. People kept teling me be quiet, don't rock the boat. And every single time I took that advice it was immediately followed by a fresh abuse of process. What I should have done is to use the appeals process immediately following the DNS Directorate detour. Phill > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Tuesday, June 24, 2003 4:20 PM > To: Hallam-Baker, Phillip > Cc: moore@cs.utk.edu; jseng@pobox.org.sg; pbaker@verisign.com; > problem-statement@alvestrand.no > Subject: Re: "trouble maker" > > > > At this point making noise about the failure of the IETF is > > empirically more productive than actually participating in > the broken > > process. > > Phill, you should stop complaining about a lack of openness > when you're > deliberately making the process closed to you. > From problem-statement-bounces@alvestrand.no Tue Jun 24 18:07:48 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13428 for ; Tue, 24 Jun 2003 18:07:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 850D5625FD; Tue, 24 Jun 2003 23:30:28 +0200 (CEST) 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 0EB90625FA for ; Tue, 24 Jun 2003 23:30:26 +0200 (CEST) Received: (qmail 57151 invoked from network); 24 Jun 2003 21:37:29 -0000 Received: from unknown (HELO pobox.org.sg) (207.253.237.204) by sentosa.post1.com with SMTP; 24 Jun 2003 21:37:29 -0000 Message-ID: <3EF8C2F8.70209@pobox.org.sg> Date: Wed, 25 Jun 2003 05:30:32 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D2279@mou1wnexm02.verisign.com> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D2279@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'problem-statement@alvestrand.no'" Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Currently, I am involved in forming a TC in OASIS myself with the help of Patrick Gannon and Karl Best so I have went thru OASIS process in certain level of detail. (We going to have our first TC in Sept when Patrick coming to town). It is probably much similar to the W3C or Unicode Consortium with their paid memberships and voting rules. My other experiences in standard work are limited the Singapore IT Standard Council (I chaired the PKI WG here) and also JTC1/SC27 and SC2 where there are even more rules & procedures to follow. What I learn from these experiences is that every standard groups have different level of formality. The standardisation processes are also very different and more importantly, the behind-the-scene work to get your idea across also varies greatly. wg chair abuse? I seen it in IETF and I seen it in JTC1. But I also see successful work done by IETF and JTC1. So, I would hestiant to say this organisation is better then another. They are ..erm.. just different. But of all organisations I been involved so far, I enjoy IETF dynamic culture most. Good luck in OASIS...maybe we see each another there. -James Seng Hallam-Baker, Phillip wrote: > At this point making noise about the failure of the IETF is empirically more > productive than actually participating in the broken process. > > Serious standards work I take to OASIS, a democratic and genuinely open > forum. > > Up until now I have only been taking new XML-based specs there. From this > point on I intend to propose modifications to specifications that IETF > considers that it holds change control on in other forums. > > If the IETF wants to influence the future direction of Internet standards I > suggest that it consider dismantling the top-down organization and work out > ways in which it can live up to the claims it makes for openness, > inclusivity and accountability. > > > Phill > > >>-----Original Message----- >>From: James Seng [mailto:jseng@pobox.org.sg] >>Sent: Tuesday, June 24, 2003 3:59 PM >>To: Hallam-Baker, Phillip >>Cc: 'problem-statement@alvestrand.no' >>Subject: Re: "trouble maker" >> >> >>i see. >> >>i guess making noise about the "failure" of the IETF process is more >>productive then actually participating in the process. >> >>its your call. >> >>-James Seng >> >>Hallam-Baker, Phillip wrote: >> >>>Pure sophistry, the WG process failed because an individual >> >>was allowed to >> >>>abuse it for three years. The three years delay was the >> >>failure of the WG. >> >>>I want to see evidence the IETF is committed to reform and >> >>openness before >> >>>making any appeal. >>> >>> >>> Phill >>> >>> >>> >>>>-----Original Message----- >>>>From: James Seng [mailto:jseng@pobox.org.sg] >>>>Sent: Tuesday, June 24, 2003 3:32 PM >>>>To: Hallam-Baker, Phillip >>>>Cc: 'problem-statement@alvestrand.no' >>>>Subject: Re: "trouble maker" >>>> >>>> >>>>The appeal process is a very important aspect of the IETF WG >>>>process. It >>>>is the safe-guard and check-and-balance against the power of the wg >>>>chair. Without the appeal process, the WG process dont make sense. >>>> >>>>Hence, you cannot conclude the WG process dont work if you >>>>dont use the >>>>appeal process. >>>> >>>>This has nothing to do who is chairing or if the same person >>>>is on the >>>>IESG or IAB. >>>> >>>>-James Seng >>>> >>>>Hallam-Baker, Phillip wrote: >>>> >>>> >>>>>That is not the point I raised which was a failure of the >>>> >>>>IETF WG process, >>>> >>>> >>>>>not the appeals process. >>>>> >>>>>The fact that the same individual can abuse the original WG >>>> >>>>process and then >>>> >>>> >>>>>participate in the appeals process is relevant however. In >>>> >>>>fact it is even >>>> >>>> >>>>>possible in theory for a single individual to chair the >>>> >>>>original WG and >>>> >>>> >>>>>participate in both the original and IAB appeal if the >>>> >>>>IESG/IAB liason were >>>> >>>> >>>>>involved. >>>>> >>>>> Phill >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: James Seng [mailto:jseng@pobox.org.sg] >>>>>>Sent: Tuesday, June 24, 2003 3:10 PM >>>>>>To: Hallam-Baker, Phillip >>>>>>Cc: 'problem-statement@alvestrand.no' >>>>>>Subject: Re: "trouble maker" >>>>>> >>>>>> >>>>>>If you pursue the appeal process as documented in RFC >> >>2026 and you >> >>>>>>failed despite having all evidences that you should win, I >>>> >>>>will agree >>>> >>>> >>>>>>that you have a case to state this as a problem. >>>>>> >>>>>>But you choose not to use the process. And your decision to >>>> >>>>pursue an >>>> >>>> >>>>>>alternative appeal *does not* indicate a failure of the IETF >>>>>>appeal process. >>>>>> >>>>>>-James Seng >>>>> >>>>> >>>>> >>> > > From problem-statement-bounces@alvestrand.no Tue Jun 24 21:45:59 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02333 for ; Tue, 24 Jun 2003 21:45:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A6E7A62603; Wed, 25 Jun 2003 01:01:05 +0200 (CEST) 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 A2D3162600 for ; Wed, 25 Jun 2003 01:01:03 +0200 (CEST) Received: from employees.org (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 24 Jun 2003 16:04:12 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5ON0uR1002575 for ; Tue, 24 Jun 2003 16:01:00 -0700 (PDT) Received: from cisco.com (sjc-vpn3-383.cisco.com [10.21.65.127]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AHL10823; Tue, 24 Jun 2003 15:54:57 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Tue, 24 Jun 2003 19:00:52 -0400 Date: Tue, 24 Jun 2003 19:00:52 -0400 From: Scott W Brim To: "'problem-statement@alvestrand.no'" Message-ID: <20030624230052.GH1748@sbrim-w2k01> Mail-Followup-To: Scott W Brim , "'problem-statement@alvestrand.no'" References: <2A1D4C86842EE14CA9BC80474919782E0D2266@mou1wnexm02.verisign.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Subject: Re: Trusting the IESG to manage the reform process (was: Re: Doing t he Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Tue, Jun 24, 2003 09:53:39AM -0700, hardie@qualcomm.com allegedly wrote: > There is a real, fundamental question raised by organizational work > (the Tipping Point and its more scholarly colleagues)--whether any > effort that relies on building networks of this type (formal or > informal) can grow past a certain point. I believe it can if it > relies on overlapping networks rather than networks with a single > focus and if it blends some formalism with the informal networks. > But, clearly, there are other ways forward; they may be better. This > is simply my view. Also stability of the group is a factor. The less churn there is the larger it can grow and function. (As in our case) as a group gets larger and more fragile the stable relationships become more pivotal. From problem-statement-bounces@alvestrand.no Wed Jun 25 10:31:07 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11967 for ; Wed, 25 Jun 2003 10:31:06 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1411F622AF; Wed, 25 Jun 2003 16:07:53 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4849B62251 for ; Wed, 25 Jun 2003 16:07:51 +0200 (CEST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5PE7nDG285174; Wed, 25 Jun 2003 10:07:49 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-234-252.mts.ibm.com [9.65.234.252])h5PE7mpo090528; Wed, 25 Jun 2003 08:07:49 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h5PE6mA21266; Wed, 25 Jun 2003 10:06:49 -0400 Message-Id: <200306251406.h5PE6mA21266@cichlid.adsl.duke.edu> To: "Hallam-Baker, Phillip" In-Reply-To: Message from pbaker@verisign.com <2A1D4C86842EE14CA9BC80474919782E0D226B@mou1wnexm02.verisign.com> Date: Wed, 25 Jun 2003 10:06:48 -0400 From: Thomas Narten Cc: problem-statement@alvestrand.no Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 "Hallam-Baker, Phillip" writes: > But there was consensus in favor of OPT IN, the chair decided to abuse his > position and ignore it subsituting his own opinion. Read the WG mailing > lists. Yes, everyone should read the mailing list and form their own opinion. > There was a last call, 12 people were in favor, 2 opposed outright, 7 were > not in favor but prepared to accept the proposal. I note that you choose to interpret the 7, as the same as supporting, or not actually being opposed. That is not consistent with what those 7 actually said, as they actually did say no. That results in a rather different picture. > Actually there were in total four last calls. Basically the Chair's > strategy was to keep asking the question until he could pretend the > result was in his favor. Again, your interpretation of motive. It is not uncommon to have multiple LCs on the same document, to make sure that it has recieved adequate review and all the bugs are worked out. The ADs supported the chairs on this. At the end of the process, the WG agreed that the technical issues had been worked out and were understood, but there was still no consensus with going forward with the solution. Thomas From problem-statement-bounces@alvestrand.no Wed Jun 25 10:59:20 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13510 for ; Wed, 25 Jun 2003 10:59:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D98686230D; Wed, 25 Jun 2003 16:58:49 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 32D2D622AF for ; Wed, 25 Jun 2003 16:58:48 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h5PEwkch004590; Wed, 25 Jun 2003 07:58:46 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 07:58:46 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D2280@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Thomas Narten'" , "Hallam-Baker, Phillip" Date: Wed, 25 Jun 2003 07:58:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: problem-statement@alvestrand.no Subject: RE: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Count the votes as 12:2 or 12:9 there was a clear majority for OPT in and the 7 who said no but were willing to stand asside for the sake of forward progress. However you count them a clear majority of the group believes that the DNSSEC specs as currently defined are broken and are in need of fixing. Why then are ANY drafts being forwarded to the IESG? Ah that is because the establishment gets to choose what consensus is and what consensus means. So a majority of the group believing that the spec is undeployable does not matter because we the establishment get to choose the questions that are asked. The more salient point was the who was in the 12 and who was in the 9 and the points being raised. The 12 people were representing[*] mostly the large registries such as dotCOM and dotDE and the software writers. Who did the 2 or 9 represent? Mostly themselves. So we have a situation where a minority can hold up a standard, if that is the establishment chooses to endorse them. This 'consensus' simply a con game that allows the establishment to ignore any decisions of the group they dislike and act whatever sweet way they please and cite 'consensus' as the reason. If the establishment want to they can interpret the WG outcome as consensus. Forgive me if I decide not to respect decisions arrived at in that manner as 'standards'. [*]Yes I know the B/S theory that only the establishment gets to speak from authority but that is the whole IETF problem. A bunch of unelected cronies can speak with the authority of their lofty perches while denying everyone else the authority that comes from the responsibility of their profession. That is a very convenient little fiction for the establishment. Given the massive conflict of interest the IETF now has on everything DNS by the ISOC having decided to become a DNS registrar competitor, the lack of accountability is a significant issue. Phill > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Wednesday, June 25, 2003 10:07 AM > To: Hallam-Baker, Phillip > Cc: problem-statement@alvestrand.no > Subject: Re: "trouble maker" > > > "Hallam-Baker, Phillip" writes: > > > But there was consensus in favor of OPT IN, the chair > decided to abuse his > > position and ignore it subsituting his own opinion. Read > the WG mailing > > lists. > > Yes, everyone should read the mailing list and form their own opinion. > > > There was a last call, 12 people were in favor, 2 opposed > outright, 7 were > > not in favor but prepared to accept the proposal. > > I note that you choose to interpret the 7, as the same as supporting, > or not actually being opposed. That is not consistent with what those > 7 actually said, as they actually did say no. That results in a rather > different picture. > > > Actually there were in total four last calls. Basically the Chair's > > strategy was to keep asking the question until he could pretend the > > result was in his favor. > > Again, your interpretation of motive. It is not uncommon to have > multiple LCs on the same document, to make sure that it has recieved > adequate review and all the bugs are worked out. The ADs supported the > chairs on this. At the end of the process, the WG agreed that the > technical issues had been worked out and were understood, but there > was still no consensus with going forward with the solution. > > Thomas > From problem-statement-bounces@alvestrand.no Wed Jun 25 12:46:25 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20884 for ; Wed, 25 Jun 2003 12:46:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5D5786256B; Wed, 25 Jun 2003 18:45:55 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id A6AA16238A for ; Wed, 25 Jun 2003 18:45:48 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h5PGjlch000517; Wed, 25 Jun 2003 09:45:47 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 09:45:47 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D2284@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Thomas Narten'" , "Hallam-Baker, Phillip" Date: Wed, 25 Jun 2003 09:45:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: problem-statement@alvestrand.no Subject: Accountability X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Not a single one of those objectors saw fit to raise an objection at last call number 2 six months earlier. So it seems unlikely that the objections were particularly deep seated. The issue is here is not the specific blatant abuses that you allowed the DNSEXT chair to commit. The issue here is PROBLEM. The issue is that chairs are imposed from above by the establishment and are not answerable to the WGs or any decisions they make. The DNSEXT history illustrates the point, but it is far from an isolated example. And yes, there can be a reasonable explanation for individual events, but the series adds up to abuse and manipulation that is indefensible. Slice it how you like, I have no confidence in the IETF process. I have significant influence in the industry and I am going to keep on using this example time after time to steer standards efforts away from the IETF. If anyone from the press asks why a modification to SMTP or BGP is being proposed in a different forum I am going to return to that example. I note that when I cited IETF, OASIS and W3C as possible venues for a standard that I have been working on it was an IBM employee who asked "IETF - are you joking?" The IETF does not at this point have a good reputation in the industry (and here I am including Open Source efforts in the definition of industry). Almost everyone accepts that it is too slow to react and that its processes have little relevance to real world problems. More importantly IETF endorsement is not considered to be either a necessary or sufficient condition to achieve widespread industry support for a protocol. If you want to re-establish the reputation that the IETF once had it will be necessary to do much more than simply tweak a few processes. Unless there is accountability to the grass roots, genuine openness and genuine inclusiveness the IETF will continue to manage an ever dwindling set of specs that people don't care about enough to take to other forums. Decisions made by closed directorates that refuse to allow interested parties to join are simply not open by any definition. The IETF is no longer the only game in town. Instead of examining your own navel why not look at some of the other standards group processes that are working? Phill > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Wednesday, June 25, 2003 10:07 AM > To: Hallam-Baker, Phillip > Cc: problem-statement@alvestrand.no > Subject: Re: "trouble maker" > > > "Hallam-Baker, Phillip" writes: > > > But there was consensus in favor of OPT IN, the chair > decided to abuse his > > position and ignore it subsituting his own opinion. Read > the WG mailing > > lists. > > Yes, everyone should read the mailing list and form their own opinion. > > > There was a last call, 12 people were in favor, 2 opposed > outright, 7 were > > not in favor but prepared to accept the proposal. > > I note that you choose to interpret the 7, as the same as supporting, > or not actually being opposed. That is not consistent with what those > 7 actually said, as they actually did say no. That results in a rather > different picture. > > > Actually there were in total four last calls. Basically the Chair's > > strategy was to keep asking the question until he could pretend the > > result was in his favor. > > Again, your interpretation of motive. It is not uncommon to have > multiple LCs on the same document, to make sure that it has recieved > adequate review and all the bugs are worked out. The ADs supported the > chairs on this. At the end of the process, the WG agreed that the > technical issues had been worked out and were understood, but there > was still no consensus with going forward with the solution. > > Thomas > From problem-statement-bounces@alvestrand.no Wed Jun 25 14:12:13 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23516 for ; Wed, 25 Jun 2003 14:12:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A67216256B; Wed, 25 Jun 2003 20:10:59 +0200 (CEST) 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 ABDC46238A for ; Wed, 25 Jun 2003 20:10:56 +0200 (CEST) Received: (qmail 74520 invoked from network); 25 Jun 2003 18:17:53 -0000 Received: from unknown (HELO pobox.org.sg) (207.253.237.204) by sentosa.post1.com with SMTP; 25 Jun 2003 18:17:53 -0000 Message-ID: <3EF9E5B5.1090706@pobox.org.sg> Date: Thu, 26 Jun 2003 02:11:01 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D2280@mou1wnexm02.verisign.com> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D2280@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Thomas Narten'" Cc: problem-statement@alvestrand.no Subject: rough consensus (was Re: "trouble maker") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Maybe lets put this particular case aside and look at the more general problem: "What is rough consensus?" How rough is "rough"? Unfortunately, this was not particular well-defined even tho it is one of our core principle. Could we tag this as a problem in the problem-statement? I remember I asked this questions before when I am a newbie in IETF. The general answer of "rough consensus" are super-super majority. The general figure is >75%-80% but bear in mind that we dont "vote", absolute figures isnt the way to go. We also need to take those who are "neutral" into considering as "neutral but wont object" and "no but wont object strongly" are important swing factor. If we can get a rough consensus on what is "rough consensus", then perhaps we could avoid a lot of misunderstanding. -James Seng Hallam-Baker, Phillip wrote: > Count the votes as 12:2 or 12:9 there was a clear majority for OPT in and > the 7 who said no but were willing to stand asside for the sake of forward > progress. > > However you count them a clear majority of the group believes that the > DNSSEC specs as currently defined are broken and are in need of fixing. Why > then are ANY drafts being forwarded to the IESG? From problem-statement-bounces@alvestrand.no Wed Jun 25 14:31:55 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24297 for ; Wed, 25 Jun 2003 14:31:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8FF586256F; Wed, 25 Jun 2003 20:31:24 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7B1E46256C for ; Wed, 25 Jun 2003 20:31:22 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h5PIVLch024798; Wed, 25 Jun 2003 11:31:21 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 11:31:21 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D2289@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'James Seng'" , "Hallam-Baker, Phillip" Date: Wed, 25 Jun 2003 11:31:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: "'Thomas Narten'" Cc: problem-statement@alvestrand.no Subject: RE: rough consensus (was Re: "trouble maker") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 think it also depends on what the stake the parties have. If we have 20 people vote on an issue (lets call things by their names eh? it is still a vote even if the supreme court decides not to count it). Say people object because they want the spec to require implementations to use some proprietary IP they own. Pretty easy call, could be 5 objectors or 15 there is something going on here that is an IETF-wide issue. Say on the other hand you have an issue that is hard to implement. In that case 5 objections from non-developers might carry much less weight than 5 from developers. Or say again that you have a case where cost is involved. Objections from five people who are unaffected by the cost issue might carry much less weight than five objections from people directly affected. But of course, nobody represents anything, nobody can speak from authority except those the establishment choose to recognize. So we are back to raw numbers. Going back to my case study (yes facts are sometimes unplesant things) the objections to the spec did not come from people with a stake in the outcome - except for those who had stated their objections were explicitly political and wanted to use DNSSEC to force some sort of change in the ICANN contracts. So what does the consensus process do except create inbuilt vetos in favor of the status quo? The fact that a spec has been undeployable for ten years is in my view and that of most software vendors a comment on its quality. As I said to Keith in private email, what you are doing here is projecting on a massive scale. You are affraid that the big corporations will dominate the process so you have rigged the rules so that they have zero influence - even though you depend on their market influence to propagate standards. Now you are surprised that we are abandoning the IETF in droves? Compare the decline in IETF attendance with the rise in OASIS participation. If the reason was the post dotcom boom recession then OASIS should have been affected at least as baddly as IETF. Contrary to the paranoid assumptions that many in this group appear to act on corporations do not in general want to exclude the academic and individual contributors from the standards process. But the way the IETF rules are being applied are leaving little choice in the matter. Phill > -----Original Message----- > From: James Seng [mailto:jseng@pobox.org.sg] > Sent: Wednesday, June 25, 2003 2:11 PM > To: Hallam-Baker, Phillip > Cc: 'Thomas Narten'; problem-statement@alvestrand.no > Subject: rough consensus (was Re: "trouble maker") > > > Maybe lets put this particular case aside and look at the > more general > problem: > > "What is rough consensus?" How rough is "rough"? > > Unfortunately, this was not particular well-defined even tho > it is one > of our core principle. Could we tag this as a problem in the > problem-statement? > > I remember I asked this questions before when I am a newbie > in IETF. The > general answer of "rough consensus" are super-super majority. > > The general figure is >75%-80% but bear in mind that we dont "vote", > absolute figures isnt the way to go. We also need to take > those who are > "neutral" into considering as "neutral but wont object" and > "no but wont > object strongly" are important swing factor. > > If we can get a rough consensus on what is "rough consensus", then > perhaps we could avoid a lot of misunderstanding. > > -James Seng > > Hallam-Baker, Phillip wrote: > > Count the votes as 12:2 or 12:9 there was a clear majority > for OPT in and > > the 7 who said no but were willing to stand asside for the > sake of forward > > progress. > > > > However you count them a clear majority of the group > believes that the > > DNSSEC specs as currently defined are broken and are in > need of fixing. Why > > then are ANY drafts being forwarded to the IESG? > From problem-statement-bounces@alvestrand.no Wed Jun 25 15:27:57 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27413 for ; Wed, 25 Jun 2003 15:27:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 854C96256B; Wed, 25 Jun 2003 21:27:26 +0200 (CEST) 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 B6CA46256B for ; Wed, 25 Jun 2003 21:27:24 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h5PJUbF23056; Wed, 25 Jun 2003 12:30:37 -0700 Date: Wed, 25 Jun 2003 12:27:10 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/11) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <160140295934.20030625122710@brandenburg.com> To: James Seng In-Reply-To: <3EF9E5B5.1090706@pobox.org.sg> References: <2A1D4C86842EE14CA9BC80474919782E0D2280@mou1wnexm02.verisign.com> <3EF9E5B5.1090706@pobox.org.sg> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: base64 Cc: problem-statement@alvestrand.no Subject: Re: rough consensus (was Re: "trouble maker") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: base64 SmFtZXMsDQoNCkpTPiAiV2hhdCBpcyByb3VnaCBjb25zZW5zdXM/IiBIb3cgcm91Z2ggaXMg InJvdWdoIj8NCg0KSlM+IFVuZm9ydHVuYXRlbHksIHRoaXMgd2FzIG5vdCBwYXJ0aWN1bGFy IHdlbGwtZGVmaW5lZCBldmVuIHRobyBpdCBpcyBvbmUNCi4uLg0KSlM+IGdlbmVyYWwgYW5z d2VyIG9mICJyb3VnaCBjb25zZW5zdXMiIGFyZSBzdXBlci1zdXBlciBtYWpvcml0eS4NCi4u Lg0KSlM+IFRoZSBnZW5lcmFsIGZpZ3VyZSBpcyA+NzUlLTgwJSBidXQgYmVhciBpbiBtaW5k IHRoYXQgd2UgZG9udCAidm90ZSIsDQoNCg0KRnJvbSBSRkMgMjQxOCwgSUVURiBXb3JraW5n IEdyb3VwIEd1aWRlbGluZXMgYW5kIFByb2NlZHVyZXM6DQoNCiAgIDMuMy4gU2Vzc2lvbiBt YW5hZ2VtZW50DQoNCiAgIFdvcmtpbmcgZ3JvdXBzIG1ha2UgZGVjaXNpb25zIHRocm91Z2gg YSAicm91Z2ggY29uc2Vuc3VzIiBwcm9jZXNzLg0KICAgSUVURiBjb25zZW5zdXMgZG9lcyBu b3QgcmVxdWlyZSB0aGF0IGFsbCBwYXJ0aWNpcGFudHMgYWdyZWUgYWx0aG91Z2gNCiAgIHRo aXMgaXMsIG9mIGNvdXJzZSwgcHJlZmVycmVkLiAgSW4gZ2VuZXJhbCwgdGhlIGRvbWluYW50 IHZpZXcgb2YgdGhlDQogICB3b3JraW5nIGdyb3VwIHNoYWxsIHByZXZhaWwuICAoSG93ZXZl ciwgaXQgbXVzdCBiZSBub3RlZCB0aGF0DQogICAiZG9taW5hbmNlIiBpcyBub3QgdG8gYmUg ZGV0ZXJtaW5lZCBvbiB0aGUgYmFzaXMgb2Ygdm9sdW1lIG9yDQogICBwZXJzaXN0ZW5jZSwg YnV0IHJhdGhlciBhIG1vcmUgZ2VuZXJhbCBzZW5zZSBvZiBhZ3JlZW1lbnQuKSBDb25zZW5z dXMNCiAgIGNhbiBiZSBkZXRlcm1pbmVkIGJ5IGEgc2hvdyBvZiBoYW5kcywgaHVtbWluZywg b3IgYW55IG90aGVyIG1lYW5zIG9uDQogICB3aGljaCB0aGUgV0cgYWdyZWVzIChieSByb3Vn aCBjb25zZW5zdXMsIG9mIGNvdXJzZSkuICBOb3RlIHRoYXQgNTElDQogICBvZiB0aGUgd29y a2luZyBncm91cCBkb2VzIG5vdCBxdWFsaWZ5IGFzICJyb3VnaCBjb25zZW5zdXMiIGFuZCA5 OSUgaXMNCiAgIGJldHRlciB0aGFuIHJvdWdoLiAgSXQgaXMgdXAgdG8gdGhlIENoYWlyIHRv IGRldGVybWluZSBpZiByb3VnaA0KICAgY29uc2Vuc3VzIGhhcyBiZWVuIHJlYWNoZWQuDQoN ClRoZSByZXN0IG9mIHRoYXQgc3ViLXNlY3Rpb24gaGFzIHVzZWZ1bCBkaXNjdXNzaW9uIGFi b3V0IHRoZSBwcmFnbWF0aWMNCmFzcGVjdHMgb2YgYXNzZXNzaW5nIHJvdWdoIGNvbnNlbnN1 cy4NCg0KV2hpbGUgdGhlIGRlZmluaXRpb24gb2Ygcm91Z2ggY29uc2Vuc3VzIGlzIG5vdCBt YXRoZW1hdGljYWwsIEkgYmVsaWV2ZQ0KaXQgYWN0dWFsbHkgaXMgcHJldHR5IGNsZWFyOg0K DQpJZiB3ZSBjYW4gdGVsbCB3aGF0IHRoZSAiZG9taW5hbnQiIHZpZXcgb2YgdGhlIGdyb3Vw IGlzLCB0aGVuIHRoZXJlIGlzDQpyb3VnaCBjb25zZW5zdXMuDQoNClJlZmVyZW5jZXMgdG8g c3VwZXItc3VwZXIgbWFqb3JpdGllcyBhbmQgbnVtYmVycyBsaWtlIDc1JSBhcmUgbWVyZWx5 DQp3YXlzIG9mIHN1Z2dlc3Rpbmcgd2hhdCBpdCB0YWtlcyB0byBtYWtlIGEgZG9taW5hbnQg dmlldyBjbGVhciB3aXRob3V0DQpoYXZpbmcgZm9ybWFsIG1lYXN1cmVtZW50IG1ldGhvZG9s b2dpZXMuDQoNClRoZSBuYXR1cmUgb2YgdGhlIHJvdWdoIGNvbnNlbnN1cyBhcHByb2FjaCB0 byBkZWNpc2lvbi1tYWtpbmcgaXMgbm90DQpqdXN0IHRoYXQgd2UgZG9uJ3QgaGF2ZSBtZW1i ZXJzaGlwLiBJdCBpcyByZWNvZ25pdGlvbiB0aGF0IG1hdGhlbWF0aWNhbA0KbWFqb3JpdHkg ZG9lc24ndCBtZWFuIG11Y2ggaWYgdGhlcmUgaXMgaW5hZGVxdWF0ZSBjb21tdW5pdHkgc3Vw cG9ydCBmb3INCmEgZGVjaXNpb24uDQoNCklmIHRoZXJlIGlzIHJvdWdoIGNvbnNlbnN1cywg dGhlbiB0aGVyZSBpcyAqY2xlYXIqIGNvbW11bml0eSBzdXBwb3J0IGZvcg0KdGhlIGRlY2lz aW9uLiBFdmVuIGlmIHRoZXJlIGlzIGEgdmlnb3JvdXMgbWlub3JpdHkgY2FsbGluZyBmb3Ig YQ0KZGlmZmVyZW50IG91dGNvbWUsIG91ciBiZWluZyBhYmxlIHRvIHNlZSB0aGF0IHRoZXJl IGlzIGEgcm91Z2ggY29uc2Vuc3VzDQoqaW4gZmF2b3IqIG9mIHRoZSBkZWNpc2lvbiBnaXZl cyB1cyBzb21lIGhvcGUgdGhhdCB0aGUgZGVjaXNpb24gd2lsbA0KbWVhbiBmb3J3YXJkIHBy b2dyZXNzIGFuZCBjb21tdW5pdHkgKnVzZSogb2YgdGhlIGRlY2lzaW9uLg0KDQpPZiBjb3Vy c2UsIHJvdWdoIGNvbnNlbnN1cyBkb2VzIG5vdCBtZWFuIG11Y2ggaWYgdGhlcmUgaXMgbm8g b25lDQpwYXJ0aWNpcGF0aW5nLiAgNzUlIG9mIDYgcGVvcGxlIGlzIG5vdCBnb2luZyB0byBt ZWFuIG11Y2ggYWJvdXQNCmNvbW11bml0eSB1c2UuDQoNCmQvDQotLQ0KIERhdmUgQ3JvY2tl ciA8bWFpbHRvOmRjcm9ja2VyQGJyYW5kZW5idXJnLmNvbT4NCiBCcmFuZGVuYnVyZyBJbnRl cm5ldFdvcmtpbmcgPGh0dHA6Ly93d3cuYnJhbmRlbmJ1cmcuY29tPg0KIFN1bm55dmFsZSwg Q0EgIFVTQSA8dGVsOisxLjQwOC4yNDYuODI1Mz4sIDxmYXg6KzEuODY2LjM1OC41MzAxPg0K From problem-statement-bounces@alvestrand.no Wed Jun 25 15:45:35 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28262 for ; Wed, 25 Jun 2003 15:45:34 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4C43A62577; Wed, 25 Jun 2003 21:45:05 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id B1DBF62573 for ; Wed, 25 Jun 2003 21:45:03 +0200 (CEST) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h5PJj2ch014491; Wed, 25 Jun 2003 12:45:02 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 12:45:02 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D228B@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'James Seng'" , "Hallam-Baker, Phillip" Date: Wed, 25 Jun 2003 12:44:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: "'Thomas Narten'" Cc: problem-statement@alvestrand.no Subject: RE: rough consensus (was Re: "trouble maker") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > But please spare a thought for the wg chairs too. They are in > this "damn if you do, damn if you dont" position... The chair was the person who created the situation. There would have been no debate at all if he had not manipulated the process repeatedly. If the chair in question had not also been on the IESG I suspect that he would not have been allowed to behave in the partisan manner he did. IETF - not open, not inclusive, not relevant. Phill From problem-statement-bounces@alvestrand.no Wed Jun 25 16:04:29 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29217 for ; Wed, 25 Jun 2003 16:04:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4C7C96256C; Wed, 25 Jun 2003 21:34:59 +0200 (CEST) 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 402EC6256B for ; Wed, 25 Jun 2003 21:34:56 +0200 (CEST) Received: (qmail 75284 invoked from network); 25 Jun 2003 19:41:55 -0000 Received: from unknown (HELO pobox.org.sg) (207.253.237.204) by sentosa.post1.com with SMTP; 25 Jun 2003 19:41:55 -0000 Message-ID: <3EF9F968.7090903@pobox.org.sg> Date: Thu, 26 Jun 2003 03:35:04 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D2289@mou1wnexm02.verisign.com> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D2289@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Thomas Narten'" Cc: problem-statement@alvestrand.no Subject: Re: rough consensus (was Re: "trouble maker") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 While we dont have the concept of "stakeholder", we have a concept of "running code". This is another swing factor in the consideration of "rough consensus". Someone also reminded me that sometimes you need as high as 95% for rough consensus and sometimes as low as 65%, varies according to the topic and the situation. So really, there is no any fixed methodology in determine rough consensus and the current process leave it to the wg chairs to determine "rough consensus". To balance this power, the appeal process was there to catch the exception case. Since everyone has their own interpretion of what is "rough consensus", I can understand the resentment for those who lost out. And the wg chairs is in this unfortunate position of been the center of this resentment. But please spare a thought for the wg chairs too. They are in this "damn if you do, damn if you dont" position... -James Seng Hallam-Baker, Phillip wrote: > I think it also depends on what the stake the parties have. > > If we have 20 people vote on an issue (lets call things by their names eh? > it is still a vote even if the supreme court decides not to count it). > > > Say people object because they want the spec to require implementations to > use some proprietary IP they own. Pretty easy call, could be 5 objectors or > 15 there is something going on here that is an IETF-wide issue. > > Say on the other hand you have an issue that is hard to implement. In that > case 5 objections from non-developers might carry much less weight than 5 > from developers. > > Or say again that you have a case where cost is involved. Objections from > five people who are unaffected by the cost issue might carry much less > weight than five objections from people directly affected. > > > But of course, nobody represents anything, nobody can speak from authority > except those the establishment choose to recognize. So we are back to raw > numbers. > > Going back to my case study (yes facts are sometimes unplesant things) the > objections to the spec did not come from people with a stake in the outcome > - except for those who had stated their objections were explicitly political > and wanted to use DNSSEC to force some sort of change in the ICANN > contracts. > > > So what does the consensus process do except create inbuilt vetos in favor > of the status quo? > > The fact that a spec has been undeployable for ten years is in my view and > that of most software vendors a comment on its quality. > > > As I said to Keith in private email, what you are doing here is projecting > on a massive scale. You are affraid that the big corporations will dominate > the process so you have rigged the rules so that they have zero influence - > even though you depend on their market influence to propagate standards. Now > you are surprised that we are abandoning the IETF in droves? > > Compare the decline in IETF attendance with the rise in OASIS participation. > If the reason was the post dotcom boom recession then OASIS should have been > affected at least as baddly as IETF. > > Contrary to the paranoid assumptions that many in this group appear to act > on corporations do not in general want to exclude the academic and > individual contributors from the standards process. But the way the IETF > rules are being applied are leaving little choice in the matter. > > > Phill > > >>-----Original Message----- >>From: James Seng [mailto:jseng@pobox.org.sg] >>Sent: Wednesday, June 25, 2003 2:11 PM >>To: Hallam-Baker, Phillip >>Cc: 'Thomas Narten'; problem-statement@alvestrand.no >>Subject: rough consensus (was Re: "trouble maker") >> >> >>Maybe lets put this particular case aside and look at the >>more general >>problem: >> >>"What is rough consensus?" How rough is "rough"? >> >>Unfortunately, this was not particular well-defined even tho >>it is one >>of our core principle. Could we tag this as a problem in the >>problem-statement? >> >>I remember I asked this questions before when I am a newbie >>in IETF. The >>general answer of "rough consensus" are super-super majority. >> >>The general figure is >75%-80% but bear in mind that we dont "vote", >>absolute figures isnt the way to go. We also need to take >>those who are >>"neutral" into considering as "neutral but wont object" and >>"no but wont >>object strongly" are important swing factor. >> >>If we can get a rough consensus on what is "rough consensus", then >>perhaps we could avoid a lot of misunderstanding. >> >>-James Seng >> >>Hallam-Baker, Phillip wrote: >> >>>Count the votes as 12:2 or 12:9 there was a clear majority >> >>for OPT in and >> >>>the 7 who said no but were willing to stand asside for the >> >>sake of forward >> >>>progress. >>> >>>However you count them a clear majority of the group >> >>believes that the >> >>>DNSSEC specs as currently defined are broken and are in >> >>need of fixing. Why >> >>>then are ANY drafts being forwarded to the IESG? >> > > From problem-statement-bounces@alvestrand.no Wed Jun 25 16:22:26 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00246 for ; Wed, 25 Jun 2003 16:22:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 19BB962573; Wed, 25 Jun 2003 22:21:56 +0200 (CEST) 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 CE0CA6256B for ; Wed, 25 Jun 2003 22:21:53 +0200 (CEST) Received: from cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 25 Jun 2003 13:23:41 -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 h5PKLpgE007691; Wed, 25 Jun 2003 13:21:51 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIV08578; Wed, 25 Jun 2003 13:21:49 -0700 (PDT) Message-Id: <200306252021.AIV08578@mira-sjc5-c.cisco.com> To: James Seng From: Melinda Shore In-Reply-To: Message from jseng@pobox.org.sg of "Thu, 26 Jun 2003 03:35:04 +0800." <3EF9F968.7090903@pobox.org.sg> Date: Wed, 25 Jun 2003 16:21:49 -0400 Cc: problem-statement@alvestrand.no Subject: Re: rough consensus (was Re: "trouble maker") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > Someone also reminded me that sometimes you need as high as 95% for > rough consensus and sometimes as low as 65%, varies according to the > topic and the situation. When you frame the question of "rough consensus" in terms of percentages you're actually framing it in terms of voting, which we don't do for a number of reasons. "Consensus" is really about the process of arriving at decisions rather than the decisions themselves - making sure that all voices are heard and respected, and that what you're doing is synthesizing information rather than selecting from available options. By choosing "rough consensus" we're providing ourselves some protection, in theory, against holdouts. We do consensus *incredibly* badly. One of the primary reasons is that it requires commitment to the process itself - to negotiation, compromise, and a willingness to accept and move forward with the outcome of the process. All too often we lack that commitment and it's causing some big process problems, including the "obstructive individual" problem that you've raised. Melinda From problem-statement-bounces@alvestrand.no Wed Jun 25 17:03:46 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02319 for ; Wed, 25 Jun 2003 17:03:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9918C6256B; Wed, 25 Jun 2003 23:03:16 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by eikenes.alvestrand.no (Postfix) with ESMTP id CEC5F6238A for ; Wed, 25 Jun 2003 23:03:15 +0200 (CEST) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196])h5PL2SMk054464; Wed, 25 Jun 2003 23:02:49 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])h5PL1wwl239134; Wed, 25 Jun 2003 23:02:08 +0200 Received: from gsine04.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA29062 from ; Wed, 25 Jun 2003 23:01:55 +0200 Message-Id: <3EFA0DD3.FB2E4037@hursley.ibm.com> Date: Wed, 25 Jun 2003 23:02:11 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Basavaraj.Patil@nokia.com References: <697DAA22C5004B4596E033803A7CEF44024DB2B2@daebe007.americas.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Basavaraj.Patil@nokia.com wrote: ... > As in any organization there needs to be a system of checks and > balances. At this time there does not seem to be any such for the > power of the IESG. I don't think that's true. There are at least 4 "features" of the IETF proces that act as checks and balances on the IESG: 1. The IAB as an advisory board for WG formation (and in practice for many major IESG decisions) 2. The appeals process 3. The recall process (never tested, for some reason) 4. Payback time, i.e. the NomCom process. Now, it's possible we need *more* checks and balances, of course. Brian From problem-statement-bounces@alvestrand.no Wed Jun 25 17:11:07 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03168 for ; Wed, 25 Jun 2003 17:11:06 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E279F62573; Wed, 25 Jun 2003 22:44:58 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by eikenes.alvestrand.no (Postfix) with ESMTP id B11B56238A for ; Wed, 25 Jun 2003 22:44:57 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180])h5PKiEMk017310; Wed, 25 Jun 2003 22:44:34 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])h5PKhhW0233454; Wed, 25 Jun 2003 22:43:53 +0200 Received: from gsine04.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA26756 from ; Wed, 25 Jun 2003 22:43:39 +0200 Message-Id: <3EFA098C.310266C0@hursley.ibm.com> Date: Wed, 25 Jun 2003 22:43:56 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D228B@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: rough consensus (was Re: "trouble maker") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Phill, you seem to be extrapolating from one case to a general statement that many of us would disagree with. In terms of the general determination of rough consensus, I would add to the definition in 2418, which is entirely workable in my experience, that if 20 people "vote" the same way, but the WG chair knows that they all work for the same organization or for associated organizations, those 20 "votes" are likely to be heavily discounted in evaluating the RFC 2418 criteria. That's why we give discretion to the WG chairs, and it's because we give them discretion that there is an appeal mechanism *which no AD can block*. Brian "Hallam-Baker, Phillip" wrote: > > > But please spare a thought for the wg chairs too. They are in > > this "damn if you do, damn if you dont" position... > > The chair was the person who created the situation. There would > have been no debate at all if he had not manipulated the process > repeatedly. > > If the chair in question had not also been on the IESG I suspect > that he would not have been allowed to behave in the partisan > manner he did. > > IETF - not open, not inclusive, not relevant. > > Phill From problem-statement-bounces@alvestrand.no Wed Jun 25 17:12:52 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03337 for ; Wed, 25 Jun 2003 17:12:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2925B6257C; Wed, 25 Jun 2003 23:12:22 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by eikenes.alvestrand.no (Postfix) with ESMTP id DE5B86238A for ; Wed, 25 Jun 2003 23:12:19 +0200 (CEST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) h5PLCGBd018610 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 25 Jun 2003 14:12:16 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) h5PLCDix009623; Wed, 25 Jun 2003 14:12:14 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <200306252021.AIV08578@mira-sjc5-c.cisco.com> References: <200306252021.AIV08578@mira-sjc5-c.cisco.com> Date: Wed, 25 Jun 2003 14:12:12 -0700 To: Melinda Shore , James Seng From: hardie@qualcomm.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: problem-statement@alvestrand.no Subject: Re: rough consensus (was Re: "trouble maker") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 At 4:21 PM -0400 6/25/03, Melinda Shore wrote: > > Someone also reminded me that sometimes you need as high as 95% for >> rough consensus and sometimes as low as 65%, varies according to the >> topic and the situation. > >When you frame the question of "rough consensus" in terms of >percentages you're actually framing it in terms of voting, >which we don't do for a number of reasons. "Consensus" is >really about the process of arriving at decisions rather >than the decisions themselves - making sure that all voices >are heard and respected, and that what you're doing is >synthesizing information rather than selecting from >available options. By choosing "rough consensus" we're >providing ourselves some protection, in theory, against >holdouts. I tried to cover some of the same points in draft-hardie-alt-consensus-00.txt, which uses steals this text to describe some of the problems using consensus in our context: > >The Conflict Research Consortium at the University of Colorado >outlines the pros and cons of consensus as: > > The advantage of consensus processes is that the resulting > decision is one that meets the interests of all the parties > and that everyone can support. The disadvantage is that > developing such a decision can be a very slow process, > involving many people over a long period of time. There is > also a relatively high probability of failure. If a quick > decision is needed, the consensus approach may not work. > Consensus rule processes also tend to favor those that oppose > change and want to preserve the status quo. All these people > have to do is refuse to support any consensus compromises and > they will win (at least as long as they can delay > change). (CONFLICT) I then tried to capture some of the differences between rough consensus and consensus > > Using "rough consensus" as a guideline limits some of > disadvantages of consensus processes by ensuring that individuals > or small factions cannot easily block a decision which has > otherwise general support. The second touchstone of "running > code" can also limit the disadvantages of consensus processes by > requiring that statements opposing particular proposals be > technically grounded. > > These limitations do not change the core mechanisms of > consensus-building, however, and the IETF process continues to > require individual participants both to use their best engineering > judgment to select among proposals and to balance their own > interests with those of the Internet as a whole. Active > participation and a willingness to compromise, possibly on key > points, are needed. Historically, this has worked because a large > majority of participants have recognized that the Internet's > growth and enhancement are more important overall than any > specific short-term advantage. > > In other words, the use of "rough consensus" is sufficient in most > cases in the IETF to ensure that individuals or small groups are > heard when they raise technical objections, but that they cannot > block progress when a general agreement has been reached. This > document does not suggest changing the usual mechanisms for > achieving forward progress; it proposes mechanisms for use when a > working group has consensus that it must make a decision, but it > cannot make that decision by the usual rules. Discussion of the draft, and the mechanisms it proposes for use in these cases does not belong here (solutions@alvestrand.no would be one place to discuss it), but the recognition of the shape of the problem is important to scoping how individuals or small groups can affect the normal process. regards, Ted Hardie From problem-statement-bounces@alvestrand.no Wed Jun 25 17:24:51 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03941 for ; Wed, 25 Jun 2003 17:24:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DAE5662594; Wed, 25 Jun 2003 23:24:21 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by eikenes.alvestrand.no (Postfix) with ESMTP id 61A6462586 for ; Wed, 25 Jun 2003 23:24:20 +0200 (CEST) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196])h5PLNjMk073852 for ; Wed, 25 Jun 2003 23:24:04 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])h5PLNgwl123700 for ; Wed, 25 Jun 2003 23:23:43 +0200 Received: from gsine04.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA26660 from ; Wed, 25 Jun 2003 23:23:40 +0200 Message-Id: <3EFA12EC.88DE5616@hursley.ibm.com> Date: Wed, 25 Jun 2003 23:23:56 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "'problem-statement@alvestrand.no'" References: <2A1D4C86842EE14CA9BC80474919782E0D2267@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: It would be a problem if... X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 It would be a problem if a design team or directorate (which are explicitly not open, as Phill says) proposed a solution that did not meet rough consensus in the WG or at IETF Last Call and then the IESG put that solution on standards track. That would in fact be a major violation of RFC 2026. However, the use of closed teams to propose solutions that can be accepted or refused by WGs is a completely valid part of the process, and in one form or another occurs in most if not all standards bodies. WGs do not, in the real world, write documents collectively. They are always written by individuals or subgroups. Brian "Hallam-Baker, Phillip" wrote: > > Randy Writes: > > not completely true. increasingly, directorates and less formal > constructs are being used as document and srchitecture review > teams. this is a massive help, at least for me. > > The reason that so many people have no confidence in the IETF is exactly > this type of closed and unaccountable process by the inner circle. > > That type of behavior is not open and it is not inclusive. It is an old boys > network (and yes they almost always are boys). > > You can call the IETF what you will, but you cannot defend that as an open > process. > > Why then is it to be considered superior to closed decisions taken behind > corporate doors? How are you going to defend your closed decisions in > persuit of your private interests against their closed decisions? > > Phill From problem-statement-bounces@alvestrand.no Wed Jun 25 17:29:24 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04137 for ; Wed, 25 Jun 2003 17:29:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7D5D06259F; Wed, 25 Jun 2003 23:28:54 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mgw-dax2.ext.nokia.com (unknown [63.78.179.217]) by eikenes.alvestrand.no (Postfix) with ESMTP id DC122622B1 for ; Wed, 25 Jun 2003 23:28:51 +0200 (CEST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])h5PLSnG22300 for ; Wed, 25 Jun 2003 16:28:50 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com ; Wed, 25 Jun 2003 16:28:49 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 25 Jun 2003 14:27:59 -0700 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: Wed, 25 Jun 2003 16:27:58 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DB300@daebe007.americas.nokia.com> Thread-Topic: MAJOR ISSUE: "Concentration of power" Thread-Index: AcM7XTwddFnYTxWLQtOdKNOIBKp/owAAzA1w From: To: X-OriginalArrivalTime: 25 Jun 2003 21:27:59.0277 (UTC) FILETIME=[A67F5DD0:01C33B60] Cc: problem-statement@alvestrand.no Subject: RE: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 >> As in any organization there needs to be a system of checks and >> balances. At this time there does not seem to be any such for the >> power of the IESG.=20 > >I don't think that's true. There are at least 4 "features" of the IETF >proces that act as checks and balances on the IESG: Okay... I guess that is true. > >1. The IAB as an advisory board for WG formation (and in practice for = many >major IESG decisions) For WG formation, yes. What kind of *major* IESG decisions does the IAB get involved? Are there instances of the IAB challenging and over-ruling the IESGs decisions (other than in the case of appeals). Does the IAB get involved only when a view is sought by the IESG or does the IAB act proactively? >2. The appeals process The appeals process causes fear in some of being ostracized by the IETF community. So not vey effective. Looking at the number of appeals in the past and outcome, one would be discouraged to take the appeals route. But I agree that the process provides the capability. I am not sure how well this works in reality. >3. The recall process (never tested, for some reason) > >4. Payback time, i.e. the NomCom process. How? By providing input to the nomcom? Does this work? And looking at the results of the last few nomcoms, I dont see this. >Now, it's possible we need *more* checks and balances, of course. Or *more effective* ones than what exists now :) > Brian -Basavaraj From problem-statement-bounces@alvestrand.no Wed Jun 25 17:31:52 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04300 for ; Wed, 25 Jun 2003 17:31:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3FC3B625AA; Wed, 25 Jun 2003 23:31:22 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0EC92625A5; Wed, 25 Jun 2003 23:31:20 +0200 (CEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA14139; Wed, 25 Jun 2003 14:31:12 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5PLVA924179; Wed, 25 Jun 2003 14:31:10 -0700 X-mProtect: <200306252131> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.12.76, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpddb6p2n; Wed, 25 Jun 2003 14:31:08 PDT Message-Id: <4.3.2.7.2.20030625142237.02d41bc0@127.0.0.1> X-Sender: hinden@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 Jun 2003 14:31:04 -0700 To: Harald Tveit Alvestrand From: Bob Hinden In-Reply-To: <99530000.1054102606@askvoll.hjemme.alvestrand.no> References: <4.3.2.7.2.20030527132518.0389cc98@mailhost.iprg.nokia.com> <04c701c31ec8$1efb8b40$0300a8c0@DFNJGL21> <5.1.0.14.2.20030515114433.04767ac8@mail.windriver.com> <4517643810.20030516200534@brandenburg.com> <04c701c31ec8$1efb8b40$0300a8c0@DFNJGL21> <4.3.2.7.2.20030527132518.0389cc98@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Cc: Leslie Daigle Subject: Re: Listing affiliations X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Harald, I note that the IESG page http://www.ietf.org/iesg.html now lists the affiliation of the IESG members and liaisons. Thanks for making this happen. Bob p.s. The equivalent IAB page still needs some work. From problem-statement-bounces@alvestrand.no Wed Jun 25 17:35:36 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04467 for ; Wed, 25 Jun 2003 17:35:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BDC49625AC; Wed, 25 Jun 2003 23:35:06 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id B54CD625A7 for ; Wed, 25 Jun 2003 23:35:04 +0200 (CEST) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h5PLZ3ch010205; Wed, 25 Jun 2003 14:35:03 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 14:35:03 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D228E@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Brian E Carpenter'" , "Hallam-Baker, Phillip" Date: Wed, 25 Jun 2003 14:35:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: problem-statement@alvestrand.no Subject: RE: rough consensus (was Re: "trouble maker") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 And who hears the appeal? - A committee where the individual responsible for the abuses has audience rights and I do not. Can you see why I might not have much confidence in that as a process? Can you see why I might not want to take a step which is most likely to result in the IESG simply ratifying the chair's abuses so that they can continue to refuse to believe that there is a PROBLEM? I have raised my complaints concerning the closed DNS directorate process with many IESG members including the IETF chair. I was not the only person to complain. Paul Vixie called for the chair to resign. The only result was they had those DNS Directorate black helicopter hats made. These were a bit funnier until Derek Attkins admitted that he had discovered that he had been booted out of the directorate and not even been told this had happened. If the hats had had a picture of someone being dropped overboard they would have been much more accurate. If we are going to have a discussion about PROBLEM then discussion of specific failures of the process would seem to be a good starting point. If we are ever going to get to a SOLUTION it would be good to start hearing that others accept that I am not the only person making the complaint about autocratic top down proceedures and that they are having a widespread effect. Phill > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Wednesday, June 25, 2003 4:44 PM > To: Hallam-Baker, Phillip > Cc: problem-statement@alvestrand.no > Subject: Re: rough consensus (was Re: "trouble maker") > > > Phill, you seem to be extrapolating from one case to a general > statement that many of us would disagree with. > > In terms of the general determination of rough consensus, I would > add to the definition in 2418, which is entirely workable in my > experience, that if 20 people "vote" the same way, but the WG chair > knows that they all work for the same organization or for associated > organizations, those 20 "votes" are likely to be heavily discounted > in evaluating the RFC 2418 criteria. That's why we give discretion > to the WG chairs, and it's because we give them discretion that > there is an appeal mechanism *which no AD can block*. > > Brian > > "Hallam-Baker, Phillip" wrote: > > > > > But please spare a thought for the wg chairs too. They are in > > > this "damn if you do, damn if you dont" position... > > > > The chair was the person who created the situation. There would > > have been no debate at all if he had not manipulated the process > > repeatedly. > > > > If the chair in question had not also been on the IESG I suspect > > that he would not have been allowed to behave in the partisan > > manner he did. > > > > IETF - not open, not inclusive, not relevant. > > > > Phill > From problem-statement-bounces@alvestrand.no Wed Jun 25 17:48:06 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04992 for ; Wed, 25 Jun 2003 17:48:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1DF4C6256C; Wed, 25 Jun 2003 23:47:36 +0200 (CEST) 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 3A86C6238A for ; Wed, 25 Jun 2003 23:47:33 +0200 (CEST) Received: (qmail 75750 invoked from network); 25 Jun 2003 21:54:31 -0000 Received: from unknown (HELO pobox.org.sg) (207.253.237.204) by sentosa.post1.com with SMTP; 25 Jun 2003 21:54:31 -0000 Message-ID: <3EFA187D.9080309@pobox.org.sg> Date: Thu, 26 Jun 2003 05:47:41 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D228E@mou1wnexm02.verisign.com> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D228E@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Cc: "'Brian E Carpenter'" Subject: Re: rough consensus (was Re: "trouble maker") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 repeat: You declare it fails even before you put it to a test. This line of argument is not conviencing. -James Seng Hallam-Baker, Phillip wrote: > And who hears the appeal? - A committee where the individual responsible for > the abuses has audience rights and I do not. > > Can you see why I might not have much confidence in that as a process? > > Can you see why I might not want to take a step which is most likely to > result in the IESG simply ratifying the chair's abuses so that they can > continue to refuse to believe that there is a PROBLEM? > > > I have raised my complaints concerning the closed DNS directorate process > with many IESG members including the IETF chair. I was not the only person > to complain. Paul Vixie called for the chair to resign. The only result was > they had those DNS Directorate black helicopter hats made. > > These were a bit funnier until Derek Attkins admitted that he had discovered > that he had been booted out of the directorate and not even been told this > had happened. If the hats had had a picture of someone being dropped > overboard they would have been much more accurate. > > > If we are going to have a discussion about PROBLEM then discussion of > specific failures of the process would seem to be a good starting point. > > If we are ever going to get to a SOLUTION it would be good to start hearing > that others accept that I am not the only person making the complaint about > autocratic top down proceedures and that they are having a widespread > effect. > > > Phill > > >>-----Original Message----- >>From: Brian E Carpenter [mailto:brian@hursley.ibm.com] >>Sent: Wednesday, June 25, 2003 4:44 PM >>To: Hallam-Baker, Phillip >>Cc: problem-statement@alvestrand.no >>Subject: Re: rough consensus (was Re: "trouble maker") >> >> >>Phill, you seem to be extrapolating from one case to a general >>statement that many of us would disagree with. >> >>In terms of the general determination of rough consensus, I would >>add to the definition in 2418, which is entirely workable in my >>experience, that if 20 people "vote" the same way, but the WG chair >>knows that they all work for the same organization or for associated >>organizations, those 20 "votes" are likely to be heavily discounted >>in evaluating the RFC 2418 criteria. That's why we give discretion >>to the WG chairs, and it's because we give them discretion that >>there is an appeal mechanism *which no AD can block*. >> >> Brian >> >>"Hallam-Baker, Phillip" wrote: >> >>>>But please spare a thought for the wg chairs too. They are in >>>>this "damn if you do, damn if you dont" position... >>> >>>The chair was the person who created the situation. There would >>>have been no debate at all if he had not manipulated the process >>>repeatedly. >>> >>>If the chair in question had not also been on the IESG I suspect >>>that he would not have been allowed to behave in the partisan >>>manner he did. >>> >>>IETF - not open, not inclusive, not relevant. >>> >>> Phill >> > > From problem-statement-bounces@alvestrand.no Wed Jun 25 17:55:30 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05234 for ; Wed, 25 Jun 2003 17:55:29 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 03CB262577; Wed, 25 Jun 2003 23:55:00 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8E1886238A for ; Wed, 25 Jun 2003 23:54:53 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.13.142]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA22269; Wed, 25 Jun 2003 14:54:15 -0700 (PDT) Message-Id: <5.1.0.14.2.20030625174005.04843d28@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 25 Jun 2003 17:50:15 -0400 To: "Hunkins, Andrew" From: Margaret Wasserman In-Reply-To: References: < <2A1D4C86842EE14CA9BC80474919782E0D2266@mou1wnexm02.verisign.com> <2A1D4C86842EE14CA9BC80474919782E0D2266@mou1wnexm02.verisign.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "'problem-statement@alvestrand.no'" Subject: Re: Trusting the IESG to manage the reform process (was: Re: Doing t he Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Phillip, On two separate occassions, Hallam-Baker, Phillip wrote: >It would also explain the generation gap problem. The simple fact is that no >matter what anyone under 40 does in the IETF they are never going to get >accepted into the inner circle. -AND- >That type of behavior is not open and it is not inclusive. It is an old boys >network (and yes they almost always are boys). I don't know what IETF you are working in, but... I am not (for another two weeks) over 40, nor am I a "boy", but I do think that I have been accepted into the "inner circle" of the IETF -- whatever that means. I did find it difficult to get established in the IETF as a newbie, but that difficulty was not (IMO) related in any way to my age or gender. Margaret From problem-statement-bounces@alvestrand.no Wed Jun 25 18:36:04 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08056 for ; Wed, 25 Jun 2003 18:36:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 87AB06256C; Thu, 26 Jun 2003 00:35:34 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5D9BD6238A for ; Thu, 26 Jun 2003 00:35:33 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180])h5PMYuMk017186; Thu, 26 Jun 2003 00:35:09 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])h5PMYPW0281678; Thu, 26 Jun 2003 00:34:41 +0200 Received: from gsine04.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA29456 from ; Thu, 26 Jun 2003 00:34:24 +0200 Message-Id: <3EFA237F.9874E801@hursley.ibm.com> Date: Thu, 26 Jun 2003 00:34:39 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D228E@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: rough consensus (was Re: "trouble maker") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 "Hallam-Baker, Phillip" wrote: > > And who hears the appeal? - A committee where the individual responsible for > the abuses has audience rights and I do not. Not at all. The IAB has several times held open hearings on appeals, for good reason. And by the way, unfairness in the appeals process would seem like reasonable grounds for a final appeal to the ISOC Board. ... > > If we are going to have a discussion about PROBLEM then discussion of > specific failures of the process would seem to be a good starting point. But if the appeal process and/or the recall process haven't been used, you simply can't assert a process failure. > If we are ever going to get to a SOLUTION it would be good to start hearing > that others accept that I am not the only person making the complaint about > autocratic top down proceedures and that they are having a widespread > effect. Indeed. One swallow does not a summer make. It would be interesting to know how many of the WGs have members who would assert such problems. Brian From problem-statement-bounces@alvestrand.no Wed Jun 25 18:41:47 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08514 for ; Wed, 25 Jun 2003 18:41:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6E4666256F; Thu, 26 Jun 2003 00:41:18 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by eikenes.alvestrand.no (Postfix) with ESMTP id C76506238A for ; Thu, 26 Jun 2003 00:41:15 +0200 (CEST) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196])h5PMeOsn068802; Thu, 26 Jun 2003 00:40:44 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])h5PMe9wl289484; Thu, 26 Jun 2003 00:40:09 +0200 Received: from gsine04.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA27908 from ; Thu, 26 Jun 2003 00:40:08 +0200 Message-Id: <3EFA2170.6BCE9C6C@hursley.ibm.com> Date: Thu, 26 Jun 2003 00:25:52 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Basavaraj.Patil@nokia.com References: <697DAA22C5004B4596E033803A7CEF44024DB300@daebe007.americas.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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, Basavaraj.Patil@nokia.com wrote: > > >> As in any organization there needs to be a system of checks and > >> balances. At this time there does not seem to be any such for the > >> power of the IESG. > > > >I don't think that's true. There are at least 4 "features" of the IETF > >proces that act as checks and balances on the IESG: > > Okay... I guess that is true. > > > > >1. The IAB as an advisory board for WG formation (and in practice for many > >major IESG decisions) > > For WG formation, yes. What kind of *major* IESG decisions does the > IAB get involved? Are there instances of the IAB challenging and > over-ruling the IESGs decisions (other than in the case of > appeals). Does the IAB get involved only when a view is sought by the > IESG or does the IAB act proactively? My experience is out of date since I left the IAB more than a year ago, but in my time on the IAB, there were several occasions a year when the IESG would ask the IAB informally for advice on how to unblock a situation or decide about a contentious document. And there were certainly cases where the IAB stuck its nose in. I felt this was the IAB's job, if it noticed a case where it thought the IESG was at risk of going off track. > > >2. The appeals process > > The appeals process causes fear in some of being ostracized by the > IETF community. So not vey effective. Looking at the number of appeals > in the past and outcome, one would be discouraged to take the appeals > route. But I agree that the process provides the capability. I am not > sure how well this works in reality. I think it has been very useful. Of course, for the IESG and IAB, an appeal is a nuisance and looks like a distraction from "real work", and it would be a problem if there were too many appeals per year. But a small number of appeals (won or lost) keeps everyone aware that the process rules deserve respect. > > >3. The recall process (never tested, for some reason) > > > >4. Payback time, i.e. the NomCom process. > > How? By providing input to the nomcom? Does this work? > And looking at the results of the last few nomcoms, I dont see this. The nomcom gets contradictory input, so their decisions are not always to everybody's liking. > > >Now, it's possible we need *more* checks and balances, of course. > > Or *more effective* ones than what exists now :) Can you phrase that as a precise problem statement? Brian From problem-statement-bounces@alvestrand.no Wed Jun 25 18:43:13 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08610 for ; Wed, 25 Jun 2003 18:43:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 202E162577; Thu, 26 Jun 2003 00:42:45 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by eikenes.alvestrand.no (Postfix) with ESMTP id D22396238A for ; Thu, 26 Jun 2003 00:42:43 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180])h5PMg5PO013768; Thu, 26 Jun 2003 00:42:25 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])h5PMfnW0260080; Thu, 26 Jun 2003 00:41:50 +0200 Received: from gsine04.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA47156 from ; Thu, 26 Jun 2003 00:41:48 +0200 Message-Id: <3EFA2170.6BCE9C6C@hursley.ibm.com> Date: Thu, 26 Jun 2003 00:25:52 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Basavaraj.Patil@nokia.com References: <697DAA22C5004B4596E033803A7CEF44024DB300@daebe007.americas.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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, Basavaraj.Patil@nokia.com wrote: > > >> As in any organization there needs to be a system of checks and > >> balances. At this time there does not seem to be any such for the > >> power of the IESG. > > > >I don't think that's true. There are at least 4 "features" of the IETF > >proces that act as checks and balances on the IESG: > > Okay... I guess that is true. > > > > >1. The IAB as an advisory board for WG formation (and in practice for many > >major IESG decisions) > > For WG formation, yes. What kind of *major* IESG decisions does the > IAB get involved? Are there instances of the IAB challenging and > over-ruling the IESGs decisions (other than in the case of > appeals). Does the IAB get involved only when a view is sought by the > IESG or does the IAB act proactively? My experience is out of date since I left the IAB more than a year ago, but in my time on the IAB, there were several occasions a year when the IESG would ask the IAB informally for advice on how to unblock a situation or decide about a contentious document. And there were certainly cases where the IAB stuck its nose in. I felt this was the IAB's job, if it noticed a case where it thought the IESG was at risk of going off track. > > >2. The appeals process > > The appeals process causes fear in some of being ostracized by the > IETF community. So not vey effective. Looking at the number of appeals > in the past and outcome, one would be discouraged to take the appeals > route. But I agree that the process provides the capability. I am not > sure how well this works in reality. I think it has been very useful. Of course, for the IESG and IAB, an appeal is a nuisance and looks like a distraction from "real work", and it would be a problem if there were too many appeals per year. But a small number of appeals (won or lost) keeps everyone aware that the process rules deserve respect. > > >3. The recall process (never tested, for some reason) > > > >4. Payback time, i.e. the NomCom process. > > How? By providing input to the nomcom? Does this work? > And looking at the results of the last few nomcoms, I dont see this. The nomcom gets contradictory input, so their decisions are not always to everybody's liking. > > >Now, it's possible we need *more* checks and balances, of course. > > Or *more effective* ones than what exists now :) Can you phrase that as a precise problem statement? Brian From problem-statement-bounces@alvestrand.no Wed Jun 25 18:51:06 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09116 for ; Wed, 25 Jun 2003 18:51:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D6F506256B; Thu, 26 Jun 2003 00:16:41 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2C528622B1 for ; Thu, 26 Jun 2003 00:16:40 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h5PMGdch018462; Wed, 25 Jun 2003 15:16:39 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 15:16:39 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D2290@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Joel M. Halpern'" , "Hallam-Baker, Phillip" , problem-statement@alvestrand.no Date: Wed, 25 Jun 2003 15:16:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: Proposals. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 have been asked if all I intend to do is complain. I would much prefer to be discussing solutions, but this is PROBLEM... Since you ask, I want to see the following changes: 1) Working Group chairs must be accountable to their working groups. * All vacancies for working group chairs to be advertised three weeks in advance. * All appointments of working group chairs to be of limited duration (e.g. two years) with the possibility of reappointment * All appointments to be ratified by the working groups concerned. Here I am also concerned about the propensity of groups to become standing committees. For example CAT was effectively a standing committee for over ten years. PKIX is in a similar situation. There is something of a problem when a successful group does not close but just keeps taking on new work. It means that people have to keep attending the group just to stop people using it as a convenient lever for forcing implementation of some scheme. I have no objection to the IETF creating an SCVP protocol that largely duplicates the functionality of XKMS. But I do think it a problem that it is doing so with the implicit endorsement of the PKI vendors who have endorsed PKIX protocols in the past - particularly when they have explicitly declined to endorse. 2) Try to get the IESG out of the loop in approving specs. * If you really like the NOMCON process that much use it to pick people to review specs, the same way Slashdot chooses moderators. People sign up to review one spec choosen at random a month. * Change from an IESG approvals process to an objections process. Default action is it gets out the door. While a large number of IETF specs reach the IESG in an unsatisfactory state I don't see that this is the most profitable use of IESG time. If a group wants to do shoddy work let them. It is a situation that will right itself soon enough. The effect I see is similar to that of US politics wrt civil rights. A lot of voters don't think civil rights are an issue because they can rely on the supreme court and the constitution to protect them. As a result people get complacent and when the supreme court makes a real mistake the consequences are serious. By the time a spec has been primped to a sufficient level to become an RFC the implementations are long out of the door. Perhaps vendors will upgrade later, probably not. The IETF process means that by the time IESG input is heard it is usually too late. What I would like to see comming from a body like the IESG is commentary on requirements that cut across standards. IESG objections should highlight issues with the spec of the form 'Security - this will create problems for other protocols' or 'Scalability - this won't work for the Internet on a global scale'. 3) Employ structured communications processes. * Abolish the RFC series, in future all documents to be identified by the WG that originates them. * Separate requirements and defects processing from the proposed solutions. * Abolish DRAFT standard status it is confusing and unnecessary. * Replace the RFC editor process with an XML based document processing system. ISOC states that it spends $800,000 running the RFC editorship a year. That seems an inordinate waste of money for a process that can be readily automated using commercial tools. The RFC process was intended to be completely informal, requests for comments. It has become a hodge podge of proposals, standards, proprietary specs pretending to be standards and so on. The documents take an inordinate amount of time to create considering the primitive typography that they employ. Then people started to equate RFC with some sort of standard and all sorts of barriers get thrown up. Avoid the problem, get rid of the problem of specious credibility by getting making it clear that this is on autopilot. Going through the engineering dept I regularly find an engineer who is writing code from a secondary source rather than try to decipher a poorly formatted RFC. It appears that this is the norm. The engineers point out that secondary sources are frequently more reliable guides to achieving interoperable implementation than the RFC. That in my view is a problem. I think decoupling the requirements process would have had a positive effect on the DNSEXT situation. There was no process by which I could force the following question to be addressed by the IESG - "Should the ability to efficiently deploy the DNSSEC specification in large zones be a protocol requirement?" That is the appeal I want to make but at present there is simply no way I can get that on the IESG agenda. I believe that the question should have preceeded the WG attempts to address the problem. Instead we spent three years and a considerable amount of engineering resources answering questions that turned out to be irrelevant and re-writing a draft that was going to be ignored. The DRAFT issue may sound minor but nobody outside the IETF can understand the difference between internet draft and draft standard, particularly since for some reason draft is more advanced than proposed. Get rid of the DRAFT step in the standards process and you reduce the IESG workload in two ways, first review the drafts fewer times, second the groups can close rather than hanging arround. Phill From problem-statement-bounces@alvestrand.no Wed Jun 25 19:44:47 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12002 for ; Wed, 25 Jun 2003 19:43:42 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 500EF62573; Thu, 26 Jun 2003 01:43:14 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 605256256C for ; Thu, 26 Jun 2003 01:43:11 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h5PNh3N27684; Wed, 25 Jun 2003 19:43:04 -0400 (EDT) Date: Wed, 25 Jun 2003 19:43:03 -0400 From: Keith Moore To: "Hallam-Baker, Phillip" Message-Id: <20030625194303.714686e0.moore@cs.utk.edu> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D228E@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D228E@mou1wnexm02.verisign.com> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: pbaker@verisign.com Cc: moore@cs.utk.edu Cc: brian@hursley.ibm.com Cc: problem-statement@alvestrand.no Subject: Re: rough consensus (was Re: "trouble maker") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > And who hears the appeal? - A committee where the individual > responsible for the abuses has audience rights and I do not. have you even bothered to find out if this is the case, or are you just making this up? I thought so. From problem-statement-bounces@alvestrand.no Wed Jun 25 19:57:46 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12807 for ; Wed, 25 Jun 2003 19:57:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2ABFA6256B; Thu, 26 Jun 2003 01:22:42 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id D4B046238A for ; Thu, 26 Jun 2003 01:22:39 +0200 (CEST) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h5PNMcch003045; Wed, 25 Jun 2003 16:22:38 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jun 2003 16:22:38 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D2293@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Brian E Carpenter'" , "Hallam-Baker, Phillip" Date: Wed, 25 Jun 2003 16:22:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: problem-statement@alvestrand.no Subject: RE: rough consensus (was Re: "trouble maker") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 ISOC is a direct competitor to VeriSign in management of DNS registries. > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Wednesday, June 25, 2003 6:35 PM > To: Hallam-Baker, Phillip > Cc: problem-statement@alvestrand.no > Subject: Re: rough consensus (was Re: "trouble maker") > > > > > "Hallam-Baker, Phillip" wrote: > > > > And who hears the appeal? - A committee where the > individual responsible for > > the abuses has audience rights and I do not. > > Not at all. The IAB has several times held open hearings on > appeals, for > good reason. And by the way, unfairness in the appeals process would > seem like reasonable grounds for a final appeal to the ISOC Board. > > ... > > > > If we are going to have a discussion about PROBLEM then > discussion of > > specific failures of the process would seem to be a good > starting point. > > But if the appeal process and/or the recall process haven't > been used, you > simply can't assert a process failure. > > > If we are ever going to get to a SOLUTION it would be good > to start hearing > > that others accept that I am not the only person making the > complaint about > > autocratic top down proceedures and that they are having a > widespread > > effect. > > Indeed. One swallow does not a summer make. It would be > interesting to know > how many of the WGs have members who would assert such problems. > > Brian > From problem-statement-bounces@alvestrand.no Wed Jun 25 21:37:47 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18931 for ; Wed, 25 Jun 2003 21:37:46 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9EAE26256B; Thu, 26 Jun 2003 03:02:38 +0200 (CEST) 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 365B06238A for ; Thu, 26 Jun 2003 03:02:34 +0200 (CEST) Received: (qmail 77229 invoked from network); 26 Jun 2003 01:09:31 -0000 Received: from unknown (HELO pobox.org.sg) (207.253.237.204) by sentosa.post1.com with SMTP; 26 Jun 2003 01:09:31 -0000 Message-ID: <3EFA4632.3020302@pobox.org.sg> Date: Thu, 26 Jun 2003 09:02:42 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D2290@mou1wnexm02.verisign.com> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D2290@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Joel M. Halpern'" Cc: problem-statement@alvestrand.no Subject: Re: Proposals. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit I think there are some pretty good suggestions on the improvement. It would be even moe useful if you can point out which problem (as listed in problem-statement) these solutions aims to solve. If the problem is missing from the doc, we probably should document it. Of course, you have to convience the group that it is indeed broken. -James Seng Hallam-Baker, Phillip wrote: > I have been asked if all I intend to do is complain. I would much prefer to > be discussing solutions, but this is PROBLEM... > > Since you ask, I want to see the following changes: > > > 1) Working Group chairs must be accountable to their working groups. > > * All vacancies for working group chairs to be advertised three weeks in > advance. > * All appointments of working group chairs to be of limited duration (e.g. > two years) with the possibility of reappointment > * All appointments to be ratified by the working groups concerned. > > Here I am also concerned about the propensity of groups to become standing > committees. For example CAT was effectively a standing committee for over > ten years. PKIX is in a similar situation. > > There is something of a problem when a successful group does not close but > just keeps taking on new work. It means that people have to keep attending > the group just to stop people using it as a convenient lever for forcing > implementation of some scheme. I have no objection to the IETF creating an > SCVP protocol that largely duplicates the functionality of XKMS. But I do > think it a problem that it is doing so with the implicit endorsement of the > PKI vendors who have endorsed PKIX protocols in the past - particularly when > they have explicitly declined to endorse. > > > 2) Try to get the IESG out of the loop in approving specs. > > * If you really like the NOMCON process that much use it to pick people to > review specs, the same way Slashdot chooses moderators. People sign up to > review one spec choosen at random a month. > * Change from an IESG approvals process to an objections process. Default > action is it gets out the door. > > While a large number of IETF specs reach the IESG in an unsatisfactory state > I don't see that this is the most profitable use of IESG time. If a group > wants to do shoddy work let them. It is a situation that will right itself > soon enough. > > The effect I see is similar to that of US politics wrt civil rights. A lot > of voters don't think civil rights are an issue because they can rely on the > supreme court and the constitution to protect them. As a result people get > complacent and when the supreme court makes a real mistake the consequences > are serious. > > By the time a spec has been primped to a sufficient level to become an RFC > the implementations are long out of the door. Perhaps vendors will upgrade > later, probably not. The IETF process means that by the time IESG input is > heard it is usually too late. > > > What I would like to see comming from a body like the IESG is commentary on > requirements that cut across standards. IESG objections should highlight > issues with the spec of the form 'Security - this will create problems for > other protocols' or 'Scalability - this won't work for the Internet on a > global scale'. > > > 3) Employ structured communications processes. > > * Abolish the RFC series, in future all documents to be identified by the WG > that originates them. > * Separate requirements and defects processing from the proposed solutions. > * Abolish DRAFT standard status it is confusing and unnecessary. > * Replace the RFC editor process with an XML based document processing > system. > > ISOC states that it spends $800,000 running the RFC editorship a year. That > seems an inordinate waste of money for a process that can be readily > automated using commercial tools. > > The RFC process was intended to be completely informal, requests for > comments. It has become a hodge podge of proposals, standards, proprietary > specs pretending to be standards and so on. The documents take an inordinate > amount of time to create considering the primitive typography that they > employ. > > Then people started to equate RFC with some sort of standard and all sorts > of barriers get thrown up. Avoid the problem, get rid of the problem of > specious credibility by getting making it clear that this is on autopilot. > > Going through the engineering dept I regularly find an engineer who is > writing code from a secondary source rather than try to decipher a poorly > formatted RFC. It appears that this is the norm. The engineers point out > that secondary sources are frequently more reliable guides to achieving > interoperable implementation than the RFC. That in my view is a problem. > > > I think decoupling the requirements process would have had a positive effect > on the DNSEXT situation. There was no process by which I could force the > following question to be addressed by the IESG - "Should the ability to > efficiently deploy the DNSSEC specification in large zones be a protocol > requirement?" > > That is the appeal I want to make but at present there is simply no way I > can get that on the IESG agenda. I believe that the question should have > preceeded the WG attempts to address the problem. > > Instead we spent three years and a considerable amount of engineering > resources answering questions that turned out to be irrelevant and > re-writing a draft that was going to be ignored. > > > The DRAFT issue may sound minor but nobody outside the IETF can understand > the difference between internet draft and draft standard, particularly since > for some reason draft is more advanced than proposed. > > Get rid of the DRAFT step in the standards process and you reduce the IESG > workload in two ways, first review the drafts fewer times, second the groups > can close rather than hanging arround. > > > Phill > > From problem-statement-bounces@alvestrand.no Wed Jun 25 22:20:11 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21671 for ; Wed, 25 Jun 2003 22:20:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B8BDD6256F; Thu, 26 Jun 2003 04:18:41 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mx-out.daemonmail.net (mx-out.daemonmail.net [216.104.160.39]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5266D6256C for ; Thu, 26 Jun 2003 04:18:35 +0200 (CEST) Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.9.3p2/8.9.3) with SMTP id TAA97423 for ; Wed, 25 Jun 2003 19:18:34 -0700 (PDT) (envelope-from spencer@mcsr-labs.org) Received: from (12.237.229.250 [12.237.229.250]) by mail.varaha.com with SMTP id ELP0kPV2 Wed, 25 Jun 2003 19:18:33 -0700 (PDT) Message-ID: <029101c33b89$4049c2c0$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <2A1D4C86842EE14CA9BC80474919782E0D2290@mou1wnexm02.verisign.com> <3EFA4632.3020302@pobox.org.sg> Date: Wed, 25 Jun 2003 21:18:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: Proposals. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Dear Phillip, ... and, speaking only for myself, the problem statement editor team has been (correctly) more interested in collecting problems than trying to figure out whether something was really broken, so this is NOT an insurmountable barrier to entry! Spencer ----- Original Message ----- From: "James Seng" To: "Hallam-Baker, Phillip" Cc: "'Joel M. Halpern'" ; Sent: Wednesday, June 25, 2003 8:02 PM Subject: Re: Proposals. > I think there are some pretty good suggestions on the improvement. > > It would be even moe useful if you can point out which problem (as > listed in problem-statement) these solutions aims to solve. > > If the problem is missing from the doc, we probably should document it. > Of course, you have to convience the group that it is indeed broken. > > -James Seng From problem-statement-bounces@alvestrand.no Thu Jun 26 00:46:36 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25760 for ; Thu, 26 Jun 2003 00:46:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3D49F621FA; Thu, 26 Jun 2003 06:45:50 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5284361AA5 for ; Thu, 26 Jun 2003 06:45:47 +0200 (CEST) Date: Thu, 26 Jun 2003 00:45:45 -0400 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <422392558.1056588345@HALVESTR-W2K1.cisco.com> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: RE: rough consensus (was Re: "trouble maker") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Note: There is not consensus in the DNSEXT WG that Phill's description of the events of that group is the right one. In particular, as far as I can tell, the WG Chairs and the responsible AD disagree with him, but they are not the only ones. This can be a problem when using examples (which I am very much in favour of, btw!) - all I'm 100% sure of is that the DNSEXT WG saw several voices raised on the issue Phill is describing, and that they did not come to consensus. The chairs reported that lack of consensus as "insufficient consensus for change", and concluded that the WG had to ship the documents in question without the proposed change. Text of announcement below. Harald ------------------------------------------------------------------------- the wg last call on [ds-only] opt-in is over. it's a tough issue and the wg discussion has been muddy, to be kind. 1 - there seems to be consensus that the spec is complete and correct. this was determined in a separate last call. 2 - is there consensus that opt-in adds complexity? probably yes, but folk disagree on how much and disagree on the impact of that complexity on dns operation and on security. 3 - is there consensus that opt-in changes the security model from 'simple dnssec'? yes. is that change bad? opinions differ. 4 - is there consensus that deployment of dnssec is important? yes. 5 - is there consensus that opt-in may help deployment of dnssec? yes, for a few very large zones. 6 - it might not be obvious how to come to a decision here - or even whether we can come to a decision. the question asked of the WG was: "is there consensus in the wg, to allow ds-only opt-in in zones?" the way this is phrased the default action, which is what applies should there not be rough consensus, is to not add the opt-in feature to the protocol. one might argue that the question was asked in a biased manner and the question should instead have been asked as: "should we allow or not allow opt-in zones?" first, it is traditional and reasonable to place the onus of consensus on *additions* to protocols, since it is likely to lead to less features in protocols if each added feature needs wg rough consensus. i.e., this was normal wg procedure. second, and possibly more important, had the question been asked that way, we would have the equivalent of a hung jury with no process for how to move forward at all. 7 - is there consensus that consensus-5 should override consensus-2 and consensus-3? discussion varied, folk had opinions on both sides. underneath the flamage, there was actual disagreement, with knowledgeable parties on both sides of the fence. this is not consensus. given that we all want to move forward the chairs, given the process, have no choice but to come to the following conclusion: there is no consensus to add opt-in. randy & olafur From problem-statement-bounces@alvestrand.no Thu Jun 26 08:16:45 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17571 for ; Thu, 26 Jun 2003 08:16:44 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7E16A62573; Thu, 26 Jun 2003 14:16:13 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from apocalypse.org (apocalypse.org [192.48.232.17]) by eikenes.alvestrand.no (Postfix) with ESMTP id AFBA162251; Thu, 26 Jun 2003 14:16:11 +0200 (CEST) Received: from acm.org (IDENT:Qq78LCzCpv8Pc1RNV9IplI2YAcPeOx7z@apocalypse.org [192.48.232.17]) by apocalypse.org (8.11.6/8.11.6) with ESMTP id h5QCG8G15107; Thu, 26 Jun 2003 08:16:09 -0400 Date: Thu, 26 Jun 2003 21:16:05 +0900 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: problem-statement@alvestrand.no From: Avri Doria In-Reply-To: <422392558.1056588345@HALVESTR-W2K1.cisco.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: Harald Alvestrand Subject: Re: rough consensus (was Re: "trouble maker") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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, This has been a very interesting discussion, and I beleive that it is important that the details of this issue be debated and resolved. I do not believe that should be done on this list. It was good to get the problem discussed so that people could do an abstraction of it for the problem statement, but I would like to avoid dwelling on the specific arguments relating to it any longer. At this point I ask that people concentrate on the general language for the problem statement so that we can make sure that the problem is reflected adequately in the problem statement. Thanks Avri co-chair On torsdag, jun 26, 2003, at 13:45 Asia/Seoul, Harald Tveit Alvestrand wrote: From problem-statement-bounces@alvestrand.no Thu Jun 26 08:48:04 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20750 for ; Thu, 26 Jun 2003 08:48:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A65086256B; Thu, 26 Jun 2003 14:47:33 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from cliffie.verisignlabs.com (thing.verisignlabs.com [65.201.175.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id 952E5621B8; Thu, 26 Jun 2003 14:47:31 +0200 (CEST) Received: from thinkingcat.com (softdnserr [::ffff:68.169.63.42]) (AUTH: PLAIN leslie, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Thu, 26 Jun 2003 08:47:29 -0400 Message-ID: <3EFAEB43.9080509@thinkingcat.com> Date: Thu, 26 Jun 2003 08:46:59 -0400 From: Leslie Daigle User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Hinden References: <4.3.2.7.2.20030527132518.0389cc98@mailhost.iprg.nokia.com> <04c701c31ec8$1efb8b40$0300a8c0@DFNJGL21> <5.1.0.14.2.20030515114433.04767ac8@mail.windriver.com> <4517643810.20030516200534@brandenburg.com> <04c701c31ec8$1efb8b40$0300a8c0@DFNJGL21> <4.3.2.7.2.20030527132518.0389cc98@mailhost.iprg.nokia.com> <4.3.2.7.2.20030625142237.02d41bc0@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Harald Tveit Alvestrand Cc: problem-statement@alvestrand.no Subject: Re: Listing affiliations X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Bob, I do have an item on my "to do" list to take this up with the IAB. I will observe that there are at least 3 different theories at play: . the community wants to know what companies are supporting the people on the iab/iesg . the employers (for those of us fortunate enough to have them) of the people on the iab/iesg would like some recognition of the fact they are contributing employee resources . we are all contributing as individuals (still) It's the latter point that has caused IAB members *not* to be introduced with affiliations at plenaries, and the affiliations not to be posted on the IAB web page. A couple or few years ago, I suggested it would be helpful to have brief statement (or web page) about/from each IAB member, linked off the IAB member listing page, so that people could have a clue what areas of interest/expertise the various IAB members have. It strikes me that would be an appropriate place to list affiliations. You can see how well the idea flew the last time I proposed it. I do have an item on my "to do" list to take this up with the IAB. Leslie. Bob Hinden wrote: > Harald, > > I note that the IESG page http://www.ietf.org/iesg.html now lists the > affiliation of the IESG members and liaisons. > > Thanks for making this happen. > > Bob > > p.s. The equivalent IAB page still needs some work. > > -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From problem-statement-bounces@alvestrand.no Thu Jun 26 11:26:08 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02649 for ; Thu, 26 Jun 2003 11:26:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1BD3F62573; Thu, 26 Jun 2003 17:25:37 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5E79F61AA5; Thu, 26 Jun 2003 17:25:35 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19VYcu-0003dX-BB; Thu, 26 Jun 2003 08:25:32 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 26 Jun 2003 08:25:31 -0700 To: Leslie Daigle References: <4.3.2.7.2.20030527132518.0389cc98@mailhost.iprg.nokia.com> <04c701c31ec8$1efb8b40$0300a8c0@DFNJGL21> <5.1.0.14.2.20030515114433.04767ac8@mail.windriver.com> <4517643810.20030516200534@brandenburg.com> <4.3.2.7.2.20030625142237.02d41bc0@127.0.0.1> <3EFAEB43.9080509@thinkingcat.com> Message-Id: Cc: Harald Tveit Alvestrand Cc: Bob Hinden Cc: problem-statement@alvestrand.no Subject: Re: Listing affiliations X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 of us have, for various reasons, personal web pages. perhaps the ietf.org web listing, instead of a mailto: should have an http:? randy From problem-statement-bounces@alvestrand.no Thu Jun 26 12:24:51 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07233 for ; Thu, 26 Jun 2003 12:24:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3A38F62573; Thu, 26 Jun 2003 18:23:10 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4A8D3623CD; Thu, 26 Jun 2003 18:23:08 +0200 (CEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA09162; Thu, 26 Jun 2003 09:23:07 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5QGN6j10906; Thu, 26 Jun 2003 09:23:06 -0700 X-mProtect: <200306261623> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.12.76, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdyHlFmp; Thu, 26 Jun 2003 09:23:04 PDT Message-Id: <4.3.2.7.2.20030626090904.03583768@127.0.0.1> X-Sender: hinden@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Jun 2003 09:22:58 -0700 To: Leslie Daigle From: Bob Hinden In-Reply-To: <3EFAEB43.9080509@thinkingcat.com> References: <4.3.2.7.2.20030527132518.0389cc98@mailhost.iprg.nokia.com> <04c701c31ec8$1efb8b40$0300a8c0@DFNJGL21> <5.1.0.14.2.20030515114433.04767ac8@mail.windriver.com> <4517643810.20030516200534@brandenburg.com> <04c701c31ec8$1efb8b40$0300a8c0@DFNJGL21> <4.3.2.7.2.20030527132518.0389cc98@mailhost.iprg.nokia.com> <4.3.2.7.2.20030625142237.02d41bc0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Harald Tveit Alvestrand Cc: problem-statement@alvestrand.no Subject: Re: Listing affiliations X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Leslie, At 05:46 AM 6/26/2003, Leslie Daigle wrote: >Bob, > >I do have an item on my "to do" list to take this up with the IAB. Thanks. >I will observe that there are at least 3 different theories >at play: > > . the community wants to know what companies are supporting > the people on the iab/iesg > > . the employers (for those of us fortunate enough to have them) > of the people on the iab/iesg would like some recognition of the > fact they are contributing employee resources > > . we are all contributing as individuals (still) I think these are all true and don't think they are conflicting. >It's the latter point that has caused IAB members *not* to be introduced >with affiliations at plenaries, and the affiliations not to be posted >on the IAB web page. I don't have a strong view if IAB members should be introduced in the plenary with their affiliations. I don't think it is necessary as long as their affiliations are publicly available (e.g., on the IAB web page). I don't see any harm if it was done either. >A couple or few years ago, I suggested it would be helpful to have >brief statement (or web page) about/from each IAB member, linked >off the IAB member listing page, so that people could have a clue what areas >of interest/expertise the various IAB members have. It strikes >me that would be an appropriate place to list affiliations. I think short bio's for IESG and IAB members would be nice for the reasons you state. My preference for this would be in addition to a listing of name and affiliation. >You can see how well the idea flew the last time I proposed it. > >I do have an item on my "to do" list to take this up with the IAB. Thanks, Bob From problem-statement-bounces@alvestrand.no Thu Jun 26 14:05:46 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12077 for ; Thu, 26 Jun 2003 14:05:46 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 63805623CD; Thu, 26 Jun 2003 20:01:29 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0003D6230F for ; Thu, 26 Jun 2003 20:01:26 +0200 (CEST) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196])h5QI1Hsn081532; Thu, 26 Jun 2003 20:01:17 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])h5QI1GZh253162; Thu, 26 Jun 2003 20:01:16 +0200 Received: from gsine04.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA44768 from ; Thu, 26 Jun 2003 20:01:09 +0200 Message-Id: <3EFB30F7.32F07932@hursley.ibm.com> Date: Thu, 26 Jun 2003 19:44:23 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Hallam-Baker, Phillip" References: <2A1D4C86842EE14CA9BC80474919782E0D2293@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: rough consensus (was Re: "trouble maker") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Phill, I don't see the relevance, since we all participate as individuals in the IETF, but since you mention it, here are some facts. ISOC went to a great deal of trouble to ensure that the .org registry is operated independently of ISOC, by an independent non-profit corporation, with a for-profit subcontractor actually operating the machinery. That suncontractor might be considered a competitor of other registry operators. This was very carefully designed to avoid conflict of interest for ISOC. I was one of the ISOC Board Members who insisted on this. Brian "Hallam-Baker, Phillip" wrote: > > ISOC is a direct competitor to VeriSign in management of DNS registries. > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Wednesday, June 25, 2003 6:35 PM > > To: Hallam-Baker, Phillip > > Cc: problem-statement@alvestrand.no > > Subject: Re: rough consensus (was Re: "trouble maker") > > > > > > > > > > "Hallam-Baker, Phillip" wrote: > > > > > > And who hears the appeal? - A committee where the > > individual responsible for > > > the abuses has audience rights and I do not. > > > > Not at all. The IAB has several times held open hearings on > > appeals, for > > good reason. And by the way, unfairness in the appeals process would > > seem like reasonable grounds for a final appeal to the ISOC Board. > > > > ... > > > > > > If we are going to have a discussion about PROBLEM then > > discussion of > > > specific failures of the process would seem to be a good > > starting point. > > > > But if the appeal process and/or the recall process haven't > > been used, you > > simply can't assert a process failure. > > > > > If we are ever going to get to a SOLUTION it would be good > > to start hearing > > > that others accept that I am not the only person making the > > complaint about > > > autocratic top down proceedures and that they are having a > > widespread > > > effect. > > > > Indeed. One swallow does not a summer make. It would be > > interesting to know > > how many of the WGs have members who would assert such problems. > > > > Brian > > From problem-statement-bounces@alvestrand.no Thu Jun 26 14:27:35 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13325 for ; Thu, 26 Jun 2003 14:27:34 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6F4186256B; Thu, 26 Jun 2003 20:27:04 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.cdt.org (www.cdt.info [206.112.85.61]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8AD4C623CD for ; Thu, 26 Jun 2003 20:27:02 +0200 (CEST) Received: from [10.0.1.19] (66.safeclick.net [63.119.245.66]) by mail.cdt.org (Postfix) with ESMTP id 2EC83490115 for ; Thu, 26 Jun 2003 14:25:11 -0400 (EDT) Mime-Version: 1.0 X-Sender: john@mail.cdt.org Message-Id: In-Reply-To: <3EFAEB43.9080509@thinkingcat.com> References: <4.3.2.7.2.20030527132518.0389cc98@mailhost.iprg.nokia.com> <04c701c31ec8$1efb8b40$0300a8c0@DFNJGL21> <5.1.0.14.2.20030515114433.04767ac8@mail.windriver.com> <4517643810.20030516200534@brandenburg.com> <04c701c31ec8$1efb8b40$0300a8c0@DFNJGL21> <4.3.2.7.2.20030527132518.0389cc98@mailhost.iprg.nokia.com> <4.3.2.7.2.20030625142237.02d41bc0@127.0.0.1> <3EFAEB43.9080509@thinkingcat.com> Date: Thu, 26 Jun 2003 14:27:38 -0400 To: problem-statement@alvestrand.no From: John Morris Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: Listing affiliations X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 At 8:46 AM -0400 6/26/03, Leslie Daigle wrote: > >A couple or few years ago, I suggested it would be helpful to have >brief statement (or web page) about/from each IAB member, linked >off the IAB member listing page, so that people could have a clue what areas >of interest/expertise the various IAB members have. It strikes >me that would be an appropriate place to list affiliations. > >You can see how well the idea flew the last time I proposed it. FWIW, in thinking about other groups or committees that perform functions similar to some of the work of the IAB, the expert committees of the National Research Council of the U.S. National Academies of Science come to mind. As a number of IABers obviously know (since they have served on those committees), the NRC publishes useful bios for all members of all of its committees. See for example http://www4.nas.edu/webcr.nsf/CommitteeDisplay/CSTB-L-99-07-A?OpenDocument The NRC certainly has a number of legal requirements of openness that do not apply to the IAB, but I still think that those NRC bios set a good example for the IAB to follow. John From problem-statement-bounces@alvestrand.no Thu Jun 26 15:44:24 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18245 for ; Thu, 26 Jun 2003 15:44:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D152662577; Thu, 26 Jun 2003 21:43:08 +0200 (CEST) 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 5663E623CD for ; Thu, 26 Jun 2003 21:43:05 +0200 (CEST) Received: (qmail 92155 invoked from network); 26 Jun 2003 19:49:55 -0000 Received: from unknown (HELO pobox.org.sg) (207.253.237.204) by sentosa.post1.com with SMTP; 26 Jun 2003 19:49:55 -0000 Message-ID: <3EFB4CCD.2040207@pobox.org.sg> Date: Fri, 27 Jun 2003 03:43:09 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Avri Doria References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Cc: Harald Alvestrand Subject: Re: rough consensus (was Re: "trouble maker") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 general problem is our current process of letting wg chairs determine rough consensus without a general definition. (Yes, I know it is a feature too :P) Since people have different opinion of the "rough consensus", those (especially the doc authors or someone with more then casual interest[1]) who disagree with the chair become resentful of the IETF process. Personally, I already lost count how many times it happens. It is not healty. [1] "more then casual interest" != vested interest. (See Keith v.s NAT, no offense intended :-) -James Seng Avri Doria wrote: > Hi, > > This has been a very interesting discussion, and I beleive that > it is important that the details of this issue be debated and resolved. > I do not believe that should be done on this list. It was good to get > the problem discussed so that people could do an abstraction of it > for the problem statement, but I would like to avoid dwelling on the > specific arguments relating to it any longer. > > At this point I ask that people concentrate on the general language > for the problem statement so that we can make sure that the problem > is reflected adequately in the problem statement. > > Thanks > > Avri > co-chair > > > > > On torsdag, jun 26, 2003, at 13:45 Asia/Seoul, Harald Tveit Alvestrand > wrote: > > > From problem-statement-bounces@alvestrand.no Thu Jun 26 16:42:12 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20669 for ; Thu, 26 Jun 2003 16:42:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A8123623CD; Thu, 26 Jun 2003 22:41:41 +0200 (CEST) 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 6ECB86230F for ; Thu, 26 Jun 2003 22:41:39 +0200 (CEST) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h5QKj1F31404 for ; Thu, 26 Jun 2003 13:45:01 -0700 Date: Thu, 26 Jun 2003 13:41:33 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/11) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <194231154582.20030626134133@brandenburg.com> To: problem-statement@alvestrand.no In-Reply-To: <20030624160713.3ef09588.moore@cs.utk.edu> References: <3EDDA77F.8050700@piuha.net> <3EDDA77F.8050700@piuha.net> <5.1.0.14.2.20030607123251.047d9aa0@mail.windriver.com> <174132382475.20030607215256@brandenburg.com> <20030624160713.3ef09588.moore@cs.utk.edu> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Subject: Re: Complex Problems (Was: Re: Discipline of Internet Protocol Engineering) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Keith, >> IETF work has been notably successful only when it has done bite-sized >> bits of coherent work. It has attacked complex issues successfully >> only when it has attacked the issues piecemeal. KM> I think we have had far more failures than successes by attacking issues KM> piecemeal. This sub-thread has really excellent potential for becoming a rat-hole. However the divide-and-conquer principle that I am citing clearly is interpreted differently by different people. So, perhaps it is worth trying to dodge the rat-holes, while trying to explore the matter substantively: Solving a big, complicated problem by trying to develop a single, coherent specification -- no matter how many documents; the point is about making all the bits of work proceed in lock-step -- is a well-known way to ensure failure. One only needs to look at OSI in general, and X.400 in particular. (And by way of anticipating one of the rat-holes, I'll note that X.400 achieved the rare success of having too much be integrated all at once, but still lack core bits of functionality.) The usual logic for explaining this problem is that the complexity of juggling all the issues, across the entire service, simply buries the development effort. At best, it ensures that the work is produced much, much later, often after the market has found an alternate solution. (And that is, most certainly, what happened to OSI. I can elaborate on this is some detail, if anyone really challenges this point.) Breaking down a complex problem into smaller pieces that are individually useful does two things that are quite good: 1) It permits each piece of work to be useful, even if some other piece of work has a persistent problem; and 2) it permits turning the crank on the specification engine more quickly and more frequently. This means that we get operational experience more quickly and can then, quickly, refine the specifications to match actual field knowledge. With large, integrated efforts, the inter-dependencies mean that the whole of the work is not useful until the most problematic part is completed. And it means that it is quite a few years before there is any feedback from the user community;. If there was a problem with the major design decisions that were made, they become essentially impossible to change, because things took so long to delivery. A couple of examples of the success stories in the Internet: (As an aside, I'll note that TCP and IP were originally one protocol, but the divide-and-conquer approach was adopted prior to fielding the technology. This makes exploring and delivering new transport modules far easier. Had this not been done, we'd be using TCP even when a UDP would have been sufficient.) Is IP a failure? Besides independent development of TCP and UDP, from the IP core, ICMP has been able to proceed independently, as has different address-mapping efforts and, for that matter, address interpretation efforts. Is email a failure? Transfer services and content services have proceeded with considerable independence. This permits multiple transfer services. (Though folks might think there is only SMTP, there are others, and there used to be more. So another bonus from good divide-an-conquer is vastly superior adaptability to changing conditions, such as adoption by "fringe" or "new" networking stacks.) And note the several large, integrated efforts to replace the ridiculously limited capabilities of Internet mail -- notably to achieve multi-media. By contrast the silly, ugly, inefficient functional module, called MIME, retrofitted multi-media onto Internet mail with remarkable success and remarkably quickly. (One could go down a rathole about nonconformance, noting how badly we suffer from excessive variance in email system behavior, but I claim that is due to lack of enforcement, rather than due to any architectural issues. Given the wide range of support for HTML, and the like, this might be an applications-level issue. But it is not a big-vs-small design effort issue.) In fact, this highlights one of the other, surprising benefits of a divide-and-conquer approach, namely that it permits post-hoc additions that were not planned. When the original philosophy is to do as little as possible to be useful, knowing that more bits of related work will be done, then it often is easier to do some of those bits many years later. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Thu Jun 26 18:44:25 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25749 for ; Thu, 26 Jun 2003 18:44:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 06E93623CD; Fri, 27 Jun 2003 00:43:55 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2F82D6230F for ; Fri, 27 Jun 2003 00:43:53 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h5QMhjN09942; Thu, 26 Jun 2003 18:43:46 -0400 (EDT) Date: Thu, 26 Jun 2003 18:43:45 -0400 From: Keith Moore To: Dave Crocker Message-Id: <20030626184345.0ce8e673.moore@cs.utk.edu> In-Reply-To: <194231154582.20030626134133@brandenburg.com> References: <3EDDA77F.8050700@piuha.net> <3EDDA77F.8050700@piuha.net> <5.1.0.14.2.20030607123251.047d9aa0@mail.windriver.com> <174132382475.20030607215256@brandenburg.com> <20030624160713.3ef09588.moore@cs.utk.edu> <194231154582.20030626134133@brandenburg.com> X-Mailer: Sylpheed version 0.9.2 (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 Cc: dhc@dcrocker.net Cc: moore@cs.utk.edu Subject: Re: Complex Problems (Was: Re: Discipline of Internet Protocol Engineering) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > Breaking down a complex problem into smaller pieces that are > individually useful does two things that are quite good: divide-and-conquer is all well and good, provided the pieces don't conflict when we try to use them together. it's not divide-and-conquer I object to, it's our too-frequent failure to provide an architecture that informs the design of each of the pieces in a way that allows them to work together. also, there are too many cases where one group tries to take something that is already in use by others and change it in a way that favors the group making the change while harming its functionality for others. NAT in IPv4, linklocal addressing in IPv4, and content negotiation over SMTP, are all good examples. Keith From problem-statement-bounces@alvestrand.no Thu Jun 26 19:44:38 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27568 for ; Thu, 26 Jun 2003 19:44:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7B7A56230A; Fri, 27 Jun 2003 01:43:51 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8A5F2622AC for ; Fri, 27 Jun 2003 01:43:49 +0200 (CEST) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196])h5QNhlMk046336 for ; Fri, 27 Jun 2003 01:43:47 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])h5QNhlZh222444 for ; Fri, 27 Jun 2003 01:43:47 +0200 Received: from gsine04.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA47306 from ; Fri, 27 Jun 2003 01:43:44 +0200 Message-Id: <3EFB853D.A527E573@hursley.ibm.com> Date: Fri, 27 Jun 2003 01:43:57 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: problem-statement@alvestrand.no References: <2A1D4C86842EE14CA9BC80474919782E0D228E@mou1wnexm02.verisign.com> <3EFA237F.9874E801@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: rough consensus (was Re: "trouble maker") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit I'm sorry for adding to everybody's email load, but it's been pointed out to me that what I wrote below might be misinterpreted. The allowed grounds for appeal to the ISOC Board are quite narrow (extract below). What I meant is that an appeal against the rules of the appeals process, on the grounds that these rules themselves are unfair, would be appear to be a valid subject of appeal to the ISOC Board. >From RFC 2026: > 6.5.3 Questions of Applicable Procedure > > Further recourse is available only in cases in which the procedures > themselves (i.e., the procedures described in this document) are > claimed to be inadequate or insufficient to the protection of the > rights of all parties in a fair and open Internet Standards Process. > Claims on this basis may be made to the Internet Society Board of > Trustees. Brian Brian E Carpenter wrote: > > "Hallam-Baker, Phillip" wrote: > > > > And who hears the appeal? - A committee where the individual responsible for > > the abuses has audience rights and I do not. > > Not at all. The IAB has several times held open hearings on appeals, for > good reason. And by the way, unfairness in the appeals process would > seem like reasonable grounds for a final appeal to the ISOC Board. > > ... > > > > If we are going to have a discussion about PROBLEM then discussion of > > specific failures of the process would seem to be a good starting point. > > But if the appeal process and/or the recall process haven't been used, you > simply can't assert a process failure. > > > If we are ever going to get to a SOLUTION it would be good to start hearing > > that others accept that I am not the only person making the complaint about > > autocratic top down proceedures and that they are having a widespread > > effect. > > Indeed. One swallow does not a summer make. It would be interesting to know > how many of the WGs have members who would assert such problems. > > Brian From problem-statement-bounces@alvestrand.no Thu Jun 26 20:57:48 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29477 for ; Thu, 26 Jun 2003 20:57:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7BEF16230F; Fri, 27 Jun 2003 02:28:13 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2666B6230A for ; Fri, 27 Jun 2003 02:28:12 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h5R0SAch002662 for ; Thu, 26 Jun 2003 17:28:10 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jun 2003 17:28:10 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22A4@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'problem-statement@alvestrand.no'" Date: Thu, 26 Jun 2003 17:28:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: Voting - no specification without representation X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Brian writes: >It would be a problem if a design team or directorate (which are >explicitly not open, as Phill says) proposed a solution that did >not meet rough consensus in the WG or at IETF Last Call and then >the IESG put that solution on standards track. That would in fact >be a major violation of RFC 2026. My problem is with the transparency of the process, not specifically the issue of whether it did or did not violate RFC 2026. In my view and according to a litteral reading of RFC 2026 the process was violated, but it is the violation of the spirit of openness that led to calls for the WG chair to resign (and not just from me). I agree that the above would be a violation, but when a protocol has yet to be deployed the use of the same tactics to defend the status quo is an exactly equivalent abuse. According to RFC 2026 the directorate is appointed by the AD and reports to the ADs alone. There was a technical violation of 2026 in that the WG chair had no business referring anything to the directorate, even though he is AD in another area. The problem is that the referal was done without any notice to the working group and was used to supress the consensus that the WG had then reached to forward OPTIN to the IESG for approval. So while everyone in the group is waiting for the draft to go to the IESG it is actually stalled in a private queue of the chair's invention. In a commercial environment a delay can have exactly the same effect as a veto. I do not believe that this behavior would survive judicial review. If it is as you claim consistent with RFC 2026 then RFC 2026 needs urgent modification to correct it. A process that allows the chair to pocket WG decisions that he has a partisan position against and then recycle the question until he can pretend that the result was the one he wanted is not open by any definition I consider credible. Or forget the process issue for a moment, look at the outcome of of the process. For me the main point in a standards process is to obtain the buy in of all the parties necessary to deploy an interoperable spec. In this case the IETF has by its refusal to insist on an open and fair process ended up with a spec that is not going to be supported by the operators of the largest zones in its current form. That is not a successful result in my view. To get XKMS adopted as an industry standard I had to spend a considerable amount of time working out how my direct and indirect competitors would benefit from supporting it - as well of course as my partners. The result of this 'consensus' process is an undeployable spec that is not supported by the principal industry stakeholders. This outcome is every bit as bad as any that is alledged for OSI process. Only instead of having a vote and moving on the issue has simmered for three years already and is far from over. My experience of voting in OASIS is that it is rarely divisive. I have not seen the type of vote packing that has occurred in WAP this is probably because you have to attend the con-calls to vote. Phill PS: If you think that the appeals process is not equally broken then why not prove me wrong by making the appeal yourself? From problem-statement-bounces@alvestrand.no Thu Jun 26 20:59:17 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29510 for ; Thu, 26 Jun 2003 20:59:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 066056230F; Fri, 27 Jun 2003 02:58:47 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from cms1.etri.re.kr (cms1.etri.re.kr [129.254.16.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2CE696230A for ; Fri, 27 Jun 2003 02:58:45 +0200 (CEST) Received: from apocalypse.org (129.254.191.55 [129.254.191.55]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NAHCTBV0; Fri, 27 Jun 2003 09:58:31 +0900 Date: Fri, 27 Jun 2003 09:58:30 +0900 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: avri To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22A4@mou1wnexm02.verisign.com> Message-Id: <77E1A470-A83A-11D7-946F-000393CC2112@apocalypse.org> X-Mailer: Apple Mail (2.552) Subject: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 personally] On fredag, jun 27, 2003, at 09:28 Asia/Seoul, Hallam-Baker, Phillip wrote: > > PS: If you think that the appeals process is not equally broken > then why not prove me wrong by making the appeal yourself? > > this brings up the problem that has appeared more in its guise as a solution on this list. the IETF has no ombuds-process (leaving aside whether it is and individual or a group that implements it) what i mean is that in cases where, for whatever reason: - language barrier - fear of being ostracized - belief in the process itself being valid - ability to do all the work involved - whatever an individual does not take advantage of the process, there is no other recourse. it can be argued that the nature of the process make it too difficult a barrier for many to overcome, sure, in the outside world, we can all be our own lawyers, but how many of us are really qualified for such a role. i think the same logic may apply in the IETF - how many of us are qualified to represent ourselves in the appeals process. and the lack of some entity that one can go to so and say 'help me, please' seems to me a problem. so the problem may be: There is no independent body in the IETF responsible for helping individuals who have process issues that may need redress. (i assume body can mean open body, i.e. person, or several people in a group - that is a solution detail) From problem-statement-bounces@alvestrand.no Thu Jun 26 21:00:02 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29543 for ; Thu, 26 Jun 2003 21:00:01 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A1C1A62573; Fri, 27 Jun 2003 02:59:32 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 20C876230A for ; Fri, 27 Jun 2003 02:59:30 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h5R0xTch010374 for ; Thu, 26 Jun 2003 17:59:29 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jun 2003 17:59:29 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22A5@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'problem-statement@alvestrand.no'" Date: Thu, 26 Jun 2003 17:59:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Brian writes: 1. The IAB as an advisory board for WG formation (and in practice for many major IESG decisions) 2. The appeals process 3. The recall process (never tested, for some reason) 4. Payback time, i.e. the NomCom process. Now, it's possible we need *more* checks and balances, of course. The problem with all the above is that they are exclusively top down approaches. NOMCON is just as top down as the rest of the structure. Consider the requirements for membership of nomcon, you have to attend two IETFs and commit to attend a further two - including one likely to be held abroad at a potentially expensive to attend location and on top commit a substantial amount of time. If you look at the members of past nomcons you will see they are mainly existing members of the establishment or pretty obvious aspirants to join the establishment. The problem here is that the IAB is appointed in the same way as the IESG and is just as unaccountable. The great fear of the process designers appears to have been mob rule, or worse any form of decision making that would make appointees accountable to a constituency of any sort. The Nomcon is not a check for the simple reason nobody knows what the composition will be. The chances that a randomly selected group of people will do something radical is actually quite slim. It only happened a couple of years ago because someone got selected for nomcon who was determined to shake things up. The appeals process is for some reason regarded as the nuclear option. I suspect because one time it was used the IESG took it on itself to censure a member for having the temerity to make an appeal. Phill From problem-statement-bounces@alvestrand.no Thu Jun 26 21:04:53 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29630 for ; Thu, 26 Jun 2003 21:04:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 435376230F; Fri, 27 Jun 2003 03:04:23 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from apocalypse.org (apocalypse.org [192.48.232.17]) by eikenes.alvestrand.no (Postfix) with ESMTP id EEA7B6230A for ; Fri, 27 Jun 2003 03:04:20 +0200 (CEST) Received: from acm.org (IDENT:bduLrJZkLnbFrrUCk01Xg7VkqbN+2tDe@apocalypse.org [192.48.232.17]) by apocalypse.org (8.11.6/8.11.6) with ESMTP id h5R14FG21783 for ; Thu, 26 Jun 2003 21:04:16 -0400 Date: Fri, 27 Jun 2003 10:04:11 +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: <2A1D4C86842EE14CA9BC80474919782E0D22A4@mou1wnexm02.verisign.com> Message-Id: <43642C24-A83B-11D7-946F-000393CC2112@acm.org> X-Mailer: Apple Mail (2.552) Subject: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 of the issues that came up in the discussion on rough consensus is the issue of ADs being WG chairs - either in their own area or in another area. I do not believe this dual role aspect of IETF management is yet reflected in the problem draft. Should it be? a. From problem-statement-bounces@alvestrand.no Thu Jun 26 21:42:49 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00476 for ; Thu, 26 Jun 2003 21:42:48 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2A1BB6230F; Fri, 27 Jun 2003 03:40:44 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from cms1.etri.re.kr (cms1.etri.re.kr [129.254.16.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id D98866230A for ; Fri, 27 Jun 2003 03:40:41 +0200 (CEST) Received: from apocalypse.org (129.254.191.55 [129.254.191.55]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NAHCTDC1; Fri, 27 Jun 2003 10:40:31 +0900 Date: Fri, 27 Jun 2003 10:40:33 +0900 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: avri To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit Message-Id: <5815D6E8-A840-11D7-946F-000393CC2112@apocalypse.org> X-Mailer: Apple Mail (2.552) Subject: on the issue of nomcom X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 now what hat i am wearing on this one, chair of Nomcom WG co-chair of Problem WG] Several people have made Nomcom an issue. As chair of Nomcom WG with a charter that is quite definite in the lack of a mandate to change the process in any fundamental way, i do not believe that the problems people bring up can be dealt with within the current charter. For any problems that are within that charter, the group is currently in last call on draft-ietf-nomcom-rfc2727bis-05.txt As WG chair of Nomcom WG, it is my fond hope that we succeed in meeting the chartered goals of that group and deliver this document to the IESG and IETF membership for review in time for it to be used by the next NomCom. However, there may be more fundamental, more structural issues with the way the IETF selects its leadership. If so, it seems to me there should be a statement in the Problem Statement to that effect. Is there a consensus that such a structural problem exists? Is there a suggested, non solutionist, wording for the problem statement of that problem? a. [CoI notice: i have all sorts of possible conflicts of interest on this topic, and any Problem WG chair issues will need to be dealt with by Melinda. i did feel it necessary to say something on this list about it.] From problem-statement-bounces@alvestrand.no Thu Jun 26 22:13:52 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01175 for ; Thu, 26 Jun 2003 22:13:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 617A76230F; Fri, 27 Jun 2003 04:13:21 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9D3906230A for ; Fri, 27 Jun 2003 04:13:16 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h5R2DFch024041 for ; Thu, 26 Jun 2003 19:13:15 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jun 2003 19:13:15 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22A7@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'problem-statement@alvestrand.no'" Date: Thu, 26 Jun 2003 19:13:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 believe this issue should be in the issues draft. I believe that it was one of the major reasons for the DNSEXT process failure. I did not feel that I had effective recourse to the AD when I was complaining about the activities of a fellow AD. Another issue was the chair's abuse of the DNS Directorate process to supress the first WG consensus on OPTIN. According to 2026 only the AD is allowed to consult the Directorate. This had a measurable effect on the process. What SHOULD have happened the first time round is that the WG consensus on the last call SHOULD have been acknowledged by the chair. The draft SHOULD then have been passed to the AD who COULD had consulted the Directorate if he choose. The difference is absolutely critical here. The only reason that the second third and fourth last calls could be made was that the original last call result was suppressed. The dynamic of the group discussion would have been completely different even if the draft had been returned by the IESG for ammendment or further work. Incidentally, this whole process has been raised repeatedly with the people who are now complaining about me complaining. Each abuse of the process was reported to the ADs at each stage. I have raised the issue with Harald on numerous occasions. They had the power both to rectify the original abuses and to prevent further abuses. Instead they decided to take the easy route and sit by rather than challenge an AD who was also abusing his position as WG chair. Phill From problem-statement-bounces@alvestrand.no Fri Jun 27 01:41:26 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05996 for ; Fri, 27 Jun 2003 01:41:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C26DD62586; Fri, 27 Jun 2003 07:40:54 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3FB9E62577 for ; Fri, 27 Jun 2003 07:40:52 +0200 (CEST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h5R5FaY12425 for ; Thu, 26 Jun 2003 22:15:36 -0700 Date: Thu, 26 Jun 2003 22:15:35 -0700 (PDT) From: Bernard Aboba To: problem-statement@alvestrand.no Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: MAJOR ISSUE: WG formation process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Having looked through the archives, I haven't seen much discussion on this topic, so I thought I'd bring it up. Is there a "problem" here? I'd be interested if anyone has looked at the time it takes to get a WG going -- that is, the time between when the first BOF occurs and when the announcement of WG chartering occurs. If our focus is timeliness and relevance, then this also needs to occur in a timely way. In general, I'm curious as to the minimum, average, and maximum times that is required for WG formation and how this compares to say, the time it takes to issue the first document once the WG is chartered. Of course, comments on other aspects of the WG formation process - predictability, transparency -- are also welcome. From problem-statement-bounces@alvestrand.no Fri Jun 27 03:05:23 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19626 for ; Fri, 27 Jun 2003 03:05:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F3B306258F; Fri, 27 Jun 2003 09:04:51 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from netcore.fi (netcore.fi [193.94.160.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BB1DB62577 for ; Fri, 27 Jun 2003 09:04:49 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h5R74hr04095; Fri, 27 Jun 2003 10:04:44 +0300 Date: Fri, 27 Jun 2003 10:04:43 +0300 (EEST) From: Pekka Savola To: Keith Moore In-Reply-To: <20030624143318.4508b4ff.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: problem-statement@alvestrand.no Cc: "Hallam-Baker, Phillip" Subject: Re: Trusting the IESG to manage the reform process (was: Re: Doing t he Right Things?) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Tue, 24 Jun 2003, Keith Moore wrote: > > The simple fact is that no > > matter what anyone under 40 does in the IETF they are never going to > > get accepted into the inner circle. > > I was on IESG for four entire years before I turned 40. Before that I > was a working group chair, and author of several RFCs. This wasn't very > long ago. I must concur that I don't see how age affects anything, except perhaps your own self (ie. some might be hesitant to make contributions, etc. because they think they would be shunned because of their age, their inexperience in how IETF works, etc.etc.). I have been WG chair and a couple of directorates before I turned 25. I haven't felt excluded at all, the least of all based on age. Maybe I could put that as a bit tongue-in-cheek: "Childs can be graybeards while graybeards can also be childs." -- 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 Jun 27 03:33:18 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19888 for ; Fri, 27 Jun 2003 03:33:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A1E036258F; Fri, 27 Jun 2003 09:32:46 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from netcore.fi (netcore.fi [193.94.160.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1946162577 for ; Fri, 27 Jun 2003 09:32:44 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h5R7We404342; Fri, 27 Jun 2003 10:32:41 +0300 Date: Fri, 27 Jun 2003 10:32:40 +0300 (EEST) From: Pekka Savola To: "Hallam-Baker, Phillip" In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D2269@mou1wnexm02.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "'problem-statement@alvestrand.no'" Subject: Re: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Tue, 24 Jun 2003, Hallam-Baker, Phillip wrote: > "i.e. there should be no place for the term "trouble maker" in IETF > documents. " > > I agree, I think that the problem here is that it becomes very easy for a > partisan chair to further reinforce his power by invoking this phrase. > > DNSSEC has just produced a spec that cannot be deployed. The WG was in favor > of fixing the spec but the chair as we all know had other ideas. > > > Pointing out that the spec was broken resulted in numerous atempts to > intimidate me by 'reporting me to my management' as a 'trouble maker'. Like > get a clue, who do you think had asked me to push for the protocol changes > in the first place? [...] I think the last sentence is interesting and troubling, at the same time. One doesn't interest the interests of the employer/management in the IETF. Now, I just tried to look at some documents, including: - RFC2026 - the TAO - newcomer's orientation web page and slides - some additional introductory slides linked under www.ietf.org .. and it seems apparent to me that this "tenet" isn't being stated as explicitly as it should. So, there seems to be a problem in the training/education of regular IETF participants (and not just the IESG/IAB/WGchair/DocEditor/etc.) too. -- 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 Jun 27 03:35:51 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19913 for ; Fri, 27 Jun 2003 03:35:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E144A62597; Fri, 27 Jun 2003 09:35:19 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from netcore.fi (netcore.fi [193.94.160.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CFADD6258F for ; Fri, 27 Jun 2003 09:35:17 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h5R7ZAS04374; Fri, 27 Jun 2003 10:35:15 +0300 Date: Fri, 27 Jun 2003 10:35:10 +0300 (EEST) From: Pekka Savola To: Spencer Dawkins In-Reply-To: <014601c33a6f$908fcd30$8100000a@DFNJGL21> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: problem-statement@alvestrand.no Subject: Re: ISSUE: Meeting scheduling X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Tue, 24 Jun 2003, Spencer Dawkins wrote: > There's probably a micro aspect to this, as well as > a macro aspect - http://www.ietf.org/meetings/wg_agenda_57.html > has exactly eight WG/BoF agendas listed, including three MobileIP > agendas and two general-area agendas. > > I really do understand our dependence on people who are willing to > come for the week, not just for a morning, but how can anyone > make an informed decision on what sessions they need to be at, > to accommodate part-time attendance plans? Moreover, the flexibility of the agenda is such that IMHO it is not possible to make make reasonable part-time attendance plans after the agenda has firmed up .. and then it is too late and costly (which was the one of the most important motives to begin with) already. -- 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 Jun 27 09:22:38 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27365 for ; Fri, 27 Jun 2003 09:22:37 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 454B16259C; Fri, 27 Jun 2003 15:21:49 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from znsgs01r.nortelnetworks.com (h42s128a211n47.user.nortelnetworks.com [47.211.128.42]) by eikenes.alvestrand.no (Postfix) with ESMTP id 08A8562594 for ; Fri, 27 Jun 2003 15:21:43 +0200 (CEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124])id h5RDLeU27325 for ; Fri, 27 Jun 2003 14:21:40 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jun 2003 14:21:40 +0100 Message-ID: <4103264BC8D3D51180B7002048400C45016234D5@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "'avri'" , problem-statement@alvestrand.no Date: Fri, 27 Jun 2003 14:21:39 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: RE: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 think what you are proposing here differs from what is usually labelled as an ombuds-process or regarding the powers of an ombuds-person. In most existing implementations the ombuds-person can only get involved once the complainant has exhausted all the other avenues of appeal and got nowhere. What you seem to be proposing here is a sort of counsellor service or citizens advice bureau to assist people in asserting their rights when they aren't sure what to do. It may be appropriate to have both. Regards, Elwyn > -----Original Message----- > From: avri [mailto:avri@apocalypse.org] > Sent: 27 June 2003 01:59 > To: problem-statement@alvestrand.no > Subject: Ombuds-process > > > [speaking personally] > > > On fredag, jun 27, 2003, at 09:28 Asia/Seoul, Hallam-Baker, Phillip > wrote: > > > > PS: If you think that the appeals process is not equally broken > > then why not prove me wrong by making the appeal yourself? > > > > > > this brings up the problem that has appeared more in its guise > as a solution on this list. > > the IETF has no ombuds-process (leaving aside whether it is > and individual or a group that implements it) > > what i mean is that in cases where, for whatever reason: > > - language barrier > - fear of being ostracized > - belief in the process itself being valid > - ability to do all the work involved > - whatever > > an individual does not take advantage of the process, > there is no other recourse. it can be argued that the > nature of the process make it too difficult a barrier for > many to overcome, sure, in the outside world, we can > all be our own lawyers, but how many of us are really > qualified for such a role. i think the same logic may > apply in the IETF - how many of us are qualified to > represent ourselves in the appeals process. > and the lack of some entity that one can go to so and > say 'help me, please' seems to me a problem. > > so the problem may be: > > There is no independent body in the IETF responsible for > helping individuals who have process issues that may need > redress. > > (i assume body can mean open body, i.e. person, or several > people in a group - that is a solution detail) > > > From problem-statement-bounces@alvestrand.no Fri Jun 27 10:52:08 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02294 for ; Fri, 27 Jun 2003 10:52:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A603D6259C; Fri, 27 Jun 2003 16:51:37 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7B8D262278 for ; Fri, 27 Jun 2003 16:51:35 +0200 (CEST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h5REpXch019090; Fri, 27 Jun 2003 07:51:33 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jun 2003 07:51:33 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22AB@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Pekka Savola'" , "Hallam-Baker, Phillip" Date: Fri, 27 Jun 2003 07:51:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Cc: "'problem-statement@alvestrand.no'" Subject: RE: "trouble maker" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > > Pointing out that the spec was broken resulted in numerous > atempts to > > intimidate me by 'reporting me to my management' as a > 'trouble maker'. Like > > get a clue, who do you think had asked me to push for the > protocol changes > > in the first place? > [...] > > I think the last sentence is interesting and troubling, at > the same time. Why don't you get disturbed by the sentence that proceeded it? If it is fair game to attempt to attack people by reporting them to management then why not regard the ADs as fair game in the same way? > One doesn't interest the interests of the employer/management > in the IETF. My employer wants to deploy DNSSEC and other protocols. That is why they paid the airfare and hotel bill for me to attend. Same for every other person who attends on their employer's expenses. In this case there was a serious issue that affected my employer. We want to deploy DNSSEC. The specs as written are unnecessarily expensive to deploy, this unnecessary expense can be removed with a small protocol change that it is agreed that the group reached consensus on. What you are trying to say here is that there SHOULD be NO WAY for a company that happens to be affected by a protocol issue in a serious way to be able to raise it in the process. What this comes down to is trying to level the playing field so only the establishment get to speak from authority. In the real world I don't need the support of the IETF, I need the support of companies such as Microsoft, IBM, CISCO, Sun, etc. Getting a standards body endorsement is a means to an end. I have no interest in excluding other parties, there is always a place for ideas and particularly requirements. The paranoia that seems to seize the IETF that the big companies might realize their strength and exclude the small guy. So to prevent this the top down establishment was created to enforce control and the myth of creative anarchy was created to prevent people noticing. So lets drop DNS for a moment, lets consider the failure to secure BGP. This is going to become a major issue soon, spam senders have been hijacking unused IP blocks for years, there will soon be incentives for them to hijack unused blocks. A not unreasonable issue for the ISP/backbone providers is how to deploy any solution using legacy infrastructure. It should be fairly clear that expecting them to upgrade every router to run BGP over IPSEC is going to have limited take up. This is even more so when you consider how much security you get from link layer security in that application. The way I would approach this problem is to get a bunch of the major ISP/backbone providers together into a room with the IP address issuers and a bunch of security consultants. I would then run through the same security requirements analysis process that I would work through with any other client. The IETF route seems to have been open the architecture document and try to slam IPSEC onto them. Thump! Here comes the answer from on high. Phill From problem-statement-bounces@alvestrand.no Fri Jun 27 11:23:11 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03911 for ; Fri, 27 Jun 2003 11:23:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 82FEE625A4; Fri, 27 Jun 2003 17:22:41 +0200 (CEST) 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 B82B26259C for ; Fri, 27 Jun 2003 17:22:38 +0200 (CEST) Message-ID: <002c01c33cbf$2dd2b6b0$636015ac@dclkempt40> From: "James Kempf" To: "Avri Doria" , References: <43642C24-A83B-11D7-946F-000393CC2112@acm.org> Date: Fri, 27 Jun 2003 08:17:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 of the issues that came up in the discussion on rough consensus > is the issue of ADs being WG chairs - either in their own area or in > another > area. > > I do not believe this dual role aspect of IETF management is yet > reflected > in the problem draft. > > Should it be? > As long as the AD acting as a WG chair recluses themselves from any and all IESG decisions having to do with the WG, to avoid conflict of interest, I don't think there should be a problem. I think its somewhat more questionable if the WG is in the same area, since it removes one person from oversight, and having two technically knowledgable, independent opinions on a WG is often useful. That said, I cannot see how, given the workload, an AD can possibly do a good job as a WG chair and still expect to fufill their duties as an AD. Just on the basis of that alone, it might be sensible to consider some kind of strong disapproval, if not restriction, and make it an exceptional case. My 0.02 euro. jak From problem-statement-bounces@alvestrand.no Fri Jun 27 12:52:16 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07205 for ; Fri, 27 Jun 2003 12:52:14 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E0D5D625A6; Fri, 27 Jun 2003 18:51:34 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0FDC062594; Fri, 27 Jun 2003 18:51:32 +0200 (CEST) Date: Fri, 27 Jun 2003 09:47:34 -0700 From: Harald Tveit Alvestrand To: avri , problem-statement@alvestrand.no Message-ID: <552100488.1056707254@localhost> In-Reply-To: <77E1A470-A83A-11D7-946F-000393CC2112@apocalypse.org> References: <77E1A470-A83A-11D7-946F-000393CC2112@apocalypse.org> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 27. juni 2003 09:58 +0900 avri wrote: > [speaking personally] > the IETF has no ombuds-process (leaving aside whether it is > and individual or a group that implements it) > > what i mean is that in cases where, for whatever reason: > > - language barrier > - fear of being ostracized > - belief in the process itself being valid > - ability to do all the work involved > - whatever > > an individual does not take advantage of the process, > there is no other recourse. it can be argued that the > nature of the process make it too difficult a barrier for > many to overcome, sure, in the outside world, we can > all be our own lawyers, but how many of us are really > qualified for such a role. i think the same logic may > apply in the IETF - how many of us are qualified to > represent ourselves in the appeals process. > and the lack of some entity that one can go to so and > say 'help me, please' seems to me a problem. > > so the problem may be: > > There is no independent body in the IETF responsible for > helping individuals who have process issues that may need > redress. I think the problem can be stated in even more nonsolutionist terms.... When an individual thnks that the process has not produced a result that is best for the Internet, there is no formal process to aid the individual in seeking to change that result. That's a VERY mild statement, and for numerous reasons: - It is not clear to me that the IETF is in the business of dispensing "redress". We're not here to seek an abstract notion of justice, but to make quality, relevant standards for the Internet; our adherence to process is a tool in our seeking those standards, and the reason we want departures from those processes to be challenged is that we think such departures will make it less likely that the right decisions are made. - It is not clear to me that the IETF formal apparatus is the best way of aiding people seeking to change IETF decisions who are challenged by the hurdles you mention. In the civil-justice court system, lawyers are rarely employees of the court. - It is not clear to me that anything the IETF formal apparatus could have done in the case of Phil Hallam-Baker and the DNSEXT working group would have made him more happy; after all, he does not seem to be hampered by a language barrier, unfamiliarity with the process, fear of being ostracized or ability to do work. Like many other things in the IETF, I think many of us have blithely assumed that the informal networks would take care of this - that an individual with a valid case would have friends and colleagues enough to talk over the issue with, and that one could assume that the consensus of that discussion would be reasonably close to the "right answer". I may have been wrong. From problem-statement-bounces@alvestrand.no Fri Jun 27 12:54:13 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07290 for ; Fri, 27 Jun 2003 12:54:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A90C8625A4; Fri, 27 Jun 2003 18:53:43 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by eikenes.alvestrand.no (Postfix) with ESMTP id 317F9625A6 for ; Fri, 27 Jun 2003 18:53:37 +0200 (CEST) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h5RGrZch016157 for ; Fri, 27 Jun 2003 09:53:36 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jun 2003 09:53:36 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D22AE@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'problem-statement@alvestrand.no'" Date: Fri, 27 Jun 2003 09:53:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: ISSUE: Meeting scheduling X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 >Moreover, the flexibility of the agenda is such that IMHO it is not >possible to make make reasonable part-time attendance plans after the >agenda has firmed up .. and then it is too late and costly (which >was the one of the most important motives to begin with) already. This is a big issue if you are trying to arrange related meetings at the same time. We had to arrange the JamSpam meeting the week before the IETF rather than the same week because we could not know which day the ASRG meeting would be held. There is a real problem with last minute changes that occur to the agenda. I have booked travel twice and had to rebook because the meeting I was going to attend had moved. Other times I would have made the visit much shorter. This is an important issue if you have a 2 yr old who keeps telephoning you to ask 'where's daddy'. I sense a mixed message here. On the one hand we have people who are complaining about 'tourists' crusing by WGs for something that might interest and on the other we have folk who are complaining that few people have a high level overview of what the IETF as a whole is up to. The most useful IETF sessions are frequently the plenaries when someone actually gets up and presents an idea to the whole membership. I think it is incredibly wasteful to bring 1400 people together in the same place at the same time and then spend all the time broken into little groups. A lot of times IETF discussions get rulled by standing predjudice and dogma that there is no way to challenge. Mention PKI and you will get a speil about how the PKI systems of ten years ago don't work. Mention security and you get a confused application of the end to end principle to security that is completely inappropriate. There are much better analyses of what is going on. There are a lot of complaints about groups re-inventing stuff that has existed before. But the mechanisms for communicating are limited and tend to be unidirectional. There is no way to ask why people have to reinvent. Take a case in point, use of UDP for short transactional messages. TCP/IP is fine for longstanding persistent connections. It is clumsy and unsatisfactory for short term connections that require perhaps one to four packets in each direction in a simple request/response format. It should not be a surprise that people keep reinventing this type of mechanism, it is supported by a valid engineering requirement. Phill From problem-statement-bounces@alvestrand.no Fri Jun 27 14:32:37 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10752 for ; Fri, 27 Jun 2003 14:32:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4B0F5625AC; Fri, 27 Jun 2003 20:30:33 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by eikenes.alvestrand.no (Postfix) with ESMTP id 12928625AC for ; Fri, 27 Jun 2003 20:30:32 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180])h5RIUS76070956; Fri, 27 Jun 2003 20:30:28 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])h5RIUQBS279274; Fri, 27 Jun 2003 20:30:27 +0200 Received: from gsine04.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA26110 from ; Fri, 27 Jun 2003 20:30:22 +0200 Message-Id: <3EFC8CD2.95000B51@hursley.ibm.com> Date: Fri, 27 Jun 2003 20:28:34 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: James Kempf References: <43642C24-A83B-11D7-946F-000393CC2112@acm.org> <002c01c33cbf$2dd2b6b0$636015ac@dclkempt40> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 agree that it's amazing that ADs ever say "yes" to this (except when the WG is tailing off, for example) and I think the case of being a chair in the same area is definitely a conflict of interest. I think recusal should cover the other cases. It is worth documenting. Brian James Kempf wrote: > > > > > One of the issues that came up in the discussion on rough consensus > > is the issue of ADs being WG chairs - either in their own area or in > > another > > area. > > > > I do not believe this dual role aspect of IETF management is yet > > reflected > > in the problem draft. > > > > Should it be? > > > > As long as the AD acting as a WG chair recluses themselves from any and all > IESG decisions having to do with the WG, to avoid conflict of interest, I > don't think there should be a problem. I think its somewhat more > questionable if the WG is in the same area, since it removes one person from > oversight, and having two technically knowledgable, independent opinions on > a WG is often useful. > > That said, I cannot see how, given the workload, an AD can possibly do a > good job as a WG chair and still expect to fufill their duties as an AD. > Just on the basis of that alone, it might be sensible to consider some kind > of strong disapproval, if not restriction, and make it an exceptional case. > > My 0.02 euro. > > jak From problem-statement-bounces@alvestrand.no Fri Jun 27 15:28:39 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16847 for ; Fri, 27 Jun 2003 15:28:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5079D625AC; Fri, 27 Jun 2003 21:28:08 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from exchange.timetra.com (unknown [64.47.48.7]) by eikenes.alvestrand.no (Postfix) with ESMTP id B0A71625A7 for ; Fri, 27 Jun 2003 21:28:05 +0200 (CEST) Received: from vkompella ([64.47.48.10] RDNS failed) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 27 Jun 2003 12:28:03 -0700 From: "Vach Kompella" To: "Brian E Carpenter" , "James Kempf" Date: Fri, 27 Jun 2003 12:29:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 In-Reply-To: <3EFC8CD2.95000B51@hursley.ibm.com> Importance: Normal X-OriginalArrivalTime: 27 Jun 2003 19:28:03.0792 (UTC) FILETIME=[3A7AFD00:01C33CE2] Cc: problem-statement@alvestrand.no Subject: RE: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vkompella@timetra.com List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit In one working group, a WG chair did more than recuse himself because he wanted to push through a draft he had co-authored. He actually stepped down from the chair position. I think that might be going too far. But these are "solutions". The problem statement is more about whether the following are perceived to be issues or not: - pursuing an individual draft within a WG that one co-chairs - co-chairing a WG that one oversees as an AD I'd see the former as less of an issue, and recusal is adequate. The second is a bigger issue. -Vach > -----Original Message----- > From: problem-statement-bounces@alvestrand.no > [mailto:problem-statement-bounces@alvestrand.no]On Behalf Of Brian E > Carpenter > Sent: Friday, June 27, 2003 11:29 AM > To: James Kempf > Cc: problem-statement@alvestrand.no > Subject: Re: ADs who are also WG chairs > > > I agree that it's amazing that ADs ever say "yes" to this (except > when the WG is tailing off, for example) and I think the case of > being a chair in the same area is definitely a conflict of interest. > I think recusal should cover the other cases. It is worth documenting. > > Brian > > James Kempf wrote: > > > > > > > > One of the issues that came up in the discussion on rough consensus > > > is the issue of ADs being WG chairs - either in their own area or in > > > another > > > area. > > > > > > I do not believe this dual role aspect of IETF management is yet > > > reflected > > > in the problem draft. > > > > > > Should it be? > > > > > > > As long as the AD acting as a WG chair recluses themselves from any and all > > IESG decisions having to do with the WG, to avoid conflict of interest, I > > don't think there should be a problem. I think its somewhat more > > questionable if the WG is in the same area, since it removes one person from > > oversight, and having two technically knowledgable, independent opinions on > > a WG is often useful. > > > > That said, I cannot see how, given the workload, an AD can possibly do a > > good job as a WG chair and still expect to fufill their duties as an AD. > > Just on the basis of that alone, it might be sensible to consider some kind > > of strong disapproval, if not restriction, and make it an exceptional case. > > > > My 0.02 euro. > > > > jak > > From problem-statement-bounces@alvestrand.no Fri Jun 27 15:36:29 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17271 for ; Fri, 27 Jun 2003 15:36:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 131E4625AC; Fri, 27 Jun 2003 21:34:43 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from thunker.thunk.org (thunk.org [140.239.227.29]) by eikenes.alvestrand.no (Postfix) with ESMTP id EA164625A6; Fri, 27 Jun 2003 21:34:40 +0200 (CEST) Received: from [66.92.109.27] (helo=think.thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.35 #1 (Debian)) id 19VyzW-0006Y3-00; Fri, 27 Jun 2003 15:34:38 -0400 Received: from tytso authenticated as tytso by think.thunk.org with local (Exim 3.35 #1 (Debian)) id 19VyzV-0005uM-00; Fri, 27 Jun 2003 15:34:37 -0400 Date: Fri, 27 Jun 2003 15:34:37 -0400 From: "Theodore Ts'o" To: Harald Tveit Alvestrand Message-ID: <20030627193437.GB22139@think> References: <77E1A470-A83A-11D7-946F-000393CC2112@apocalypse.org> <552100488.1056707254@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <552100488.1056707254@localhost> User-Agent: Mutt/1.5.4i Cc: problem-statement@alvestrand.no Cc: avri Subject: Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Fri, Jun 27, 2003 at 09:47:34AM -0700, Harald Tveit Alvestrand wrote: > - It is not clear to me that anything the IETF formal apparatus could have > done in the case of Phil Hallam-Baker and the DNSEXT working group would > have made him more happy; after all, he does not seem to be hampered by a > language barrier, unfamiliarity with the process, fear of being ostracized > or ability to do work. It is also not clear to me whether or not the anecdotal problems described by Phil Hallam-Baker are systemic in nature, or possibly due to personality issues; either on his part, or on the part of the AD and/or wg chair(s) involved. Of course, that is why we have an appeals process, but the fact that he chose not to use that avenue means that we don't necessarily know how the system would have worked. Phil has been very vocal about a particular experience of his, and some of his generalizations that he has made, such as asserting that no one under 40 makes it into the inner circle, have been disputed by more than one person who has pointed out several counter-examples to his generalization. As a rule, I think we need to be very careful about generalizing from a single person's experience to the general case. Phil is not alone in doing this; I've seen it done in others within the IETF context, and I've spoken out against this practice of taking a single incident and generalizing it to condemn an individual or a system has being unfair and unjustified. So please don't take this as an outright objection to Phil's comments, but just as a cautionery note. Perhaps it would be useful to find out if others had similar experiences to Phil. I certainly haven't, and I'm well under 30.... Of course, it might just be because I'm not in the inner circle (whatever that means; maybe it's just becuase I've just never been invited into any of the smoke-filled back rooms(*), and I don't know what I'm missing --- although I have been to the ones with Scotch. :-) (*) OK, I've been nomcom chair, but I can definitively state that no one was smoking in any of our meetings.... - Ted From problem-statement-bounces@alvestrand.no Fri Jun 27 15:55:56 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18145 for ; Fri, 27 Jun 2003 15:55:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 448EE625AC; Fri, 27 Jun 2003 21:55:25 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0C6AC625A6 for ; Fri, 27 Jun 2003 21:55:24 +0200 (CEST) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196])h5RJtMsn065740 for ; Fri, 27 Jun 2003 21:55:22 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])h5RJtLe5037030 for ; Fri, 27 Jun 2003 21:55:22 +0200 Received: from gsine04.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA44996 from ; Fri, 27 Jun 2003 21:55:19 +0200 Message-Id: <3EFCA137.95DEFF42@hursley.ibm.com> Date: Fri, 27 Jun 2003 21:55:35 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: problem-statement@alvestrand.no References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: ISSUE: Meeting scheduling X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Pekka Savola wrote: > > On Tue, 24 Jun 2003, Spencer Dawkins wrote: > > There's probably a micro aspect to this, as well as > > a macro aspect - http://www.ietf.org/meetings/wg_agenda_57.html > > has exactly eight WG/BoF agendas listed, including three MobileIP > > agendas and two general-area agendas. > > > > I really do understand our dependence on people who are willing to > > come for the week, not just for a morning, but how can anyone > > make an informed decision on what sessions they need to be at, > > to accommodate part-time attendance plans? > > Moreover, the flexibility of the agenda is such that IMHO it is not > possible to make make reasonable part-time attendance plans after the > agenda has firmed up .. and then it is too late and costly (which > was the one of the most important motives to begin with) already. Having been involved in scheduling discussions many times, dealing with complex clash-avoidance for essential participants, I really doubt that we can do significantly better - the only possible change is to shift the whole scheduling process several weeks earlier. And that makes it very tough to schedule BOFs, given the iterative process behind BOFs. Brian From problem-statement-bounces@alvestrand.no Fri Jun 27 16:03:10 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18273 for ; Fri, 27 Jun 2003 16:03:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B4AC9625AC; Fri, 27 Jun 2003 22:02:39 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6B013625A6 for ; Fri, 27 Jun 2003 22:02:38 +0200 (CEST) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h5RK2b76031604 for ; Fri, 27 Jun 2003 22:02:37 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])h5RK2aBS143912 for ; Fri, 27 Jun 2003 22:02:36 +0200 Received: from gsine04.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA44954 from ; Fri, 27 Jun 2003 22:02:34 +0200 Message-Id: <3EFCA2E4.AB0EDB91@hursley.ibm.com> Date: Fri, 27 Jun 2003 22:02:44 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: problem-statement@alvestrand.no References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: MAJOR ISSUE: WG formation process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Bernard Aboba wrote: > > Having looked through the archives, I haven't seen much discussion on this > topic, so I thought I'd bring it up. Is there a "problem" here? > > I'd be interested if anyone has looked at the time it takes to get a WG > going -- that is, the time between when the first BOF occurs and when the > announcement of WG chartering occurs. If our focus is timeliness and > relevance, then this also needs to occur in a timely way. In general, I'm > curious as to the minimum, average, and maximum times that is required for > WG formation and how this compares to say, the time it takes to issue the > first document once the WG is chartered. > > Of course, comments on other aspects of the WG formation process - > predictability, transparency -- are also welcome. As I think I've said already, I think that WG creation is the most important single action we take in the IETF, and that getting the objectives right is very, very important. So it's not obviously a *problem* if it takes months to create a WG. The real issue may be whether our WG creation process is right - for example do we have enough of a road map for a given area or topic to judge whether the WG fits the roadmap, or whether it has to be evaluated as a special case? Brian From problem-statement-bounces@alvestrand.no Fri Jun 27 16:29:54 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19507 for ; Fri, 27 Jun 2003 16:29:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6BAFB625AF; Fri, 27 Jun 2003 22:29:23 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from thunker.thunk.org (thunk.org [140.239.227.29]) by eikenes.alvestrand.no (Postfix) with ESMTP id C104C625A7; Fri, 27 Jun 2003 22:29:21 +0200 (CEST) Received: from [66.92.109.27] (helo=think.thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.35 #1 (Debian)) id 19VzqS-0006m8-00; Fri, 27 Jun 2003 16:29:21 -0400 Received: from tytso authenticated as tytso by think.thunk.org with local (Exim 3.35 #1 (Debian)) id 19VzqS-0005wW-00; Fri, 27 Jun 2003 16:29:20 -0400 Date: Fri, 27 Jun 2003 16:29:19 -0400 From: "Theodore Ts'o" To: Harald Tveit Alvestrand Message-ID: <20030627202919.GA22838@think> References: <77E1A470-A83A-11D7-946F-000393CC2112@apocalypse.org> <552100488.1056707254@localhost> <20030627193437.GB22139@think> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030627193437.GB22139@think> User-Agent: Mutt/1.5.4i Cc: problem-statement@alvestrand.no Cc: avri Subject: Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Fri, Jun 27, 2003 at 03:34:37PM -0400, Theodore Ts'o wrote: > Perhaps it would be useful to find out if others had similar > experiences to Phil. I certainly haven't, and I'm well under 30.... My mistake. That should have read, "well under 40...". I did add my "fifth bit" party a while ago... - Ted From problem-statement-bounces@alvestrand.no Fri Jun 27 16:34:14 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19771 for ; Fri, 27 Jun 2003 16:34:14 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 32175625AF; Fri, 27 Jun 2003 22:33:44 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0DFFA625A7 for ; Fri, 27 Jun 2003 22:33:42 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h5RKXbN03855; Fri, 27 Jun 2003 16:33:38 -0400 (EDT) Date: Fri, 27 Jun 2003 16:33:37 -0400 From: Keith Moore To: Brian E Carpenter Message-Id: <20030627163337.77a90899.moore@cs.utk.edu> In-Reply-To: <3EFCA2E4.AB0EDB91@hursley.ibm.com> References: <3EFCA2E4.AB0EDB91@hursley.ibm.com> X-Mailer: Sylpheed version 0.9.2 (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 Cc: moore@cs.utk.edu Subject: Re: MAJOR ISSUE: WG formation process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 I think I've said already, I think that WG creation is the most > important single action we take in the IETF, and that getting the > objectives right is very, very important. So it's not obviously a > *problem* if it takes months to create a WG. I agree with you that WG creation is important (though I might argue that final document approval is more important). But I do think that it probably is a problem if it takes months to create a WG. I think it's similar to the problem we have that few documents get promoted beyond Proposed Standard. In both cases one problem is that our processes are a poor impedance match for the energies that people have to put into them. And IESG tries hard to get WG charters right for much the same reason as it tries to get Proposed Standards right - because once they're approved, it's hard to fix things that are broken. And charters take a long time to get approved partially because a lot is at stake, and partially because IESG is busy and (rightfully) gives priority to finishing up existing work over starting new work. But people are often eager to get started on a new group; it's really unfortunate if we cannot take advantage of that energy. From problem-statement-bounces@alvestrand.no Fri Jun 27 20:01:09 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27070 for ; Fri, 27 Jun 2003 20:01:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8E178625AC; Sat, 28 Jun 2003 01:30:53 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1DEBD625A6 for ; Sat, 28 Jun 2003 01:30:52 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 4.14) id 19W2g7-000Dbu-9u; Fri, 27 Jun 2003 23:30:51 +0000 To: Bernard Aboba In-Reply-To: Message from Bernard Aboba Date: Fri, 27 Jun 2003 16:30:50 -0700 From: Allison Mankin Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: MAJOR ISSUE: WG formation process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > > Having looked through the archives, I haven't seen much discussion on this > topic, so I thought I'd bring it up. Is there a "problem" here? > > I'd be interested if anyone has looked at the time it takes to get a WG > going -- that is, the time between when the first BOF occurs and when the > announcement of WG chartering occurs. If our focus is timeliness and > relevance, then this also needs to occur in a timely way. In general, I'm > curious as to the minimum, average, and maximum times that is required for > WG formation and how this compares to say, the time it takes to issue the > first document once the WG is chartered. > > Of course, comments on other aspects of the WG formation process - > predictability, transparency -- are also welcome. > Bernard, There are aspects of relevance, IETF-wide overload, concentration of power, and transparency, all important to the WG formation process. I thought I'd send a summary note from my perspective of having helped quite a few WGs into existence. It takes the form of a chronology of the process when there is just one BOF. Just getting the process clear and transparent is something we have never done, and which "problem" should do. There are issues that I can see. More comments specific to "problem" are interspersed at **. BOF request o Does the problem belong in IETF? BOF may be used to test. Area's "charter", big picture, constituents, state of industry, judgement calls, reviews, all enter in...this part is not Process, but our real intellectual capital, our stock in trade...I think the process here applies to ensuring that the broad enough eview of whether it's an IETF problem takes place. More below on that.** o Is there a good charter? AD may iterate with proposers, with discussion on BOF mailing list. o Is there a draft clearly showing the problem? Discussion begun? The Transport Area does not allow BOFs without. o Even if the problem does belong in IETF, are there cycles to do the proposed work (management and development)? Can the proposer show before or during the BOF that workers will come forward to justify IETF investment in the effort? BOF review o IESG/IAB BOF pre-review. Process needs more transparency**. o How did the BOF go? Meeting, minutes, mailing list... o IAB review. Process needs more transparency**. o Determination of outcome from meeting consensus and reviews. This determination needs more transparency.** Chair selection o This is likely to be the BOF Chairs, but not necessarily. o Chair selection is very important. See separate message**. Charter development o Chairs collaborate on charter development (consult mailing list). o More intense discussion of questions in BOF request/BOF review. o Does every milestone have someone with cycles associated with it? o Does every milestone match the purposes in the charter? Are all the milestones well-defined? Does the charter conclude? Charter review o IESG/IAB internal review. This currently cc's the proposed chairs. Chairs often take up the discussion points on the mailing list. o IETF WG Review. This currently involves ietf-announce and discussion on the IETF list. We rev charters based on the discussions. By tradition, IETF WG Review doesn't include the milestones. Should this be changed**? WG formation time lag** This really varies a lot. If the WG proposer does well with steps above, there will be a BOF at one IETF, one cycle of reviews, and formation of the WG by the next IETF. (This may not be OK for IETF-wide overload, but I've already overloaded this messages with topics, so enough :) Allison From problem-statement-bounces@alvestrand.no Fri Jun 27 20:12:25 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27417 for ; Fri, 27 Jun 2003 20:12:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 696BB625AF; Sat, 28 Jun 2003 02:11:54 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from turkey.mail.pas.earthlink.net (turkey.mail.pas.earthlink.net [207.217.120.126]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9960C625AC for ; Sat, 28 Jun 2003 02:11:52 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19W3Ji-0006lh-00; Fri, 27 Jun 2003 17:11:46 -0700 Date: Fri, 27 Jun 2003 20:08:19 -0400 From: Keith Moore To: Bernard Aboba Message-Id: <20030627200819.64589b38.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.1 (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 Cc: moore@cs.utk.edu Subject: Re: MAJOR ISSUE: WG formation process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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'd be interested if anyone has looked at the time it takes to get a WG ] going -- that is, the time between when the first BOF occurs and when the ] announcement of WG chartering occurs. If our focus is timeliness and ] relevance, then this also needs to occur in a timely way. I agree that WG formation time is a valid issue, but I strongly disagree that it's meaningful to measure times from first BOF to chartering. A lot of BOFs are held for very dubious ideas that take considerable time for refinement before it's reasonable to even consider chartering WGs for them. From problem-statement-bounces@alvestrand.no Fri Jun 27 20:19:07 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27626 for ; Fri, 27 Jun 2003 20:19:06 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 243A3625AF; Sat, 28 Jun 2003 02:18:36 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3064D625AC for ; Sat, 28 Jun 2003 02:18:34 +0200 (CEST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5S0IVIn004961; Fri, 27 Jun 2003 17:18:31 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIY04660; Fri, 27 Jun 2003 17:18:29 -0700 (PDT) Message-Id: <200306280018.AIY04660@mira-sjc5-c.cisco.com> To: Allison Mankin From: Melinda Shore In-Reply-To: Message from mankin@psg.com of "Fri, 27 Jun 2003 16:30:50 PDT." Date: Fri, 27 Jun 2003 20:18:29 -0400 Cc: problem-statement@alvestrand.no Cc: Bernard Aboba Subject: Re: MAJOR ISSUE: WG formation process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > Just getting the process clear and transparent > is something we have never done, and which "problem" > should do. Just to be clear, what we're trying to clarify in this instantiation of the working group is what the problems are. That means that we aren't going to be taking on process improvement or, for that matter, process documentation. That said, as a WG chair and as an IETF participant I thought your description of the steps taken in working group formation were a terrific help. I've never seen them described clearly before. Working group formation is often a highly contentious, fraught process and I think it would be valuable if something like this could be taken and firmed up by the appropriate parties (IESG?), and then posted on the IETF website on the IESG page or the "Additional Information" page, etc. In terms of process transparency, where I've really gotten hammered by WG-to-be participants wanting to know what's going on and why there hasn't been more progress is the period during which the charter is being iterated back and forth between the AD and the proposer, and then after the charter disappears into the bowels of the IESG, sometimes reappearing in a surprisingly different form. Melinda From problem-statement-bounces@alvestrand.no Fri Jun 27 21:31:18 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29283 for ; Fri, 27 Jun 2003 21:31:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 50C79625AF; Sat, 28 Jun 2003 03:28:52 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from relay1.kornet.net (relay1.kornet.net [211.48.62.161]) by eikenes.alvestrand.no (Postfix) with ESMTP id F2648625A7; Sat, 28 Jun 2003 03:28:49 +0200 (CEST) Received: from [220.89.169.87] (avri@apocalypse.org) by relay1.kornet.net (Terrace Internet Messaging Server) with ESMTP id 2003062810:28:43:948757.7564.5171 for ; Sat, 28 Jun 2003 10:28:43 +0900 (KST) Date: Sat, 28 Jun 2003 10:28:44 +0900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Harald Tveit Alvestrand From: avri In-Reply-To: <552100488.1056707254@localhost> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Subject: Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable On l=F6rdag, jun 28, 2003, at 01:47 Asia/Seoul, Harald Tveit Alvestrand=20= wrote: > > When an individual thnks that the process has not produced a result=20 > that is best for the Internet, there is no formal process to aid the=20= > individual in seeking to change that result. i think this formulation is better then mine. but is too restrictive. =20= it calls for the judgment of what is best for the Internet. as an alternative i=20 suggest: When an individual thinks that the process has not produced the right=20 result, or thinks that the process has been abused, there is no formal=20= mechanism to aid that individual in seeking to change that result. differences: - sometimes there is a process problem that can be fixed before the=20= wrong result is on the books so one should not have to wait until the=20 results are in. - i used the word mechanism as opposed to process, i think that is=20= the problem; one can reasonably argue that there is currently a process, it=20 takes very little to have a process - that is just words on paper. i think the problem=20= is that there is no functional entity that assists in the process. the word=20 'mechanism' is hopefully sufficiently abstract and non-solutionist. > > That's a VERY mild statement, and for numerous reasons: > > - It is not clear to me that the IETF is in the business of dispensing=20= > "redress". We're not here to seek an abstract notion of justice, but=20= > to make quality, relevant standards for the Internet; our adherence to=20= > process is a tool in our seeking those standards, and the reason we=20 > want departures from those processes to be challenged is that we think=20= > such departures will make it less likely that the right decisions are=20= > made. > i think it goes beyond this. the organization has to be seen as one=20 that is open and is fair to the individuals participating in it in order for it to=20 remain a place where people are willing to bring their work or a place=20= where work can continue without rancor. yes the process is there to help the work get done. it is=20 not an abstract notion of justice i am looking for, rather it is a notion of being=20 fair and just according to our rules, processes and principles. the case under discussion is not the only one of people feeling abused=20= by the system that i have heard. i have been involved in many=20 conversations where folks were unhappy with how the system had been=20 used to 'force a result' they felt was not in consensus and not fair,=20 but the way forward to redress that issue was not clear and did not not=20= seem possible. i have suggested an appeal several times and have often=20= gotten answers of inability, fear or disbelief that the system could=20 work for them . > - It is not clear to me that the IETF formal apparatus is the best way=20= > of aiding people seeking to change IETF decisions who are challenged=20= > by the hurdles you mention. In the civil-justice court system, lawyers=20= > are rarely employees of the court. possibly beside the point, but i think that essentially all public=20 defenders (at least in the US) are employees of the legal system. and i don't=20 think we are talking about employees here. i see those holding offices in=20 this organization as being individuals who volunteer to take on a trust and to do their best to meet that trust. > > Like many other things in the IETF, I think many of us have blithely=20= > assumed that the informal networks would take care of this - that an=20= > individual with a valid case would have friends and colleagues enough=20= > to talk over the issue with, and that one could assume that the=20 > consensus of that discussion would be reasonably close to the "right=20= > answer". i think that we cannot count on informal networks. i think sometimes=20= the need is purely informational. IETF processes are not simple and not easy to=20 understand. it is very difficult for many of our participants, especially the=20 international ones to know how to use the process to achieve their goals - something many of=20= us on this list are fairly talented at. and we cannot assume that all=20 participants have a set of friends, especially friends who understand the process, to help them=20 get the right and fair, as defined by our process, result. a.= From problem-statement-bounces@alvestrand.no Fri Jun 27 21:44:09 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29474 for ; Fri, 27 Jun 2003 21:44:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 10181625AC; Sat, 28 Jun 2003 03:43:38 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from relay4.kornet.net (relay4.kornet.net [211.48.62.164]) by eikenes.alvestrand.no (Postfix) with ESMTP id 68A1C625AC for ; Sat, 28 Jun 2003 03:43:35 +0200 (CEST) Received: from [220.89.169.87] (avri@apocalypse.org) by relay4.kornet.net (Terrace Internet Messaging Server) with ESMTP id 2003062810:43:30:441041.27077.4937 for ; Sat, 28 Jun 2003 10:43:30 +0900 (KST) Date: Sat, 28 Jun 2003 10:43:30 +0900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: "Theodore Ts'o" From: avri In-Reply-To: <20030627193437.GB22139@think> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Subject: Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable On l=F6rdag, jun 28, 2003, at 04:34 Asia/Seoul, Theodore Ts'o wrote: > > As a rule, I think we need to be very careful about generalizing from > a single person's experience to the general case. Phil is not alone > in doing this; I've seen it done in others within the IETF context, > and I've spoken out against this practice of taking a single incident > and generalizing it to condemn an individual or a system has being > unfair and unjustified. So please don't take this as an outright > objection to Phil's comments, but just as a cautionery note. > while i did use Phill's comments as entry into the topic, it is not my only reason for proposing an addition to the problem statement. as i argued elsewhere, i think there are many people who have trouble with the process. i have had heard many tales of woe about the process and about unfair treatment from WG chairs and ADs and how there was=20 nothing to be done about it. few of these have ever resulted in appeals. does=20= this mean they were all unfounded or all settled amicably later behind the scenes? that is not what my anecdotal evidence leads me to believe. i=20= think in most cases those complaining are wrong, but without an easy and=20 visibly fair way for the complaint to made and brought to a conclusion, it remains=20= a wound in the system and sometimes achieves greater significance then perhaps warranted. a. From problem-statement-bounces@alvestrand.no Sat Jun 28 00:34:58 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02767 for ; Sat, 28 Jun 2003 00:34:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2AA50625AC; Sat, 28 Jun 2003 06:34:05 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by eikenes.alvestrand.no (Postfix) with ESMTP id 70C98625A7 for ; Sat, 28 Jun 2003 06:34:03 +0200 (CEST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h5S48fr24332; Fri, 27 Jun 2003 21:08:41 -0700 Date: Fri, 27 Jun 2003 21:08:41 -0700 (PDT) From: Bernard Aboba To: Keith Moore In-Reply-To: <20030627200819.64589b38.moore@cs.utk.edu> Message-ID: References: <20030627200819.64589b38.moore@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: problem-statement@alvestrand.no Subject: Re: MAJOR ISSUE: WG formation process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 agree that WG formation time is a valid issue. OK. What exactly do you think the "issue" is? > but I strongly disagree that > it's meaningful to measure times from first BOF to chartering. I am curious as to what the distribution of these times are. I'm not suggesting that this is a metric we should be using to judge future performance. But if someone has looked at this, I'd be interested to know. From problem-statement-bounces@alvestrand.no Sat Jun 28 00:51:46 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03132 for ; Sat, 28 Jun 2003 00:51:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B1E3C625AC; Sat, 28 Jun 2003 06:51:16 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id 45D9262594 for ; Sat, 28 Jun 2003 06:51:15 +0200 (CEST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])h5S4pEa27739 for ; Sat, 28 Jun 2003 07:51:14 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com ; Sat, 28 Jun 2003 07:51:14 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 28 Jun 2003 07:51:14 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 28 Jun 2003 07:51:13 +0300 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: Sat, 28 Jun 2003 07:51:12 +0300 Message-ID: Thread-Topic: ADs who are also WG chairs Thread-Index: AcM8v/jf2+QPtH5KT7q0IwVACHpFBAAH0dTg From: To: , , X-OriginalArrivalTime: 28 Jun 2003 04:51:13.0610 (UTC) FILETIME=[E6C80AA0:01C33D30] Subject: RE: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Hi all, My opinion on this is that ADs SHOULD NOT be WG chairs. My reasons, in no particular order are: 1) concerns about current IESG overload - IESG members have a lot of=20 work as it is. Adding more work is not a good thing. 2) concerns that individuals will fear challenging AD because of = possible problems later on in the IETF process - hopefully unlikely, but people will speculate - or at least develop conspiracies. 3) potential conflicts of interest & no good guidelines for how someone could recuse themselves & under what circumstances they = should. 4) concerns about lack of transparancy - already a number of issues have been raised about WG creation, WG Chair picking, etc. But in summary, does the IETF really need an IESG member to be a WG chair? There are a lot of talented people in the IETF, why can't a non-IETF WG chair be found? Is there a problem about a WG that=20 only an IESG member run it? If so, I would imagine the WG probably has other problems then. br, John > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 27 June, 2003 18:17 > To: Avri Doria; problem-statement@alvestrand.no > Subject: Re: ADs who are also WG chairs >=20 >=20 >=20 > > > > One of the issues that came up in the discussion on rough consensus > > is the issue of ADs being WG chairs - either in their own area or in > > another area. > > > > I do not believe this dual role aspect of IETF management is yet > > reflected in the problem draft. > > > > Should it be? > > >=20 > As long as the AD acting as a WG chair recluses themselves from any = and all > IESG decisions having to do with the WG, to avoid conflict of = interest, I > don't think there should be a problem. I think its somewhat more > questionable if the WG is in the same area, since it removes one = person from > oversight, and having two technically knowledgable, independent = opinions on > a WG is often useful. >=20 > That said, I cannot see how, given the workload, an AD can possibly do = a > good job as a WG chair and still expect to fufill their duties as an = AD. > Just on the basis of that alone, it might be sensible to consider some = kind > of strong disapproval, if not restriction, and make it an exceptional = case. >=20 > My 0.02 euro. >=20 > jak >=20 >=20 From problem-statement-bounces@alvestrand.no Sat Jun 28 11:07:13 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24859 for ; Sat, 28 Jun 2003 11:07:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D9AA1625C7; Sat, 28 Jun 2003 17:05:48 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8AB49625A6 for ; Sat, 28 Jun 2003 17:05:46 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19WHGm-0003tn-00; Sat, 28 Jun 2003 08:05:40 -0700 Date: Sat, 28 Jun 2003 11:02:10 -0400 From: Keith Moore To: Bernard Aboba Message-Id: <20030628110210.3e34b3a8.moore@cs.utk.edu> In-Reply-To: References: <20030627200819.64589b38.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.9.1 (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 Cc: moore@cs.utk.edu Subject: Re: MAJOR ISSUE: WG formation process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 agree that WG formation time is a valid issue. ] ] OK. What exactly do you think the "issue" is? often, we're not able to take advantage of the energy that accompanies an effort to start a new WG; by the time we get it started, that energy has often waned considerably. this makes it harder to recruit people to do the heavy lifting in the group, and may cause the group to take longer to produce output. in rare cases the group is unable to produce output while it's still useful or relevant. From problem-statement-bounces@alvestrand.no Sat Jun 28 14:40:11 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29344 for ; Sat, 28 Jun 2003 14:40:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 39E586238C; Sat, 28 Jun 2003 20:39:39 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by eikenes.alvestrand.no (Postfix) with ESMTP id B7C89622BB for ; Sat, 28 Jun 2003 20:39:36 +0200 (CEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 3A5306A901; Sat, 28 Jun 2003 21:39:35 +0300 (EEST) Message-ID: <3EFDE05D.3080706@piuha.net> Date: Sat, 28 Jun 2003 21:37:17 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore References: <20030627200819.64589b38.moore@cs.utk.edu> <20030628110210.3e34b3a8.moore@cs.utk.edu> In-Reply-To: <20030628110210.3e34b3a8.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Cc: Bernard Aboba Subject: Re: MAJOR ISSUE: WG formation process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jari.arkko@piuha.net 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 Keith Moore wrote: > often, we're not able to take advantage of the energy that accompanies an > effort to start a new WG; by the time we get it started, that energy has often > waned considerably. this makes it harder to recruit people to do the heavy > lifting in the group, and may cause the group to take longer to produce > output. in rare cases the group is unable to produce output while it's still > useful or relevant. I agree. In addition, the energy level applies not just to the IETF folks but also the rest of the society. In most cases, new features have a window of opportunity to become defined and deployed. After the window is gone, other solutions (possibly inferior) have been found, the users are interested in other things, etc. --Jari From problem-statement-bounces@alvestrand.no Sat Jun 28 16:07:25 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02077 for ; Sat, 28 Jun 2003 16:07:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6C770625A6; Sat, 28 Jun 2003 22:06:51 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A85286238C; Sat, 28 Jun 2003 22:06:46 +0200 (CEST) Date: Sat, 28 Jun 2003 10:30:11 -0700 From: Harald Tveit Alvestrand To: vkompella@timetra.com Message-ID: <641057882.1056796211@localhost> In-Reply-To: References: X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: problem-statement@alvestrand.no Subject: RE: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 27. juni 2003 12:29 -0700 Vach Kompella wrote: > The problem statement is more about whether the following are perceived > to be issues or not: > > - pursuing an individual draft within a WG that one co-chairs > - co-chairing a WG that one oversees as an AD > > I'd see the former as less of an issue, and recusal is adequate. The > second is a bigger issue. This may not be a problem, because we've already dealt with the potential... I think the IESG has avoided the situation of direct oversight of one's "own" WG. I don't think we have any WG where the responsible AD is also chairing the WG. We've had some group where the chair is also an AD in the same area, but in that case (I can think of only one), the other AD has acted as responsible AD for the WG. (One exception: TSVWG is chartered as a WG, but is chaired by both ADs of the transport area - it functions more as an area forum than as a standalone working group. I wouldn't want to attempt to change that!) We've become more strident over the last year in trying to find alternative chairs for WGs where the chair becomes an AD; I think (but can't check - I'm in flight) the latest set of ADs have managed to shed all their WG chair jobs by now. (and btw - thanks to all those who stepped up when asked, both in these cases and in the many other cases where a chair has been needed - the IETF is totally dependent on people willing and able to be WG chairs!) Harald From problem-statement-bounces@alvestrand.no Sat Jun 28 16:07:34 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02082 for ; Sat, 28 Jun 2003 16:07:33 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E82D6625CB; Sat, 28 Jun 2003 22:07:03 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C071A6238C; Sat, 28 Jun 2003 22:06:52 +0200 (CEST) Date: Sat, 28 Jun 2003 10:39:06 -0700 From: Harald Tveit Alvestrand To: avri Message-ID: <641593232.1056796746@localhost> In-Reply-To: References: X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: problem-statement@alvestrand.no Subject: Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 like your rephrasing. --On 28. juni 2003 10:28 +0900 avri wrote: > When an individual thinks that the process has not produced the right > result, or thinks that the process has been abused, there is no formal > mechanism to aid that individual in seeking to change that result. > > differences: > > - sometimes there is a process problem that can be fixed before the > wrong result is on the books so one should not have to wait until > the results are in. and we both agree that the absence of a result can at times be as troubling as the appearance of a result that one does not agree with..... > - i used the word mechanism as opposed to process, i think that is > the problem; one can reasonably argue that there is currently a > process, it takes very little to have a process - that is just words > on paper. i think the problem is that there is no functional entity > that assists in the process. the word 'mechanism' is hopefully > sufficiently abstract and non-solutionist. > >> >> That's a VERY mild statement, and for numerous reasons: >> >> - It is not clear to me that the IETF is in the business of dispensing >> "redress". We're not here to seek an abstract notion of justice, but >> to make quality, relevant standards for the Internet; our adherence to >> process is a tool in our seeking those standards, and the reason we >> want departures from those processes to be challenged is that we think >> such departures will make it less likely that the right decisions are >> made. >> > > i think it goes beyond this. the organization has to be seen as one that > is open and is fair to the individuals participating in it in order for > it to remain a place where people are willing to bring their work or a > place where work can continue without rancor. yes the process is there > to help the work get done. it is not an abstract notion of justice i am > looking for, rather it is a notion of being fair and just according to > our rules, processes and principles. agreed. > the case under discussion is not the only one of people feeling abused by > the system that i have heard. i have been involved in many conversations > where folks were unhappy with how the system had been used to 'force a > result' they felt was not in consensus and not fair, but the way forward > to redress that issue was not clear and did not not seem possible. i > have suggested an appeal several times and have often gotten answers of > inability, fear or disbelief that the system could work for them. the fear may be our greatest enemy. I liked the appeal that Glen Zorn put before the IESG when we failed to follow the rules we had set for codepoint allocation in RADIUS; when we looked at the documents he pointed at, it took us only seconds to realize that we'd done the wrong thing. It did take a while to figure out what the right thing was, given RADIUS' long and convoluted history - we had to figure out something that was both consistent with process and consistent with the right thing for the Internet; I think we managed. >> - It is not clear to me that the IETF formal apparatus is the best way >> of aiding people seeking to change IETF decisions who are challenged >> by the hurdles you mention. In the civil-justice court system, lawyers >> are rarely employees of the court. > > possibly beside the point, but i think that essentially all public > defenders (at least in the US) are employees of the legal system. and i > don't think we are talking about employees here. i see those holding > offices in this organization as being individuals who volunteer to take > on a trust and to do their best to meet that trust. Other traditions .... in Norway, criminal-court defendants are independent lawyers/attorneys (not sure how the titles match up) who take on cases, and their fees are paid by public money. The fact that nobody in the justice dept can hire or fire them is seen as a major guarantee of their independence from the prosecutors and judges (who, again, report to different administrative hierarchies). But this is a sidetrack - I'm unsure whether either model (civil court with its assumption that "one wins and another loses", or criminal court with its assumption of "violations against an universal standard of right behaviour") fits well with the process of seeking the best high quality, relevant standards for the Internet. >> Like many other things in the IETF, I think many of us have blithely >> assumed that the informal networks would take care of this - that an >> individual with a valid case would have friends and colleagues enough >> to talk over the issue with, and that one could assume that the >> consensus of that discussion would be reasonably close to the "right >> answer". > > i think that we cannot count on informal networks. i think sometimes > the need is purely informational. IETF processes are not simple and not > easy to understand. it is very difficult for many of our participants, > especially the international ones to know how to use the process to > achieve their goals - something many of us on this list are fairly > talented at. and we cannot assume that all participants have a set of > friends, especially friends who understand the process, to help them get > the right and fair, as defined by our process, result. as you say - the fear is out there. And we need to deal with that somehow. From problem-statement-bounces@alvestrand.no Sat Jun 28 16:07:54 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02112 for ; Sat, 28 Jun 2003 16:07:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 76C8E625CA; Sat, 28 Jun 2003 22:07:16 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5A254625CA for ; Sat, 28 Jun 2003 22:07:02 +0200 (CEST) Date: Sat, 28 Jun 2003 11:07:31 -0700 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <643297633.1056798451@localhost> In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D22AE@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D22AE@mou1wnexm02.verisign.com > X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Reinventing the wheel (Re: ISSUE: Meeting scheduling) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 27. juni 2003 09:53 -0700 "Hallam-Baker, Phillip" wrote: > There are a lot of complaints about groups re-inventing stuff that has > existed before. But the mechanisms for communicating are limited and tend > to be unidirectional. There is no way to ask why people have to reinvent. actually there is ..... you can ask them. We even did this formally some time ago - we had a BOF in Salt Lake City (I think) dedicated to "why do people invent UDP-based protocols". As I remember, it was fairly entertaining, including people who said "next time I'll use TCP, so I don't have to bother adding all its stuff back into the protocol later"...... > Take a case in point, use of UDP for short transactional messages. TCP/IP > is fine for longstanding persistent connections. It is clumsy and > unsatisfactory for short term connections that require perhaps one to four > packets in each direction in a simple request/response format. It should > not be a surprise that people keep reinventing this type of mechanism, it > is supported by a valid engineering requirement. Old fogey mode....... People tend to forget things like Belsnes' old proof that if you need two parties to exchange data, and both ends have to know that the data has been successfully transferred, it is IMPOSSIBLE to do it in less than five packets. Just because something's an engineering requirement doesn't mean it's possible. (the even older fogies will no doubt correct me if I got the details wrong....) And, of course, networks have been brought to their knees by UDP-based "simple" protocols that just didn't think about congestion. I've had to debug some of those situations. (DNS works because a server doesn't care whether the client got the answer or not - it's the client's business. But not all "quick" protocols are allowed to be that careless...) Mumble.... I sometimes wonder whether part of our structural problem is that neither the IETF nor any other organization in the world (AFAIK) really teaches protocol design as an engineering skill. Harald From problem-statement-bounces@alvestrand.no Sat Jun 28 16:09:56 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02240 for ; Sat, 28 Jun 2003 16:09:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2ADB862594; Sat, 28 Jun 2003 22:09:25 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by eikenes.alvestrand.no (Postfix) with ESMTP id 296E86238C for ; Sat, 28 Jun 2003 22:09:23 +0200 (CEST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5SK9KIn021238 for ; Sat, 28 Jun 2003 13:09:20 -0700 (PDT) Received: from cisco.com (sjc-vpn3-224.cisco.com [10.21.64.224]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AHO38469; Sat, 28 Jun 2003 13:02:21 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Sat, 28 Jun 2003 16:09:17 -0400 Date: Sat, 28 Jun 2003 16:09:17 -0400 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030628160917.R1880@sbrim-w2k01> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: <20030627200819.64589b38.moore@cs.utk.edu> <20030628110210.3e34b3a8.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030628110210.3e34b3a8.moore@cs.utk.edu>; from moore@cs.utk.edu on Sat, Jun 28, 2003 at 11:02:10AM -0400 Subject: Re: MAJOR ISSUE: WG formation process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Sat, Jun 28, 2003 11:02:10AM -0400, Keith Moore allegedly wrote: > often, we're not able to take advantage of the energy that accompanies > an effort to start a new WG; by the time we get it started, that > energy has often waned considerably. this makes it harder to recruit > people to do the heavy lifting in the group, and may cause the group > to take longer to produce output. in rare cases the group is unable > to produce output while it's still useful or relevant. Is this a problem? Why would energy quickly evaporate? People start work but then lose support to participate? Some article in Wired shifts everybody's attention to the next hot topic? I'm used to thinking of the WG formation process as a pain, but it might be a good thing for filtering out fads. From problem-statement-bounces@alvestrand.no Sat Jun 28 16:44:29 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02730 for ; Sat, 28 Jun 2003 16:44:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0ECCF625A6; Sat, 28 Jun 2003 22:43:58 +0200 (CEST) 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 CF2C36238C for ; Sat, 28 Jun 2003 22:43:55 +0200 (CEST) Received: from cisco.com (171.68.223.138) by sj-iport-1.cisco.com with ESMTP; 28 Jun 2003 13:45:42 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h5SKhrRJ026275; Sat, 28 Jun 2003 13:43:53 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIY49218; Sat, 28 Jun 2003 13:43:51 -0700 (PDT) Message-Id: <200306282043.AIY49218@mira-sjc5-c.cisco.com> To: Scott W Brim , problem-statement@alvestrand.no From: Melinda Shore In-Reply-To: Message from swb@employees.org of "Sat, 28 Jun 2003 16:09:17 EDT." <20030628160917.R1880@sbrim-w2k01> Date: Sat, 28 Jun 2003 16:43:51 -0400 Subject: Re: MAJOR ISSUE: WG formation process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > Is this a problem? Why would energy quickly evaporate? People start > work but then lose support to participate? Some article in Wired shifts > everybody's attention to the next hot topic? I'm used to thinking of > the WG formation process as a pain, but it might be a good thing for > filtering out fads. Well, clearly there's a problem if getting a needed protocol out takes so long that proprietary protocol/implementations take hold and the IETF working group becomes irrelevant. Still, I've found that to be more of a problem once a working group is underway than it is during the chartering process. Also, I've found that fewer people tend to be interested in the bits-'n-bytes aspect of the work than they are in the architectural framework phase (I suppose there's some irony there, given how badly we do architecture) and that causes some natural attrition as working groups hunker down after an initial protocol draft. Melinda From problem-statement-bounces@alvestrand.no Sat Jun 28 19:07:43 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06197 for ; Sat, 28 Jun 2003 19:07:42 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 67D4D625C7; Sun, 29 Jun 2003 01:04:36 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by eikenes.alvestrand.no (Postfix) with ESMTP id E5C3F625A6 for ; Sun, 29 Jun 2003 01:04:34 +0200 (CEST) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196])h5SN4WMk007200 for ; Sun, 29 Jun 2003 01:04:32 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])h5SN4WjO274568 for ; Sun, 29 Jun 2003 01:04:32 +0200 Received: from gsine03.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA44700 from ; Sun, 29 Jun 2003 01:04:30 +0200 Message-Id: <3EFDE523.AEF7E984@hursley.ibm.com> Date: Sat, 28 Jun 2003 20:57:39 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: problem-statement@alvestrand.no References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 avri wrote: ... > as i argued elsewhere, i think there are many people who have trouble > with the process. i have had heard many tales of woe about the process > and about unfair treatment from WG chairs and ADs and how there was > nothing > to be done about it. few of these have ever resulted in appeals. does > this > mean they were all unfounded or all settled amicably later behind the > scenes? that is not what my anecdotal evidence leads me to believe. i > think > in most cases those complaining are wrong, but without an easy and > visibly fair > way for the complaint to made and brought to a conclusion, it remains > a wound > in the system and sometimes achieves greater significance then perhaps > wbarranted. People seem to be saying that the appeal process is too hard & intimidating to use. Now if we fixed that, the implication is that there would be many more appeals, which the IESG and IAB simply couldn't handle. So at the risk of entering solution space, it may be that the need is for an appeals mechanism which is separate from the IESG and IAB, and which is set up to be easy to use. Brian From problem-statement-bounces@alvestrand.no Sat Jun 28 19:57:42 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06198 for ; Sat, 28 Jun 2003 19:07:42 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 22952625CC; Sun, 29 Jun 2003 01:04:50 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by eikenes.alvestrand.no (Postfix) with ESMTP id BF417625CB for ; Sun, 29 Jun 2003 01:04:38 +0200 (CEST) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196])h5SN4aIe108308 for ; Sun, 29 Jun 2003 01:04:37 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])h5SN4ajO267880 for ; Sun, 29 Jun 2003 01:04:37 +0200 Received: from gsine03.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA45034 from ; Sun, 29 Jun 2003 01:04:35 +0200 Message-Id: <3EFDE8AA.24795859@hursley.ibm.com> Date: Sat, 28 Jun 2003 21:12:42 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: problem-statement@alvestrand.no References: <2A1D4C86842EE14CA9BC80474919782E0D22A5@mou1wnexm02.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Phill, Firstly I believe that this issue, in somewhat different words, is covered in the draft. Secondly, the IETF isn't structured as a democracy. In fact, doing so is immensely hard since the open door policy means that companies and special interest groups could (and would) attempt to stuff any form of one-person one-vote process. (I'm not saying that is what you are advocating, but it seems to be somewhat implicit in your words.) Finally, there have been quite a few appeals. Apellants I can remember without searching are Dave Crocker, Dan Bernstein, Dave Perkins, Bill Simpson and Robert Elz. Probably we have been sloppy about systematically documenting the appeals, but you can find some of them via http://www.iab.org. Brian "Hallam-Baker, Phillip" wrote: > > Brian writes: > > 1. The IAB as an advisory board for WG formation (and in practice for many > major IESG decisions) > 2. The appeals process > 3. The recall process (never tested, for some reason) > 4. Payback time, i.e. the NomCom process. > Now, it's possible we need *more* checks and balances, of course. > > The problem with all the above is that they are exclusively top down > approaches. NOMCON is just as top down as the rest of the structure. > Consider the requirements for membership of nomcon, you have to attend two > IETFs and commit to attend a further two - including one likely to be held > abroad at a potentially expensive to attend location and on top commit a > substantial amount of time. If you look at the members of past nomcons you > will see they are mainly existing members of the establishment or pretty > obvious aspirants to join the establishment. > > The problem here is that the IAB is appointed in the same way as the IESG > and is just as unaccountable. The great fear of the process designers > appears to have been mob rule, or worse any form of decision making that > would make appointees accountable to a constituency of any sort. > > The Nomcon is not a check for the simple reason nobody knows what the > composition will be. The chances that a randomly selected group of people > will do something radical is actually quite slim. It only happened a couple > of years ago because someone got selected for nomcon who was determined to > shake things up. > > The appeals process is for some reason regarded as the nuclear option. I > suspect because one time it was used the IESG took it on itself to censure a > member for having the temerity to make an appeal. > > Phill From problem-statement-bounces@alvestrand.no Sat Jun 28 20:42:55 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07343 for ; Sat, 28 Jun 2003 20:42:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CD0B3625C8; Sun, 29 Jun 2003 02:41:03 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from albatross.mail.pas.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by eikenes.alvestrand.no (Postfix) with ESMTP id C4753625A6; Sun, 29 Jun 2003 02:41:01 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19WQFN-0006PD-00; Sat, 28 Jun 2003 17:40:49 -0700 Date: Sat, 28 Jun 2003 20:37:17 -0400 From: Keith Moore To: avri Message-Id: <20030628203717.440cae8e.moore@cs.utk.edu> In-Reply-To: References: <552100488.1056707254@localhost> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: harald@alvestrand.no Cc: moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Sat, 28 Jun 2003 10:28:44 +0900 avri wrote: ] > When an individual thnks that the process has not produced a result ] > that is best for the Internet, there is no formal process to aid the ] > individual in seeking to change that result. ] ] i think this formulation is better then mine. but is too restrictive. ] it calls for the judgment of what is best for the Internet. well, that's what the rules say that IETF participants are supposed to do, so I don't see a problem with invoking it here. but reasonable people can disagree about what is "best", and I don't want to expect challenges every time someone has a difference of opinion - I think we should expect some gap between "best" and "so bad it deserves to be challenged" I would instead say "when an individual thinks that the process has produced a result that is harmful to the Internet..." though I would assert that our existing appeals process does permit individuals to appeal decisions based on this criteria - in that anything that is harmful to the Internet is almost certainly not suitable under the criteria for standards-track documents. (e.g. "no known technical omissions") ] as an alternative i suggest: ] ] When an individual thinks that the process has not produced the right ] result, or thinks that the process has been abused, there is no formal ] mechanism to aid that individual in seeking to change that result. strongly disagree. nothing in our process requires the "right result", and it's not clear that there is any such thing. nor is it clear what "abusing the process" is as opposed to "failing to adhere to the process". if someone follows the rules but produces a harmful result, is that abusing the process? Keith From problem-statement-bounces@alvestrand.no Sat Jun 28 21:00:29 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07471 for ; Sat, 28 Jun 2003 21:00:29 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A2E83625C7; Sun, 29 Jun 2003 02:59:57 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from turkey.mail.pas.earthlink.net (turkey.mail.pas.earthlink.net [207.217.120.126]) by eikenes.alvestrand.no (Postfix) with ESMTP id CC583625A6 for ; Sun, 29 Jun 2003 02:59:55 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19WQX2-0000gJ-00; Sat, 28 Jun 2003 17:59:04 -0700 Date: Sat, 28 Jun 2003 20:55:32 -0400 From: Keith Moore To: Scott W Brim Message-Id: <20030628205532.2f4c42ff.moore@cs.utk.edu> In-Reply-To: <20030628160917.R1880@sbrim-w2k01> References: <20030627200819.64589b38.moore@cs.utk.edu> <20030628110210.3e34b3a8.moore@cs.utk.edu> <20030628160917.R1880@sbrim-w2k01> X-Mailer: Sylpheed version 0.9.1 (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 Cc: moore@cs.utk.edu Subject: Re: MAJOR ISSUE: WG formation process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Sat, Jun 28, 2003 11:02:10AM -0400, Keith Moore allegedly wrote: ] > often, we're not able to take advantage of the energy that accompanies ] > an effort to start a new WG; by the time we get it started, that ] > energy has often waned considerably. this makes it harder to recruit ] > people to do the heavy lifting in the group, and may cause the group ] > to take longer to produce output. in rare cases the group is unable ] > to produce output while it's still useful or relevant. ] ] Is this a problem? Why would energy quickly evaporate? People start ] work but then lose support to participate? Some article in Wired shifts ] everybody's attention to the next hot topic? I'm used to thinking of ] the WG formation process as a pain, but it might be a good thing for ] filtering out fads. Analyzing the psychology behind this is probably beyond my expertise. But I'm certainly not the first to observe that the enthusiasm for a project fades fairly quickly after it is started. (Surely you've seen the "six phases of a project" sign?) I would love to believe that talented people could be found to work for free on any IETF project that is worthwhile. But experience suggests that people prefer to work on things that are visible, that promise significant benefit, that can win them recognition, and yes, that are in fashion. Given that we are a volunteer organization I suspect we're going to need to be able to take advantage of fads. From problem-statement-bounces@alvestrand.no Sun Jun 29 00:11:20 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09557 for ; Sun, 29 Jun 2003 00:11:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 962F06257B; Sun, 29 Jun 2003 06:10:06 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from relay6.kornet.net (relay6.kornet.net [211.48.62.166]) by eikenes.alvestrand.no (Postfix) with ESMTP id 36AA862574 for ; Sun, 29 Jun 2003 06:10:00 +0200 (CEST) Received: from [220.89.169.90] (avri@apocalypse.org) by relay6.kornet.net (Terrace Internet Messaging Server) with ESMTP id 2003062913:09:57:083429.18913.20 for ; Sun, 29 Jun 2003 13:09:52 +0900 (KST) Date: Sun, 29 Jun 2003 13:09:49 +0900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Keith Moore From: avri In-Reply-To: <20030628203717.440cae8e.moore@cs.utk.edu> Message-Id: <86BD6B17-A9E7-11D7-A025-000393CC2112@apocalypse.org> Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Subject: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable i am personally fine with the statement of the problem as: When an individual thinks that the process has produced a result that is harmful to the Internet or thinks that IETF processes have not been adhered to, there is no mechanism to aid that individual in seeking to change that result. i think this take your comments into account. does it? a. On s=F6ndag, jun 29, 2003, at 09:37 Asia/Seoul, Keith Moore wrote: > On Sat, 28 Jun 2003 10:28:44 +0900 > avri wrote: > > ] > When an individual thnks that the process has not produced a = result > ] > that is best for the Internet, there is no formal process to aid=20= > the > ] > individual in seeking to change that result. > ] > ] i think this formulation is better then mine. but is too = restrictive. > ] it calls for the judgment of what is best for the Internet. > > well, that's what the rules say that IETF participants are supposed to=20= > do, > so I don't see a problem with invoking it here. but reasonable people > can disagree about what is "best", and I don't want to expect=20 > challenges > every time someone has a difference of opinion - I think we should=20 > expect > some gap between "best" and "so bad it deserves to be challenged" > I would instead say > > "when an individual thinks that the process has produced a result that=20= > is > harmful to the Internet..." > > though I would assert that our existing appeals process does permit > individuals to appeal decisions based on this criteria - in that > anything that is harmful to the Internet is almost certainly not > suitable under the criteria for standards-track documents. > (e.g. "no known technical omissions") > > ] as an alternative i suggest: > ] > ] When an individual thinks that the process has not produced the = right > ] result, or thinks that the process has been abused, there is no=20 > formal > ] mechanism to aid that individual in seeking to change that result. > > strongly disagree. nothing in our process requires the "right = result", > and it's not clear that there is any such thing. nor is it clear=20 > what > "abusing the process" is as opposed to "failing to adhere to the=20 > process". > if someone follows the rules but produces a harmful result, is that > abusing the process? > > Keith > From problem-statement-bounces@alvestrand.no Sun Jun 29 00:42:08 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09931 for ; Sun, 29 Jun 2003 00:42:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0EB3C6257B; Sun, 29 Jun 2003 06:41:38 +0200 (CEST) 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 BDA8462205 for ; Sun, 29 Jun 2003 06:41:36 +0200 (CEST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])h5T4fa928655 for ; Sun, 29 Jun 2003 07:41:36 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com ; Sun, 29 Jun 2003 07:41:35 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 29 Jun 2003 07:41:35 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 29 Jun 2003 07:41:35 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 29 Jun 2003 07:41:34 +0300 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: Sun, 29 Jun 2003 07:41:33 +0300 Message-ID: Thread-Topic: MAJOR ISSUE: WG formation process Thread-Index: AcM9sTD8YG20Gr9URiKiQ9mb4h82QAARyytQ From: To: , X-OriginalArrivalTime: 29 Jun 2003 04:41:34.0727 (UTC) FILETIME=[B8274170:01C33DF8] Subject: RE: MAJOR ISSUE: WG formation process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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, > Is this a problem? Why would energy quickly evaporate? People start > work but then lose support to participate? Some article in Wired = shifts > everybody's attention to the next hot topic? I'm used to thinking of > the WG formation process as a pain, but it might be a good thing for > filtering out fads. What I think is more of the problem is the indeterminism of the process. WGs can take a very long time to form, 2 BOFs and often not an official approval until just before the next IETF meeting. These is no good way to get a status check on the proposed WG; and especially in these time, it is hard to convince management to sponsor some work that is not yet official and noone knows when it may or may not become official. John From problem-statement-bounces@alvestrand.no Sun Jun 29 00:51:20 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10004 for ; Sun, 29 Jun 2003 00:51:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BD9A66257B; Sun, 29 Jun 2003 06:50:47 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by eikenes.alvestrand.no (Postfix) with ESMTP id 07A7862205 for ; Sun, 29 Jun 2003 06:50:46 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19WU9B-0000qI-00; Sat, 28 Jun 2003 21:50:41 -0700 Date: Sun, 29 Jun 2003 00:47:08 -0400 From: Keith Moore To: avri Message-Id: <20030629004708.55f69e19.moore@cs.utk.edu> In-Reply-To: <86BD6B17-A9E7-11D7-A025-000393CC2112@apocalypse.org> References: <20030628203717.440cae8e.moore@cs.utk.edu> <86BD6B17-A9E7-11D7-A025-000393CC2112@apocalypse.org> X-Mailer: Sylpheed version 0.9.1 (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 Cc: moore@cs.utk.edu Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Sun, 29 Jun 2003 13:09:49 +0900 avri wrote: ] i am personally fine with the statement of the problem as: ] ] When an individual thinks that the process has produced a ] result that is harmful to the Internet or thinks that IETF processes ] have not been adhered to, there is no mechanism to aid that ] individual in seeking to change that result. ] ] i think this take your comments into account. does it? mostly. but is it really the case that the appeals process doesn't serve this purpose? I would claim that something that is harmful to the Internet is a technical error, and of course not adhering to process is a process error, either of which can be appealed under our current rules. From problem-statement-bounces@alvestrand.no Sun Jun 29 01:03:37 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10221 for ; Sun, 29 Jun 2003 01:03:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 55B0662588; Sun, 29 Jun 2003 07:03:04 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id CB75762205 for ; Sun, 29 Jun 2003 07:03:02 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 4.14) id 19WUL8-000JkV-11; Sun, 29 Jun 2003 05:03:02 +0000 To: Melinda Shore In-Reply-To: Message from Melinda Shore <200306280018.AIY04660@mira-sjc5-c.cisco.com> Date: Sat, 28 Jun 2003 22:03:01 -0700 From: Allison Mankin Message-Id: Cc: problem-statement@alvestrand.no Cc: Bernard Aboba Subject: Re: MAJOR ISSUE: WG formation process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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, > > > Just getting the process clear and transparent > > is something we have never done, and which "problem" > > should do. > > Just to be clear, what we're trying to clarify in this > instantiation of the working group is what the problems > are. That means that we aren't going to be taking on > process improvement or, for that matter, process > documentation. Yes. My wording was a little unclear - I'd change it to to read that the problem-statement could identify areas in which the working group formation process is not transparent enough, as your example does. > > That said, as a WG chair and as an IETF participant I > thought your description of the steps taken in working group > formation were a terrific help. I've never seen them > described clearly before. Working group formation is > often a highly contentious, fraught process and I think it > would be valuable if something like this could be taken and > firmed up by the appropriate parties (IESG?), and then > posted on the IETF website on the IESG page or the > "Additional Information" page, etc. I'll see about doing this. > > In terms of process transparency, where I've really gotten > hammered by WG-to-be participants wanting to know what's > going on and why there hasn't been more progress is the > period during which the charter is being iterated back and > forth between the AD and the proposer, and then after the > charter disappears into the bowels of the IESG, sometimes > reappearing in a surprisingly different form. > AD and proposer really can do some or all of it on the BOF mailing lists, or the Area mailing lists. There are just old habits to get out of. I think we'd benefit from strongly encouraging this openness, and some of the questions being discussed about relevance and enthusiasm might improve if more people were in on the charter development at such a critical point. Allison From problem-statement-bounces@alvestrand.no Sun Jun 29 09:25:21 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28022 for ; Sun, 29 Jun 2003 09:24:30 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 54F06625CD; Sun, 29 Jun 2003 15:23:44 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by eikenes.alvestrand.no (Postfix) with ESMTP id 02AB062574 for ; Sun, 29 Jun 2003 15:23:43 +0200 (CEST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5TDNdO0016065; Sun, 29 Jun 2003 06:23:40 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIY74638; Sun, 29 Jun 2003 06:23:38 -0700 (PDT) Message-Id: <200306291323.AIY74638@mira-sjc5-c.cisco.com> To: Brian E Carpenter From: Melinda Shore In-Reply-To: Message from brian@hursley.ibm.com of "Sat, 28 Jun 2003 21:12:42 +0200." <3EFDE8AA.24795859@hursley.ibm.com> Date: Sun, 29 Jun 2003 09:23:38 -0400 Cc: problem-statement@alvestrand.no Subject: Re: MAJOR ISSUE: "Concentration of power" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > Secondly, the IETF isn't structured as a democracy. In fact, > doing so is immensely hard since the open door policy means that > companies and special interest groups could (and would) attempt > to stuff any form of one-person one-vote process. This happens anyway, actually, although obviously it's more in the form of stuffing the room (or putting 18 authors on a draft) than it is of bringing in ringers to vote. Even so, I think it's far easier to deal with this problem using our current decision-making process than would be if we went to a voting system. Melinda From problem-statement-bounces@alvestrand.no Sun Jun 29 09:30:36 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28154 for ; Sun, 29 Jun 2003 09:30:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C002A625CD; Sun, 29 Jun 2003 15:30:04 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by eikenes.alvestrand.no (Postfix) with ESMTP id D908462574 for ; Sun, 29 Jun 2003 15:30:02 +0200 (CEST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5TDU02K009251; Sun, 29 Jun 2003 06:30:00 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIY74784; Sun, 29 Jun 2003 06:29:59 -0700 (PDT) Message-Id: <200306291329.AIY74784@mira-sjc5-c.cisco.com> To: Allison Mankin From: Melinda Shore In-Reply-To: Message from mankin@psg.com of "Sat, 28 Jun 2003 22:03:01 PDT." Date: Sun, 29 Jun 2003 09:29:59 -0400 Cc: problem-statement@alvestrand.no Cc: Bernard Aboba Subject: Re: MAJOR ISSUE: WG formation process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > My wording was a little unclear - I'd change it to to read that > the problem-statement could identify areas in which the working group > formation process is not transparent enough, as your example does. One thing that's popping out of the discussion is that the question of transparency is tied directly to one's role in the process - for example, things that look obvious to IESG members may not be obvious to chairs and things that are obvious to chairs may not be obvious to WG participants (and the problem probably flows in the opposite direction once a WG is under way). Melinda From problem-statement-bounces@alvestrand.no Sun Jun 29 21:42:54 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12795 for ; Sun, 29 Jun 2003 21:42:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2CF6A625D4; Mon, 30 Jun 2003 03:42:23 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from apocalypse.org (apocalypse.org [192.48.232.17]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0D90D61BA7 for ; Mon, 30 Jun 2003 03:42:21 +0200 (CEST) Received: from apocalypse.org (IDENT:Za76a8vnLNUNbqcn+mDYzYqbhxrdhx7h@apocalypse.org [192.48.232.17]) by apocalypse.org (8.11.6/8.11.6) with ESMTP id h5U1gIG14073; Sun, 29 Jun 2003 21:42:18 -0400 Date: Mon, 30 Jun 2003 10:42:12 +0900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Spencer Dawkins From: avri In-Reply-To: <045201c33ea6$bfd052a0$0200a8c0@DFNJGL21> Message-Id: <123A6F9F-AA9C-11D7-A025-000393CC2112@apocalypse.org> Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: quoted-printable Hi, On m=E5ndag, jun 30, 2003, at 10:27 Asia/Seoul, Spencer Dawkins wrote: > I agree with the sentiment, but we've had at least a couple > of people who've posted references to appeals that were > filed, including appeals that resulted in overturned > decisions. i think looking at the counter-examples will show that the folks brave enough and process savvy enough to file these appeals where not our average participants. yes, there is a process but it takes a lot of energy and savvy to use that process. > > I'm thinking "there is no mechanism" will just generate more > postings of this type. > > What about "existing mechanisms intended to aid an individual > in seeking to change such a result, including the appeals process > described in RFC 2026 section 6.5, aren't used consistently"? there is a process which i would argue is not a mechanism. and certainly not a mechanism intended to aid. i think it is as much a barrier to appeal as anything else. i certainly do not believe the existing process is a mechanism that aids people in making appeals. a.= From problem-statement-bounces@alvestrand.no Sun Jun 29 22:01:11 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13208 for ; Sun, 29 Jun 2003 22:01:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4AA00625D0; Mon, 30 Jun 2003 03:27:22 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mx-out.daemonmail.net (mx-out.daemonmail.net [216.104.160.39]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0EF3C61BA7 for ; Mon, 30 Jun 2003 03:27:20 +0200 (CEST) Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.9.3p2/8.9.3) with SMTP id SAA22680 for ; Sun, 29 Jun 2003 18:27:19 -0700 (PDT) (envelope-from spencer@mcsr-labs.org) Received: from (12.237.229.250 [12.237.229.250]) by mail.varaha.com with SMTP id it50EyB2 Sun, 29 Jun 2003 18:27:18 -0700 (PDT) Message-ID: <045201c33ea6$bfd052a0$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <86BD6B17-A9E7-11D7-A025-000393CC2112@apocalypse.org> Date: Sun, 29 Jun 2003 20:27:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit Dear Avri, I agree with the sentiment, but we've had at least a couple of people who've posted references to appeals that were filed, including appeals that resulted in overturned decisions. I'm thinking "there is no mechanism" will just generate more postings of this type. What about "existing mechanisms intended to aid an individual in seeking to change such a result, including the appeals process described in RFC 2026 section 6.5, aren't used consistently"? Spencer ----- Original Message ----- From: "avri" To: "Keith Moore" Cc: Sent: Saturday, June 28, 2003 11:09 PM Subject: appeal mechanisms was Re: Ombuds-process i am personally fine with the statement of the problem as: When an individual thinks that the process has produced a result that is harmful to the Internet or thinks that IETF processes have not been adhered to, there is no mechanism to aid that individual in seeking to change that result. i think this take your comments into account. does it? a. On söndag, jun 29, 2003, at 09:37 Asia/Seoul, Keith Moore wrote: > On Sat, 28 Jun 2003 10:28:44 +0900 > avri wrote: > > ] > When an individual thnks that the process has not produced a result > ] > that is best for the Internet, there is no formal process to aid > the > ] > individual in seeking to change that result. > ] > ] i think this formulation is better then mine. but is too restrictive. > ] it calls for the judgment of what is best for the Internet. > > well, that's what the rules say that IETF participants are supposed to > do, > so I don't see a problem with invoking it here. but reasonable people > can disagree about what is "best", and I don't want to expect > challenges > every time someone has a difference of opinion - I think we should > expect > some gap between "best" and "so bad it deserves to be challenged" > I would instead say > > "when an individual thinks that the process has produced a result that > is > harmful to the Internet..." > > though I would assert that our existing appeals process does permit > individuals to appeal decisions based on this criteria - in that > anything that is harmful to the Internet is almost certainly not > suitable under the criteria for standards-track documents. > (e.g. "no known technical omissions") > > ] as an alternative i suggest: > ] > ] When an individual thinks that the process has not produced the right > ] result, or thinks that the process has been abused, there is no > formal > ] mechanism to aid that individual in seeking to change that result. > > strongly disagree. nothing in our process requires the "right result", > and it's not clear that there is any such thing. nor is it clear > what > "abusing the process" is as opposed to "failing to adhere to the > process". > if someone follows the rules but produces a harmful result, is that > abusing the process? > > Keith > From problem-statement-bounces@alvestrand.no Sun Jun 29 22:01:59 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13263 for ; Sun, 29 Jun 2003 22:01:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 165AE625D3; Mon, 30 Jun 2003 04:01:29 +0200 (CEST) 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 5CCA3625D0 for ; Mon, 30 Jun 2003 04:01:25 +0200 (CEST) Received: (qmail 31489 invoked from network); 30 Jun 2003 02:08:03 -0000 Received: from ida120.ida.gov.sg (HELO pobox.org.sg) (210.24.194.120) by sentosa.post1.com with SMTP; 30 Jun 2003 02:08:03 -0000 Message-ID: <3EFF9A03.1000306@pobox.org.sg> Date: Mon, 30 Jun 2003 10:01:39 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: "Theodore Ts'o" References: <77E1A470-A83A-11D7-946F-000393CC2112@apocalypse.org> <552100488.1056707254@localhost> <20030627193437.GB22139@think> <20030627202919.GA22838@think> In-Reply-To: <20030627202919.GA22838@think> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Harald Tveit Alvestrand Cc: avri Cc: problem-statement@alvestrand.no Subject: Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Well, I am in the "under 30" category. -James Seng Theodore Ts'o wrote: > On Fri, Jun 27, 2003 at 03:34:37PM -0400, Theodore Ts'o wrote: > >>Perhaps it would be useful to find out if others had similar >>experiences to Phil. I certainly haven't, and I'm well under 30.... > > > My mistake. That should have read, "well under 40...". I did add my > "fifth bit" party a while ago... > > - Ted > > > From problem-statement-bounces@alvestrand.no Sun Jun 29 22:02:16 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13290 for ; Sun, 29 Jun 2003 22:02:15 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E7E47625D0; Mon, 30 Jun 2003 04:01:45 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1DAAF61BA7 for ; Mon, 30 Jun 2003 04:01:44 +0200 (CEST) Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4901437 for problem-statement@alvestrand.no; Sun, 29 Jun 2003 22:01:42 -0400 Message-Id: <5.1.0.14.0.20030629215047.02953f90@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 29 Jun 2003 22:00:12 -0400 To: problem-statement@alvestrand.no From: "Joel M. Halpern" In-Reply-To: <123A6F9F-AA9C-11D7-A025-000393CC2112@apocalypse.org> References: <045201c33ea6$bfd052a0$0200a8c0@DFNJGL21> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Let us be clear on the history and purpose, and then decide which of=20 several possible problems we actually have. [This is based largely on outside observation, as I was not active in=20 defining these processes at the time.] When the current processes were being created, it was understood that there= =20 was plenty of room for the IESG or IAB to do things wrong, and some=20 mechanism for correcting these errors was needed. It was presumed that errors requiring this level of appeal ought to be=20 rare. Normally, WG chair errors should be discussed with the AD, and AD=20 errors would be discussed with the IETF chair. If significant errors=20 requiring major action ever become common, then the basic structure is=20 wrong and needs changing. It was also presumed (and activity since has shown this to be true) that=20 requests to overturn IESG action would inevitably require significant work= =20 from a fair number of people. Hence, the current system simply will not=20 work if such requests were common (even ignoring the fundamental=20 observation in the previous paragraph.) Hence, the appeals process was not created to make it easy to cause=20 extensive review of IESG actions. The IETF last call is the intended=20 mechanism to make it easy for folks to provide useful input. And that=20 (sensibly) is before the decision. So, my question becomes what problem do we want to solve? Do we really want to make appeals of IESG decisions easy and common? I=20 hope not. Is there a problem where people feel that their input has not been=20 considered, and it is too hard to force the issue? Probably. Is the underlying problem then that people think that they are being=20 ignored when in fact their input was considered? Or is there an underlying problem of the IESG ignoring important input? I= =20 hope not, but it is certainly not impossible. Or is there a problem that the appeals process, by nature difficult, is=20 simply perceived as too hard, even if it is appropriate for the job? Or is there a problem of insufficient explanations of the decisions that do= =20 get made? Yours, Joel M. Halpern At 10:42 AM 6/30/2003 +0900, avri wrote: >Hi, > >On m=E5ndag, jun 30, 2003, at 10:27 Asia/Seoul, Spencer Dawkins wrote: > >>I agree with the sentiment, but we've had at least a couple >>of people who've posted references to appeals that were >>filed, including appeals that resulted in overturned >>decisions. > >i think looking at the counter-examples will show that the folks >brave enough and process savvy enough to file these appeals >where not our average participants. > >yes, there is a process but it takes a lot of energy and savvy to >use that process. > >> >>I'm thinking "there is no mechanism" will just generate more >>postings of this type. >> >>What about "existing mechanisms intended to aid an individual >>in seeking to change such a result, including the appeals process >>described in RFC 2026 section 6.5, aren't used consistently"? > >there is a process which i would argue is not a mechanism. >and certainly not a mechanism intended to aid. >i think it is as much a barrier to appeal as anything else. > >i certainly do not believe the existing process is a mechanism >that aids people in making appeals. > >a. From problem-statement-bounces@alvestrand.no Sun Jun 29 22:01:03 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13186 for ; Sun, 29 Jun 2003 22:01:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A1CEF625D3; Mon, 30 Jun 2003 04:00:31 +0200 (CEST) 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 6702E61BA7 for ; Mon, 30 Jun 2003 04:00:28 +0200 (CEST) Received: (qmail 31471 invoked from network); 30 Jun 2003 02:07:04 -0000 Received: from ida120.ida.gov.sg (HELO pobox.org.sg) (210.24.194.120) by sentosa.post1.com with SMTP; 30 Jun 2003 02:07:04 -0000 Message-ID: <3EFF99C9.2040501@pobox.org.sg> Date: Mon, 30 Jun 2003 10:00:41 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: vkompella@timetra.com References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Cc: James Kempf Cc: Brian E Carpenter Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 While I dont disagree we should document the problem of IESG dual role as WG chairs, we should be aware that it is a secondary problem resulted from the power granted to the WG chairs & IESG, ie. it is a problem of balance of power. -James Seng Vach Kompella wrote: > In one working group, a WG chair did more than recuse himself because he wanted > to push through a draft he had co-authored. He actually stepped down from the > chair position. I think that might be going too far. But these are > "solutions". > > The problem statement is more about whether the following are perceived to be > issues or not: > > - pursuing an individual draft within a WG that one co-chairs > - co-chairing a WG that one oversees as an AD > > I'd see the former as less of an issue, and recusal is adequate. The second is > a bigger issue. > > -Vach > > >>-----Original Message----- >>From: problem-statement-bounces@alvestrand.no >>[mailto:problem-statement-bounces@alvestrand.no]On Behalf Of Brian E >>Carpenter >>Sent: Friday, June 27, 2003 11:29 AM >>To: James Kempf >>Cc: problem-statement@alvestrand.no >>Subject: Re: ADs who are also WG chairs >> >> >>I agree that it's amazing that ADs ever say "yes" to this (except >>when the WG is tailing off, for example) and I think the case of >>being a chair in the same area is definitely a conflict of interest. >>I think recusal should cover the other cases. It is worth documenting. >> >> Brian >> >>James Kempf wrote: >> >>>>One of the issues that came up in the discussion on rough consensus >>>>is the issue of ADs being WG chairs - either in their own area or in >>>>another >>>>area. >>>> >>>>I do not believe this dual role aspect of IETF management is yet >>>>reflected >>>>in the problem draft. >>>> >>>>Should it be? >>>> >>> >>>As long as the AD acting as a WG chair recluses themselves from any and all >>>IESG decisions having to do with the WG, to avoid conflict of interest, I >>>don't think there should be a problem. I think its somewhat more >>>questionable if the WG is in the same area, since it removes one person from >>>oversight, and having two technically knowledgable, independent opinions on >>>a WG is often useful. >>> >>>That said, I cannot see how, given the workload, an AD can possibly do a >>>good job as a WG chair and still expect to fufill their duties as an AD. >>>Just on the basis of that alone, it might be sensible to consider some kind >>>of strong disapproval, if not restriction, and make it an exceptional case. >>> >>>My 0.02 euro. >>> >>> jak >> >> > > > > From problem-statement-bounces@alvestrand.no Sun Jun 29 22:07:51 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13561 for ; Sun, 29 Jun 2003 22:07:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 650F9625D3; Mon, 30 Jun 2003 04:07:19 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mx-out.daemonmail.net (mx-out.daemonmail.net [216.104.160.39]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4061361BA7 for ; Mon, 30 Jun 2003 04:07:16 +0200 (CEST) Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.9.3p2/8.9.3) with SMTP id TAA39625 for ; Sun, 29 Jun 2003 19:07:15 -0700 (PDT) (envelope-from spencer@mcsr-labs.org) Received: from (12.237.229.250 [12.237.229.250]) by mail.varaha.com with SMTP id yIA0UNG2 Sun, 29 Jun 2003 19:07:15 -0700 (PDT) Message-ID: <053501c33eac$5417d190$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <123A6F9F-AA9C-11D7-A025-000393CC2112@apocalypse.org> Date: Sun, 29 Jun 2003 21:07:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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: 8bit Dear Avri, I agree with everything you're saying. I'm just thinking that if we think we have a process but the process does not provide an effective mechanism, we should say so clearly. Spencer ----- Original Message ----- From: "avri" To: "Spencer Dawkins" Cc: Sent: Sunday, June 29, 2003 8:42 PM Subject: Re: appeal mechanisms was Re: Ombuds-process Hi, On måndag, jun 30, 2003, at 10:27 Asia/Seoul, Spencer Dawkins wrote: > I agree with the sentiment, but we've had at least a couple > of people who've posted references to appeals that were > filed, including appeals that resulted in overturned > decisions. i think looking at the counter-examples will show that the folks brave enough and process savvy enough to file these appeals where not our average participants. yes, there is a process but it takes a lot of energy and savvy to use that process. > > I'm thinking "there is no mechanism" will just generate more > postings of this type. > > What about "existing mechanisms intended to aid an individual > in seeking to change such a result, including the appeals process > described in RFC 2026 section 6.5, aren't used consistently"? there is a process which i would argue is not a mechanism. and certainly not a mechanism intended to aid. i think it is as much a barrier to appeal as anything else. i certainly do not believe the existing process is a mechanism that aids people in making appeals. a. From problem-statement-bounces@alvestrand.no Mon Jun 30 00:15:02 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16900 for ; Mon, 30 Jun 2003 00:15:01 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3B908625D5; Mon, 30 Jun 2003 06:14:32 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by eikenes.alvestrand.no (Postfix) with ESMTP id B5B41625BC for ; Mon, 30 Jun 2003 06:14:30 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19Wq3V-0003bs-00; Sun, 29 Jun 2003 21:14:17 -0700 Date: Mon, 30 Jun 2003 00:10:41 -0400 From: Keith Moore To: James Seng Message-Id: <20030630001041.6b257d44.moore@cs.utk.edu> In-Reply-To: <3EFF99C9.2040501@pobox.org.sg> References: <3EFF99C9.2040501@pobox.org.sg> X-Mailer: Sylpheed version 0.9.1 (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 Cc: moore@cs.utk.edu Cc: kempf@docomolabs-usa.com Cc: brian@hursley.ibm.com Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 ] While I dont disagree we should document the problem of IESG dual role ] as WG chairs, we should be aware that it is a secondary problem resulted ] from the power granted to the WG chairs & IESG, ie. it is a problem of ] balance of power. Seems like you could describe almost any problem as a balance of power problem. For instance, the global pollution problem is caused by too much power being concentrated in the hands of those who pollute and too little power being concentrated in the hands of those who wish to protect the environment. But I don't see how this illuminates an understanding of the problems of ADs also being WG chairs. From problem-statement-bounces@alvestrand.no Mon Jun 30 00:16:37 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16942 for ; Mon, 30 Jun 2003 00:16:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 85DD5625D4; Mon, 30 Jun 2003 06:11:46 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 70F68625BC for ; Mon, 30 Jun 2003 06:11:44 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19Wq0q-0005KB-00; Sun, 29 Jun 2003 21:11:32 -0700 Date: Mon, 30 Jun 2003 00:07:56 -0400 From: Keith Moore To: avri Message-Id: <20030630000756.69f79e26.moore@cs.utk.edu> In-Reply-To: <123A6F9F-AA9C-11D7-A025-000393CC2112@apocalypse.org> References: <045201c33ea6$bfd052a0$0200a8c0@DFNJGL21> <123A6F9F-AA9C-11D7-A025-000393CC2112@apocalypse.org> X-Mailer: Sylpheed version 0.9.1 (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 Cc: moore@cs.utk.edu Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 certainly do not believe the existing process is a mechanism ] that aids people in making appeals. so do you think the existing appeals mechanism imposes too much of a burden for the appellant? From problem-statement-bounces@alvestrand.no Mon Jun 30 00:21:01 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17068 for ; Mon, 30 Jun 2003 00:21:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 11B7C625D4; Mon, 30 Jun 2003 06:20:31 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by eikenes.alvestrand.no (Postfix) with ESMTP id 796AF625BC for ; Mon, 30 Jun 2003 06:20:29 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19Wq90-00011Y-00; Sun, 29 Jun 2003 21:19:58 -0700 Date: Mon, 30 Jun 2003 00:16:23 -0400 From: Keith Moore To: "Joel M. Halpern" Message-Id: <20030630001623.5db10b96.moore@cs.utk.edu> In-Reply-To: <5.1.0.14.0.20030629215047.02953f90@mail.stevecrocker.com> References: <045201c33ea6$bfd052a0$0200a8c0@DFNJGL21> <5.1.0.14.0.20030629215047.02953f90@mail.stevecrocker.com> X-Mailer: Sylpheed version 0.9.1 (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 Cc: moore@cs.utk.edu Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Sun, 29 Jun 2003 22:00:12 -0400 "Joel M. Halpern" wrote: ] Hence, the appeals process was not created to make it easy to cause ] extensive review of IESG actions. The IETF last call is the intended ] mechanism to make it easy for folks to provide useful input. And that ] (sensibly) is before the decision. ] ] So, my question becomes what problem do we want to solve? ] Do we really want to make appeals of IESG decisions easy and common? I ] hope not. ] Is there a problem where people feel that their input has not been ] considered, and it is too hard to force the issue? Probably. ] Is the underlying problem then that people think that they are being ] ignored when in fact their input was considered? ] Or is there an underlying problem of the IESG ignoring important input? I ] hope not, but it is certainly not impossible. ] Or is there a problem that the appeals process, by nature difficult, is ] simply perceived as too hard, even if it is appropriate for the job? ] Or is there a problem of insufficient explanations of the decisions that do ] get made? I think the problem is that too much of what gets to IESG has failed to consider important design considerations and/or is of poor quality. By the time the documents get to IESG, there's little that IESG can do to fix the problem - and there is a significant chance that *any* action that IESG takes would either warrant an appeal (say, because it approved a document containing technical errors), or cause someone to believe that IESG had acted improperly. When working groups do their jobs properly, there's already consensus on the document (not just within the working group, but through the entire community) *before* the document goes to IESG, and IESG's job is easy. So what we need to do is insist that working groups make IESG's job easy. From problem-statement-bounces@alvestrand.no Mon Jun 30 00:22:13 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17113 for ; Mon, 30 Jun 2003 00:22:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 81569625D4; Mon, 30 Jun 2003 06:21:43 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id D5144625BC for ; Mon, 30 Jun 2003 06:21:41 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19WqAe-0000Us-00; Sun, 29 Jun 2003 21:21:40 -0700 Date: Mon, 30 Jun 2003 00:18:04 -0400 From: Keith Moore To: Spencer Dawkins Message-Id: <20030630001804.06a7cddc.moore@cs.utk.edu> In-Reply-To: <053501c33eac$5417d190$0200a8c0@DFNJGL21> References: <123A6F9F-AA9C-11D7-A025-000393CC2112@apocalypse.org> <053501c33eac$5417d190$0200a8c0@DFNJGL21> X-Mailer: Sylpheed version 0.9.1 (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 Cc: moore@cs.utk.edu Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 agree with everything you're saying. I'm just thinking that ] if we think we have a process but the process does not ] provide an effective mechanism, we should say so clearly. it's as clear as mud to me. are you saying that the appeal process is too much trouble, or that the appeal process, when invoked, fails to produce a desirable result? From problem-statement-bounces@alvestrand.no Mon Jun 30 00:29:24 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17277 for ; Mon, 30 Jun 2003 00:29:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 256B3625D4; Mon, 30 Jun 2003 06:28:53 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4DC73625BC for ; Mon, 30 Jun 2003 06:28:51 +0200 (CEST) Received: by romeo.rtfm.com (Postfix, from userid 556) id C7691ABBF; Sun, 29 Jun 2003 21:35:04 -0700 (PDT) To: Keith Moore References: <045201c33ea6$bfd052a0$0200a8c0@DFNJGL21> <5.1.0.14.0.20030629215047.02953f90@mail.stevecrocker.com> <20030630001623.5db10b96.moore@cs.utk.edu> From: Eric Rescorla Date: 29 Jun 2003 21:35:04 -0700 In-Reply-To: <20030630001623.5db10b96.moore@cs.utk.edu> Message-ID: Lines: 26 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Portable Code) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Joel M. Halpern" Cc: problem-statement@alvestrand.no Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: EKR 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 Keith Moore writes: > I think the problem is that too much of what gets to IESG has failed to > consider important design considerations and/or is of poor quality. > By the time the documents get to IESG, there's little that IESG can do to fix > the problem - and there is a significant chance that *any* action that IESG > takes would either warrant an appeal (say, because it approved a document > containing technical errors), or cause someone to believe that IESG had acted > improperly. > > When working groups do their jobs properly, there's already consensus on the > document (not just within the working group, but through the entire community) > *before* the document goes to IESG, and IESG's job is easy. > > So what we need to do is insist that working groups make IESG's job easy. The obvious way to do that would be for the IESG to block documents that don't meet their standards. If they're not going to do that, how do you propose that "we" insist that the WGs make the IESG's life easy? -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From problem-statement-bounces@alvestrand.no Mon Jun 30 00:42:07 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17415 for ; Mon, 30 Jun 2003 00:42:06 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D5891625BC; Mon, 30 Jun 2003 06:41:34 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mallard.mail.pas.earthlink.net (mallard.mail.pas.earthlink.net [207.217.120.48]) by eikenes.alvestrand.no (Postfix) with ESMTP id C70F062590 for ; Mon, 30 Jun 2003 06:41:33 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19WqTZ-0001s6-00; Sun, 29 Jun 2003 21:41:13 -0700 Date: Mon, 30 Jun 2003 00:37:36 -0400 From: Keith Moore To: EKR Message-Id: <20030630003736.6721b512.moore@cs.utk.edu> In-Reply-To: References: <045201c33ea6$bfd052a0$0200a8c0@DFNJGL21> <5.1.0.14.0.20030629215047.02953f90@mail.stevecrocker.com> <20030630001623.5db10b96.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: joel@stevecrocker.com Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 29 Jun 2003 21:35:04 -0700 Eric Rescorla wrote: ] > When working groups do their jobs properly, there's already consensus on ] > the document (not just within the working group, but through the entire ] > community) *before* the document goes to IESG, and IESG's job is easy. ] > ] > So what we need to do is insist that working groups make IESG's job easy. ] ] The obvious way to do that would be for the IESG to block ] documents that don't meet their standards. no, that's not easy for IESG, because people put considerable pressure on IESG to "do the right thing" and block the document, while others pressure them to approve standards even when they're broken - and then we get people coming to the problem-statement group claiming that IESG is harming IETF. the point is that basic design issues need to be sorted out, most of the time, within a working group. and that means that the WG needs to build and demonstrate a broad consensus for its approach early on, rather than ignoring the conflicts that they're causing and hoping that IESG will ignore them too. ] If they're not going to do that, how do you propose that "we" insist that ] the WGs make the IESG's life easy? IESG's role has to stay the same, but we need to arrange things so that IESG rarely feels a need to significantly push back on a document after Last Call. From problem-statement-bounces@alvestrand.no Mon Jun 30 00:58:45 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17806 for ; Mon, 30 Jun 2003 00:58:44 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 97A7B625BC; Mon, 30 Jun 2003 06:58:12 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from apocalypse.org (apocalypse.org [192.48.232.17]) by eikenes.alvestrand.no (Postfix) with ESMTP id DCCB062590 for ; Mon, 30 Jun 2003 06:58:10 +0200 (CEST) Received: from apocalypse.org (IDENT:kmDaZZV78kj/HcOFiliasegnhnA/aEPC@apocalypse.org [192.48.232.17]) by apocalypse.org (8.11.6/8.11.6) with ESMTP id h5U4w5G26225; Mon, 30 Jun 2003 00:58:06 -0400 Date: Mon, 30 Jun 2003 13:58:00 +0900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Keith Moore From: avri In-Reply-To: <20030630000756.69f79e26.moore@cs.utk.edu> Message-Id: <6C50B77B-AAB7-11D7-A025-000393CC2112@apocalypse.org> Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 m=E5ndag, jun 30, 2003, at 13:07 Asia/Seoul, Keith Moore wrote: > ] i certainly do not believe the existing process is a mechanism > ] that aids people in making appeals. > > so do you think the existing appeals mechanism imposes too much of a > burden for the appellant? > > yes, i personally do believe that the appeals process that currently=20 exists imposes too much burden for many, though not all, appellants. i also believe that a process that uses the same channel for appeals as might be the object of the appeal, is flawed. i think this may be an aspect of too much control in too few hands. and i believe that a process on paper is not the same as a mechanism that aids the appellants. a. From problem-statement-bounces@alvestrand.no Mon Jun 30 00:59:53 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17843 for ; Mon, 30 Jun 2003 00:59:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 563C4625BC; Mon, 30 Jun 2003 06:59:22 +0200 (CEST) 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 E442C62590 for ; Mon, 30 Jun 2003 06:59:17 +0200 (CEST) Received: (qmail 34311 invoked from network); 30 Jun 2003 05:05:55 -0000 Received: from ida120.ida.gov.sg (HELO pobox.org.sg) (210.24.194.120) by sentosa.post1.com with SMTP; 30 Jun 2003 05:05:55 -0000 Message-ID: <3EFFC3B5.2030204@pobox.org.sg> Date: Mon, 30 Jun 2003 12:59:33 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Keith Moore References: <3EFF99C9.2040501@pobox.org.sg> <20030630001041.6b257d44.moore@cs.utk.edu> In-Reply-To: <20030630001041.6b257d44.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Cc: kempf@docomolabs-usa.com Cc: brian@hursley.ibm.com Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Let me put it another way: The current IETF process gives too much power to the wg chairs & IESG so a person dual role at wg chair & IESG is likely to be problematic. If the process is redesigned, it could be done in such a way that having dual role is not a problem. Note that I dont object documenting the dual role problem specifically. And we could argue what's the appropriate solution (altho not in this forum) but the answer is not neccessary the simplistic rule of "no person shall be wg chair and IESG at the same time". -James Seng Keith Moore wrote: > ] While I dont disagree we should document the problem of IESG dual role > ] as WG chairs, we should be aware that it is a secondary problem resulted > ] from the power granted to the WG chairs & IESG, ie. it is a problem of > ] balance of power. > > Seems like you could describe almost any problem as a balance of power > problem. For instance, the global pollution problem is caused by too much > power being concentrated in the hands of those who pollute and too little > power being concentrated in the hands of those who wish to protect the > environment. > > But I don't see how this illuminates an understanding of the problems of ADs > also being WG chairs. > > > From problem-statement-bounces@alvestrand.no Mon Jun 30 01:04:36 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17916 for ; Mon, 30 Jun 2003 01:04:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EFD29625BC; Mon, 30 Jun 2003 07:04:03 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by eikenes.alvestrand.no (Postfix) with ESMTP id 42AFA62590 for ; Mon, 30 Jun 2003 07:04:02 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19WqpV-0003Nv-00; Sun, 29 Jun 2003 22:03:53 -0700 Date: Mon, 30 Jun 2003 01:00:17 -0400 From: Keith Moore To: avri Message-Id: <20030630010017.2d5e57a3.moore@cs.utk.edu> In-Reply-To: <6C50B77B-AAB7-11D7-A025-000393CC2112@apocalypse.org> References: <20030630000756.69f79e26.moore@cs.utk.edu> <6C50B77B-AAB7-11D7-A025-000393CC2112@apocalypse.org> X-Mailer: Sylpheed version 0.9.1 (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 Cc: moore@cs.utk.edu Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 ] yes, i personally do believe that the appeals process that currently ] exists imposes too much burden for many, though not all, appellants. okay, I got that. ] i also believe that a process that uses the same channel for appeals ] as might be the object of the appeal, is flawed. mumble. I find it hard to imagine that if the appeal is about someone on IESG, for instance, that that AD would not recuse himself. but it wouldn't bother me if the process were changed to make that explicit. ] and i believe that a process on paper is not the same as ] a mechanism that aids the appellants. well, since everything we do is "on paper" (or "on bits") I guess I wonder what kind of mechanism you have in mind. From problem-statement-bounces@alvestrand.no Mon Jun 30 01:11:41 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18047 for ; Mon, 30 Jun 2003 01:11:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C1D03625BC; Mon, 30 Jun 2003 07:11:08 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9EC7462590 for ; Mon, 30 Jun 2003 07:11:07 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19WqwP-0005Py-00; Sun, 29 Jun 2003 22:11:01 -0700 Date: Mon, 30 Jun 2003 01:07:24 -0400 From: Keith Moore To: James Seng Message-Id: <20030630010724.4b44a35e.moore@cs.utk.edu> In-Reply-To: <3EFFC3B5.2030204@pobox.org.sg> References: <3EFF99C9.2040501@pobox.org.sg> <20030630001041.6b257d44.moore@cs.utk.edu> <3EFFC3B5.2030204@pobox.org.sg> X-Mailer: Sylpheed version 0.9.1 (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 Cc: kempf@docomolabs-usa.com Cc: moore@cs.utk.edu Cc: brian@hursley.ibm.com Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 ] Let me put it another way: ] ] The current IETF process gives too much power to the wg chairs & IESG so ] a person dual role at wg chair & IESG is likely to be problematic. if you're saying that this creates a conflict of interest, I'd probably agree with you. the same person cannot adequately represent the WG to IESG and fulfill the duty of IESG to review the WG's documents. though it's already well-established that an AD who is a WG chair must recuse himself from discussions of that WG's work, this still means that there's one fewer AD reviewing the work - and given that most works are only reviewed by a couple of ADs anyway, this is a problem. however, I don't think you've demonstrated that "the current IETF process gives too much power to the wg chairs & IESG", and I'd object to that statement. *somebody* has to decide whether there is consensus, and whether the document is of adequate quality, both within the WG and within the IETF as a whole, and I don't see how decision can reasonably be made by other than a small group of people. From problem-statement-bounces@alvestrand.no Mon Jun 30 01:19:14 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18205 for ; Mon, 30 Jun 2003 01:19:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 56915625D4; Mon, 30 Jun 2003 07:18:41 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from apocalypse.org (apocalypse.org [192.48.232.17]) by eikenes.alvestrand.no (Postfix) with ESMTP id A549F625BC for ; Mon, 30 Jun 2003 07:18:38 +0200 (CEST) Received: from apocalypse.org (IDENT:5TDg2LqvOyNCUUNQ6FL3dvLBffpG1y3O@apocalypse.org [192.48.232.17]) by apocalypse.org (8.11.6/8.11.6) with ESMTP id h5U5IaG27723; Mon, 30 Jun 2003 01:18:36 -0400 Date: Mon, 30 Jun 2003 14:18:30 +0900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Keith Moore From: avri In-Reply-To: <20030630010017.2d5e57a3.moore@cs.utk.edu> Message-Id: <49A73F37-AABA-11D7-A025-000393CC2112@apocalypse.org> Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 m=E5ndag, jun 30, 2003, at 14:00 Asia/Seoul, Keith Moore wrote: > ] yes, i personally do believe that the appeals process that currently > ] exists imposes too much burden for many, though not all, appellants. > > okay, I got that. > > ] i also believe that a process that uses the same channel for appeals > ] as might be the object of the appeal, is flawed. > > mumble. I find it hard to imagine that if the appeal is about someone=20= > on > IESG, for instance, that that AD would not recuse himself. but it=20 > wouldn't > bother me if the process were changed to make that explicit. i think that might be enough. the close nature of the IESG=20 relationship, could make true impartiality difficult. i obviously can't speak for the=20 internal dynamic of the current or any other IESG, but the nature of the group, as had=20 been described externally, seems a place where handling appeals against=20 sitting members could be too much of a challenge. > > ] and i believe that a process on paper is not the same as > ] a mechanism that aids the appellants. > > well, since everything we do is "on paper" (or "on bits") I guess I=20 > wonder > what kind of mechanism you have in mind. > > well last time i tried to explain that i wandered too far into=20 solutions. but i do see it as possibly involving people formally charged with the task of providing such aid and as possibly, occasionally, acting on behalf of appellants. a.= From problem-statement-bounces@alvestrand.no Mon Jun 30 01:21:12 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18290 for ; Mon, 30 Jun 2003 01:21:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2181461AA5; Mon, 30 Jun 2003 07:20:40 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1910761A96 for ; Mon, 30 Jun 2003 07:20:38 +0200 (CEST) Received: by romeo.rtfm.com (Postfix, from userid 556) id 4BF8AABBC; Sun, 29 Jun 2003 22:26:56 -0700 (PDT) To: Keith Moore References: <045201c33ea6$bfd052a0$0200a8c0@DFNJGL21> <5.1.0.14.0.20030629215047.02953f90@mail.stevecrocker.com> <20030630001623.5db10b96.moore@cs.utk.edu> <20030630003736.6721b512.moore@cs.utk.edu> From: Eric Rescorla Date: 29 Jun 2003 22:26:55 -0700 In-Reply-To: <20030630003736.6721b512.moore@cs.utk.edu> Message-ID: Lines: 25 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Portable Code) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: joel@stevecrocker.com Cc: problem-statement@alvestrand.no Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: EKR 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 Keith Moore writes: > ] If they're not going to do that, how do you propose that "we" insist that > ] the WGs make the IESG's life easy? > > IESG's role has to stay the same, but we need to arrange things so that IESG > rarely feels a need to significantly push back on a document after Last Call. I don't see any way to arrange this other than the IESG rejecting documents and holding firm. I'd be glad to hear your suggestions, however. The problem here is that there is an incentive conflict: The people in the WGs who write documents by and large simply want them passed. There are some people, including most (all) of the IESG who believe that the WGs are not putting out work of sufficient quality. In order to change this situation, the WG's incentives have to change. The only people who can make their incentives change are those who have the power to block their documents. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From problem-statement-bounces@alvestrand.no Mon Jun 30 09:22:14 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21727 for ; Mon, 30 Jun 2003 09:22:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 307EB62590; Mon, 30 Jun 2003 15:19:13 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0915061AA5 for ; Mon, 30 Jun 2003 15:19:11 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19WyYg-0003LR-00; Mon, 30 Jun 2003 06:19:02 -0700 Date: Mon, 30 Jun 2003 09:15:24 -0400 From: Keith Moore To: avri Message-Id: <20030630091524.5258337c.moore@cs.utk.edu> In-Reply-To: <49A73F37-AABA-11D7-A025-000393CC2112@apocalypse.org> References: <20030630010017.2d5e57a3.moore@cs.utk.edu> <49A73F37-AABA-11D7-A025-000393CC2112@apocalypse.org> X-Mailer: Sylpheed version 0.9.1 (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 Cc: moore@cs.utk.edu Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 ] > ] yes, i personally do believe that the appeals process that currently ] > ] exists imposes too much burden for many, though not all, appellants. ] > ] > okay, I got that. ] > ] > ] i also believe that a process that uses the same channel for appeals ] > ] as might be the object of the appeal, is flawed. ] > ] > mumble. I find it hard to imagine that if the appeal is about someone ] > on IESG, for instance, that that AD would not recuse himself. but it ] > wouldn't bother me if the process were changed to make that explicit. ] ] i think that might be enough. the close nature of the IESG ] relationship, could make true impartiality difficult. i obviously can't ] speak for the internal dynamic of the current or any other IESG, but the ] nature of the group, as had been described externally, seems a place where ] handling appeals against sitting members could be too much of a challenge. hmmm. you might have a point there. ] > ] and i believe that a process on paper is not the same as ] > ] a mechanism that aids the appellants. ] > ] > well, since everything we do is "on paper" (or "on bits") I guess I ] > wonder what kind of mechanism you have in mind. ] ] well last time i tried to explain that i wandered too far into solutions. ] but i do see it as possibly involving people formally charged with the task ] of providing such aid and as possibly, occasionally, acting on behalf of ] appellants. ah, now I think I see what you mean. \begin{solution-space} IMHO, if we were to have a mechanism to aid people who have trouble grokking the process it should not be exclusively for appeals. appeals are very time-consuming for both appellant and IESG; our goal must be to arrange things so that appeals are hardly ever necessary. so we need to think in terms of helping people get a fair result long before an appeal would be considered. \end{solution-space} From problem-statement-bounces@alvestrand.no Mon Jun 30 09:24:05 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21842 for ; Mon, 30 Jun 2003 09:24:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5AD7B62590; Mon, 30 Jun 2003 15:23:33 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mx-out.daemonmail.net (mx-out.daemonmail.net [216.104.160.39]) by eikenes.alvestrand.no (Postfix) with ESMTP id 66D6361AA5 for ; Mon, 30 Jun 2003 15:23:28 +0200 (CEST) Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1]) by mx-out.daemonmail.net (8.9.3p2/8.9.3) with SMTP id GAA10144 for ; Mon, 30 Jun 2003 06:23:27 -0700 (PDT) (envelope-from spencer@mcsr-labs.org) Received: from (216.62.6.129 [216.62.6.129]) by mail.varaha.com with SMTP id Vd201i82 Mon, 30 Jun 2003 06:23:26 -0700 (PDT) Message-ID: <00df01c33f0a$cb08a4b0$8100000a@DFNJGL21> From: "Spencer Dawkins" To: References: <20030630010017.2d5e57a3.moore@cs.utk.edu><49A73F37-AABA-11D7-A025-000393CC2112@apocalypse.org> <20030630091524.5258337c.moore@cs.utk.edu> Date: Mon, 30 Jun 2003 08:23:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Spencer Dawkins List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Dear Keith, Your proposal does not seem solutionist to me - just very pragmatic! I agree that our problem is NOT "we don't have enough formal appeals"... Spencer ----- Original Message ----- From: "Keith Moore" To: "avri" Cc: ; Sent: Monday, June 30, 2003 8:15 AM Subject: Re: appeal mechanisms was Re: Ombuds-process > > \begin{solution-space} > IMHO, if we were to have a mechanism to aid people who have trouble grokking > the process it should not be exclusively for appeals. appeals are very > time-consuming for both appellant and IESG; our goal must be to arrange things > so that appeals are hardly ever necessary. so we need to think in terms of > helping people get a fair result long before an appeal would be considered. > \end{solution-space} From problem-statement-bounces@alvestrand.no Mon Jun 30 09:26:38 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21942 for ; Mon, 30 Jun 2003 09:25:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DB07362590; Mon, 30 Jun 2003 15:25:01 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from grouse.mail.pas.earthlink.net (grouse.mail.pas.earthlink.net [207.217.120.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8958B61AA5 for ; Mon, 30 Jun 2003 15:25:00 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19WyeF-0002hk-00; Mon, 30 Jun 2003 06:24:47 -0700 Date: Mon, 30 Jun 2003 09:21:09 -0400 From: Keith Moore To: EKR Message-Id: <20030630092109.11b6f2db.moore@cs.utk.edu> In-Reply-To: References: <045201c33ea6$bfd052a0$0200a8c0@DFNJGL21> <5.1.0.14.0.20030629215047.02953f90@mail.stevecrocker.com> <20030630001623.5db10b96.moore@cs.utk.edu> <20030630003736.6721b512.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: joel@stevecrocker.com Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit ] The problem here is that there is an incentive conflict: ] The people in the WGs who write documents by and large simply ] want them passed. There are some people, including most (all) ] of the IESG who believe that the WGs are not putting out ] work of sufficient quality. In order to change this situation, ] the WG's incentives have to change. true. but one way to change the incentives is to change how WGs operate, e.g. require them to do widespread review of goals and design documents before writing the protocol. I can also imagine making WGs responsible for reviewing and responding to all Last Call comments. of course IESG would have to make sure that the WG had followed the new procedure, that the responses to those comments were reasonable, etc. and this is too new in my mind and too much into solution space to supply details right now, but I think it ends up having WGs operate very differently than they do now, and the chair's role also being very different. From problem-statement-bounces@alvestrand.no Mon Jun 30 09:46:44 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23712 for ; Mon, 30 Jun 2003 09:46:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 280D0625D5; Mon, 30 Jun 2003 15:46:12 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from znsgs01r.nortelnetworks.com (h42s128a211n47.user.nortelnetworks.com [47.211.128.42]) by eikenes.alvestrand.no (Postfix) with ESMTP id B582462590 for ; Mon, 30 Jun 2003 15:46:09 +0200 (CEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124])id h5UDk4303210; Mon, 30 Jun 2003 14:46:04 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jun 2003 14:46:04 +0100 Message-ID: <4103264BC8D3D51180B7002048400C45016234F5@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "'Margaret Wasserman'" Date: Mon, 30 Jun 2003 14:45:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33F0D.6B59FC50" Cc: "'problem-statement@alvestrand.no'" Subject: RE: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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_01C33F0D.6B59FC50 Content-Type: text/plain; charset="iso-8859-1" Very true. I also pointed out in the last version of the issues draft (not quite in these words though) that getting ADs to be WG chairs is like adding a rather large girder to the camel's back. The ADs have far too much to do without being WG chairs as well. Elwyn > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: 30 June 2003 14:15 > To: problem-statement@alvestrand.no > Subject: Re: ADs who are also WG chairs > > > > I sent this in a private response, but thought it might be > useful to say more publicly... > > > >I view the problem of ADs as WG chairs a symptom of a more basic > >problem that is already identified in both documents -- we don't > >do enough to identify and develop new leaders. We just keep > >overusing the ones that we have until they become so burned out > >that they walk away. > > > >Margaret > > > ------_=_NextPart_001_01C33F0D.6B59FC50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: ADs who are also WG chairs

Very true.  I also pointed out in the last = version of the issues draft (not quite in these words though) that = getting ADs to be WG chairs is like adding a rather large girder to the = camel's back.

The ADs have far too much to do without being WG = chairs as well.

Elwyn

> -----Original Message-----
> From: Margaret Wasserman [mailto:mrw@windriver.com]
> Sent: 30 June 2003 14:15
> To: problem-statement@alvestrand.no
> Subject: Re: ADs who are also WG chairs
>
>
>
> I sent this in a private response, but thought = it might be
> useful to say more publicly...
>
>
> >I view the problem of ADs as WG chairs a = symptom of a more basic
> >problem that is already identified in both = documents -- we don't
> >do enough to identify and develop new = leaders.  We just keep
> >overusing the ones that we have until they = become so burned out
> >that they walk away.
> >
> >Margaret
>
>
>

------_=_NextPart_001_01C33F0D.6B59FC50-- From problem-statement-bounces@alvestrand.no Mon Jun 30 10:42:26 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28253 for ; Mon, 30 Jun 2003 10:42:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 861C362571; Mon, 30 Jun 2003 16:37:55 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8053761AA5 for ; Mon, 30 Jun 2003 16:37:53 +0200 (CEST) Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5UEbng5000134; Mon, 30 Jun 2003 10:37:50 -0400 (EDT) Message-Id: <200306301437.h5UEbng5000134@rtp-core-1.cisco.com> To: Spencer Dawkins In-reply-to: Your message of Mon, 30 Jun 2003 08:23:27 -0500. <00df01c33f0a$cb08a4b0$8100000a@DFNJGL21> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 30 Jun 2003 10:37:49 -0400 From: Eric Rosen Cc: problem-statement@alvestrand.no Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: erosen@cisco.com 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 People seem to have trouble remembering just what the problem with the appeals process is, although this was discussed extensively on this list a month or so ago. An AD may decide to derail a document by explicitly rejecting it on non-objective grounds. Or, more likely, the AD may derail it by delaying it indefinitely; John Klensin gave a very lucid description of the "hypothetical" process which an AD could use to ensure that the document never gets published, even though it never really gets rejected.) Unless there is an explicit process violation, there is no effective appeals mechanism to remedy this situation. Given that the IETF is ostensibly set up as a meritocracy, its legitimacy depends on the application of objective criteria for decision making, but there is no effective way to audit the IESG to ensure that they don't try to impose their own personal visions and/or political agendas. It is unfortunate that most of the messages on this list seem to be from the "old boys" themselves, who of course take umbrage any time someone tries to point out a real problem. From problem-statement-bounces@alvestrand.no Mon Jun 30 10:49:13 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28554 for ; Mon, 30 Jun 2003 10:49:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9147062571; Mon, 30 Jun 2003 16:48:42 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from netcore.fi (netcore.fi [193.94.160.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8CE4C61AA5 for ; Mon, 30 Jun 2003 16:48:40 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h5UEmS608149; Mon, 30 Jun 2003 17:48:30 +0300 Date: Mon, 30 Jun 2003 17:48:26 +0300 (EEST) From: Pekka Savola To: Elwyn Davies In-Reply-To: <4103264BC8D3D51180B7002048400C45016234F5@zhard0jd.europe.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "'Margaret Wasserman'" Cc: "'problem-statement@alvestrand.no'" Subject: RE: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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, 30 Jun 2003, Elwyn Davies wrote: > The ADs have far too much to do without being WG chairs as well. True, true; but I think this is more of a problem caused by long-term working groups. The AD job is 2 years. There are two kinds of issues, I think: 1) WG chair-ship from before being selected AD (should you resign from your WG(s)?) 2) new WG chair-ship during your AD term (should you refuse new WG chair positions while being AD?) I think we all agree that AD's should try to avoid new WG chair jobs (2), but especially when very typically WGs last more than two years (and there may not be good substitutes handy, etc.), having (1) may prove difficult. Of course, all of this would be moot if there actually were a large pool of willing & trusted (by those who select the chairs) people ready for WG chair positions (ie. Margaret's point). -- 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 Mon Jun 30 11:00:01 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21728 for ; Mon, 30 Jun 2003 09:22:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A30A9625D7; Mon, 30 Jun 2003 15:19:29 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.wrs.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id A9DD161AA5 for ; Mon, 30 Jun 2003 15:19:27 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.19]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA03686 for ; Mon, 30 Jun 2003 06:18:50 -0700 (PDT) Message-Id: <5.1.0.14.2.20030630091352.04bc02f0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 30 Jun 2003 09:14:46 -0400 To: problem-statement@alvestrand.no From: Margaret Wasserman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: ADs who are also WG chairs X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no I sent this in a private response, but thought it might be useful to say more publicly... >I view the problem of ADs as WG chairs a symptom of a more basic >problem that is already identified in both documents -- we don't >do enough to identify and develop new leaders. We just keep >overusing the ones that we have until they become so burned out >that they walk away. > >Margaret From problem-statement-bounces@alvestrand.no Mon Jun 30 11:11:09 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00029 for ; Mon, 30 Jun 2003 11:11:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5931662571; Mon, 30 Jun 2003 17:10:37 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from turkey.mail.pas.earthlink.net (turkey.mail.pas.earthlink.net [207.217.120.126]) by eikenes.alvestrand.no (Postfix) with ESMTP id E4F7461AA5 for ; Mon, 30 Jun 2003 17:10:35 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19X0IY-0000wl-00; Mon, 30 Jun 2003 08:10:30 -0700 Date: Mon, 30 Jun 2003 11:06:52 -0400 From: Keith Moore To: erosen@cisco.com Message-Id: <20030630110652.7ff385eb.moore@cs.utk.edu> In-Reply-To: <200306301437.h5UEbng5000134@rtp-core-1.cisco.com> References: <00df01c33f0a$cb08a4b0$8100000a@DFNJGL21> <200306301437.h5UEbng5000134@rtp-core-1.cisco.com> X-Mailer: Sylpheed version 0.9.1 (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 Cc: moore@cs.utk.edu Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 ] People seem to have trouble remembering just what the problem with the ] appeals process is, although this was discussed extensively on this list a ] month or so ago. ] ] An AD may decide to derail a document by explicitly rejecting it on ] non-objective grounds. Or, more likely, the AD may derail it by delaying it ] indefinitely; John Klensin gave a very lucid description of the ] "hypothetical" process which an AD could use to ensure that the document ] never gets published, even though it never really gets rejected.) Let's take these two cases separately. First, to some degree engineering judgement is and must be subjective, so it may be perfectly valid for an AD to reject a document on such grounds. However since the reasons for objection are made explicit, they can be the subject of an appeal - the appellant can assert that the AD made a technical error in his subjective judgement, and the IAB can agree or disagree as it sees fit. As for the second case, it can be difficult to distinguish between a case where an AD is trying to get a document fixed before putting it to the entire IESG for review, and the case where an AD is trying to delay the document indefinitely; d different observers might come to different conclusions. For a while it has at least been recommended that WG chairs CC the IESG secretary when submitting a document for approval by IESG; this at least makes it visible that the document is waiting for review by an AD. I don't see any reason to not make this a formal requirement. The one thing we cannot do is require an AD to approve a document merely because the WG submitted it. It may be that we need another means by which a WG can get their documents reviewed by the entire IESG, so that the lone AD cannot hold things up forever. But whenever a WG submits a docuent that the WG's AD doesn't like, in most cases this is because the WG has failed to get broad consensus on a document. And IMHO that's a much bigger problem than the potential deadlock at AD review. ] Unless there is an explicit process violation, there is no effective appeals ] mechanism to remedy this situation. Well, the appellant could in some cases claim that the AD made a technical error. But I object to the use of the word "derail" as it presumes a right to publication which doesn't (and shouldn't) exist. ] Given that the IETF is ostensibly set up as a meritocracy, its legitimacy ] depends on the application of objective criteria for decision making, but ] there is no effective way to audit the IESG to ensure that they don't try to ] impose their own personal visions and/or political agendas. To some degree engineering judgement is and must be subjective. ] It is unfortunate that most of the messages on this list seem to be from the ] "old boys" themselves, who of course take umbrage any time someone tries to ] point out a real problem. so when you can't support your arguments, inovke ad hominem attacks (in advance) against those who point out their flaws. that way, you don't even have to know what the arguments are to discredit them. Keith From problem-statement-bounces@alvestrand.no Mon Jun 30 11:17:35 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00503 for ; Mon, 30 Jun 2003 11:17:34 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D7D4A62571; Mon, 30 Jun 2003 17:17:03 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.wrs.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1924161AA5 for ; Mon, 30 Jun 2003 17:16:57 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.52]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA13851; Mon, 30 Jun 2003 08:16:03 -0700 (PDT) Message-Id: <5.1.0.14.2.20030630110931.04bc9eb8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 30 Jun 2003 11:11:50 -0400 To: Keith Moore From: Margaret Wasserman In-Reply-To: <20030630110652.7ff385eb.moore@cs.utk.edu> References: <200306301437.h5UEbng5000134@rtp-core-1.cisco.com> <00df01c33f0a$cb08a4b0$8100000a@DFNJGL21> <200306301437.h5UEbng5000134@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 At 11:06 AM 6/30/2003 -0400, Keith Moore wrote: >Let's take these two cases separately. First, to some degree engineering >judgement is and must be subjective, so it may be perfectly valid for an AD >to reject a document on such grounds. However since the reasons for >objection are made explicit, they can be the subject of an appeal - the >appellant can assert that the AD made a technical error in his subjective >judgement, and the IAB can agree or disagree as it sees fit. Yes, the IAB could agree or disagree with the IESG's technical decision... BUT, there would be no point in appealing the IESG's rejection of a document, because the IAB cannot overrule the IESG and publish the document, even if the IAB believes that the IESG made a technical or process error in rejecting the document. Margaret From problem-statement-bounces@alvestrand.no Mon Jun 30 11:19:41 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00708 for ; Mon, 30 Jun 2003 11:19:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 634E662590; Mon, 30 Jun 2003 17:19:10 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED04262571 for ; Mon, 30 Jun 2003 17:19:08 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19X0Qm-0003Rp-00; Mon, 30 Jun 2003 08:19:01 -0700 Date: Mon, 30 Jun 2003 11:15:23 -0400 From: Keith Moore To: Margaret Wasserman Message-Id: <20030630111523.6e9f46e3.moore@cs.utk.edu> In-Reply-To: <5.1.0.14.2.20030630110931.04bc9eb8@mail.windriver.com> References: <200306301437.h5UEbng5000134@rtp-core-1.cisco.com> <00df01c33f0a$cb08a4b0$8100000a@DFNJGL21> <200306301437.h5UEbng5000134@rtp-core-1.cisco.com> <5.1.0.14.2.20030630110931.04bc9eb8@mail.windriver.com> X-Mailer: Sylpheed version 0.9.1 (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 Cc: moore@cs.utk.edu Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 ] At 11:06 AM 6/30/2003 -0400, Keith Moore wrote: ] >Let's take these two cases separately. First, to some degree engineering ] >judgement is and must be subjective, so it may be perfectly valid for an AD ] >to reject a document on such grounds. However since the reasons for ] >objection are made explicit, they can be the subject of an appeal - the ] >appellant can assert that the AD made a technical error in his subjective ] >judgement, and the IAB can agree or disagree as it sees fit. ] ] Yes, the IAB could agree or disagree with the IESG's technical ] decision... ] ] BUT, there would be no point in appealing the IESG's rejection of a ] document, because the IAB cannot overrule the IESG and publish the ] document, even if the IAB believes that the IESG made a technical or ] process error in rejecting the document. if that's the case, we should probably fix it. at the least the IAB should be able to remand the document to IESG for consideration according to different criteria. Keith From problem-statement-bounces@alvestrand.no Mon Jun 30 11:30:08 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01304 for ; Mon, 30 Jun 2003 11:30:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DE54F62571; Mon, 30 Jun 2003 17:29:36 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.wrs.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id 524C261AA5 for ; Mon, 30 Jun 2003 17:29:35 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.52]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA20158; Mon, 30 Jun 2003 08:28:55 -0700 (PDT) Message-Id: <5.1.0.14.2.20030630112034.04be3488@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 30 Jun 2003 11:24:43 -0400 To: Keith Moore From: Margaret Wasserman In-Reply-To: <20030630111523.6e9f46e3.moore@cs.utk.edu> References: <5.1.0.14.2.20030630110931.04bc9eb8@mail.windriver.com> <200306301437.h5UEbng5000134@rtp-core-1.cisco.com> <00df01c33f0a$cb08a4b0$8100000a@DFNJGL21> <200306301437.h5UEbng5000134@rtp-core-1.cisco.com> <5.1.0.14.2.20030630110931.04bc9eb8@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 At 11:15 AM 6/30/2003 -0400, Keith Moore wrote: >] BUT, there would be no point in appealing the IESG's rejection of a >] document, because the IAB cannot overrule the IESG and publish the >] document, even if the IAB believes that the IESG made a technical or >] process error in rejecting the document. > >if that's the case, we should probably fix it. at the least the IAB should be >able to remand the document to IESG for consideration according to different >criteria. This is what RFC 2026 says: "If an individual should disagree with an action taken by the IESG in this process, that person should first discuss the issue with the ISEG Chair. If the IESG Chair is unable to satisfy the complainant then the IESG as a whole should re-examine the action taken, along with input from the complainant, and determine whether any further action is needed. The IESG shall issue a report on its review of the complaint to the IETF. Should the complainant not be satisfied with the outcome of the IESG review, an appeal may be lodged to the IAB. The IAB shall then review the situation and attempt to resolve it in a manner of its own choosing and report to the IETF on the outcome of its review. If circumstances warrant, the IAB may direct that an IESG decision be annulled, and the situation shall then be as it was before the IESG decision was taken. The IAB may also recommend an action to the IESG, or make such other recommendations as it deems fit. The IAB may not, however, pre-empt the role of the IESG by issuing a decision which only the IESG is empowered to make." So, the IAB may recommend an action to the IESG, but it can't force the publication of an RFC. Margaret From problem-statement-bounces@alvestrand.no Mon Jun 30 12:05:17 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03101 for ; Mon, 30 Jun 2003 12:05:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6D32D622AF; Mon, 30 Jun 2003 18:03:31 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1B89B61AA5 for ; Mon, 30 Jun 2003 18:03:30 +0200 (CEST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h5UG3LN11321; Mon, 30 Jun 2003 12:03:22 -0400 (EDT) Date: Mon, 30 Jun 2003 12:03:20 -0400 From: Keith Moore To: Margaret Wasserman Message-Id: <20030630120320.30d5a334.moore@cs.utk.edu> In-Reply-To: <5.1.0.14.2.20030630112034.04be3488@mail.windriver.com> References: <5.1.0.14.2.20030630110931.04bc9eb8@mail.windriver.com> <200306301437.h5UEbng5000134@rtp-core-1.cisco.com> <00df01c33f0a$cb08a4b0$8100000a@DFNJGL21> <200306301437.h5UEbng5000134@rtp-core-1.cisco.com> <5.1.0.14.2.20030630110931.04bc9eb8@mail.windriver.com> <5.1.0.14.2.20030630112034.04be3488@mail.windriver.com> X-Mailer: Sylpheed version 0.9.2 (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 Cc: moore@cs.utk.edu Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > If circumstances warrant, the IAB may direct that an IESG decision > be annulled, and the situation shall then be as it was before the > IESG decision was taken. The IAB may also recommend an action to > the IESG, or make such other recommendations as it deems fit. The > IAB may not, however, pre-empt the role of the IESG by issuing a > decision which only the IESG is empowered to make." > > So, the IAB may recommend an action to the IESG, but it can't force > the publication of an RFC. I think this is mostly as it should be, and at the moment I'm at a loss to see how to improve it. From problem-statement-bounces@alvestrand.no Mon Jun 30 18:18:17 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19469 for ; Mon, 30 Jun 2003 18:18:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C6167625D4; Tue, 1 Jul 2003 00:17:46 +0200 (CEST) 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 580AA6230D for ; Tue, 1 Jul 2003 00:17:45 +0200 (CEST) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h5UMHSDw003271; Mon, 30 Jun 2003 18:17:28 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h5UMHR5I003270; Mon, 30 Jun 2003 18:17:27 -0400 (EDT) Date: Mon, 30 Jun 2003 18:17:27 -0400 (EDT) From: Scott Bradner Message-Id: <200306302217.h5UMHR5I003270@newdev.harvard.edu> To: moore@cs.utk.edu, mrw@windriver.com In-Reply-To: <5.1.0.14.2.20030630110931.04bc9eb8@mail.windriver.com> Cc: problem-statement@alvestrand.no Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > BUT, there would be no point in appealing the IESG's rejection of a > document, because the IAB cannot overrule the IESG and publish the > document, I do not see anything in the appeal process that prevents the IAB from tellingthe IESG that the rejection was wrong and that the document should be published Scott From problem-statement-bounces@alvestrand.no Mon Jun 30 18:21:06 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19553 for ; Mon, 30 Jun 2003 18:21:06 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 665E8625D4; Tue, 1 Jul 2003 00:20:35 +0200 (CEST) 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 6AF046230D for ; Tue, 1 Jul 2003 00:20:32 +0200 (CEST) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h5UMKVDw003282; Mon, 30 Jun 2003 18:20:31 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h5UMKVXa003281; Mon, 30 Jun 2003 18:20:31 -0400 (EDT) Date: Mon, 30 Jun 2003 18:20:31 -0400 (EDT) From: Scott Bradner Message-Id: <200306302220.h5UMKVXa003281@newdev.harvard.edu> To: moore@cs.utk.edu, mrw@windriver.com In-Reply-To: <5.1.0.14.2.20030630112034.04be3488@mail.windriver.com> Cc: problem-statement@alvestrand.no Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 > So, the IAB may recommend an action to the IESG, but it can't force > the publication of an RFC. it would take a rather stupid IESG to not take the IAB's advice in an appeals process - the ISG has not been *that* stupid yet and I doubt it would ever be - to reject such a judgement would, in my opinion be grounds for a complete turnover of teh then sitting IESG and I would personally start the recall process Scott From problem-statement-bounces@alvestrand.no Mon Jun 30 19:06:56 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21154 for ; Mon, 30 Jun 2003 19:06:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3EDD0625D7; Tue, 1 Jul 2003 01:06:23 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6FA49625D4 for ; Tue, 1 Jul 2003 01:06:21 +0200 (CEST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) h5UN6HZf021259; Mon, 30 Jun 2003 16:06:18 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) h5UN6FBC017931; Mon, 30 Jun 2003 16:06:16 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <200306302217.h5UMHR5I003270@newdev.harvard.edu> References: <200306302217.h5UMHR5I003270@newdev.harvard.edu> Date: Mon, 30 Jun 2003 16:06:14 -0700 To: Scott Bradner , moore@cs.utk.edu, mrw@windriver.com From: hardie@qualcomm.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: problem-statement@alvestrand.no Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 Scott, The only appeal heard when I was on the IAB dealt with a document being advanced, not being rejected, but we did talk about the process fairly extensively. My understanding of the consensus of the then-IAB was that the IAB could annul a decision of the IESG, but that doing so returned something to the state before the decision. This came out this section of 2026: If circumstances warrant, the IAB may direct that an IESG decision be annulled, and the situation shall then be as it was before the IESG decision was taken. The IAB may also recommend an action to the IESG, or make such other recommendations as it deems fit. The IAB may not, however, pre-empt the role of the IESG by issuing a decision which only the IESG is empowered to make. In the case of a decision not to publish a standards track document, the state previous to the decision (the document is not yet published) and the state after (the document is not published) are functionally the same. So the IAB rendering a decision does not trigger the publication, the IESG issuing the document onto the standards track in compliance with the IAB recommendation does. While the result may be, again, functionally the same, the distinction helps preserve the separation of function that provides the basis of the check and balance. Since you wrote 2026, you are, of course, uniquely suited to tell us whether that is what you meant, but I thought I would share my understanding of the interpretation it has been given by at least one IAB. regards, Ted Hardie At 6:17 PM -0400 6/30/03, Scott Bradner wrote: > > BUT, there would be no point in appealing the IESG's rejection of a >> document, because the IAB cannot overrule the IESG and publish the >> document, > >I do not see anything in the appeal process that prevents the IAB >from tellingthe IESG that the rejection was wrong and that the >document should be published > >Scott From problem-statement-bounces@alvestrand.no Mon Jun 30 19:08:13 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21251 for ; Mon, 30 Jun 2003 19:08:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B64D0625D7; Tue, 1 Jul 2003 01:07:41 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 92369625D4 for ; Tue, 1 Jul 2003 01:07:39 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19X7kG-000K5E-00; Mon, 30 Jun 2003 18:07:36 -0500 Date: Mon, 30 Jun 2003 19:07:36 -0400 From: John C Klensin To: Scott Bradner , "moore@cs.utk.edu" , "mrw@windriver.com" Message-ID: <69922853.1057000056@p3.JCK.COM> In-Reply-To: <200306302220.h5UMKVXa003281@newdev.harvard.edu> References: <200306302220.h5UMKVXa003281@newdev.harvard.edu> X-Mailer: Mulberry/3.1.0b3 (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: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On Monday, 30 June, 2003 18:20 -0400 Scott Bradner wrote: >> So, the IAB may recommend an action to the IESG, but it can't >> force the publication of an RFC. > > it would take a rather stupid IESG to not take the IAB's advice > in an appeals process - the ISG has not been *that* stupid yet > and I doubt it would ever be - to reject such a judgement > would, in my opinion be grounds for a complete turnover of > teh then sitting IESG and I would personally start the recall > process To be strictly accurate, as I understand the relevant procedures, the IAB _can_ direct that a document be published, it just can't give such a document a standards-track category. Specifically... > "The IAB may not, however, pre-empt the role of the IESG by > issuing a decision which only the IESG is empowered to make." But the IAB may direct the publication of an RFC in the normal course of events (see 2223bis), so its asking for publication doesn't involve a decision that only the IESG is empowered to make. Classifying something as a standard is another matter -- only the IESG can do that. On the other hand, that particular way of dealing with a "rather stupid IESG" might be equally stupid on the IAB's part: if we were to get into that state, we would be in deep enough trouble that Scott's proposed "complete turnover" remedy would be among the most mild of reasonable actions. Folks, I don't think there is any point trying to make procedures for meltdown situations in which, e.g., the IAB, on appeal, strongly disagrees with an IESG decision and the IESG decides to ignore whatever the IAB has to say. If that happens and we have elaborate procedures, an IESG in that mode is fairly likely to ignore them too. Then we need a potentially-bloody revolution, not more procedures. Ergo, more procedures don't help, at least as long as we believe that, in sufficiently extreme cases, the recall mechanism really would work. john From problem-statement-bounces@alvestrand.no Mon Jun 30 19:21:06 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21713 for ; Mon, 30 Jun 2003 19:21:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4F187625D7; Tue, 1 Jul 2003 01:20:33 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 127DD625D4 for ; Tue, 1 Jul 2003 01:20:31 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19X7wj-000K5i-00; Mon, 30 Jun 2003 18:20:29 -0500 Date: Mon, 30 Jun 2003 19:20:29 -0400 From: John C Klensin To: avri Message-ID: <70696325.1057000829@p3.JCK.COM> In-Reply-To: <123A6F9F-AA9C-11D7-A025-000393CC2112@apocalypse.org> References: <123A6F9F-AA9C-11D7-A025-000393CC2112@apocalypse.org> X-Mailer: Mulberry/3.1.0b3 (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: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On Monday, 30 June, 2003 10:42 +0900 avri wrote: >> I agree with the sentiment, but we've had at least a couple >> of people who've posted references to appeals that were >> filed, including appeals that resulted in overturned >> decisions. > > i think looking at the counter-examples will show that the > folks brave enough and process savvy enough to file these > appeals where not our average participants. > > yes, there is a process but it takes a lot of energy and savvy > to use that process. >... > there is a process which i would argue is not a mechanism. > and certainly not a mechanism intended to aid. > i think it is as much a barrier to appeal as anything else. > > i certainly do not believe the existing process is a mechanism > that aids people in making appeals. Mumble. Ok, I have filed an appeal, and it was successful in getting an action changed. I've also been in the middle of the IAB review process for several of them. So, with your indulgence (I don't think this is a problem, and what I'm about to say isn't a solution), let me explain how to mount a successful appeal so it isn't a secret any more. Step 1: Produce a coherent and focused statement about what is being appealed, what the issues are, and why the action that was taken was wrong. Leave out any random musings or accusations about, e.g., the eating habits or parentage of IESG members and assumptions about their evil motivations. This is often not an easy writing job, but it is necessary. For better or worse, if the IESG and IAB can't figure out what you are complaining about, or if the appeal seems to be an excuse for a personal attack, the appeal won't go anywhere unless the problem is really, obviously, an abuse of judgment or authority. Step 2: Be absolutely clear about what remedy is desired and expected, and be sure that it is within the authority of the AD or IESG to grant and execute. Leaving the IAB or IESG sitting around and saying to each other "well, she is probably right, but what on earth does she want us to do about it?" is not likely to produce a useful and positive outcome. That is really all there is to it. Most, if not all, of the appeals that have dragged out for a long time and then produced results that either upheld the IESG in some lukewarm way or were satisfactory to no one showed symptoms consequent of omitting one of the steps above. If the IAB (or even the IESG) get an appeal that says "the problem is obvious, you can read all about it on the following 400 web pages and many megabytes of logs, AD Jones is a fool and has it in for me, and I'd like you to un-invent the wheel so I can patent it", that appeal probably isn't going anywhere even if the underlying issue is a problem that really does need fixing. This isn't either a complex procedure or rocket science... it is just recognizing that presenting a clear case to the IESG and IAB is much more likely to get careful attention and reasonable results. john From problem-statement-bounces@alvestrand.no Mon Jun 30 19:45:19 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22741 for ; Mon, 30 Jun 2003 19:45:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EDBAC625D7; Tue, 1 Jul 2003 01:44:46 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7A6D961A96 for ; Tue, 1 Jul 2003 01:44:45 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19X8K0-0001ve-00; Mon, 30 Jun 2003 16:44:32 -0700 Date: Mon, 30 Jun 2003 19:40:53 -0400 From: Keith Moore To: John C Klensin Message-Id: <20030630194053.19f6d293.moore@cs.utk.edu> In-Reply-To: <70696325.1057000829@p3.JCK.COM> References: <123A6F9F-AA9C-11D7-A025-000393CC2112@apocalypse.org> <70696325.1057000829@p3.JCK.COM> X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: avri@apocalypse.org Cc: moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 ] Step 1: Produce a coherent and focused statement about ] what is being appealed, what the issues are, and why the ] action that was taken was wrong. Leave out any random ] musings or accusations about, e.g., the eating habits or ] parentage of IESG members and assumptions about their ] evil motivations. This is often not an easy writing ] job, but it is necessary. For better or worse, if the ] IESG and IAB can't figure out what you are complaining ] about, or if the appeal seems to be an excuse for a ] personal attack, the appeal won't go anywhere unless the ] problem is really, obviously, an abuse of judgment or ] authority. ] ] Step 2: Be absolutely clear about what remedy is desired ] and expected, and be sure that it is within the ] authority of the AD or IESG to grant and execute. ] Leaving the IAB or IESG sitting around and saying to ] each other "well, she is probably right, but what on ] earth does she want us to do about it?" is not likely to ] produce a useful and positive outcome. 3. state your argument and your proposed remedy as simply and succinctly as possible while still being complete. The less irrelevant material IESG or IAB has to wade through, the easier it will be for them to consider your case. maybe this should be an I-D? Keith From problem-statement-bounces@alvestrand.no Mon Jun 30 19:45:55 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22769 for ; Mon, 30 Jun 2003 19:45:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C6587625DE; Tue, 1 Jul 2003 01:45:23 +0200 (CEST) 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 66C08625DC for ; Tue, 1 Jul 2003 01:45:22 +0200 (CEST) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h5UNjLDw003513 for ; Mon, 30 Jun 2003 19:45:21 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h5UNjLqD003512 for problem-statement@alvestrand.no; Mon, 30 Jun 2003 19:45:21 -0400 (EDT) Date: Mon, 30 Jun 2003 19:45:21 -0400 (EDT) From: Scott Bradner Message-Id: <200306302345.h5UNjLqD003512@newdev.harvard.edu> To: problem-statement@alvestrand.no Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 agree with what John says here (other than the nuance that the IAB could "recommend" to teh IESG that an ID be published as stds track) my outburst should be seen as a reaction to the dancing on the sharp end of a pin discussion that this has desolved into lets move on to real problems that changes in rulesets could deal with Scott ------- To be strictly accurate, as I understand the relevant procedures, the IAB _can_ direct that a document be published, it just can't give such a document a standards-track category. Specifically... > "The IAB may not, however, pre-empt the role of the IESG by > issuing a decision which only the IESG is empowered to make." But the IAB may direct the publication of an RFC in the normal course of events (see 2223bis), so its asking for publication doesn't involve a decision that only the IESG is empowered to make. Classifying something as a standard is another matter -- only the IESG can do that. On the other hand, that particular way of dealing with a "rather stupid IESG" might be equally stupid on the IAB's part: if we were to get into that state, we would be in deep enough trouble that Scott's proposed "complete turnover" remedy would be among the most mild of reasonable actions. Folks, I don't think there is any point trying to make procedures for meltdown situations in which, e.g., the IAB, on appeal, strongly disagrees with an IESG decision and the IESG decides to ignore whatever the IAB has to say. If that happens and we have elaborate procedures, an IESG in that mode is fairly likely to ignore them too. Then we need a potentially-bloody revolution, not more procedures. Ergo, more procedures don't help, at least as long as we believe that, in sufficiently extreme cases, the recall mechanism really would work. john From problem-statement-bounces@alvestrand.no Mon Jun 30 20:42:56 2003 Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24176 for ; Mon, 30 Jun 2003 20:42:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8C182625D7; Tue, 1 Jul 2003 02:42:24 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from apocalypse.org (apocalypse.org [192.48.232.17]) by eikenes.alvestrand.no (Postfix) with ESMTP id 283206230D for ; Tue, 1 Jul 2003 02:42:22 +0200 (CEST) Received: from apocalypse.org (IDENT:luml7/0KblKFtQcTX7Svzrs29PkXF4/M@apocalypse.org [192.48.232.17]) by apocalypse.org (8.11.6/8.11.6) with ESMTP id h610gIG05553; Mon, 30 Jun 2003 20:42:18 -0400 Date: Tue, 1 Jul 2003 09:42:13 +0900 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: John C Klensin From: avri In-Reply-To: <70696325.1057000829@p3.JCK.COM> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: "problem-statement@alvestrand.no" Subject: Re: appeal mechanisms was Re: Ombuds-process X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 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 tisdag, jul 1, 2003, at 08:20 Asia/Seoul, John C Klensin wrote: > --On Monday, 30 June, 2003 10:42 +0900 avri > wrote: > >>> I agree with the sentiment, but we've had at least a couple >>> of people who've posted references to appeals that were >>> filed, including appeals that resulted in overturned >>> decisions. >> >> i think looking at the counter-examples will show that the >> folks brave enough and process savvy enough to file these >> appeals where not our average participants. >> >> yes, there is a process but it takes a lot of energy and savvy >> to use that process. >> ... >> there is a process which i would argue is not a mechanism. >> and certainly not a mechanism intended to aid. >> i think it is as much a barrier to appeal as anything else. >> >> i certainly do not believe the existing process is a mechanism >> that aids people in making appeals. > > Mumble. Ok, I have filed an appeal, and it was successful in getting > an action changed. And you are most definitely not a regular participant and are most adept at the processes of the organization. You also have excellent command of the english language. And due to long term association with the I* know exactly what is relevant and what is not. You also share a cultural similarity to the majority of those who read and adjudicate the appeals. the fact that you think this is trivial easy and thatanyone can do what you can do is indeed a significant part of the problem in my opinion. Those of us who can command the language to do what we want it to do (well I don't always succeed) and those of us who can play the process game, often think that everyone can do what we can do. It is not the case. > I've also been in the middle of the IAB review process for several of > them. So, with your indulgence (I don't think this is a problem, and > what I'm about to say isn't a solution), let me explain how to mount a > successful appeal so it isn't a secret any more. > > Step 1: Produce a coherent and focused statement about > what is being appealed, what the issues are, and why the > action that was taken was wrong. Leave out any random > musings or accusations about, e.g., the eating habits or > parentage of IESG members and assumptions about their > evil motivations. This is often not an easy writing > job, but it is necessary. For better or worse, if the > IESG and IAB can't figure out what you are complaining > about, or if the appeal seems to be an excuse for a > personal attack, the appeal won't go anywhere unless the > problem is really, obviously, an abuse of judgment or > authority. Coherency is a value laden judgment and is often difficult for people. What is a lack of coherence to one is lack of understanding to another. I have often found that it takes me a lot of work to find the coherency in an argument. And the fault is often mine. If I look at the world one way, and the writer looks at it another, the language may be such that the beauty and coherence of the argument is lost on me. And sometimes a complaint is covered by some vitriol that is emotionally justifiable as it does happen that sometimes WG chairs and AD are not paragons of impartiality and virtue - even though I know we try to claim that all problems are systemic and have nothing to do with the people themselves or human nature. And yes, it would be better if they could put all hard feelings aside and write like lawyers but sometimes they can't. So, underneath there may be a real issue that requires a real solution and to ignore it would do harm to the complainant and sometimes even to the Internet itself. These questions are indeed part of my reason for believing that the IETF needs some mechanism to make sure that all valid complaints do get a just and complete airing. > > Step 2: Be absolutely clear about what remedy is desired > and expected, and be sure that it is within the > authority of the AD or IESG to grant and execute. > Leaving the IAB or IESG sitting around and saying to > each other "well, she is probably right, but what on > earth does she want us to do about it?" is not likely to > produce a useful and positive outcome. I also question whether the appellant must also have the solution. Often one see something and 'knows' it is wrong, but does not know the right solution. Or may have a valid complaint but an invalid solution. Is the complaint therefore worthless? And should the problem be ignored in that case? > > That is really all there is to it. Most, if not all, of the appeals > that have dragged out for a long time and then produced results that > either upheld the IESG in some lukewarm way or were satisfactory to no > one showed symptoms consequent of omitting one of the steps above. > If the IAB (or even the IESG) get an appeal that says "the problem is > obvious, you can read all about it on the following 400 web pages and > many megabytes of logs, AD Jones is a fool and has it in for me, and > I'd like you to un-invent the wheel so I can patent it", that appeal > probably isn't going anywhere even if the underlying issue is a > problem that really does need fixing. Have there really been that many appeals asking that the wheel be un-invented? I think it is is incumbent on those resolving appeals to find the underlying problem. Or rather it is the responsibility of the IETF leadership, in some way and form, to make sure that the underlying issue is always brought forward. > > This isn't either a complex procedure or rocket science... it is just > recognizing that presenting a clear case to the IESG and IAB is much > more likely to get careful attention and reasonable results. I disagree. Construction of a valid appeal is a complex problem for many. And the process with its nuance of who get which appeal when and in in which order can run people ragged. I would really be interested in an analysis of the number of appeals that have been brought forth in last years, the number of successful ones and the reasons formally given for the unsuccessful ones. Is a formal record kept of all appeals and the deliberation on those appeals? Are those records open and readily available to the IETF participants? a.