From problem-statement-bounces@alvestrand.no Thu May 8 06:44: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 GAA19349 for ; Thu, 8 May 2003 06:44:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DF9FF62590 for ; Thu, 8 May 2003 12:46:46 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Welcome to the "Problem-statement" mailing list From: problem-statement-request@alvestrand.no To: problem-archive@ietf.org X-No-Archive: yes Message-ID: Date: Thu, 08 May 2003 12:46:44 +0200 Precedence: bulk X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 List-Id: Problem Statement X-List-Administrivia: yes Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Welcome to the Problem-statement@alvestrand.no mailing list! To post to this list, send your email to: problem-statement@alvestrand.no General information about the mailing list is at: http://eikenes.alvestrand.no/mailman/listinfo/problem-statement If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: http://eikenes.alvestrand.no/mailman/options/problem-statement/problem-archive%40lists.ietf.org You can also make such adjustments via email by sending a message to: Problem-statement-request@alvestrand.no with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: zapiup Normally, Mailman will remind you of your alvestrand.no mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you. From problem-statement-bounces@alvestrand.no Thu May 8 07:23: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 HAA19886 for ; Thu, 8 May 2003 07:23:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0419D62590; Thu, 8 May 2003 13:25:49 +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 3E146622B1 for ; Thu, 8 May 2003 13:25:47 +0200 (CEST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])h48BPk712471 for ; Thu, 8 May 2003 14:25:46 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com ; Thu, 8 May 2003 14:25:46 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 8 May 2003 14:25:46 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 8 May 2003 14:25:44 +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, 8 May 2003 14:25:44 +0300 Message-ID: Thread-Topic: WG / documentation question Thread-Index: AcMVS9eGfgZKBLWdQC636XzUEjjgzwACG6gA From: To: X-OriginalArrivalTime: 08 May 2003 11:25:44.0974 (UTC) FILETIME=[90F24AE0:01C31554] Cc: problem-statement@alvestrand.no Subject: RE: WG / documentation question X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 HAA19886 Hi, > Actually a few of the editors and members of the editorial team > have been participating, they just have been doing so without saying > they are editors. > > As far as the documents go, as I mentioned earlier in the week, > they should be coming out in a few days. > > I personally apologize for doing more listening then talking on > this list, but as of now I don't have much to say that someone > else hasn't already contributed. I have also been focused on > annoying the editors of the two docs. I think much of the > editorial team has been trying to absorb the concerns of > the folks on the list, but as I said several have been active > all along. I expect that once the IDs are submitted > in the next days, there will be even more active conversation > on this list. OK, but a small pet peeve - I dislike unbounded email discussions - in my experience, after a certain point, they cease to be productive. I understand you want to listen, but it would be helpful to be 'managing' the discussion, trying to summarize long threads, making conclusions, etc. thanks, John From problem-statement-bounces@alvestrand.no Thu May 8 08: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 IAA20645 for ; Thu, 8 May 2003 08:13:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5E71B62590; Thu, 8 May 2003 14:15:37 +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 06343622B1 for ; Thu, 8 May 2003 14:15:32 +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 EF24A610; Thu, 8 May 2003 08:15:30 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Thu, 8 May 2003 08:15: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: Thu, 8 May 2003 08:15:24 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD75F@tayexc13.americas.cpqcorp.net> Thread-Topic: My thoughts about the problems of the IETF Thread-Index: AcMVSP+vToMaW4IASO+Wx6ab4HfhgwAEnNIg From: "Bound, Jim" To: "Brian E Carpenter" X-OriginalArrivalTime: 08 May 2003 12:15:30.0795 (UTC) FILETIME=[84A26BB0:01C3155B] Cc: problem-statement@alvestrand.no Subject: RE: My thoughts about the problems of the IETF X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 IAA20645 Exactly and in line with Keiths mail last night. Yes. /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday, May 08, 2003 6:03 AM > To: Bound, Jim > Cc: problem-statement@alvestrand.no > Subject: Re: My thoughts about the problems of the IETF > > > "Bound, Jim" wrote: > > > > > However, I do not agree on the comparison to personel > practices in a > > > company. IETF is not a company, but a community. In a > company, the > > > management represents (at least > > > theoretically) the owner(s) of the company, and is not > responsible > > > the workers. In a community, like the IETF, the community > "owns" the > > > community. The management is responsible to the > community, and has > > > to report its doings to them. I think this reporting is > now what is > > > a bit missing. > > > > > > Cheers, > > > > > > Jonne. > > > > Very well stated. I agree. > > But I assume that you wouldn't expect to see something like: > > Harald stated that Joe Blow is doing a really poor job running > the slurp WG and that no progress has been made. Jane Doe would > be a much better chair but she won't touch it unless Biff the Dog > disappears from the WG. > > (with apologies to the real Joe, Jane and Biff). > > Would > > Harald reported that no progress has been made in the slurp WG. > > be useful? > > Brian > From problem-statement-bounces@alvestrand.no Thu May 8 08:24: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 IAA20821 for ; Thu, 8 May 2003 08:24:37 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 04748625A1; Thu, 8 May 2003 14:27:03 +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 569E0622B1 for ; Thu, 8 May 2003 14:27:00 +0200 (CEST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])h48CQxD03433 for ; Thu, 8 May 2003 15:26:59 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com ; Thu, 8 May 2003 15:26:55 +0300 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 8 May 2003 15:26:55 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 8 May 2003 15:26:55 +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, 8 May 2003 15:26:50 +0300 Message-ID: Thread-Topic: "Adult supervision" Thread-Index: AcMUqe7M2ma4Un/FQHCoJ6acr8rZYQAao+wA From: To: X-OriginalArrivalTime: 08 May 2003 12:26:55.0580 (UTC) FILETIME=[1CCC51C0:01C3155D] Cc: problem-statement@alvestrand.no Subject: A real example, with names RE: "Adult supervision" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 IAA20821 Hi Keith, > do you think writing up 30 pages of detailed explanation is > constructive? In some cases a 2 or 5 page document would be enough, at least for me. Many times, I am just looking for documentation why I should or should not do 'x'. Here is a good example, actually involving you. When I took over the editorship of the Diameter Base spec, I was given a comment by the IESG that using different ports for TLS & non-TLS traffic violated a long-held IESG policy. Of course, this policy is not written down. As I have certain job responsibilities, folks at home were asking me what problems are caused by this, for which I had no answer. After some pestering, someone, Bert W. I think, pointed me to an SMTP RFC with some discussion about port usage ... it didn't really provide me with convincing material, but I was motivated to get the doc done, so I made the fix. A bit later, in another WG, the same issue came up again. The WG Security advisor, when asked about this mentioned - 'Oh, that was Keith's big thing ... mumble, mumble.' Further mail exchanges with him & the responsible AD did not produce any insight or conclusions, so I'm left with little insight or understanding if it is allowed to use multiple ports or not. Currently, the WG is leaning towards a 2-port model; does this mean we'll suffer a gotcha during IESG review? John From problem-statement-bounces@alvestrand.no Thu May 8 08:31: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 IAA20931 for ; Thu, 8 May 2003 08:31:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6855D625A1; Thu, 8 May 2003 14:33: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 AA99F622B1 for ; Thu, 8 May 2003 14:33:44 +0200 (CEST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])h48CXh724108 for ; Thu, 8 May 2003 15:33:44 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com ; Thu, 8 May 2003 15:33:36 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 8 May 2003 15:33:36 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 8 May 2003 15:33:35 +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, 8 May 2003 15:33:35 +0300 Message-ID: Thread-Topic: Mentoring [Re: "Adult supervision"] Thread-Index: AcMUnu1VAfXcJvlyTIm/gxULK1Cw0wAmFi2Q From: To: , X-OriginalArrivalTime: 08 May 2003 12:33:35.0917 (UTC) FILETIME=[0B6AE5D0:01C3155E] Cc: problem-statement@alvestrand.no Subject: draft-carpenter-solution-sirs-00.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 IAA20931 Brian & Dave, I like the draft; I am more impressed with the idea after reading the draft then I was when it was originally proposed. It might be useful to include mechanisms to allow objections from document editors & also mention that document reviewers should avoid or at least state conflicts of interests upfront. Another question, how should we handle SIRs that are active in the WG they are reviewing? Should this fall under a potential conflict of interest? John From problem-statement-bounces@alvestrand.no Thu May 8 09:07: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 JAA21662 for ; Thu, 8 May 2003 09:07:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 09A6A62590; Thu, 8 May 2003 15:09: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 E347B622B1; Thu, 8 May 2003 15:09:24 +0200 (CEST) Date: Thu, 08 May 2003 15:09:25 +0200 From: Harald Tveit Alvestrand To: john.loughney@nokia.com Message-ID: <93130000.1052399364@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: A real example, with names X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, mai 08, 2003 15:26:50 +0300 john.loughney@nokia.com wrote: > Hi Keith, > >> do you think writing up 30 pages of detailed explanation is >> constructive? > > In some cases a 2 or 5 page document would be enough, at least for > me. Many times, I am just looking for documentation why I should > or should not do 'x'. Here is a good example, actually involving > you. > > When I took over the editorship of the Diameter Base spec, I > was given a comment by the IESG that using different ports > for TLS & non-TLS traffic violated a long-held IESG policy. Of course, > this policy is not written down. As I have certain job responsibilities, > folks at home were asking me what problems are caused by this, > for which I had no answer. After some pestering, someone, Bert W. > I think, pointed me to an SMTP RFC with some discussion about port > usage ... it didn't really provide me with convincing material, > but I was motivated to get the doc done, so I made the fix. > > A bit later, in another WG, the same issue came up again. The WG > Security advisor, when asked about this mentioned - 'Oh, that was > Keith's big thing ... mumble, mumble.' Further mail exchanges with > him & the responsible AD did not produce any insight or conclusions, > so I'm left with little insight or understanding if it is allowed > to use multiple ports or not. Currently, the WG is leaning towards > a 2-port model; does this mean we'll suffer a gotcha during IESG > review? actually there's a little text around.... but I think this is what you were referring to.... RFC 2595 ("Using TLS with IMAP, POP3 and ACAP") says this: 7. imaps and pop3s ports Separate "imaps" and "pop3s" ports were registered for use with SSL. Use of these ports is discouraged in favor of the STARTTLS or STLS commands. A number of problems have been observed with separate ports for "secure" variants of protocols. This is an attempt to enumerate some of those problems. - Separate ports lead to a separate URL scheme which intrudes into the user interface in inappropriate ways. For example, many web pages use language like "click here if your browser supports SSL." This is a decision the browser is often more capable of making than the user. - Separate ports imply a model of either "secure" or "not secure." This can be misleading in a number of ways. First, the "secure" port may not in fact be acceptably secure as an export-crippled cipher suite might be in use. This can mislead users into a false sense of security. Second, the normal port might in fact be secured by using a SASL mechanism which includes a security layer. Thus the separate port distinction makes the complex topic of security policy even more confusing. One common result of this confusion is that firewall administrators are often misled into permitting the "secure" port and blocking the standard port. This could be a poor choice given the common use of SSL with a 40-bit key encryption layer and plain-text password authentication is less secure than strong SASL mechanisms such as GSSAPI with Kerberos 5. - Use of separate ports for SSL has caused clients to implement only two security policies: use SSL or don't use SSL. The desirable security policy "use TLS when available" would be cumbersome with the separate port model, but is simple with STARTTLS. - Port numbers are a limited resource. While they are not yet in short supply, it is unwise to set a precedent that could double (or worse) the speed of their consumption. There are also a few lines in the sec-cons draft dealing with a specific problem (virtual hosts) that is at the moment VERY painful for the folks hosting secure Web servers.... I think this is a typical case of: - someone thinks through a problem, coming to a conclusion. In this case that separate ports for different versions of the same application protocol is a thoroughly bad idea. - that someone explains this multiple times, convincing at least the people in a position to enforce policy at the time. But does not write down explicitly the full justification for it. - the person leaves, and the policy remains in force. The quality of the explanations tends to deteriorate. (FWIW, I personally think separate ports are just plain stupid, because they are a totally inappropriate granularity of security policy control, and their existence forms a slow, error-prone and eminently attackable form of security negotiation, but I've generally not had the energy to dive into those discussions, having other fish to fry so to speak, so you can't find many quotes from me on the subject....) Harald From problem-statement-bounces@alvestrand.no Thu May 8 09:11: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 JAA21758 for ; Thu, 8 May 2003 09:11:21 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D7F5F625A2; Thu, 8 May 2003 15:13:47 +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 DFB9F62590; Thu, 8 May 2003 15:13:37 +0200 (CEST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])h48DDO704462; Thu, 8 May 2003 16:13:34 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com ; Thu, 8 May 2003 16:13:23 +0300 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 8 May 2003 16:13:23 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 8 May 2003 16:13: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: Thu, 8 May 2003 16:13:21 +0300 Message-ID: Thread-Topic: A real example, with names Thread-Index: AcMVYw7u9fLRYC0mQpySVz6MqfbTjgAAGxnA From: To: X-OriginalArrivalTime: 08 May 2003 13:13:22.0585 (UTC) FILETIME=[99FB8890:01C31563] Cc: problem-statement@alvestrand.no Subject: RE: A real example, with names X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 JAA21758 Hi Harald, > I think this is a typical case of: > > - someone thinks through a problem, coming to a conclusion. In this case > that separate ports for different versions of the same application protocol > is a thoroughly bad idea. > > - that someone explains this multiple times, convincing at least the people > in a position to enforce policy at the time. But does not write down > explicitly the full justification for it. > > - the person leaves, and the policy remains in force. The quality of the > explanations tends to deteriorate. This is why documentation of some sort is helpful/useful/needed, which is exactly my point. John From problem-statement-bounces@alvestrand.no Thu May 8 09:25: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 JAA21981 for ; Thu, 8 May 2003 09:25:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7EEAA625A2; Thu, 8 May 2003 15:28: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 2796C62590 for ; Thu, 8 May 2003 15:27:56 +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.6/8.12.6) with ESMTP id h48DRoFf002390; Thu, 8 May 2003 06:27:50 -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 AGZ09924; Thu, 8 May 2003 06:27:48 -0700 (PDT) Message-Id: <200305081327.AGZ09924@mira-sjc5-c.cisco.com> To: john.loughney@nokia.com From: Melinda Shore In-Reply-To: Message from john.loughney@nokia.com Date: Thu, 08 May 2003 09:27:48 -0400 Cc: problem-statement@alvestrand.no Cc: avri@apocalypse.org Subject: Re: WG / documentation question X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Things will be a lot more focused once the problem statement revision and the first draft of the process document are out, not only because they provide anchors for the discussion but also because we (the working group) have a specific task, which is to move those documents towards publication. Melinda From problem-statement-bounces@alvestrand.no Thu May 8 09: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 JAA22040 for ; Thu, 8 May 2003 09:27:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 20E72625A2; Thu, 8 May 2003 15:30:08 +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 C73C162590 for ; Thu, 8 May 2003 15:30:05 +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 19DlTD-0005VI-00; Thu, 08 May 2003 06:29:59 -0700 Date: Thu, 8 May 2003 09:29:41 -0400 From: Keith Moore To: Message-Id: <20030508092941.747d0d08.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: A real example, with names RE: "Adult supervision" X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 two ports is that (besides wasting scarce ports), in the case of clients that will downgrade from TLS to non-TLS if TLS doesn't work, it's fairly easy for an active attacker to force the downgrade, and thus, to force the conversation to appear in cleartext. what I was presuming is that sending a TCP RST was easier for an attacker than say, hijacking the TLS connection to negotiate a weak cipher. I thought this had been written up somewhere, but I can't remember where. maybe on iana.org? but I think this is a good example of something that *should* be written up, at least on a web page. Keith On Thu, 8 May 2003 15:26:50 +0300 wrote: > Hi Keith, > > > do you think writing up 30 pages of detailed explanation is > > constructive? > > In some cases a 2 or 5 page document would be enough, at least for > me. Many times, I am just looking for documentation why I should > or should not do 'x'. Here is a good example, actually involving > you. > > When I took over the editorship of the Diameter Base spec, I > was given a comment by the IESG that using different ports > for TLS & non-TLS traffic violated a long-held IESG policy. Of course, > this policy is not written down. As I have certain job responsibilities, > folks at home were asking me what problems are caused by this, > for which I had no answer. After some pestering, someone, Bert W. > I think, pointed me to an SMTP RFC with some discussion about port > usage ... it didn't really provide me with convincing material, > but I was motivated to get the doc done, so I made the fix. > > A bit later, in another WG, the same issue came up again. The WG > Security advisor, when asked about this mentioned - 'Oh, that was > Keith's big thing ... mumble, mumble.' Further mail exchanges with > him & the responsible AD did not produce any insight or conclusions, > so I'm left with little insight or understanding if it is allowed > to use multiple ports or not. Currently, the WG is leaning towards > a 2-port model; does this mean we'll suffer a gotcha during IESG > review? > > John From problem-statement-bounces@alvestrand.no Thu May 8 09:33: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 JAA22146 for ; Thu, 8 May 2003 09:33:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E46DE625A2; Thu, 8 May 2003 15:35:42 +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 2C85162590 for ; Thu, 8 May 2003 15:35:40 +0200 (CEST) Received: from 33-pool1.ras12.calan-e.alerondial.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h48DZBN04335; Thu, 8 May 2003 06:35:12 -0700 Date: Thu, 8 May 2003 06:37:24 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: TribalWise X-Priority: 3 (Normal) Message-ID: <10146045359.20030508063724@dcrocker.net> 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: problem-statement@alvestrand.no Cc: brian@hursley.ibm.com Subject: Re: draft-carpenter-solution-sirs-00.txt 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> Another question, how should we handle SIRs that are active jlnc> in the WG they are reviewing? Should this fall under a potential jlnc> conflict of interest? The question of SIR direct involvement strikes me as one that could be decided in either direction. If we simply view the role of an SIR to be one of contributing an experienced eye, then direct involvement well might be a good thing. In fact, it well might be necessary, to help the working group break through "strategic" technical log-jams. If we are worried that direct involvement could cloud that eye, then it is important that they have a degree of detachment. As someone who never lets my strong advocacy of technical positions cloud their judgement about problems, of course I believe there is no problem with the direct involvement. And of course, most other senior folk in the community equally sustain excellent professional detachment from technical debates. mumble. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Thu May 8 09:36: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 JAA22239 for ; Thu, 8 May 2003 09:36:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F0282625A2; Thu, 8 May 2003 15:39:01 +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 E148562590 for ; Thu, 8 May 2003 15:38:58 +0200 (CEST) Received: from apocalypse.org (IDENT:f01edy0xgHN89c7nliVILw91thvdGMsX@apocalypse.org [192.48.232.17]) by apocalypse.org (8.11.6/8.11.6) with ESMTP id h48Dcqw30005; Thu, 8 May 2003 09:38:53 -0400 Message-ID: <3EBA5DE7.1000405@apocalypse.org> Date: Thu, 08 May 2003 22:38:47 +0900 From: avri User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: WG / documentation question X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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: > > OK, but a small pet peeve - I dislike unbounded email discussions - > in my experience, after a certain point, they cease to be productive. I am not sure what you mean by unbounded. If you mean that one does not know the termination point before it is reached, then I don't agree with you. On the other hand if you mean a looping conversation then I do. In terms of the conversations on this list, I think that by and large, new information and new details of analysis have come through as the conversations continued. A few times, I was close to stepping in with a recap or a translation or whatever, but things resolved themselves to my satisfaction. And a few times the conversation strayed uncomfortably close to personal recriminations, but the participants pulled back, so nothing needed to be said. > > I understand you want to listen, but it would be helpful to be > 'managing' the discussion, trying to summarize long threads, making > conclusions, etc. This is an interesting issue. As has been mentioned on several occasions there are different styles of chairing. I think that they range from micro management to exception management. I tend away from micro management and do not believe in curtailing or trying to shape the dialogue except for when it strays to far from the charter; i.e. basically a form of exception management. But I do admit to being very liberal in what I accept as being on topic. BTW, I do not think there is one right style of chairing. I think the proper method depends on the situation, the topic and the tendencies of the participants (including the chair). I certainly find I have a different style chairing a process group then I do chairing a technical group. And I chair differently when I have a co-chair then when I am a solo chair. Sometimes a chair needs to be a facilitator, and sometimes a chair needs to be a traffic cop. And sometimes a chair needs to stand back and let people talk - of course until someone asks for them to say something, And then they must respond. Also, while I am interested in listening, I also mentioned that the ideas I wish to contribute had already been contributed by others. It is certainly an element of my preferred behavior pattern for myself to not say things someone else has already said unless it becomes necessary for emphasis or to show support. So, when I have little new to add I will listen. Especially in a group like this that is trying to really express the perception people have of problems and the processes by which they can be alleviated Thanks for your comments, a. From problem-statement-bounces@alvestrand.no Thu May 8 09:40: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 JAA22309 for ; Thu, 8 May 2003 09:40:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 33FFD625A2; Thu, 8 May 2003 15:43:19 +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 3E39262590 for ; Thu, 8 May 2003 15:43:12 +0200 (CEST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])h48DhB700718 for ; Thu, 8 May 2003 16:43:11 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com ; Thu, 8 May 2003 16:43:11 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 8 May 2003 16:43:11 +0300 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 8 May 2003 16:43:10 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 8 May 2003 16:43:10 +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, 8 May 2003 16:43:07 +0300 Message-ID: Thread-Topic: WG / documentation question Thread-Index: AcMVZyzWVKcKEvfERIKAd6+zIZQrQgAABk/Q From: To: X-OriginalArrivalTime: 08 May 2003 13:43:10.0252 (UTC) FILETIME=[C383DEC0:01C31567] Cc: problem-statement@alvestrand.no Subject: RE: WG / documentation question X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 JAA22309 Hi Avri, > I am not sure what you mean by unbounded. If you mean that one does not > know the termination point before it is reached, then I don't agree with > you. On the other hand if you mean a looping conversation then I do. Looping conversations are one example, or another example is a thread/topic that just dies & there seem to be no summary or conclusion reached ... > > I understand you want to listen, but it would be helpful to be > > 'managing' the discussion, trying to summarize long threads, making > > conclusions, etc. > > This is an interesting issue. As has been mentioned on several > occasions there are different styles of chairing. I think that > they range from micro management to exception management. I tend away > from micro management and do not believe in curtailing or trying to > shape the dialogue except for when it strays to far from the charter; > i.e. basically a form of exception management. But I do > admit to being very liberal in what I accept as being on topic. I'm a big proponent of trying to reach some conclusions and those conclusions be explicitly stated, even if it is simply repeating that what everyone knows. I have found that trying to repeat / summarize what people are saying tends to either clarify the result or indicate that what I or others thought was a conclusion was not the same thing that others thought. John From problem-statement-bounces@alvestrand.no Thu May 8 09:51: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 JAA22537 for ; Thu, 8 May 2003 09:51:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1191362590; Thu, 8 May 2003 15:53:45 +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 E2BE7622B1 for ; Thu, 8 May 2003 15:53:41 +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 BD3BAADDD; Thu, 8 May 2003 09:53:37 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Thu, 8 May 2003 09:53: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: Thu, 8 May 2003 09:53:37 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD764@tayexc13.americas.cpqcorp.net> Thread-Topic: WG / documentation question Thread-Index: AcMVZbfxvHiiX+CeSJyjfir+Tu6AXQAAzb3g From: "Bound, Jim" To: "Melinda Shore" X-OriginalArrivalTime: 08 May 2003 13:53:37.0648 (UTC) FILETIME=[3978E700:01C31569] Cc: problem-statement@alvestrand.no Cc: avri@apocalypse.org Subject: RE: WG / documentation question X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 JAA22537 Melinda and Avri, Can we make our meeting in Vienna not on Friday? I am rethinking I have to be at IETF for multiple reasons and have to plan? I am sure others do too. As it is in the middle of European and U.S. vacation time I am sure many will want to get back as soon as possible. Any strategy yet? Thanks /jim From problem-statement-bounces@alvestrand.no Thu May 8 10:29: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 KAA24941 for ; Thu, 8 May 2003 10:29:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D78B7625AB; Thu, 8 May 2003 16:31: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 4A23F62590; Thu, 8 May 2003 16:31:28 +0200 (CEST) Date: Thu, 08 May 2003 16:31:28 +0200 From: Harald Tveit Alvestrand To: ietf@ietf.org, problem-statement@alvestrand.no Message-ID: <10600000.1052404288@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: NON-WG LAST CALL on the IESG charter?????? (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 FYI: I just sent the enclosed message to the POISED list. If you could direct comments there or to me directly, I'd be grateful. Harald ---------- Forwarded Message ---------- Date: torsdag, mai 08, 2003 15:22:19 +0200 From: Harald Tveit Alvestrand To: poised@lists.tislabs.com Cc: Subject: NON-WG LAST CALL on the IESG charter?????? Folks, apart from Dave Crocker's proposed change to the first paragraph, I have had very few comments on version -02 of the IESG charter. I have also heard one comment (in the nomcom WG) that the IESG charter should have provisions for appointing an interim IETF chair in the case where the IETF chair is unable to function, for the time before the Nomcom completes the task of picking a new one. I suggest stating that the IESG picks an AD from its own membership to function as the interim chair, and make no other comment on it. If I hear no further comments or objections, I intend to publish an -03 version with these changes, and then make an IETF-wide Last Call. Comments? Harald Alvestrand ---------- End Forwarded Message ---------- From problem-statement-bounces@alvestrand.no Thu May 8 11:29: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 LAA26615 for ; Thu, 8 May 2003 11:29:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 98BB0625B3; Thu, 8 May 2003 17:31:59 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by eikenes.alvestrand.no (Postfix) with ESMTP id 09C3F625A2 for ; Thu, 8 May 2003 17:30:28 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19DnLc-0006mZ-00; Thu, 08 May 2003 16:30:16 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19DnLb-0006mP-00; Thu, 08 May 2003 16:30:15 +0100 Received: from hursley.ibm.com (dhcp21-189.zurich.ibm.com [9.4.21.189]) QAA164238; Thu, 8 May 2003 16:30:12 +0100 Message-ID: <3EBA781C.25A8716A@hursley.ibm.com> Date: Thu, 08 May 2003 17:30:36 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Dave Crocker References: <10146045359.20030508063724@dcrocker.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: john.loughney@nokia.com Cc: problem-statement@alvestrand.no Subject: Re: draft-carpenter-solution-sirs-00.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 should be good citizens and discuss this on the solutions@alvestrand.no list? Brian Dave Crocker wrote: > > john, > > jlnc> Another question, how should we handle SIRs that are active > jlnc> in the WG they are reviewing? Should this fall under a potential > jlnc> conflict of interest? > > The question of SIR direct involvement strikes me as one that could be > decided in either direction. > > If we simply view the role of an SIR to be one of contributing an > experienced eye, then direct involvement well might be a good thing. > In fact, it well might be necessary, to help the working group break > through "strategic" technical log-jams. > > If we are worried that direct involvement could cloud that eye, then > it is important that they have a degree of detachment. > > As someone who never lets my strong advocacy of technical positions > cloud their judgement about problems, of course I believe there is no > problem with the direct involvement. And of course, most other senior > folk in the community equally sustain excellent professional > detachment from technical debates. > > mumble. > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From problem-statement-bounces@alvestrand.no Thu May 8 17: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 RAA11262 for ; Thu, 8 May 2003 17:05:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9A190625A6; Thu, 8 May 2003 23:07:34 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by eikenes.alvestrand.no (Postfix) with ESMTP id 86B816233E for ; Thu, 8 May 2003 23:07:32 +0200 (CEST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])h48L7Vb19252 for ; Thu, 8 May 2003 16:07:31 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com ; Thu, 8 May 2003 16:07:29 -0500 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 8 May 2003 16:06:20 -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: Thu, 8 May 2003 14:06:19 -0700 Message-ID: <4D7B558499107545BB45044C63822DDEEBDCC8@mvebe001.americas.nokia.com> Thread-Topic: My thoughts about the problems of the IETF Thread-Index: AcMVSP+vToMaW4IASO+Wx6ab4HfhgwAEnNIgABJT9tA= From: To: , X-OriginalArrivalTime: 08 May 2003 21:06:20.0675 (UTC) FILETIME=[ACA46D30:01C315A5] Cc: problem-statement@alvestrand.no Subject: RE: My thoughts about the problems of the IETF X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 RAA11262 Hi Jim and Brian, > > > But I assume that you wouldn't expect to see something like: > > > > Harald stated that Joe Blow is doing a really poor job running > > the slurp WG and that no progress has been made. Jane Doe would > > be a much better chair but she won't touch it unless Biff the Dog > > disappears from the WG. > > This is just another example, where you have not minuted everything: Now we don't know who is to be fed to the pigs! ;) > > (with apologies to the real Joe, Jane and Biff). > > > > Would > > > > Harald reported that no progress has been made in the slurp WG. This was what my example with the feeding to pigs was in one of the first mails. You can minute quite easily that there is a problem in a WG without pointing the blaming finger on any individual. However, the actual issue (no progress in a WG) should be reported. Cheers, Jonne. From problem-statement-bounces@alvestrand.no Thu May 8 22:25: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 WAA20261 for ; Thu, 8 May 2003 22:25:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8262D6256B; Fri, 9 May 2003 04:28:17 +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 27100622A1 for ; Fri, 9 May 2003 04:27:54 +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 73D5E7EB3; Thu, 8 May 2003 22:27: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); Thu, 8 May 2003 22:27: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: Thu, 8 May 2003 22:27:51 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD78A@tayexc13.americas.cpqcorp.net> Thread-Topic: My thoughts about the problems of the IETF Thread-Index: AcMVSP+vToMaW4IASO+Wx6ab4HfhgwAEnNIgABJT9tAAC2Sw8A== From: "Bound, Jim" To: , X-OriginalArrivalTime: 09 May 2003 02:27:52.0350 (UTC) FILETIME=[97606BE0:01C315D2] Cc: problem-statement@alvestrand.no Subject: RE: My thoughts about the problems of the IETF X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 WAA20261 So your saying identify when possible if a problem that is reportable when possible. So if there is one position vs the other then the two positions impeding progress would at least be publicly recorded? That might be fair? Have to be careful. If this works then at least those you don't agree with permit one to find them and feed them to pigs :--) /jim > -----Original Message----- > From: Jonne.Soininen@nokia.com [mailto:Jonne.Soininen@nokia.com] > Sent: Thursday, May 08, 2003 5:06 PM > To: Bound, Jim; brian@hursley.ibm.com > Cc: problem-statement@alvestrand.no > Subject: RE: My thoughts about the problems of the IETF > > > Hi Jim and Brian, > > > > > > But I assume that you wouldn't expect to see something like: > > > > > > Harald stated that Joe Blow is doing a really poor job running > > > the slurp WG and that no progress has been made. Jane Doe would > > > be a much better chair but she won't touch it unless > Biff the Dog > > > disappears from the WG. > > > > > This is just another example, where you have not minuted > everything: Now we don't know who is to be fed to the pigs! ;) > > > > (with apologies to the real Joe, Jane and Biff). > > > > > > Would > > > > > > Harald reported that no progress has been made in the slurp WG. > > This was what my example with the feeding to pigs was in one > of the first mails. You can minute quite easily that there is > a problem in a WG without pointing the blaming finger on any > individual. However, the actual issue (no progress in a WG) > should be reported. > > Cheers, > > Jonne. > From problem-statement-bounces@alvestrand.no Mon May 12 13:47: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 NAA25421 for ; Mon, 12 May 2003 13:47:30 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 07531625BE; Mon, 12 May 2003 19:50:01 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from nit.isi.edu (nit.isi.edu [128.9.160.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id B41366223F; Mon, 12 May 2003 19:49:56 +0200 (CEST) Received: (from falk@localhost) by nit.isi.edu (8.11.6/8.11.6) id h4CHnqx08570; Mon, 12 May 2003 10:49:52 -0700 Date: Mon, 12 May 2003 10:49:52 -0700 From: Aaron Falk To: john.loughney@nokia.com Message-ID: <20030512174952.GJ2247@isi.edu> Mail-Followup-To: john.loughney@nokia.com, harald@alvestrand.no, problem-statement@alvestrand.no References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Cc: harald@alvestrand.no Cc: problem-statement@alvestrand.no Subject: Re: Time required to write down "wisdom" (Re: "Adult supervision") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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.loughney@nokia.com wrote: > Hi Harald, > > > for a worked example of something that everything we've said here says > > "should have been published sooner", consider draft-iab-sec-cons, on how to > > write security considerations. > > > > the history of that document, which started life as an emailed note in > > 1997, is probably instructive when considering the bars to timely > > publication. > > This sounds strangely like the experience of getting an RFC published > by a WG. It seems that the IAB faces many of the same troubles that > WGs face in moving a document to RFC. > > It seems that the 'process' has some how gotten twisted to disable the > quick publication of important documents. Maybe WGs have been spending > too much time trying to find creative ways to excede their charters > & destroy the Internet; and the IESG spends too much time flying > around in black helicopters. > > I think that we, as an organization, do need to do better. > > John John- It may just be that it takes time to write good documents, esp. ones that are expected to have long shelf life. --aaron From problem-statement-bounces@alvestrand.no Mon May 12 14: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 OAA26005 for ; Mon, 12 May 2003 14:05:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0DFE2625BE; Mon, 12 May 2003 20:08:00 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from nit.isi.edu (nit.isi.edu [128.9.160.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6D8B76223F for ; Mon, 12 May 2003 20:07:56 +0200 (CEST) Received: (from falk@localhost) by nit.isi.edu (8.11.6/8.11.6) id h4CI7s008704; Mon, 12 May 2003 11:07:54 -0700 Date: Mon, 12 May 2003 11:07:54 -0700 From: Aaron Falk To: Spencer Dawkins , problem-statement@alvestrand.no Message-ID: <20030512180753.GK2247@isi.edu> Mail-Followup-To: Spencer Dawkins , problem-statement@alvestrand.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Mutt/1.4i Subject: Re: Mentoring [Re: "Adult supervision"] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 Wednesday, May 07, 2003 8:19 AM -0500 Spencer Dawkins wrote: > The "Tao of the IETF" is focused on work style, not technical > principles. When we try to reveal guiding technical principles as part of > post-WG document review, the input is a "late surprise", and the process > does not scale. Not sure if I sent this link to this list in the past (if so, forgive me for repeating myself) but here is a useful presentation on architectural principles of the Internet which might be of interest: --aaron From problem-statement-bounces@alvestrand.no Mon May 12 14:16: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 OAA26366 for ; Mon, 12 May 2003 14:16:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0B7F9625C2; Mon, 12 May 2003 20:19:24 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by eikenes.alvestrand.no (Postfix) with ESMTP id 90F24625BE for ; Mon, 12 May 2003 20:19:17 +0200 (CEST) Received: from new.isi.edu (new.isi.edu [128.9.160.38]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h4CIJE104878; Mon, 12 May 2003 11:19:14 -0700 (PDT) Date: Sat, 10 May 2003 18:00:03 -0700 From: Aaron Falk To: Spencer Dawkins , problem-statement@alvestrand.no Message-ID: <87155482.1052589603@[10.0.1.44]> 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: Mentoring [Re: "Adult supervision"] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, May 07, 2003 8:19 AM -0500 Spencer Dawkins wrote: > The "Tao of the IETF" is focused on work style, not technical > principles. When we try to reveal guiding technical principles as part of > post-WG document review, the input is a "late surprise", and the process > does not scale. Not sure if I sent this link to this list in the past (if so, forgive me for repeating myself) but here is a useful presentation on architectural principles of the Internet which might be of interest: --aaron From problem-statement-bounces@alvestrand.no Mon May 12 16:53: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 QAA03763 for ; Mon, 12 May 2003 16:53:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C71B46259F; Mon, 12 May 2003 22:55:54 +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 A854B6223F; Mon, 12 May 2003 22:55: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 h4CKtoYp240020; Mon, 12 May 2003 16:55:50 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-254-35.mts.ibm.com [9.65.254.35])h4CKtjE5030232; Mon, 12 May 2003 14:55:49 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h4CKtXn02343; Mon, 12 May 2003 16:55:33 -0400 Message-Id: <200305122055.h4CKtXn02343@cichlid.adsl.duke.edu> To: john.loughney@nokia.com In-Reply-To: Message from john.loughney@nokia.com Date: Mon, 12 May 2003 16:55:33 -0400 From: Thomas Narten Cc: harald@alvestrand.no Cc: problem-statement@alvestrand.no Subject: Re: Time required to write down "wisdom" (Re: "Adult supervision") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > It seems that the 'process' has some how gotten twisted to disable the > quick publication of important documents. This may true if the assumption is that the *process* is what caused the problems. >From my perspective, the real issue often tends to be: 1) Good documents don't pop out in the -00 version. 2) Iteration is essential. Iteration means a small number of people (e.g., 1-5) read the document, provide good feedback, and then a new revision is produced. 3) process is repeated at least a few more times, with a different set of reviewers providing the review and feedback each time. 4) Process terminates, because subsequent reviews don't uncover significant issues and the reviewers think the document is good enough to ship. You can't rush a document (if you want it to be good). Indeed, when I write documents, I personally find that if I reread something I wrote a month earlier, I often find obvious things that need fixing. I often don't see these if I review the document a few days after last working on it. The point here is that good documents just don't happen on the first version and time is needed to properly review and iterate. Where the "process" sometimes goes wrong is that the sequence of reviews and iterations haven't happened properly/optimally. Either not enough iterations, or too long between iterations. IMO, there is a problem here that bears further examination. Getting good reviews and then subsequent revisions in a timely fashion is something I see too much of. > I think that we, as an organization, do need to do better. Yep. IMO, we should look hard at ways of ensuring that the needed iteration on revisions happens in a timely fashion. But not too timely, as that leads to documents being pushed forward before they are truly ready. Thomas From problem-statement-bounces@alvestrand.no Mon May 12 18:35: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 SAA07155 for ; Mon, 12 May 2003 18:35:15 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 59BE2625BD; Tue, 13 May 2003 00:37:44 +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 39AB56259F for ; Tue, 13 May 2003 00:37:41 +0200 (CEST) Received: from medea.wz-berlin.de ([193.174.6.5]) by athene.wz-berlin.de with esmtp (Exim 4.14) id 19FLvM-00077X-V2; Tue, 13 May 2003 00:37:36 +0200 Received: from ERDE/SpoolDir by medea.wz-berlin.de (Mercury 1.48); 13 May 03 00:37:36 +0200 Received: from SpoolDir by ERDE (Mercury 1.48); 13 May 03 00:37:15 +0200 From: "Jeanette Hofmann" Organization: Wissenschaftszentrum Berlin To: Thomas Narten Date: Tue, 13 May 2003 00:37:15 +0200 MIME-Version: 1.0 Message-ID: <3EC03E3E.27943.170A986@localhost> Priority: normal In-reply-to: <200305122055.h4CKtXn02343@cichlid.adsl.duke.edu> References: Message from john.loughney@nokia.com 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: Amavis with NAI VirusScan on athene.wz-berlin.de Cc: problem-statement@alvestrand.no Subject: Re: Time required to write down "wisdom" (Re: "Adult supervision") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 12 May 2003 at 16:55, Thomas Narten wrote: > > It seems that the 'process' has some how gotten twisted to disable the > > quick publication of important documents. > > This may true if the assumption is that the *process* is what caused > the problems. > > >From my perspective, the real issue often tends to be: > > 1) Good documents don't pop out in the -00 version. > > 2) Iteration is essential. Iteration means a small number of people > (e.g., 1-5) read the document, provide good feedback, and then a > new revision is produced. > > 3) process is repeated at least a few more times, with a different set > of reviewers providing the review and feedback each time. > > 4) Process terminates, because subsequent reviews don't uncover > significant issues and the reviewers think the document is good > enough to ship. > > You can't rush a document (if you want it to be good). Indeed, when I > write documents, I personally find that if I reread something I wrote > a month earlier, I often find obvious things that need fixing. I often > don't see these if I review the document a few days after last working > on it. The point here is that good documents just don't happen on the > first version and time is needed to properly review and iterate. > > Where the "process" sometimes goes wrong is that the sequence of > reviews and iterations haven't happened properly/optimally. Either not > enough iterations, or too long between iterations. > > IMO, there is a problem here that bears further examination. Getting > good reviews and then subsequent revisions in a timely fashion is > something I see too much of. > > > I think that we, as an organization, do need to do better. > > Yep. IMO, we should look hard at ways of ensuring that the needed > iteration on revisions happens in a timely fashion. But not too > timely, as that leads to documents being pushed forward before they > are truly ready. One of the few good things that came out of the ICANN reform process is the introduction of a policy development process, PDP. It is the attempt to define and standardize the steps and overall timeframe of decision making processes, as it were a finetuning of the milestones procedure. There are no practical experiences with the PDP yet. Moreover, ICANN is not exactly a good recommendation for best practice models, I know. Yet, perhaps it is worth a thought whether a similar model might improve the milestones function. Jeanette > > Thomas From problem-statement-bounces@alvestrand.no Mon May 12 23:07: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 XAA12356 for ; Mon, 12 May 2003 23:07:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0806862582; Tue, 13 May 2003 05:10: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 39A606230E; Tue, 13 May 2003 05:10:00 +0200 (CEST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])h4D39xD05003; Tue, 13 May 2003 06:09:59 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com ; Tue, 13 May 2003 06:09:56 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 13 May 2003 06:09:56 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 13 May 2003 06:09:56 +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, 13 May 2003 06:09:54 +0300 Message-ID: Thread-Topic: Time required to write down "wisdom" (Re: "Adult supervision") Thread-Index: AcMYysh5MQH6Aff3RyKP5YWIpZFkOQAMYhpA From: To: X-OriginalArrivalTime: 13 May 2003 03:09:56.0170 (UTC) FILETIME=[2157CAA0:01C318FD] Cc: harald@alvestrand.no Cc: problem-statement@alvestrand.no Subject: RE: Time required to write down "wisdom" (Re: "Adult supervision") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 XAA12356 Thomas, I think my original mail sounded a bit more cranky than I wanted it, but I was more responding to Harald's original mail - by the way is there an archive of this list? Harald mentioned that the document he was talking about sat around, the token passed between a number of editors, etc. It sounded to me like the process for editing the document, soliciting comments, producing revisions and so forth, fell apart, resulting in a much longer than needed process. I am not advocating pushing documents forward without adequate review, but much more for having pro-active editors, WG chairs and sheparding ADs to make sure the documents are getting done in a timely fashion, especially ones identified as important. This is more about breakdown in management, in my opinion. Anyway, this mail is coming close to solutions - which is not really my intention of posting the original mail. I think that one of the problems in getting work done in a timely fashion is the breakdown of the document management process. br, John > -----Original Message----- > From: ext Thomas Narten [mailto:narten@us.ibm.com] > Sent: 12 May, 2003 23:56 > To: Loughney John (NRC/Helsinki) > Cc: harald@alvestrand.no; problem-statement@alvestrand.no > Subject: Re: Time required to write down "wisdom" (Re: "Adult > supervision") > > > > It seems that the 'process' has some how gotten twisted to > disable the > > quick publication of important documents. > > This may true if the assumption is that the *process* is what caused > the problems. > > From my perspective, the real issue often tends to be: > > 1) Good documents don't pop out in the -00 version. > > 2) Iteration is essential. Iteration means a small number of people > (e.g., 1-5) read the document, provide good feedback, and then a > new revision is produced. > > 3) process is repeated at least a few more times, with a different set > of reviewers providing the review and feedback each time. > > 4) Process terminates, because subsequent reviews don't uncover > significant issues and the reviewers think the document is good > enough to ship. > > You can't rush a document (if you want it to be good). Indeed, when I > write documents, I personally find that if I reread something I wrote > a month earlier, I often find obvious things that need fixing. I often > don't see these if I review the document a few days after last working > on it. The point here is that good documents just don't happen on the > first version and time is needed to properly review and iterate. > > Where the "process" sometimes goes wrong is that the sequence of > reviews and iterations haven't happened properly/optimally. Either not > enough iterations, or too long between iterations. > > IMO, there is a problem here that bears further examination. Getting > good reviews and then subsequent revisions in a timely fashion is > something I see too much of. > > > I think that we, as an organization, do need to do better. > > Yep. IMO, we should look hard at ways of ensuring that the needed > iteration on revisions happens in a timely fashion. But not too > timely, as that leads to documents being pushed forward before they > are truly ready. > > Thomas > From problem-statement-bounces@alvestrand.no Mon May 12 23:13: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 XAA12438 for ; Mon, 12 May 2003 23:13:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4D1EB625BD; Tue, 13 May 2003 05:15:42 +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 C86DB62573; Tue, 13 May 2003 05:15:40 +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 19FQGN-0001WQ-00; Mon, 12 May 2003 20:15:35 -0700 Date: Mon, 12 May 2003 23:15:00 -0400 From: Keith Moore To: Thomas Narten Message-Id: <20030512231500.708a1a49.moore@cs.utk.edu> In-Reply-To: <200305122055.h4CKtXn02343@cichlid.adsl.duke.edu> References: <200305122055.h4CKtXn02343@cichlid.adsl.duke.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: john.loughney@nokia.com Cc: harald@alvestrand.no Cc: moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: Re: Time required to write down "wisdom" (Re: "Adult supervision") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Good summary. The other pitfall I see with this process is that sometimes we keep iterating on bad documents in the vain hope that they'll get better, and sometimes those documents get approved due to exhaustion on the part of the reviewers. (or worse, in an attempt to avoid embarassment at having invested so much effort in a bad idea) But if we could figure out a way to get enough review cycles, at about the right intervals, and at the same time learn how to prune bad ideas or incomplete ideas that weren't ready to avoid investing too much in them, we could drastically improve the quality and relevance of our output. Keith > 1) Good documents don't pop out in the -00 version. > > 2) Iteration is essential. Iteration means a small number of people > (e.g., 1-5) read the document, provide good feedback, and then a > new revision is produced. > > 3) process is repeated at least a few more times, with a different set > of reviewers providing the review and feedback each time. > > 4) Process terminates, because subsequent reviews don't uncover > significant issues and the reviewers think the document is good > enough to ship. > > You can't rush a document (if you want it to be good). Indeed, when I > write documents, I personally find that if I reread something I wrote > a month earlier, I often find obvious things that need fixing. I often > don't see these if I review the document a few days after last working > on it. The point here is that good documents just don't happen on the > first version and time is needed to properly review and iterate. > > Where the "process" sometimes goes wrong is that the sequence of > reviews and iterations haven't happened properly/optimally. Either not > enough iterations, or too long between iterations. From problem-statement-bounces@alvestrand.no Mon May 12 23: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 XAA12518 for ; Mon, 12 May 2003 23:17:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7D88762573; Tue, 13 May 2003 05:20:10 +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 39F616230E; Tue, 13 May 2003 05:20:07 +0200 (CEST) Date: Tue, 13 May 2003 05:20:07 +0200 From: Harald Tveit Alvestrand To: john.loughney@nokia.com Message-ID: <281660000.1052796007@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: Finding archives X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, others: since this is a repeated question: > by the > way is there an archive of this list? 1) the list is an IETF WG list. All IETF WGs have the archive listed in the WG's charter. 2) the list is a Mailman list. In the headers of every single message on the list, the following appears: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Just pointing out two common ways of finding the answer to the question without asking... Harald From problem-statement-bounces@alvestrand.no Mon May 12 23:46: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 XAA13533 for ; Mon, 12 May 2003 23:46:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9499D62573; Tue, 13 May 2003 05:48:39 +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 3F2006230E for ; Tue, 13 May 2003 05:48:38 +0200 (CEST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])h4D3mbD25179 for ; Tue, 13 May 2003 06:48:37 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com ; Tue, 13 May 2003 06:48:37 +0300 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 13 May 2003 06:48:37 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 13 May 2003 06:48:36 +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, 13 May 2003 06:48:36 +0300 Message-ID: Thread-Topic: Time required to write down "wisdom" (Re: "Adult supervision") Thread-Index: AcMY/e5YmaeqMxkMSm+SyYsz5kDJ6wAAR9OQ From: To: X-OriginalArrivalTime: 13 May 2003 03:48:36.0744 (UTC) FILETIME=[88834880:01C31902] Cc: problem-statement@alvestrand.no Subject: RE: Time required to write down "wisdom" (Re: "Adult supervision") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 XAA13533 Thomas, One follow-up: > You can't rush a document (if you want it to be good). Indeed, when I > write documents, I personally find that if I reread something I wrote > a month earlier, I often find obvious things that need fixing. I often > don't see these if I review the document a few days after last working > on it. The point here is that good documents just don't happen on the > first version and time is needed to properly review and iterate. Well, sometimes good may even be too much, if it results in a document coming out much later than the market needs. 'Good Enough' is, quite often, sufficient. Part of the IETF work is to make protocols that interoperate. If needed protocols are not done when needed, then there is no interoperation. Talking to some former-IETFers, one of the main reasons for not bringing new protocol work to the IETF is that it takes too long to get the work done. To me, good enough is better than none at all. I think in most cases, this is probably enough. John From problem-statement-bounces@alvestrand.no Tue May 13 01:26: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 BAA15662 for ; Tue, 13 May 2003 01:26:46 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DD669625BD; Tue, 13 May 2003 07:29:16 +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 669A962573; Tue, 13 May 2003 07:29: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 19FSLc-00055A-00; Mon, 12 May 2003 22:29:08 -0700 Date: Tue, 13 May 2003 01:28:33 -0400 From: Keith Moore To: Message-Id: <20030513012833.39ffc2c6.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: narten@us.ibm.com Cc: harald@alvestrand.no Cc: moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: Re: Time required to write down "wisdom" (Re: "Adult supervision") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 not advocating pushing documents forward without adequate > review, but much more for having pro-active editors, WG chairs > and sheparding ADs to make sure the documents are getting done > in a timely fashion, especially ones identified as important. > This is more about breakdown in management, in my opinion. It's one thing to require this of WG documents. It's somewhat harder to imagine how to apply it to individual submissions. And in general, having people be more pro-active means giving them more time to work on things, which might be beyond our control. From problem-statement-bounces@alvestrand.no Tue May 13 01:30: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 BAA15765 for ; Tue, 13 May 2003 01:30:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CB87162582; Tue, 13 May 2003 07:32:34 +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 05B2A62573 for ; Tue, 13 May 2003 07:32:32 +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 19FSOm-0001Ze-00; Mon, 12 May 2003 22:32:24 -0700 Date: Tue, 13 May 2003 01:31:49 -0400 From: Keith Moore To: Message-Id: <20030513013149.1e3e6f9b.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: narten@us.ibm.com Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: Time required to write down "wisdom" (Re: "Adult supervision") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 can't rush a document (if you want it to be good). Indeed, when I > > write documents, I personally find that if I reread something I wrote > > a month earlier, I often find obvious things that need fixing. I often > > don't see these if I review the document a few days after last working > > on it. The point here is that good documents just don't happen on the > > first version and time is needed to properly review and iterate. > > Well, sometimes good may even be too much, if it results in a document > coming out much later than the market needs. 'Good Enough' is, quite > often, sufficient. If the market needs something that screws the users, then it's not Good Enough. IETF does not exist to bless whatever the market wants, and especially not to bless whatever marketers think the market wants. We MUST NOT let presumptions about market criteria compel us to accept technically shoddy work. From problem-statement-bounces@alvestrand.no Tue May 13 02:19: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 CAA28468 for ; Tue, 13 May 2003 02:19:33 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E9A99625BD; Tue, 13 May 2003 08:22:04 +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 5996C62582 for ; Tue, 13 May 2003 08:22:02 +0200 (CEST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])h4D6M0D15464 for ; Tue, 13 May 2003 09:22:00 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com ; Tue, 13 May 2003 09:22:00 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 13 May 2003 09:22:00 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 13 May 2003 09:21: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: Tue, 13 May 2003 09:21:59 +0300 Message-ID: Thread-Topic: Time required to write down "wisdom" (Re: "Adult supervision") Thread-Index: AcMZEQqNZcUUALXzSSuVP9Yae2nlXgABorJA From: To: X-OriginalArrivalTime: 13 May 2003 06:21:59.0797 (UTC) FILETIME=[F5F5BA50:01C31917] Cc: narten@us.ibm.com Cc: problem-statement@alvestrand.no Subject: RE: Time required to write down "wisdom" (Re: "Adult supervision") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 CAA28468 Hi Keith, > > > You can't rush a document (if you want it to be good). > Indeed, when I > > > write documents, I personally find that if I reread > something I wrote > > > a month earlier, I often find obvious things that need > fixing. I often > > > don't see these if I review the document a few days after > last working > > > on it. The point here is that good documents just don't > happen on the > > > first version and time is needed to properly review and iterate. > > > > Well, sometimes good may even be too much, if it results in a document > > coming out much later than the market needs. 'Good Enough' is, quite > > often, sufficient. > > If the market needs something that screws the users, then it's not Good > Enough. IETF does not exist to bless whatever the market wants, > and especially not to bless whatever marketers think the market wants. > We MUST NOT let presumptions about market criteria compel us to accept > technically shoddy work. Without a doubt, you are correct. What I meant more is that if we are working on a technically valid topic, it helps to get that work completed in a reasonable time, so that other groups or companies don't create alternatives which may be less sound. John From problem-statement-bounces@alvestrand.no Tue May 13 02:22: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 CAA28546 for ; Tue, 13 May 2003 02:22:42 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E2F33625C2; Tue, 13 May 2003 08:25:12 +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 45BBC62582; Tue, 13 May 2003 08:25:10 +0200 (CEST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])h4D6P9717926; Tue, 13 May 2003 09:25:09 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com ; Tue, 13 May 2003 09:25:07 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 13 May 2003 09:25:06 +0300 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 13 May 2003 09:25:06 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 13 May 2003 09:25: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: Tue, 13 May 2003 09:25:05 +0300 Message-ID: Thread-Topic: Time required to write down "wisdom" (Re: "Adult supervision") Thread-Index: AcMZEJWaBaa4/XN1SB6le5XyJTTPwQAB2Jew From: To: X-OriginalArrivalTime: 13 May 2003 06:25:06.0060 (UTC) FILETIME=[64FB34C0:01C31918] Cc: narten@us.ibm.com Cc: harald@alvestrand.no Cc: problem-statement@alvestrand.no Subject: RE: Time required to write down "wisdom" (Re: "Adult supervision") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 CAA28546 Hi Keith, > > I am not advocating pushing documents forward without adequate > > review, but much more for having pro-active editors, WG chairs > > and sheparding ADs to make sure the documents are getting done > > in a timely fashion, especially ones identified as important. > > This is more about breakdown in management, in my opinion. > > It's one thing to require this of WG documents. It's somewhat harder to > imagine how to apply it to individual submissions. I agree we can enable this with WG, IESG or IAB documents - individual submissions are another story, of course. > And in general, having people be more pro-active means giving them more time > to work on things, which might be beyond our control. Also, setting the right timers so that documents don't sit around waiting because there has been miscommunication between the relavant parties. In the past, there has not always been clear communication whether the IESG, WG, AD or document editor has the token for a document when it is being reviewed by the IESG. Also, I think that WG chairs should monitor documents under their charter more closely to ensure that they progress. br, John From problem-statement-bounces@alvestrand.no Tue May 13 05:53: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 FAA02257 for ; Tue, 13 May 2003 05:53:48 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7392D625C3; Tue, 13 May 2003 11:56:18 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by eikenes.alvestrand.no (Postfix) with ESMTP id CB82F62205 for ; Tue, 13 May 2003 11:56:15 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19FWW4-0004Bs-00; Tue, 13 May 2003 10:56:12 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19FWW4-0004Bn-00; Tue, 13 May 2003 10:56:12 +0100 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) KAA110604; Tue, 13 May 2003 10:56:10 +0100 Message-ID: <3EC09F76.E3C04AB@hursley.ibm.com> Date: Tue, 13 May 2003 09:32:06 +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 Subject: Re: Time required to write down "wisdom" (Re: "Adult supervision") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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: > > Thomas, > > One follow-up: > > > You can't rush a document (if you want it to be good). Indeed, when I > > write documents, I personally find that if I reread something I wrote > > a month earlier, I often find obvious things that need fixing. I often > > don't see these if I review the document a few days after last working > > on it. The point here is that good documents just don't happen on the > > first version and time is needed to properly review and iterate. > > Well, sometimes good may even be too much, if it results in a document > coming out much later than the market needs. 'Good Enough' is, quite > often, sufficient. Part of the IETF work is to make protocols that > interoperate. If needed protocols are not done when needed, then > there is no interoperation. Talking to some former-IETFers, one > of the main reasons for not bringing new protocol work to the IETF > is that it takes too long to get the work done. To me, good enough > is better than none at all. I think in most cases, this is probably > enough. John, Our industry is maturing, I think. Our notions of "good enough" and "too slow" may need to change. Note, I'm not disagreeing that we need better processes - but let's recognise that the world is changing. Brian From problem-statement-bounces@alvestrand.no Tue May 13 08:03: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 IAA05566 for ; Tue, 13 May 2003 08:03:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 66D83625C3; Tue, 13 May 2003 14:05:48 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eikenes.alvestrand.no (Postfix) with ESMTP id 54E0E62598 for ; Tue, 13 May 2003 14:03:29 +0200 (CEST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05317; Tue, 13 May 2003 08:00:25 -0400 (EDT) Message-Id: <200305131200.IAA05317@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: problem-statement@alvestrand.no From: Internet-Drafts@ietf.org Date: Tue, 13 May 2003 08:00:25 -0400 X-Mailman-Approved-At: Tue, 13 May 2003 14:05:47 +0200 Subject: I-D ACTION:draft-ietf-problem-process-00.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Internet-Drafts@ietf.org List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Problem Statement Working Group of the IETF. Title : IETF Problem Resolution Processes Author(s) : M. Wasserman Filename : draft-ietf-problem-process-00.txt Pages : 28 Date : 2003-5-12 This document suggests processes to address the problems identified in the IETF Problem Statement. This document decomposes each of the problems described in the problem statement into a few areas for improvement, categorizes those areas into longer-term and near-term problems, and suggests processes to address each area. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-problem-process-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-problem-process-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-problem-process-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-12152643.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-problem-process-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-problem-process-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-12152643.I-D@ietf.org> --OtherAccess-- --NextPart-- From problem-statement-bounces@alvestrand.no Tue May 13 08:03: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 IAA05582 for ; Tue, 13 May 2003 08:03:34 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8C18F625CB; Tue, 13 May 2003 14:05:49 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eikenes.alvestrand.no (Postfix) with ESMTP id E5920625CA for ; Tue, 13 May 2003 14:03:34 +0200 (CEST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05333; Tue, 13 May 2003 08:00:31 -0400 (EDT) Message-Id: <200305131200.IAA05333@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: problem-statement@alvestrand.no From: Internet-Drafts@ietf.org Date: Tue, 13 May 2003 08:00:31 -0400 X-Mailman-Approved-At: Tue, 13 May 2003 14:05:47 +0200 Subject: I-D ACTION:draft-ietf-problem-issue-statement-01.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Internet-Drafts@ietf.org List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Problem Statement Working Group of the IETF. Title : IETF Problem Statement Author(s) : E. Davies Filename : draft-ietf-problem-issue-statement-01.txt Pages : 19 Date : 2003-5-12 This memo summarizes perceived problems in the structure, function and processes of the Internet Engineering Task Force (IETF). We are attempting to identify these problems, so that they can be addressed and corrected by the IETF community. The problems have been digested and categorized from an extensive discussion which took place on the 'problem-statement' mailing list from November 2002 to May 2003. The problem list has been further analyzed to try and determine the root causes, that are at the heart of the perceived problems: The result will be used to guide the next stage of the process in the Problem Statement working group which is to determine the structures and processes that will carry out the corrections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-problem-issue-statement-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-problem-issue-statement-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-problem-issue-statement-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-12152653.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-problem-issue-statement-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-problem-issue-statement-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-12152653.I-D@ietf.org> --OtherAccess-- --NextPart-- From problem-statement-bounces@alvestrand.no Tue May 13 08:24: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 IAA06709 for ; Tue, 13 May 2003 08:24:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 18343625C6; Tue, 13 May 2003 14:27:07 +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 61C65625C3 for ; Tue, 13 May 2003 14:27:04 +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 19FYrt-0000ox-00; Tue, 13 May 2003 05:26:54 -0700 Date: Tue, 13 May 2003 08:26:15 -0400 From: Keith Moore To: Message-Id: <20030513082615.714a742f.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: narten@us.ibm.com Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: Time required to write down "wisdom" (Re: "Adult supervision") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 the market needs something that screws the users, then it's not Good > > Enough. IETF does not exist to bless whatever the market wants, > > and especially not to bless whatever marketers think the market wants. > > We MUST NOT let presumptions about market criteria compel us to accept > > technically shoddy work. > > Without a doubt, you are correct. What I meant more is that if we are > working on a technically valid topic, it helps to get that work completed > in a reasonable time, so that other groups or companies don't create > alternatives which may be less sound. agreed. though we probably need to realize that there are cases in which there is no way to produce a technically sound standard before the market deploys an inferior solution. From problem-statement-bounces@alvestrand.no Tue May 13 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 IAA09115 for ; Tue, 13 May 2003 08:59:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ADF29625C3; Tue, 13 May 2003 15:01: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 73510625BD for ; Tue, 13 May 2003 15:01:47 +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 GAA39055 for ; Tue, 13 May 2003 06:01:44 -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 o9A0KEG2 Tue, 13 May 2003 06:01:44 -0700 (PDT) Message-ID: <028a01c3194f$cfb8c750$0300a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <20030513082615.714a742f.moore@cs.utk.edu> Date: Tue, 13 May 2003 08:01:46 -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: Time required to write down "wisdom" (Re: "Adult supervision") 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 think the Problem Statement implication here is that there are two possible cases: - a company tries to slam-dunk its protocol into products before we can complete a specification for it, and - we take so long completing a specification that protocols start appearing in products before we're finished with our solution We can't prevent the first case from happening, and companies that attempt this may succeed from time to time. We can't prevent the second case from happening, in all situations but every improvement we can make in "removing avoidable delays" will help. We want to reward people for bringing technology to us, by producing quality specifications in a timely manner. When we are, once again, recognized as a body that can develop specifications quickly, this will encourage customers to say "but is this based on IETF standards track specifications?" more frequently. And any wisdom we write down can help informed readers oppose the deployment of inferior solutions. Spencer the idealist ----- Original Message ----- From: "Keith Moore" > > > > Without a doubt, you are correct. What I meant more is that if we are > > working on a technically valid topic, it helps to get that work completed > > in a reasonable time, so that other groups or companies don't create > > alternatives which may be less sound. > > agreed. though we probably need to realize that there are cases in which > there is no way to produce a technically sound standard before the market > deploys an inferior solution. From problem-statement-bounces@alvestrand.no Tue May 13 10:52: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 KAA15267 for ; Tue, 13 May 2003 10:52:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 54B2E625C6; Tue, 13 May 2003 16:54:42 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by eikenes.alvestrand.no (Postfix) with ESMTP id 54B72623F9; Tue, 13 May 2003 16:54:39 +0200 (CEST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4DEsZE2186926; Tue, 13 May 2003 10:54:35 -0400 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) h4DEsXxT131750; Tue, 13 May 2003 10:54:33 -0400 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) h4DEr815005782; Tue, 13 May 2003 10:53:08 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) h4DEr8Nl005777; Tue, 13 May 2003 10:53:08 -0400 Message-Id: <200305131453.h4DEr8Nl005777@rotala.raleigh.ibm.com> To: john.loughney@nokia.com In-Reply-To: Message from john.loughney@nokia.com Date: Tue, 13 May 2003 10:53:08 -0400 From: Thomas Narten Cc: harald@alvestrand.no Cc: problem-statement@alvestrand.no Subject: Re: Time required to write down "wisdom" (Re: "Adult supervision") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 think my original mail sounded a bit more cranky than I wanted it, > but I was more responding to Harald's original mail - by the > way is there an archive of this list? Email can be funny that way... > Harald mentioned that the document he was talking about sat around, > the token passed between a number of editors, etc. It sounded to > me like the process for editing the document, soliciting comments, > producing revisions and so forth, fell apart, resulting in a > much longer than needed process. Yep. > I am not advocating pushing documents forward without adequate > review, but much more for having pro-active editors, WG chairs > and sheparding ADs to make sure the documents are getting done > in a timely fashion, especially ones identified as important. > This is more about breakdown in management, in my opinion. Yep. I think it would be good to understand when and why this process seems to breakdown, as it leads to stalled documents much more frequently than we perhaps realize. And these breakdowns can lead to an extra month or two or three of delay. Or worse. A couple more things I might add to me original post. Thomas Narten writes: > > It seems that the 'process' has some how gotten twisted to disable the > > quick publication of important documents. > This may true if the assumption is that the *process* is what caused > the problems. > >From my perspective, the real issue often tends to be: > 1) Good documents don't pop out in the -00 version. > 2) Iteration is essential. Iteration means a small number of people > (e.g., 1-5) read the document, provide good feedback, and then a > new revision is produced. One thing that needs to be done here as well is that the original person who reviewed the document needs to sign off on the revision. That is one of the essential parts of our process (when it works). Person reviews, provides feedback, a new revision comes a long, and original reviewer says "works for me". Everyone is happy, document is truely more of a consensus document. But, this doesn't always happen. What sometimes happens is the revision is so long in coming, it becomes hard to get the attention of the original reviewer, who has since forgotten about the details of the document (in the worst case, this leads to the death spiral where the delays get increasing longer...). Or, the author revises the document, and *thinks* they have addressed the comments, but there is no confirmation. When the original reviewer goes back, they may not be happy with the result. Now there is bad feeling on top of everything else, in that a reviewer feels like their input was ignored and not given proper consideration. Or, the author just responds to the issues clarifying them in email. While this might explain what is meant, it doesn't mean the document has gotten any better. Author thinks input has been dealt with "I responded to that", while the reviewer feels like they have been ignored. Document further stalls while it is unclear who has the token... I'm sure there are other examples. I think your point is right though that there is a document "management" function that we often don't pay sufficient attention to, and this does lead to long delayed documents. Oh, and note also that one also needs to deal with the situation where the author/reviewer can't agree, so that we don't get deadlock. This also can block documents for inappropriately long periods of time. > 3) process is repeated at least a few more times, with a different set > of reviewers providing the review and feedback each time. > 4) Process terminates, because subsequent reviews don't uncover > significant issues and the reviewers think the document is good > enough to ship. > You can't rush a document (if you want it to be good). Indeed, when I > write documents, I personally find that if I reread something I wrote > a month earlier, I often find obvious things that need fixing. I often > don't see these if I review the document a few days after last working > on it. The point here is that good documents just don't happen on the > first version and time is needed to properly review and iterate. > Where the "process" sometimes goes wrong is that the sequence of > reviews and iterations haven't happened properly/optimally. Either not > enough iterations, or too long between iterations. > IMO, there is a problem here that bears further examination. Getting > good reviews and then subsequent revisions in a timely fashion is > something I see too much of. > > I think that we, as an organization, do need to do better. > Yep. IMO, we should look hard at ways of ensuring that the needed > iteration on revisions happens in a timely fashion. But not too > timely, as that leads to documents being pushed forward before they > are truly ready. > Thomas From problem-statement-bounces@alvestrand.no Tue May 13 11:02: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 LAA15704 for ; Tue, 13 May 2003 11:02:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 862B1625BD; Tue, 13 May 2003 17:05:07 +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 E57D2623F9 for ; Tue, 13 May 2003 17:05:04 +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 IAA80224 for ; Tue, 13 May 2003 08:05:03 -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 ErK0kvQ2 Tue, 13 May 2003 08:05:02 -0700 (PDT) Message-ID: <02d201c31961$09a905e0$0300a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <3EC09F76.E3C04AB@hursley.ibm.com> Date: Tue, 13 May 2003 10:05:05 -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: Time required to write down "wisdom" (Re: "Adult supervision") 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 Brian, I'm finding myself reading a number of things into your e-mail that you didn't actually SAY - could you elaborate a bit, so that I can better understand? Thank you, Spencer ----- Original Message ----- From: "Brian E Carpenter" To: Cc: Sent: Tuesday, May 13, 2003 2:32 AM Subject: Re: Time required to write down "wisdom" (Re: "Adult supervision") > Our industry is maturing, I think. Our notions of "good enough" and "too > slow" may need to change. Note, I'm not disagreeing that we need better > processes - but let's recognise that the world is changing. > > Brian From problem-statement-bounces@alvestrand.no Tue May 13 11:07: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 LAA15900 for ; Tue, 13 May 2003 11:07:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F0525625C6; Tue, 13 May 2003 17:10:08 +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 521BF623F9 for ; Tue, 13 May 2003 17:10:06 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.27]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA17299; Tue, 13 May 2003 08:09:57 -0700 (PDT) Message-Id: <5.1.0.14.2.20030513105406.04746468@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 13 May 2003 11:05:57 -0400 To: Thomas Narten From: Margaret Wasserman In-Reply-To: <200305131453.h4DEr8Nl005777@rotala.raleigh.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: Time required to write down "wisdom" (Re: "Adult supervision") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 Thomas, At 10:53 AM 5/13/2003 -0400, Thomas Narten wrote: >I'm sure there are other examples. I think your point is right though >that there is a document "management" function that we often don't pay >sufficient attention to, and this does lead to long delayed documents. This is related to the document editor function that I keep discussing in various fora... Each document should have an editor who is managing the document, dealing with and resolving issues, etc. In some SDOs, this is a centralized (even paid) function. But in the IETF, we have a tendency to just assume that the original author(s) of the document will serve in this function. The defacto editor may not understand what they are being asked/expected to do, they have no training, no formal role definition, no tools to help with the job, nothing... >Oh, and note also that one also needs to deal with the situation where >the author/reviewer can't agree, so that we don't get deadlock. This >also can block documents for inappropriately long periods of time. IMO, this is a WG chair function. When the editor can't establish agreement with a reviewer, the WG chair needs to determine what WG consensus is on the issue. Margaret From problem-statement-bounces@alvestrand.no Tue May 13 11:19: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 LAA16321 for ; Tue, 13 May 2003 11:19:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6127C625BD; Tue, 13 May 2003 17:22: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 927AC623F9 for ; Tue, 13 May 2003 17:22:11 +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 IAA86250 for ; Tue, 13 May 2003 08:22:10 -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 yQM0UVS2 Tue, 13 May 2003 08:22:10 -0700 (PDT) Message-ID: <02e501c31963$6e1eb9f0$0300a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <5.1.0.14.2.20030513105406.04746468@mail.windriver.com> Date: Tue, 13 May 2003 10:22: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: Time required to write down "wisdom" (Re: "Adult supervision") 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 following up to Margaret's post - > > This is related to the document editor function that I keep > discussing in various fora... Each document should have an > editor who is managing the document, dealing with and resolving > issues, etc. > > In some SDOs, this is a centralized (even paid) function. But > in the IETF, we have a tendency to just assume that the original > author(s) of the document will serve in this function. The defacto > editor may not understand what they are being asked/expected to > do, they have no training, no formal role definition, no tools > to help with the job, nothing... (Your mileage may vary, but I'm also seen some documents derailed because of editor job changes) One of the points that we're making in the current WG chair training (thank you, Margaret) is that the decisions about who the editor is, and whether an editor continues to be the editor, really are WG chair decisions, even though they are often defaulted to "original author, who edits forever". One might argue that the author skills for good -00 individual submissions aren't even the same skills as the editor skills for good -08 working group revisions. Spencer From problem-statement-bounces@alvestrand.no Tue May 13 11:43: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 LAA17327 for ; Tue, 13 May 2003 11:43:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A301625CA; Tue, 13 May 2003 17:46:21 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5FAB9625C6 for ; Tue, 13 May 2003 17:46:17 +0200 (CEST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by e2.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4DFkB9X122852; Tue, 13 May 2003 11:46:12 -0400 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4DFk9K8208498; Tue, 13 May 2003 17:46:09 +0200 Received: from gsine05.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA61584 from ; Tue, 13 May 2003 17:46:03 +0200 Message-Id: <3EC11356.FFF1AC07@hursley.ibm.com> Date: Tue, 13 May 2003 17:46:30 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Spencer Dawkins References: <02d201c31961$09a905e0$0300a8c0@DFNJGL21> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Maturing [Re: Time required to write down "wisdom" ...] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Spencer Dawkins wrote: > > Dear Brian, > > I'm finding myself reading a number of things into your e-mail that you > didn't actually SAY - could you elaborate a bit, so that I can better > understand? > > Thank you, > > Spencer > > ----- Original Message ----- > From: "Brian E Carpenter" > To: > Cc: > Sent: Tuesday, May 13, 2003 2:32 AM > Subject: Re: Time required to write down "wisdom" (Re: "Adult supervision") > > > Our industry is maturing, I think. Our notions of "good enough" and "too > > slow" may need to change. Note, I'm not disagreeing that we need better > > processes - but let's recognise that the world is changing. Well, I wrote that while sitting in an IPv6 Forum meeting in Madrid, which is a good place for realising that strategic goals are important in the face of pragmatic solutions. Also the current Economist has an excellent survey on the maturing of the IT industry - well worth reading. For paid subscribers, it starts at http://www.economist.com/printedition/displayStory.cfm?Story_ID=1747329 I think we are heading towards a period when "good enough" may in fact not be good enough. I would expect customers to be expecting something much nearer perfection within a few years. And the history of every industrial technology has, I think, showed that high quality standards are an unavoidable part of getting to that level. So I think that while the frustration of a thorough standards process is annoying, that doesn't allow us to adopt short cuts that compromise quality. We should work out how to achieve quality more quickly. Brian From problem-statement-bounces@alvestrand.no Tue May 13 12:12: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 MAA18695 for ; Tue, 13 May 2003 12:12:21 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 85C9D625C7; Tue, 13 May 2003 18:14:51 +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 7EBB4625C6 for ; Tue, 13 May 2003 18:14:48 +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 JAA09696; Tue, 13 May 2003 09:14:46 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4DGEeb06953; Tue, 13 May 2003 09:14:40 -0700 X-mProtect: <200305131614> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdHSNdty; Tue, 13 May 2003 09:14:38 PDT Message-ID: <3EC119EF.596C4C21@iprg.nokia.com> Date: Tue, 13 May 2003 09:14:39 -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: Thomas Narten References: <200305131453.h4DEr8Nl005777@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Time required to write down "wisdom" (Re: "Adult supervision") X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 Thomas, Perhaps we can agree that it takes time to produce quality documents, and that sometimes procedural difficulties extend that time to seemingly unreasonable lengths. My original suggestion was that an Area Director should be expected to be able to point to documentation when raising major architectural objections to a working group document. This expectation should rise linearly as the working group document progresses. It is NOT too much to expect an Area Director to write a two page explanation when killing or significantly devaluing the efforts of dozens of people. I don't want that point to get lost in tautologies about how documents are hard to write. Even an Internet Draft would be better than the sometimes terse snippets of lore that substitute for documentation in recent memory. At least then there is the possibility that some process can lead to some conclusion according to professional ethics, instead of what could appear to be arbitrary quashing of something the AD just doesn't like. Plus, it's not all black and white. My point is that it's too gray today. Regards, Charlie P. From problem-statement-bounces@alvestrand.no Tue May 13 13: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 NAA20521 for ; Tue, 13 May 2003 13:08:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8A4E6625CB; Tue, 13 May 2003 19:10:34 +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 8C12E625C7 for ; Tue, 13 May 2003 19:10:32 +0200 (CEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id D31376A901; Tue, 13 May 2003 20:10:30 +0300 (EEST) Message-ID: <3EC126B3.7080400@piuha.net> Date: Tue, 13 May 2003 20:09: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: Margaret Wasserman References: <5.1.0.14.2.20030513105406.04746468@mail.windriver.com> In-Reply-To: <5.1.0.14.2.20030513105406.04746468@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Time required to write down "wisdom" (Re: "Adult supervision") 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 Margaret Wasserman wrote: > In some SDOs, this is a centralized (even paid) function. But > in the IETF, we have a tendency to just assume that the original > author(s) of the document will serve in this function. The defacto > editor may not understand what they are being asked/expected to > do, they have no training, no formal role definition, no tools > to help with the job, nothing... In the paid, centralized function model you'd probably see not just more formal role definitions, but the whole process would likely become more formal. We'd be sending detailed Change Requests all over the place ;-( [I'm not sure whether that would be good or bad.] Anyway, *if* its true that IETF editors in general don't understand what the job is, have no training or tools... perhaps we need a BCP or training material for this purpose. I took a quick look at what's easily found from www.ietf.org, and it seems that there isn't that much information, at least if you don't know what to look for. The ID guidelines and nits are mainly tailored for someone who is making his first draft. The chairs training concentrates on, well, chairs issues. Newcomers orientation doesn't talk about these issues either. The directly available material doesn't even mention xml2rfc, for instance. But to do more than submit an initial draft to the IETF, editors need to do many things. Perhaps it would be useful to have some material that talks about the following: o Tool support - Editing - ID nits checks - State machine drawing / verification tools (oh well, the IETF uses formalisms very little...) - Difference visualization - Issue tracking tools o Specific text guidance - How to write IANA section (point to RFC 2434 ) - How to write security considerations section (...) - Nits - Checklists for specific issues (beyond ID nits) o Process - Role of editor - Tasks upon writing a new document, producing a new revision, list discussion, getting it approved at IESG, ... o ... --Jari From problem-statement-bounces@alvestrand.no Tue May 13 13:48: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 NAA22070 for ; Tue, 13 May 2003 13:48:48 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1548E625C7; Tue, 13 May 2003 19:51: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 12C7C625A1; Tue, 13 May 2003 19:50:59 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19FdvW-0004tz-00; Tue, 13 May 2003 12:50:58 -0500 Date: Tue, 13 May 2003 13:50:58 -0400 From: John C Klensin To: Harald Tveit Alvestrand Message-ID: <145911910.1052833858@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 Cc: problem-statement@alvestrand.no Cc: "poised@lists.tislabs.com" Subject: Comments on section 5.2.2 of IESG charter (draft-iesg-charter-02.txt) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 copied the problem-statement list on this because the draft Charter text does not precisely describe current practice, violates/ changes the provisions of RFC 2026, and is arguably the root of a problem that has been discussed on that list. Detailed discussion probably belongs on the Poised list only. For the information of problem-statement participants who are not subscribed to the poised list, this note accompanies a much longer one that comments on other sections of the IESG Charter I-D. --------------- > Section 5.2 Non-working group documents >... > Section 5.2.2. Informational and Experimental documents > "NOTE IN DRAFT ... The IESG is discussing". Procedurally, I don't understand how you can propose to issue an Last Call while this note is still in the text. If the IESG has reached a conclusion, it should be posted to to the list. My own view is that this "procedure" has been the source of considerable abuse, much of it starting from good intentions, and that it has few benefits. In particular, as I understand the procedures, if a document goes to the RFC Editor, there is expected to be a fairly quick review for relevance and publishability (see my comments on 2223bis), followed by handoff to the IESG with a timeout. While the IESG can request additional time, I would expect those requests to reflect IESG consensus (however lightweight), to be accompanied with a reason, and for the request and reason to appear in IESG minutes. I would expect, or at least hope, that the RFC Editor would not grant extensions indefinitely and I would assume that an IESG action to repeatedly ask for extensions (or to ask for a very long extension) would be appealable. The IESG review is also constrained (by 2026) to catching end-runs and damaging or high-risk proposals only: the IESG is not supposed to be able to block a document, using these normal procedures, because, e.g., some AD simply disagrees with what it says. Now, contrast this with the history of IESG taking responsibility/ control of these individual-contribution informational or experimental documents and the procedure you have outlined in this section. The text says: > When an AD decides that an Informational or Experimental > document is of particular importance to the community, the > AD may also choose to put it directly before the IESG. > This document will then be processed in the same fashion as > an Informational or Experimental document from a working > group. The decision is made by an individual AD, not by IESG consensus. The decision does not even require the agreement of either the author (which deviates somewhat from current practice as I understand it). The RFC Editor timeout doesn't apply, so there are no constraints --even those created by pressure from an angry WG-- to promote timeliness. And, from observation, the limitations on IESG review of an independent submission imposed by 2026 don't apply either: if the document is handled "in the same fashion as... from a Working Group", the AD can apply whatever standards he or she likes as to when the document has been adequately nit-picked before releasing it for IESG review. While I'm not aware of its having occurred, an AD who was hostile to the content of a particular individual contribution could easily declare it as "of particular importance" and then bury it or kill it with the death of a thousand cuts (or nits). I would suggest, if the IESG really feels a need to do this, that the decision to treat an individually-submitted document as if it were a WG one should require IESG consensus, up front, about that treatment. That consensus should be reflected in minutes, the reasons given, and it should be entered into the tracking system. The IESG should then also agree on the AD (or Area) to which the document should be assigned. In other words, if the documents are to be processed as if they were WG ones, they should undergo similar IESG signoff and approval --before AD review begins-- as that for a WG. If the document is not _that_ important, then it should be processed through the normal, "submit to the RFC Editor" process. In the much larger number of cases in which one or more ADs consider a document important, but not important enough to process as if it were from a WG, I suggest that the IESG has, or could establish, mechanisms for giving the RFC Editor proactive feedback that a particular document should be given greater or lesser priority. The RFC Editor would, of course, not be bound by that type of advice, but unless the IAB disagreed, I would assume that they would continue to treat IESG advice and requests with courtesy and good sense as they have done in the past. regards, john p.s. As I mentioned in my comments on 2223bis, the elimination of the User Services area has essentially created a loose end with regard to FYI RFCs. The are clearly not standards-track, unlike the slightly gray-area BCPs which we treat as standards-track for most purposes. If the IESG intends to specify which RFCs get an FYI designation, then this Charter document should probably say that. If it intends to delegate that job to the RFC Editor, then some appropriate offspring of 2223bis should define the RFC Editor's process for initiating or considering the action/ designation. And, if we intend to not issue any new FYI documents, then there is a bit of tidying up that should be done elsewhere. From problem-statement-bounces@alvestrand.no Wed May 14 00:59: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 AAA10084 for ; Wed, 14 May 2003 00:59:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 36D14625A8; Wed, 14 May 2003 07:01:59 +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 D68D4623F9 for ; Wed, 14 May 2003 07:01:56 +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 19FoOp-0000nI-00; Tue, 13 May 2003 22:01:55 -0700 Date: Wed, 14 May 2003 01:01:17 -0400 From: Keith Moore To: problem-statement@alvestrand.no Message-Id: <20030514010117.60be2009.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: moore@cs.utk.edu Subject: draft-ietf-problem-issue-statement-01.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Wow! This a tremendous improvement. At least on first reading, I have no serious issues with this version. And it also seems fairly comprehensive. thanks! Keith From problem-statement-bounces@alvestrand.no Wed May 14 06:41: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 GAA11852 for ; Wed, 14 May 2003 06:41:48 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2F3D7625A2; Wed, 14 May 2003 12:44:17 +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 8E8316230F for ; Wed, 14 May 2003 12:44:09 +0200 (CEST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])h4EAi8D06470 for ; Wed, 14 May 2003 13:44:08 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com ; Wed, 14 May 2003 13:44:08 +0300 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 14 May 2003 13:44:08 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 14 May 2003 13:44:07 +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, 14 May 2003 13:44:06 +0300 Message-ID: Thread-Topic: Maturing [Re: Time required to write down "wisdom" ...] Thread-Index: AcMZZuRmVIZ/SiaAS1+luYoy3riTcwAm+jeQ From: To: X-OriginalArrivalTime: 14 May 2003 10:44:07.0249 (UTC) FILETIME=[BEAA3410:01C31A05] Cc: problem-statement@alvestrand.no Subject: RE: Maturing [Re: Time required to write down "wisdom" ...] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 GAA11852 Brian, > Well, I wrote that while sitting in an IPv6 Forum meeting in Madrid, which > is a good place for realising that strategic goals are important in the > face of pragmatic solutions. Also the current Economist has an excellent > survey on the maturing of the IT industry - well worth reading. > For paid subscribers, it starts at > http://www.economist.com/printedition/displayStory.cfm?Story_ID=1747329 > I think we are heading towards a period when "good enough" may in fact > not be good enough. I would expect customers to be expecting something > much nearer perfection within a few years. And the history of every > industrial technology has, I think, showed that high quality standards > are an unavoidable part of getting to that level. > > So I think that while the frustration of a thorough standards process > is annoying, that doesn't allow us to adopt short cuts that compromise > quality. We should work out how to achieve quality more quickly. So, in reading the above set of articles, I am lead to belief that certain technologies are promoted before they are ready, implementations tend to be rough & users' needs are not taken into account. I am of a (perhaps naive) belief that there are windows of opportunities for certain solutions. If we miss the window, certain technologies may not be deployed, even if superior. I am not suggesting, as alluded to by Keith, that we allow marketers to dictate to us what to do, but that we should have some understanding of the implacations of our actions. John From problem-statement-bounces@alvestrand.no Wed May 14 07: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 HAA13499 for ; Wed, 14 May 2003 07:57:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3B3C06230F; Wed, 14 May 2003 14:00:16 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46]) by eikenes.alvestrand.no (Postfix) with ESMTP id 60DD9622B1 for ; Wed, 14 May 2003 14:00:12 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19FuvW-00072p-00; Wed, 14 May 2003 05:00:07 -0700 Date: Wed, 14 May 2003 07:59:27 -0400 From: Keith Moore To: Message-Id: <20030514075927.0c3ff83a.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: brian@hursley.ibm.com Subject: Re: Maturing [Re: Time required to write down "wisdom" ...] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 of a (perhaps naive) belief that there are windows of opportunities > for certain solutions. If we miss the window, certain technologies may > not be deployed, even if superior. I share this belief. Though I'm not sure we know how to predict those windows with any useful accuracy. From problem-statement-bounces@alvestrand.no Thu May 15 08:48: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 IAA07388 for ; Thu, 15 May 2003 08:48:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C5CCA6225B; Thu, 15 May 2003 14:50:52 +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 EC7C961C73 for ; Thu, 15 May 2003 14:50:45 +0200 (CEST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) h4FCogCi013996 for ; Thu, 15 May 2003 14:50:44 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4FCogbD215170 for ; Thu, 15 May 2003 14:50:42 +0200 Received: from dhcp22-123.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA54342 from ; Thu, 15 May 2003 14:50:40 +0200 Message-Id: <3EC38D3F.44DBBB80@hursley.ibm.com> Date: Thu, 15 May 2003 14:51: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: problem-statement@alvestrand.no References: <20030514075927.0c3ff83a.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Maturing [Re: Time required to write down "wisdom" ...] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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: > > > I am of a (perhaps naive) belief that there are windows of opportunities > > for certain solutions. If we miss the window, certain technologies may > > not be deployed, even if superior. > > I share this belief. Though I'm not sure we know how to predict those > windows with any useful accuracy. Can't disagree with either statement. And sometimes, that's in conflict with the need for stable, high quality standards for the mature market. Brian From problem-statement-bounces@alvestrand.no Thu May 15 10:44: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 KAA11234 for ; Thu, 15 May 2003 10:44:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 279296257C; Thu, 15 May 2003 16:46:43 +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 A2AC46225B for ; Thu, 15 May 2003 16:46:39 +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 HAA19777; Thu, 15 May 2003 07:46:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4FEkb922056; Thu, 15 May 2003 07:46:37 -0700 X-mProtect: <200305151446> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd64pvhF; Thu, 15 May 2003 07:46:36 PDT Message-ID: <3EC3A86B.8020808@iprg.nokia.com> Date: Thu, 15 May 2003 07:47:07 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter References: <20030514075927.0c3ff83a.moore@cs.utk.edu> <3EC38D3F.44DBBB80@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Maturing [Re: Time required to write down "wisdom" ...] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 Brian, I guess it's obvious, but if we were late with all the specifications, we would be also guaranteed to miss all the windows. Since the windows are unpredictable, the temptation becomes irresistable to keep working on the specification for longer, because, hey, the window might still be open, and there might still be a bug if we would just look harder... Regards, Charlie P. Brian E Carpenter wrote: >Keith Moore wrote: > > >>>I am of a (perhaps naive) belief that there are windows of opportunities >>>for certain solutions. If we miss the window, certain technologies may >>>not be deployed, even if superior. >>> >>> >>I share this belief. Though I'm not sure we know how to predict those >>windows with any useful accuracy. >> >> > >Can't disagree with either statement. And sometimes, that's in conflict >with the need for stable, high quality standards for the mature market. > > Brian > > From problem-statement-bounces@alvestrand.no Thu May 15 11:43: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 LAA12718 for ; Thu, 15 May 2003 11:43:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8E3086256B; Thu, 15 May 2003 17:46:10 +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 F3C236233E for ; Thu, 15 May 2003 17:46:07 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA15690 for ; Thu, 15 May 2003 08:45:58 -0700 (PDT) Message-Id: <5.1.0.14.2.20030515113022.014d6b88@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 15 May 2003 11:35:26 -0400 To: problem-statement@alvestrand.no From: Margaret Wasserman In-Reply-To: <200305131200.IAA05317@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: draft-ietf-problem-process-00.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Well, since no one else has jumped in, I guess I will... There are several open issues raised in the process document that will require discussion and resolution by the WG. I have opinions about how we should resolve these issues, and I'll offer my opinions now. Others should feel free to chime in with either agreement or dissent. I will raise each issue in a separate message, in an attempt to promote threading... Please try to respond to individual issues in their appropriate threads, so that I can keep better track of the discussion and reflect it in the document. Thanks, Margaret From problem-statement-bounces@alvestrand.no Thu May 15 11:43: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 LAA12732 for ; Thu, 15 May 2003 11:43:46 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AC8CD62590; Thu, 15 May 2003 17:46:13 +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 D3DA76256B for ; Thu, 15 May 2003 17:46:08 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA15703 for ; Thu, 15 May 2003 08:46:00 -0700 (PDT) Message-Id: <5.1.0.14.2.20030515113529.014ba800@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 15 May 2003 11:41:27 -0400 To: problem-statement@alvestrand.no From: Margaret Wasserman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 process document current says: >There is also a more fundamental issue with the IETF's engineering >practices. Although our current standards track contains three >levels of maturity (Proposed Standard, Draft Standard and Full >Standard), we do not have sufficient differentiation regarding the >quality and completeness of documents required at each stage. The >bar is set very high for publication at Proposed Standard, and very >few documents advance beyond this stage. [OPEN ISSUE: Do we have >IETF consensus that this is a problem?] I believe that this is a real issue, and that we need to make some changes to our standards-track document processes to address this. In particular, I think that we have inadvertently reached a point where our proposed standards are treated as standards by most of the industry. I think that this was caused, in part, by the high level of scrutiny that we place on documents before we allowing them to reach this level. This also leads to a lack of motivation to move documents to draft standard, where there interoperability will be demonstrated. In general, I think that this damages the quality and integrity of the IETF standards-track documents, and we should do something to fix it. Margaret From problem-statement-bounces@alvestrand.no Thu May 15 11:53: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 LAA13093 for ; Thu, 15 May 2003 11:53:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A94956256B; Thu, 15 May 2003 17:56:12 +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 329366225B for ; Thu, 15 May 2003 17:56:09 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA22667 for ; Thu, 15 May 2003 08:56:00 -0700 (PDT) Message-Id: <5.1.0.14.2.20030515114433.04767ac8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 15 May 2003 11:47:42 -0400 To: problem-statement@alvestrand.no From: Margaret Wasserman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: OPEN ISSUE: 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 Currently, the process document says: >We may also want to reconsider the process that is used to select >WG chairs. In particular, ADs could be encouraged to announce WG >chair openings within their areas and/or to identify and develop >more potential leaders. [OPEN ISSUE: Is there IETF consensus that >we have a problem in this area?] I don't think that we should change our official procedures in this area. I do think it would be good if ADs would communicate open WG chairs slots to the community and request input regarding potential candidates. However, it is important for ADs and WG chairs to have a good relationship, and for the AD to have authority over the WG chair. I believe that the current reporting relationship (AD chooses WG chair, chair serves at ADs pleasure) is appropriate. Margaret From problem-statement-bounces@alvestrand.no Thu May 15 11:53: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 LAA13111 for ; Thu, 15 May 2003 11:53:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7FCC962588; Thu, 15 May 2003 17:56:19 +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 57DDB6256B for ; Thu, 15 May 2003 17:56:10 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA22697 for ; Thu, 15 May 2003 08:56:02 -0700 (PDT) Message-Id: <5.1.0.14.2.20030515114755.014cedb8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 15 May 2003 11:49:56 -0400 To: problem-statement@alvestrand.no From: Margaret Wasserman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: OPEN ISSUE: Quality Process WG Charter X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Currently the process document says: >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: [...] > [OPEN ISSUE: Should the Problem Statement WG propose a charter for > this group, or leave that to the General AD and selected chair(s)?] I think that developing a charter for this group should be done by the ADs and chair(s), probably through the normal BOF process. Margaret From problem-statement-bounces@alvestrand.no Thu May 15 11:54: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 LAA13127 for ; Thu, 15 May 2003 11:54:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4CF25625AA; Thu, 15 May 2003 17:56:20 +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 D3A5E6233E for ; Thu, 15 May 2003 17:56:07 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA22635 for ; Thu, 15 May 2003 08:55:59 -0700 (PDT) Message-Id: <5.1.0.14.2.20030515114129.04754880@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 15 May 2003 11:44:14 -0400 To: problem-statement@alvestrand.no From: Margaret Wasserman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: OPEN ISSUE: Nomcom 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 The process document currently says: >We may also need to modify our Nomcom processes so that IETF >participants who are not part of the IETF leadership can have more >visibility into the Nomcom process and more proportional input into >leadership selection. [OPEN ISSUE: Do we have consensus that these >are real problems that need to be solved?] I believe that this is a real problem, and that we should modify our Nomcom processes to do two (related) things: - Give the community more visibility into the process. - Get more feedback on potential candidates from the community. Currently, some candidates are discussed with the leaders (IESG/IAB members and WG chairs), but the greater community doesn't even know who is being considered. Margaret From problem-statement-bounces@alvestrand.no Thu May 15 11:54: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 LAA13151 for ; Thu, 15 May 2003 11:54:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 00A936233E; Thu, 15 May 2003 17:57:28 +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 05AE26225B for ; Thu, 15 May 2003 17:57:24 +0200 (CEST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])h4FFvM712420 for ; Thu, 15 May 2003 18:57:22 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com ; Thu, 15 May 2003 18:57:22 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 15 May 2003 18:57:21 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 15 May 2003 18:57: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: Thu, 15 May 2003 18:57:20 +0300 Message-ID: Thread-Topic: OPEN ISSUE: Quality Process WG Charter Thread-Index: AcMa+o5hnJ2H8rX3Qb6uYbvH4XORxAAAAyLg From: To: , X-OriginalArrivalTime: 15 May 2003 15:57:21.0560 (UTC) FILETIME=[AB5C3980:01C31AFA] Subject: RE: OPEN ISSUE: Quality Process WG Charter X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 LAA13151 Hi Margaret, > >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: > > [...] > > > [OPEN ISSUE: Should the Problem Statement WG propose a charter for > > this group, or leave that to the General AD and selected chair(s)?] > > > I think that developing a charter for this group should be > done by the ADs and chair(s), probably through the normal > BOF process. I agree with you on this. John From problem-statement-bounces@alvestrand.no Thu May 15 11:57: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 LAA13229 for ; Thu, 15 May 2003 11:57:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 41D5D6233E; Thu, 15 May 2003 17:59:49 +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 E1D006225B for ; Thu, 15 May 2003 17:59:41 +0200 (CEST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])h4FFxf714324 for ; Thu, 15 May 2003 18:59:41 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com ; Thu, 15 May 2003 18:59:41 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 15 May 2003 18:59:41 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 15 May 2003 18:59:40 +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, 15 May 2003 18:59:40 +0300 Message-ID: Thread-Topic: OPEN ISSUE: Nomcom Process Thread-Index: AcMa+pTfaA6plZ3yTA6dACBiKXgwywAADIWA From: To: , X-OriginalArrivalTime: 15 May 2003 15:59:40.0753 (UTC) FILETIME=[FE536410:01C31AFA] Subject: RE: OPEN ISSUE: Nomcom 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA13229 Hi Margaret, I know this has been done in the past, but people nominated (and accepting the nomination) for IESG/IAB positions should be identified. I think, at a minimum, at least current IAB & IESG members who are interested in continuing should be announced. John > -----Original Message----- > From: ext Margaret Wasserman [mailto:mrw@windriver.com] > Sent: 15 May, 2003 18:44 > To: problem-statement@alvestrand.no > Subject: OPEN ISSUE: Nomcom Process > > > > The process document currently says: > > >We may also need to modify our Nomcom processes so that IETF > >participants who are not part of the IETF leadership can have more > >visibility into the Nomcom process and more proportional input into > >leadership selection. [OPEN ISSUE: Do we have consensus that these > >are real problems that need to be solved?] > > I believe that this is a real problem, and that we should > modify our Nomcom processes to do two (related) things: > > - Give the community more visibility into the > process. > - Get more feedback on potential candidates from > the community. Currently, some candidates > are discussed with the leaders (IESG/IAB > members and WG chairs), but the greater > community doesn't even know who is being > considered. > > Margaret > > > > From problem-statement-bounces@alvestrand.no Thu May 15 12: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 MAA13619 for ; Thu, 15 May 2003 12:03:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E53596233E; Thu, 15 May 2003 18:06:10 +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 0FED16225B for ; Thu, 15 May 2003 18:06:05 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA29010 for ; Thu, 15 May 2003 09:05:56 -0700 (PDT) Message-Id: <5.1.0.14.2.20030515115014.014db9f0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 15 May 2003 11:59:10 -0400 To: problem-statement@alvestrand.no From: Margaret Wasserman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: OPEN ISSUE: Improvement WG Oversight X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 process document current says: >There is an open question regarding who should have oversight >responsibility for the IETF Improvement WG, including management of >the WG chairs and approving the output for publication by the RFC >editor. The two primary options are an IESG-driven approach >overseen by the General AD, or an ISOC-driven approach overseen by >the ISOC President. These two proposals are further explained in >the next two sections. I think that the Improvement WG should use the IESG-driven process. The IESG-driven process is the usual process that the IETF uses to produce all types of IETF documents, and I don't see any reason why a different process is needed for us to update our own organization or processes. Our current organization and processes are documented in BCP RFCs that can and should be changed by the IETF using our existing process. The IESG members are our selected leaders, and I trust them to run this process fairly and openly. I also have three major concerns about the alternative (the ISOC-driven approach): - The ISOC-driven approach effectively cedes control of the IETF's processes to ISOC. I would rather keep control of these processes within the IETF. - The current Nomcom processes will require some significant modification to apply in this situation, as they are not intended to (a) produce documents, (b) produce results that represent community consensus, (c) have an adequate appeals process for this situation. - It is not the job of the ISOC President or the ISOC BoTs to determine consensus of the IETF community. That responsibility belongs to the IETF Chair and the IESG. Even though there are issues with the current IETF processes, I don't think that they are fatally flawed. IMO, we are better off using our current well-defined, well-understood processes than inventing a new set of processes just for this work. Margaret From problem-statement-bounces@alvestrand.no Thu May 15 12: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 MAA13840 for ; Thu, 15 May 2003 12:09:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C5B186233E; Thu, 15 May 2003 18:12:25 +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 60F096225B for ; Thu, 15 May 2003 18:12:21 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA02498 for ; Thu, 15 May 2003 09:12:13 -0700 (PDT) Message-Id: <5.1.0.14.2.20030515115941.014dbb30@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 15 May 2003 12:02:48 -0400 To: problem-statement@alvestrand.no From: Margaret Wasserman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: OPEN ISSUE: Appeals Path X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 process document currently says: >- [The ISOC-driven] approach does not require an explicit appeals > process, because an IETF Plenary is used as the basis for approval, > and it is that body from which the IETF draws its authority. > [OPEN ISSUE: Do we have consensus that a defined appeals > process is not required for this option?] I think that a well-defined appeals process is needed for any activity the size and scope of the proposed Improvement WG. For example, there may be a need to appeal decisions or actions of the WG chair(s), before any IETF-wide decisions are made. Margaret From problem-statement-bounces@alvestrand.no Thu May 15 12:10: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 MAA13854 for ; Thu, 15 May 2003 12:10:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 38F0F62588; Thu, 15 May 2003 18:12:28 +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 714006233E for ; Thu, 15 May 2003 18:12:22 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA02503 for ; Thu, 15 May 2003 09:12:14 -0700 (PDT) Message-Id: <5.1.0.14.2.20030515120309.0476a948@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 15 May 2003 12:08:13 -0400 To: problem-statement@alvestrand.no From: Margaret Wasserman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: OPEN 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 The process document currently says: >Another open question is how the chairs for the IETF Improvement WG >should be selected. As with the organization and management of the >WG, this document offers two choices: > > - The chair(s) of the WG could be selected by the "responsible > AD", or equivalent -- either the General AD or the ISOC > President. > - The chair(s) of the WG could be selected by the Nominations > Committee (Nomcom), or by a Nomcom-like group assembled for > the purpose. > >Either method of chair selection could be applied to either method >of WG oversight. As I stated earlier, I believe that the IESG-driven approach should be used. In that case, I believe that the General AD (as "responsible AD" for the proposed WG) should choose the chairs. IMO, the General AD should be fairly public about the process of chair selection (similar to what was done for the problem-statement WG), but should have the ultimate responsibility for this decision. The Nomcom-like approach seems compelling, but I believe that it has three flaws: - The process is too heavy-weight and would delay initiation of the WG. - This approach could choose a chair that the "responsible AD" does not know or trust. - There is no provision for what should happen if a chair needs to be replaced (for non-performance, resignation, etc.). Spinning up a Nomcom again could create an unacceptable delay for the work of the group. Margaret From problem-statement-bounces@alvestrand.no Thu May 15 12:25: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 MAA14259 for ; Thu, 15 May 2003 12:25:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 291E86233E; Thu, 15 May 2003 18:27:38 +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 12F456225B for ; Thu, 15 May 2003 18:27:34 +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 h4FGRKk02147; Thu, 15 May 2003 12:27:21 -0400 (EDT) Date: Thu, 15 May 2003 12:27:20 -0400 From: Keith Moore To: Charlie Perkins Message-Id: <20030515122720.37173568.moore@cs.utk.edu> In-Reply-To: <3EC3A86B.8020808@iprg.nokia.com> References: <20030514075927.0c3ff83a.moore@cs.utk.edu> <3EC38D3F.44DBBB80@hursley.ibm.com> <3EC3A86B.8020808@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 Cc: brian@hursley.ibm.com Subject: Re: Maturing [Re: Time required to write down "wisdom" ...] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 guess it's obvious, but if we were late with all the > specifications, we would be also guaranteed to miss > all the windows. Since the windows are unpredictable, > the temptation becomes irresistable to keep working > on the specification for longer, because, hey, the > window might still be open, and there might still > be a bug if we would just look harder... actually the argument is often made that we have to complete the specification immediately, whether it's ready or not, because we'll miss the unpredictable 'window'. I suspect it's also possible for specifications to be completed too soon - either before the real needs are understood or before the market is ready for them. and nobody wants to dust off a 10-year old spec even if it is within epsilon of what is needed for the current problem. From problem-statement-bounces@alvestrand.no Thu May 15 12:29: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 MAA14362 for ; Thu, 15 May 2003 12:29:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7F4A86233E; Thu, 15 May 2003 18:31: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 900096225B for ; Thu, 15 May 2003 18:31: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 JAA25285; Thu, 15 May 2003 09:31:30 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4FGVTl14535; Thu, 15 May 2003 09:31:29 -0700 X-mProtect: <200305151631> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVNuXdc; Thu, 15 May 2003 09:31:28 PDT Message-ID: <3EC3C0FE.80001@iprg.nokia.com> Date: Thu, 15 May 2003 09:31:58 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore References: <20030514075927.0c3ff83a.moore@cs.utk.edu> <3EC38D3F.44DBBB80@hursley.ibm.com> <3EC3A86B.8020808@iprg.nokia.com> <20030515122720.37173568.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Maturing [Re: Time required to write down "wisdom" ...] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, Let's take as an example the recent site-local discussion. IPv6 has some chance today, because it was published as a Proposed Standard quite a while ago. Imagine the chance it would have, if the site-local discussion would have prevented publication until, say, 2003. Regards, Charlie P. Keith Moore wrote: >>I guess it's obvious, but if we were late with all the >>specifications, we would be also guaranteed to miss >>all the windows. Since the windows are unpredictable, >>the temptation becomes irresistable to keep working >>on the specification for longer, because, hey, the >>window might still be open, and there might still >>be a bug if we would just look harder... >> >> > >actually the argument is often made that we have to complete the >specification immediately, whether it's ready or not, because >we'll miss the unpredictable 'window'. > >I suspect it's also possible for specifications to be completed too soon >- either before the real needs are understood or before the market is >ready for them. and nobody wants to dust off a 10-year old spec >even if it is within epsilon of what is needed for the current problem. > > From problem-statement-bounces@alvestrand.no Thu May 15 12:49: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 MAA14861 for ; Thu, 15 May 2003 12:49:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D29096233E; Thu, 15 May 2003 18:51:46 +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 7E9EB6225B for ; Thu, 15 May 2003 18:51:43 +0200 (CEST) Message-ID: <013b01c31b02$0d7baf40$176015ac@DCLKEMPFTP> From: "James Kempf" To: , , References: Date: Thu, 15 May 2003 09:50:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: OPEN ISSUE: Nomcom 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 John, Making the names of nominated candidates public has been discussed in the past and has been rejected for a variety of reasons. Here are some: 1) It would make the process more overtly political, so candidates would be tempted to lobby for election. It would also tend to attract candidates who like that kind of process, to the detriment of those who might be better qualified on technical grounds but are not comfortable with a more politicized selection process. 2) For those candidates who are not selected, there could be the feeling of having been "defeated". This is especially a problem for cultures where loss of face is a big issue, and so would serve to discourage their participation. Nocomm this year was very proactive about soliciting input on candidates. Those solicited were asked to keep the names confidential, and most people agree that this request was followed this year, though it hasn't been as closely followed in past years. Since IAB and IESG members standing for re-election are already known, and their record should be an issue in whether or not they are re-elected, I agree that making public who is up for re-election would be appropriate, however, to avoid 1) above, it might make sense to just put out the names of those I* who are up for re-election, regardless of whether they are interested in serving again or not. jak ----- Original Message ----- From: To: ; Sent: Thursday, May 15, 2003 8:59 AM Subject: RE: OPEN ISSUE: Nomcom Process > Hi Margaret, > > I know this has been done in the past, but people nominated (and accepting the > nomination) for IESG/IAB positions should be identified. I think, at a minimum, > at least current IAB & IESG members who are interested in continuing should > be announced. > > John > > > -----Original Message----- > > From: ext Margaret Wasserman [mailto:mrw@windriver.com] > > Sent: 15 May, 2003 18:44 > > To: problem-statement@alvestrand.no > > Subject: OPEN ISSUE: Nomcom Process > > > > > > > > The process document currently says: > > > > >We may also need to modify our Nomcom processes so that IETF > > >participants who are not part of the IETF leadership can have more > > >visibility into the Nomcom process and more proportional input into > > >leadership selection. [OPEN ISSUE: Do we have consensus that these > > >are real problems that need to be solved?] > > > > I believe that this is a real problem, and that we should > > modify our Nomcom processes to do two (related) things: > > > > - Give the community more visibility into the > > process. > > - Get more feedback on potential candidates from > > the community. Currently, some candidates > > are discussed with the leaders (IESG/IAB > > members and WG chairs), but the greater > > community doesn't even know who is being > > considered. > > > > Margaret > > > > > > > > > > From problem-statement-bounces@alvestrand.no Thu May 15 13: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 NAA15209 for ; Thu, 15 May 2003 13:01:06 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AA7EB62588; Thu, 15 May 2003 19:03:40 +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 B1F806257C for ; Thu, 15 May 2003 19:03:37 +0200 (CEST) Message-ID: <014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> From: "James Kempf" To: , "Margaret Wasserman" References: <5.1.0.14.2.20030515113529.014ba800@mail.windriver.com> Date: Thu, 15 May 2003 10:02:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, I've felt for some time that there is a need for a change in this area, but this analysis leaves out the issue of Working Group drafts, which I think is a critical component. Right now, they have grey area status. I've seen drafts move from individual contribution to Working Group status only because nobody on the mailing list spoke up when the Working Group chair put out the question about whether a draft should move to Working Group status or not. Many vendors start implementing when something becomes a Working Group draft, since realistically, they view that move as entry into the standardization process, regardless of what IETF's process RFCs say about it. Arguments have been made on this list that we should not touch the current Proposed/Draft distinction, and I agree that the distinction is useful even if Proposed is treated as "standard" by vendors for all practical purposes (Full Standard, however, is largely useless except as a historical distinction). However, I think some attention is needed to how a draft becomes a Working Group draft. Perhaps that move is when a preliminary review is made on the design, so that movement to Working Group draft status does not happen for reasons that have nothing to do with the technical aspects of the design. jak ----- Original Message ----- From: "Margaret Wasserman" To: Sent: Thursday, May 15, 2003 8:41 AM Subject: OPEN ISSUE: Standards Track > > The process document current says: > > >There is also a more fundamental issue with the IETF's engineering > >practices. Although our current standards track contains three > >levels of maturity (Proposed Standard, Draft Standard and Full > >Standard), we do not have sufficient differentiation regarding the > >quality and completeness of documents required at each stage. The > >bar is set very high for publication at Proposed Standard, and very > >few documents advance beyond this stage. [OPEN ISSUE: Do we have > >IETF consensus that this is a problem?] > > I believe that this is a real issue, and that we need to make > some changes to our standards-track document processes to > address this. > > In particular, I think that we have inadvertently reached a > point where our proposed standards are treated as standards > by most of the industry. I think that this was caused, in > part, by the high level of scrutiny that we place on documents > before we allowing them to reach this level. This also leads > to a lack of motivation to move documents to draft standard, > where there interoperability will be demonstrated. > > In general, I think that this damages the quality and > integrity of the IETF standards-track documents, and we > should do something to fix it. > > Margaret > > > > > > From problem-statement-bounces@alvestrand.no Thu May 15 13:16: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 NAA15654 for ; Thu, 15 May 2003 13:16:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EC5FA6256B; Thu, 15 May 2003 19:19:06 +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 12E2E6225B for ; Thu, 15 May 2003 19:18:56 +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 h4FHIsk04601; Thu, 15 May 2003 13:18:54 -0400 (EDT) Date: Thu, 15 May 2003 13:18:53 -0400 From: Keith Moore To: Charlie Perkins Message-Id: <20030515131853.36b0d668.moore@cs.utk.edu> In-Reply-To: <3EC3C0FE.80001@iprg.nokia.com> References: <20030514075927.0c3ff83a.moore@cs.utk.edu> <3EC38D3F.44DBBB80@hursley.ibm.com> <3EC3A86B.8020808@iprg.nokia.com> <20030515122720.37173568.moore@cs.utk.edu> <3EC3C0FE.80001@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: Maturing [Re: Time required to write down "wisdom" ...] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 as an example the recent site-local discussion. > > IPv6 has some chance today, because it was published > as a Proposed Standard quite a while ago. > > Imagine the chance it would have, if the site-local discussion > would have prevented publication until, say, 2003. and imagine how much better IPv6's chances for success would have been at if we had actually considered the implications of scoped addresses before we declared IPv6 suitable for Proposed Standard. had we held up declaring IPv6 as a proposed standard until the scoped address problem was understood, it would have been dealt with long before now. as it turned out, declaring IPv6 suitable for PS status had the effect of sweeping serious problems under the rug for several years, and it's much harder to fix those problems now. From problem-statement-bounces@alvestrand.no Thu May 15 15: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 PAA21121 for ; Thu, 15 May 2003 15:49:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E87516230A; Thu, 15 May 2003 21:52:17 +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 00EF5622AC for ; Thu, 15 May 2003 21:52:15 +0200 (CEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id AB61A6A905; Thu, 15 May 2003 22:52:12 +0300 (EEST) Message-ID: <3EC3EF99.9050709@piuha.net> Date: Thu, 15 May 2003 22:50:49 +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: Margaret Wasserman References: <5.1.0.14.2.20030515113529.014ba800@mail.windriver.com> In-Reply-To: <5.1.0.14.2.20030515113529.014ba800@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Standards Track 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 Margaret Wasserman wrote: > > The process document current says: > >> There is also a more fundamental issue with the IETF's engineering >> practices. Although our current standards track contains three >> levels of maturity (Proposed Standard, Draft Standard and Full >> Standard), we do not have sufficient differentiation regarding the >> quality and completeness of documents required at each stage. The >> bar is set very high for publication at Proposed Standard, and very >> few documents advance beyond this stage. [OPEN ISSUE: Do we have >> IETF consensus that this is a problem?] It is a problem. --Jari From problem-statement-bounces@alvestrand.no Thu May 15 15:50: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 PAA21147 for ; Thu, 15 May 2003 15:50:29 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4233862572; Thu, 15 May 2003 21:53:02 +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 5C416622AC for ; Thu, 15 May 2003 21:52:58 +0200 (CEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 44D0D6A902; Thu, 15 May 2003 22:52:57 +0300 (EEST) Message-ID: <3EC3EFC5.5090401@piuha.net> Date: Thu, 15 May 2003 22:51:33 +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: Margaret Wasserman References: <5.1.0.14.2.20030515114433.04767ac8@mail.windriver.com> In-Reply-To: <5.1.0.14.2.20030515114433.04767ac8@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: WG Chair Selection 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 Margaret Wasserman wrote: > > Currently, the process document says: > >> We may also want to reconsider the process that is used to select >> WG chairs. In particular, ADs could be encouraged to announce WG >> chair openings within their areas and/or to identify and develop >> more potential leaders. [OPEN ISSUE: Is there IETF consensus that >> we have a problem in this area?] The selection and reporting relationship as it stands now is not a problem imho. But I agree with you Margaret that some openness of the process (maybe a web page of open IETF positions including chairs) would be good. Might add to the number persons available for the tasks, might give better input on the potential candidates, let folks know what's going on the organization. --Jari From problem-statement-bounces@alvestrand.no Fri May 16 01:34: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 BAA02278 for ; Fri, 16 May 2003 01:34:14 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8BF6F6230A; Fri, 16 May 2003 07:36:10 +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 E00B361C73 for ; Fri, 16 May 2003 07:36:05 +0200 (CEST) Date: Thu, 15 May 2003 22:40:06 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <1689237845.1053038406@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 ISSUE: Quality Process WG Charter X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 15. mai 2003 18:57 +0300 john.loughney@nokia.com wrote: >> > [OPEN ISSUE: Should the Problem Statement WG propose a charter for >> > this group, or leave that to the General AD and selected chair(s)?] >> >> >> I think that developing a charter for this group should be >> done by the ADs and chair(s), probably through the normal >> BOF process. > > I agree with you on this. timing issue..... is the creation of the Quality WG dependent on IETF consensus on the Problem and Process documentson this WG? If yes - the WG cannot be started until after Vienna. If no - the WG process can be started as soon as there appears to be reasonable consensus that the WG should be formed. It seems reasonable to expect that the WG could start before this WG produces its final output. identity issue.... is this WG in parallel to, in cooperation with, or orthogonal to, the proposal to form a WG (that is, an activity with a charter) focusing on training/education/leader development for the IETF? From problem-statement-bounces@alvestrand.no Fri May 16 02:21: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 BAA02277 for ; Fri, 16 May 2003 01:34:14 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F1BCB62572; Fri, 16 May 2003 07:36:13 +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 5835C61BA7 for ; Fri, 16 May 2003 07:36:09 +0200 (CEST) Date: Thu, 15 May 2003 22:49:19 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <1689790900.1053038959@localhost> In-Reply-To: <014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> References: <5.1.0.14.2.20030515113529.014ba800@mail.windriver.com> <014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> 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 ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit mumble.... there's another issue here, but I don't know if it is possible to untangle it...... *what sort of bugs, if detected, would make a protocol unsuitable for Proposed Standard?* If there are 2 reasonable interpretations of a statement, which could lead to 2 noninteroperable interpretations? (Happened with BGP, I believe..... common practice now is only one, and there is a new spec being written that clarifies the point) If there is part of the overall function that is not specified, so that you can implement it, but it can do nothing useful without further specification? (my favourite example is TIP, if anyone remembers that) If there are issues that you know will arise when people try it, for instance "what is an alphabetic character"? (one of the recent specs out of PKIX) It's fairly obvious that we invented the 3-step process so that we could fix bugs. And that implies that we think there are bugs that will only be flushed out after people try it out in practice. But - does that mean that we should let known bugs pass into Proposed? Or will this be forever a judgment call? ..... A related issue is whether or not the restrictions on going to Draft from Proposed are really appropriate; currently, we say that *only* deletion of features is appropriate, and that any change or extension, no matter how worthwhile the purpose or how sure we are that it makes no problems, requires another round through Proposed. Is this really best for the Internet? Harald From problem-statement-bounces@alvestrand.no Fri May 16 02: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 CAA14878 for ; Fri, 16 May 2003 02:28:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 161726256B; Fri, 16 May 2003 08:30:35 +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 5403B61C73; Fri, 16 May 2003 08:30:26 +0200 (CEST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])h4G6UPD12284; Fri, 16 May 2003 09:30:25 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com ; Fri, 16 May 2003 09:30:25 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 16 May 2003 09:30:25 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 16 May 2003 09:30:24 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 16 May 2003 09:30: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: Fri, 16 May 2003 09:30:23 +0300 Message-ID: Thread-Topic: OPEN ISSUE: Quality Process WG Charter Thread-Index: AcMbbRSFkRAALXVxSqi6FFpckNjGIgABzKvw From: To: , X-OriginalArrivalTime: 16 May 2003 06:30:23.0737 (UTC) FILETIME=[A1921E90:01C31B74] Subject: RE: OPEN ISSUE: Quality Process WG Charter X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 CAA14878 Harold, > >> > [OPEN ISSUE: Should the Problem Statement WG propose > a charter for > >> > this group, or leave that to the General AD and > selected chair(s)?] > >> > >> > >> I think that developing a charter for this group should be > >> done by the ADs and chair(s), probably through the normal > >> BOF process. > > > > I agree with you on this. > > timing issue..... > > is the creation of the Quality WG dependent on IETF consensus on the > Problem and Process documentson this WG? > If yes - the WG cannot be started until after Vienna. > If no - the WG process can be started as soon as there appears to be > reasonable consensus that the WG should be formed. It seems reasonable to > expect that the WG could start before this WG produces its > final output. Irrespective of the yes or no - what stops us from having a bof on this, where a charter is proposed, etc? > identity issue.... > > is this WG in parallel to, in cooperation with, or orthogonal to, the > proposal to form a WG (that is, an activity with a charter) > focusing on training/education/leader development for the IETF? I guess I haven't been paying attention - I did not realize that there was such a proposal for a WG. Anyhow, I'd say there was a relation, but not a direct coupling of the two efforts. thanks, John From problem-statement-bounces@alvestrand.no Fri May 16 02:39: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 CAA15098 for ; Fri, 16 May 2003 02:39:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 47DEA6259C; Fri, 16 May 2003 08:39: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 260E762590; Fri, 16 May 2003 08:39:45 +0200 (CEST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])h4G6dhD23990; Fri, 16 May 2003 09:39:44 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com ; Fri, 16 May 2003 09:39:41 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 16 May 2003 09:39:39 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 16 May 2003 09:39: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: Fri, 16 May 2003 09:39:33 +0300 Message-ID: Thread-Topic: OPEN ISSUE: Standards Track Thread-Index: AcMbbRx7U3SNAgL0Srmr7a5ipd1gygAB5nLg From: To: , X-OriginalArrivalTime: 16 May 2003 06:39:33.0645 (UTC) FILETIME=[E9576BD0:01C31B75] Subject: RE: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 CAA15098 More mumbles ... > there's another issue here, but I don't know if it is > possible to untangle it...... > > *what sort of bugs, if detected, would make a protocol unsuitable for > Proposed Standard?* Bugs that cause interoperability failures. > If there are 2 reasonable interpretations of a statement, which could lead > to 2 noninteroperable interpretations? (Happened with BGP, I believe..... > common practice now is only one, and there is a new spec > being written that clarifies the point) That would be a red flag, in my opinion. > If there is part of the overall function that is not specified, so that you > can implement it, but it can do nothing useful without further > specification? (my favourite example is TIP, if anyone remembers that) This, in my opinion, shouldn't be a show-stopper. > If there are issues that you know will arise when people try it, for > instance "what is an alphabetic character"? (one of the > recent specs out of PKIX) Most likely a showstopper. > It's fairly obvious that we invented the 3-step process so that we could > fix bugs. And that implies that we think there are bugs that will only be > flushed out after people try it out in practice. I always thought that the 3 step process was used because we wanted to get deployment experience sooner rather than later. In a past life, I implemented some Intelligent Network protocols. If anyone has a spare month, take a look into some CoreINAP specifications. Suffice it to say that 90% of the spec is probably unimplementable - forget about deployment issues. I don't think that we want to go down that road. We should make good proposed standards, which may have some flaws or some open issues, things that need refinement - but getting implementation, deployment & real-world use is key. > But - does that mean that we should let known bugs pass into Proposed? > Or will this be forever a judgment call? Bugs can be in the eye of the beholder, that is why I think focusing on known interoperability problems should be something not passed into Proposed Standards. SOme other issues are more judgement calls, in my mind. > A related issue is whether or not the restrictions on going to Draft from > Proposed are really appropriate; currently, we say that *only* deletion of > features is appropriate, and that any change or extension, no matter how > worthwhile the purpose or how sure we are that it makes no problems, > requires another round through Proposed. Is this really best for the > Internet? I can't say - anyone have examples? John From problem-statement-bounces@alvestrand.no Fri May 16 05:05: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 FAA17086 for ; Fri, 16 May 2003 05:05:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9BE9662571; Fri, 16 May 2003 11:04: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 5725061BA7; Fri, 16 May 2003 11:03:44 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id CAA16482; Fri, 16 May 2003 02:03:34 -0700 (PDT) Message-Id: <5.1.0.14.2.20030516045138.039fad60@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 16 May 2003 04:57:23 -0400 To: Harald Tveit Alvestrand From: Margaret Wasserman In-Reply-To: <1689237845.1053038406@localhost> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: RE: OPEN ISSUE: Quality Process WG Charter X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 Harald, At 10:40 PM 5/15/2003 +0200, Harald Tveit Alvestrand wrote: >timing issue..... > >is the creation of the Quality WG dependent on IETF consensus on the >Problem and Process documentson this WG? >If yes - the WG cannot be started until after Vienna. >If no - the WG process can be started as soon as there appears to be >reasonable consensus that the WG should be formed. It seems reasonable to >expect that the WG could start before this WG produces its final output. IMO, we should start the near-term efforts described in this document (all four of them) as soon as there is community consensus to start them. In fact, at least two of them are already underway. I don't think that the problem-statement group should cause a delay in our efforts to improve outselves. >identity issue.... > >is this WG in parallel to, in cooperation with, or orthogonal to, the >proposal to form a WG (that is, an activity with a charter) focusing on >training/education/leader development for the IETF? There are four near-term efforts identified in the document that can proceed immediately and in parallel: - WG quality processes (the WG you're talking about). - Training/Education (this is only defined as an "effort" in the document, not explicitly as a WG -- that discussion didn't start until after I published the document). - Identifying/deploying tools for issue tracking and document revision control. - Promoting/increasing communication between WG chairs. Hopefully all of the near-term efforts will spin-up while we are still trying to define and start the longer-term effort which will: - Improve the scalability and effectiveness of the management structure of the IETF (i.e. reorganize). - Update the standards-track document processes to be more effective and timely. If you've read the document carefully and this is unclear, please let me know, so that I can attempt to make it clearer. Thanks, Margaret From problem-statement-bounces@alvestrand.no Fri May 16 05: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 FAA17482 for ; Fri, 16 May 2003 05:28:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D0C3A621FB; Fri, 16 May 2003 11:30:50 +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 C578C61BA7 for ; Fri, 16 May 2003 11:30:47 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id CAA27937 for ; Fri, 16 May 2003 02:30:39 -0700 (PDT) Message-Id: <5.1.0.14.2.20030516050623.038bd7f0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 16 May 2003 05:26:45 -0400 To: problem-statement@alvestrand.no From: Margaret Wasserman In-Reply-To: <1689790900.1053038959@localhost> References: <014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> <5.1.0.14.2.20030515113529.014ba800@mail.windriver.com> <014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 10:49 PM 5/15/2003 +0200, Harald Tveit Alvestrand wrote: >mumble.... > >there's another issue here, but I don't know if it is possible to untangle >it...... > >*what sort of bugs, if detected, would make a protocol unsuitable for >Proposed Standard?* There are at least two ways to look at the concept of a staged release process: (1) You define the criteria for acceptance at each phase. These criteria are easier to meet at lower phases (i.e. you can have more bugs of certain types, you need implementations for a certain phase, etc.). (2) You expend different levels of effort to determine the quality at each phase (i.e. you subject the document to successively wider review and comment at each phase). We already do (1) to some extent (requiring implementations for DS), but we don't do (2) at all... It might be possible, for example for area management to publish a document to the first phase in the standards process, without full IESG review. This would also help with the scaling problems at the top. I also think that there are two other problems facing us: (1) There is no real differentiation in our market between Proposed Standards and Draft Standards. Our "customers" don't know what documents are at what level, and they don't care. In fact, most of them can't remember which comes first, PS or DS... And once something has an RFC number (even experimental or info), it is treated like a standard. So, there is really no reason to do the work necessary to move to DS, and certainly not to FS. (2) The term "Proposed Standard" currently indicates to our market that the document is a standard. If we create a lower-level category, we should give it a different name, and put something _in the document_ that indicates its provisional status. (No one actually looks at the RFC index to determine the status of a document before specifying it in an RFQ or RFP). >It's fairly obvious that we invented the 3-step process so that we could >fix bugs. And that implies that we think there are bugs that will only be >flushed out after people try it out in practice. > >But - does that mean that we should let known bugs pass into Proposed? >Or will this be forever a judgment call? I think it will forever be a judgement call, just as it is in software and hardware development. Like all judgement calls, there is a certain amount of effort spent in gathering the information to make the call, and then the call is made based on available information. The best way to create a tiered process is not to remove the judgement call... Instead, you could move it to lower levels of the organization (if we had any) and/or lessen the time and resources spent gathering information before the judgement call is made. >A related issue is whether or not the restrictions on going to Draft from >Proposed are really appropriate; currently, we say that *only* deletion of >features is appropriate, and that any change or extension, no matter how >worthwhile the purpose or how sure we are that it makes no problems, >requires another round through Proposed. Is this really best for the Internet? I think that this process is damaging, because it tends to lead to all of the implementation-related experience being reflected in the PS version. This, in turn, offers even less incentive to the group to produce a DS version. At this point, there are _many_ WG and non-WG I-Ds in the IETF that have already been widely implemented and fairly widely deployed. If it weren't for the requirement that documents be published at PS for six months and recycled if there are any changes other than deletions, many of these documents could go straight to DS... Sometimes, I feel like a hypocrite about this topic. On the one hand, I'm fighting to keep the "integrity" of the standards-track document set, according to our current rules. And, on the other hand, I think that our current rules are more than a bit draconian. For example, I think that it should be possible for several different proposals that solve the same problem to be published in an enduring form by the IETF, and for a subsequent process to determine which one(s) will advance on the standards-track. This would solve some of the problems that we have in the v6ops WG, for example. But, we have no tools to do this in a way that makes the status of these documents visible to our "customers". As soon as a protocol has an RFC number, our "customers" treat it as a standard. Meanwhile, we have individual submission track where people can get RFC numbers without jumping through any of the IETF hoops (unless they happen to overlap with a WG). What is wrong with this picture? Margaret From problem-statement-bounces@alvestrand.no Fri May 16 07:33: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 HAA19956 for ; Fri, 16 May 2003 07:33:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3F9B9621FB; Fri, 16 May 2003 13:36:19 +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 D1578621B8 for ; Fri, 16 May 2003 13:36:16 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.5]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id EAA08698 for ; Fri, 16 May 2003 04:36:07 -0700 (PDT) Message-Id: <5.1.0.14.2.20030516072814.04754080@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 16 May 2003 07:32:10 -0400 To: problem-statement@alvestrand.no From: Margaret Wasserman In-Reply-To: <5.1.0.14.2.20030516050623.038bd7f0@mail.windriver.com> References: <1689790900.1053038959@localhost> <014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> <5.1.0.14.2.20030515113529.014ba800@mail.windriver.com> <014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 reading over my own response I had a further thought... At 05:26 AM 5/16/2003 -0400, Margaret Wasserman wrote: >I think it will forever be a judgement call, just as it is in software >and hardware development. > >Like all judgement calls, there is a certain amount of effort spent in >gathering the information to make the call, and then the call is made >based on available information. The best way to create a tiered process >is not to remove the judgement call... Instead, you could move it to >lower levels of the organization (if we had any) and/or lessen the time and >resources spent gathering information before the judgement call is made. When documents are reviewed, it would be useful if we could get two types of (clearly delineated) feedback: (1) Blocking issues that would prevent the publication of the document at PS. In the opinion of the reviewer (currently the IESG), it is worth delaying publication of the document to fix this problem. (2) Non-blocking issues that should be fixed in the next revision (and certainly before the document goes to the next stage). Right now, any issue raised by the IESG (through a DISCUSS) is treated as a blocking issue. Margaret From problem-statement-bounces@alvestrand.no Fri May 16 08: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 IAA20697 for ; Fri, 16 May 2003 08:17:49 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 50CAB621FB; Fri, 16 May 2003 14:20: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 2234B621FB for ; Fri, 16 May 2003 14:20:16 +0200 (CEST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) h4GCK8Um019826 for ; Fri, 16 May 2003 14:20:10 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4GCK5aY229902 for ; Fri, 16 May 2003 14:20:06 +0200 Received: from dhcp22-123.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA55990 from ; Fri, 16 May 2003 14:20:03 +0200 Message-Id: <3EC4D791.941C50E9@hursley.ibm.com> Date: Fri, 16 May 2003 14:20:33 +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: <200305131200.IAA05333@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: I-D ACTION:draft-ietf-problem-issue-statement-01.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Nice job. The phrasings that I disliked in the -00 version have all been fixed. Brian From problem-statement-bounces@alvestrand.no Fri May 16 08:46: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 IAA21152 for ; Fri, 16 May 2003 08:46:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 57B3462572; Fri, 16 May 2003 14:49:02 +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 8D8E76256B for ; Fri, 16 May 2003 14:48:54 +0200 (CEST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) h4GCmqCi055632 for ; Fri, 16 May 2003 14:48:52 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4GCmqaY073908 for ; Fri, 16 May 2003 14:48:52 +0200 Received: from dhcp22-123.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA46146 from ; Fri, 16 May 2003 14:48:51 +0200 Message-Id: <3EC4DE50.D04E601C@hursley.ibm.com> Date: Fri, 16 May 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: <200305131200.IAA05317@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: I-D ACTION:draft-ietf-problem-process-00.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Generally I like this draft. I will comment separately on Margaret's open issues threads. > 2 IETF Core Values I'm surprised not to find self-governance listed as a core value. ... > 5.1 Near-Term Improvements ... > 5. Modify IESG-internal processes to make it impossible for one > or two IESG members to block a document. There is a strong implication here that ADs might do this for spurious reasons. But if one or both Security ADs are deeply convinced that a draft constitutes a major security risk, or one or both Routing ADs are convinced that a draft will lead to routing loops, isn't it quite appropriate for them to block the document? Such cases suggest failures much earlier in the process, not misbehaviour by the IESG. So I don't think we should fix this, because it is actually a vital back-stop, not a bug. ... > 5.2.1.1 Working Group Charter and Deliverables ... > Although the IETF Improvement WG will ultimately be responsible for > determining what improvements are required, it should be clear that > this WG is empowered to make changes to the IETF organizational > structure and processes, subject to approval by the appropriate > oversight body (see below), such as: > > - Updates to RFC 2418, the Nomcom processes and the IESG and > IAB charters (as needed) to define a more scaleable and > effective organizational structure for the IETF. I have some difficulty with this. It's inconceivable to me to make changes to the IAB charter, or to create an IESG charter, without the overwhelming support of the current IAB or IESG respectively. So I don't agree that the proposed WG can be "empowered" for this. It could be chartered to make concrete proposals to the IAB|IESG but the only workable outcome is consensus between the WG and IAB|IESG. > - Updates to RFC 2026 and other published processes to build > an effective multi-level standards-track and to reflect any > new organizational roles. Please specifically exclude updates to IPR policy, since we have just reached consensus over in IPRWG not to do this. ... > 5.2.2.1 IESG-Directed Approach > > One possibility is that we could use the IETF WG and document > processes defined in RFCs 2418 and 2026 [RFC2418, RFC2026] for the > oversight of the IETF Improvement WG. > > In particular: > > - The WG would be formed in the General Area of the IETF, with > the General AD serving as the "responsible AD". > - The documents would be submitted to the IESG for approval > and publication, according to the usual IETF processes. > - If necessary, any appeals based on the processes or output > of this WG would be handled according to the appeals > procedures defined in RFCs 2418 and 2026. A very important step is missing here. All IETF process documents need to be formally accepted by the ISOC Board, to ensure that we have the necessary chain of authority to validate the liability insurance. > 5.2.2.2 ISOC-Directed Approach > > Another approach would be to ask the ISOC President and the ISOC > Board of Trustees (ISOC BoT) to assume responsibility for the > oversight of the IETF Improvement WG, similar to our current > Nominations Committee processes, as defined in RFC 2727 [RFC2727]. > Although I am currently an ISOC Trustee, I certainly can't speak for the ISOC on this. However, I wouldn't advocate it. Only a few members of the ISOC Board are truly familiar with the IETF's internal workings. Having the Board accept the final documents, as noted above, is enough. Brian From problem-statement-bounces@alvestrand.no Fri May 16 08:49: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 IAA21192 for ; Fri, 16 May 2003 08:49:41 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5DB4D6256B; Fri, 16 May 2003 14:52:11 +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 69638621B8 for ; Fri, 16 May 2003 14:52:06 +0200 (CEST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) h4GCq4lr072260 for ; Fri, 16 May 2003 14:52:04 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4GCq3aY279808 for ; Fri, 16 May 2003 14:52:04 +0200 Received: from dhcp22-123.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA54024 from ; Fri, 16 May 2003 14:52:01 +0200 Message-Id: <3EC4DF0F.C4F56D80@hursley.ibm.com> Date: Fri, 16 May 2003 14:52:31 +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: <5.1.0.14.2.20030515115941.014dbb30@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: OPEN ISSUE: Appeals Path X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 Wasserman wrote: > > The process document currently says: > > >- [The ISOC-driven] approach does not require an explicit appeals > > process, because an IETF Plenary is used as the basis for approval, > > and it is that body from which the IETF draws its authority. > > [OPEN ISSUE: Do we have consensus that a defined appeals > > process is not required for this option?] > > I think that a well-defined appeals process is needed for any > activity the size and scope of the proposed Improvement WG. > > For example, there may be a need to appeal decisions or > actions of the WG chair(s), before any IETF-wide decisions > are made. Yet another reason why the ISOC-driven approach is a bad idea. (For the basic reason, see my previous message.) Brian From problem-statement-bounces@alvestrand.no Fri May 16 08:52: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 IAA21231 for ; Fri, 16 May 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 2FAFF62572; Fri, 16 May 2003 14:54:25 +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 81B206256B for ; Fri, 16 May 2003 14:54:19 +0200 (CEST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) h4GCsHlr107160 for ; Fri, 16 May 2003 14:54:17 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4GCsGaY279952 for ; Fri, 16 May 2003 14:54:16 +0200 Received: from dhcp22-123.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA54070 from ; Fri, 16 May 2003 14:54:15 +0200 Message-Id: <3EC4DF95.F127BBDE@hursley.ibm.com> Date: Fri, 16 May 2003 14:54:45 +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: <5.1.0.14.2.20030515115014.014db9f0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: OPEN ISSUE: Improvement WG Oversight X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 Wasserman wrote: > > The process document current says: > > >There is an open question regarding who should have oversight > >responsibility for the IETF Improvement WG, including management of > >the WG chairs and approving the output for publication by the RFC > >editor. The two primary options are an IESG-driven approach > >overseen by the General AD, or an ISOC-driven approach overseen by > >the ISOC President. These two proposals are further explained in > >the next two sections. > > I think that the Improvement WG should use the IESG-driven > process. I concur, for many reasons. Brian > > The IESG-driven process is the usual process that the IETF > uses to produce all types of IETF documents, and I don't see > any reason why a different process is needed for us to update > our own organization or processes. Our current organization > and processes are documented in BCP RFCs that can and should > be changed by the IETF using our existing process. > > The IESG members are our selected leaders, and I trust them > to run this process fairly and openly. > > I also have three major concerns about the alternative (the > ISOC-driven approach): > > - The ISOC-driven approach effectively cedes control of > the IETF's processes to ISOC. I would rather keep > control of these processes within the IETF. > - The current Nomcom processes will require some significant > modification to apply in this situation, as they are not > intended to (a) produce documents, (b) produce results > that represent community consensus, (c) have an adequate > appeals process for this situation. > - It is not the job of the ISOC President or the ISOC BoTs > to determine consensus of the IETF community. That > responsibility belongs to the IETF Chair and the IESG. > > Even though there are issues with the current IETF processes, > I don't think that they are fatally flawed. IMO, we are > better off using our current well-defined, well-understood > processes than inventing a new set of processes just for > this work. > > Margaret -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From problem-statement-bounces@alvestrand.no Fri May 16 08:53: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 IAA21260 for ; Fri, 16 May 2003 08:53:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 385F062572; Fri, 16 May 2003 14:56:03 +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 B41A86256B for ; Fri, 16 May 2003 14:55:56 +0200 (CEST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4GCtpu9032650 for ; Fri, 16 May 2003 14:55:52 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4GCtoaY280696 for ; Fri, 16 May 2003 14:55:50 +0200 Received: from dhcp22-123.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA41518 from ; Fri, 16 May 2003 14:55:48 +0200 Message-Id: <3EC4DFF1.3F2F073C@hursley.ibm.com> Date: Fri, 16 May 2003 14:56:17 +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: <5.1.0.14.2.20030515120309.0476a948@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: OPEN 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 Margaret Wasserman wrote: > > The process document currently says: > > >Another open question is how the chairs for the IETF Improvement WG > >should be selected. As with the organization and management of the > >WG, this document offers two choices: > > > > - The chair(s) of the WG could be selected by the "responsible > > AD", or equivalent -- either the General AD or the ISOC > > President. > > - The chair(s) of the WG could be selected by the Nominations > > Committee (Nomcom), or by a Nomcom-like group assembled for > > the purpose. > > > >Either method of chair selection could be applied to either method > >of WG oversight. > > As I stated earlier, I believe that the IESG-driven approach > should be used. > > In that case, I believe that the General AD (as "responsible > AD" for the proposed WG) should choose the chairs. I concur Brian > IMO, the > General AD should be fairly public about the process of chair > selection (similar to what was done for the problem-statement > WG), but should have the ultimate responsibility for this > decision. > > The Nomcom-like approach seems compelling, but I believe that > it has three flaws: > > - The process is too heavy-weight and would delay > initiation of the WG. > - This approach could choose a chair that the "responsible > AD" does not know or trust. > - There is no provision for what should happen if a chair > needs to be replaced (for non-performance, resignation, > etc.). Spinning up a Nomcom again could create an > unacceptable delay for the work of the group. > > Margaret -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From problem-statement-bounces@alvestrand.no Fri May 16 08:57: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 IAA21349 for ; Fri, 16 May 2003 08:57:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A222F6256B; Fri, 16 May 2003 15:00:04 +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 D82B96233E for ; Fri, 16 May 2003 15:00:02 +0200 (CEST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) h4GCxsDI085370; Fri, 16 May 2003 14:59:56 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4GCxkEw093882; Fri, 16 May 2003 14:59:46 +0200 Received: from dhcp22-123.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA53938 from ; Fri, 16 May 2003 14:59:41 +0200 Message-Id: <3EC4E0DB.AA829841@hursley.ibm.com> Date: Fri, 16 May 2003 15:00: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: James Kempf References: <013b01c31b02$0d7baf40$176015ac@DCLKEMPFTP> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: john.loughney@nokia.com Cc: mrw@windriver.com Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Nomcom 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 would add that this was discussed *extensively* in the current nomcom WG and there was no consensus to publish the names. I would suggest that it would be ironic if the problem-statement WG were to commit the sin of re-discussing a solution that another WG has recently discussed and abandoned. Brian James Kempf wrote: > > John, > > Making the names of nominated candidates public has been discussed in > the past and has been rejected for a variety of reasons. Here are > some: > > 1) It would make the process more overtly political, so candidates > would be tempted to lobby for election. It would also tend to attract > candidates who like that kind of process, to the detriment of those > who might be better qualified on technical grounds but are not > comfortable with a more politicized selection process. > 2) For those candidates who are not selected, there could be the > feeling of having been "defeated". This is especially a problem for > cultures where loss of face is a big issue, and so would serve to > discourage their participation. > > Nocomm this year was very proactive about soliciting input on > candidates. Those solicited were asked to keep the names confidential, > and most people agree that this request was followed this year, though > it hasn't been as closely followed in past years. Since IAB and IESG > members standing for re-election are already known, and their record > should be an issue in whether or not they are re-elected, I agree that > making public who is up for re-election would be appropriate, however, > to avoid 1) above, it might make sense to just put out the names of > those I* who are up for re-election, regardless of whether they are > interested in serving again or not. > > jak > > ----- Original Message ----- > From: > To: ; > Sent: Thursday, May 15, 2003 8:59 AM > Subject: RE: OPEN ISSUE: Nomcom Process > > > Hi Margaret, > > > > I know this has been done in the past, but people nominated (and > accepting the > > nomination) for IESG/IAB positions should be identified. I think, > at a minimum, > > at least current IAB & IESG members who are interested in continuing > should > > be announced. > > > > John > > > > > -----Original Message----- > > > From: ext Margaret Wasserman [mailto:mrw@windriver.com] > > > Sent: 15 May, 2003 18:44 > > > To: problem-statement@alvestrand.no > > > Subject: OPEN ISSUE: Nomcom Process > > > > > > > > > > > > The process document currently says: > > > > > > >We may also need to modify our Nomcom processes so that IETF > > > >participants who are not part of the IETF leadership can have > more > > > >visibility into the Nomcom process and more proportional input > into > > > >leadership selection. [OPEN ISSUE: Do we have consensus that > these > > > >are real problems that need to be solved?] > > > > > > I believe that this is a real problem, and that we should > > > modify our Nomcom processes to do two (related) things: > > > > > > - Give the community more visibility into the > > > process. > > > - Get more feedback on potential candidates from > > > the community. Currently, some candidates > > > are discussed with the leaders (IESG/IAB > > > members and WG chairs), but the greater > > > community doesn't even know who is being > > > considered. > > > > > > Margaret From problem-statement-bounces@alvestrand.no Fri May 16 09:02: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 JAA21429 for ; Fri, 16 May 2003 09:02:48 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E2C316256B; Fri, 16 May 2003 15:05:20 +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 5AD646233E for ; Fri, 16 May 2003 15:05:15 +0200 (CEST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) h4GD5Dlr060760 for ; Fri, 16 May 2003 15:05:13 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4GD5DEw052358 for ; Fri, 16 May 2003 15:05:13 +0200 Received: from dhcp22-123.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA53932 from ; Fri, 16 May 2003 15:05:12 +0200 Message-Id: <3EC4E226.569D4712@hursley.ibm.com> Date: Fri, 16 May 2003 15:05: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: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: OPEN ISSUE: Quality Process WG Charter X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 Margaret, > > > >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: > > > > [...] > > > > > [OPEN ISSUE: Should the Problem Statement WG propose a charter for > > > this group, or leave that to the General AD and selected chair(s)?] > > > > > > I think that developing a charter for this group should be > > done by the ADs and chair(s), probably through the normal > > BOF process. > > I agree with you on this. > > John ditto Brian From problem-statement-bounces@alvestrand.no Fri May 16 09:03: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 JAA21456 for ; Fri, 16 May 2003 09:03:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1F94D6256B; Fri, 16 May 2003 15:06:24 +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 05B306233E for ; Fri, 16 May 2003 15:06:20 +0200 (CEST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) h4GD6HDI038194 for ; Fri, 16 May 2003 15:06:18 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4GD6FaY050466 for ; Fri, 16 May 2003 15:06:15 +0200 Received: from dhcp22-123.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA39432 from ; Fri, 16 May 2003 15:06:14 +0200 Message-Id: <3EC4E263.7E39555D@hursley.ibm.com> Date: Fri, 16 May 2003 15:06:43 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: problem-statement@alvestrand.no References: <5.1.0.14.2.20030515114433.04767ac8@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: OPEN ISSUE: 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 Margaret Wasserman wrote: > > Currently, the process document says: > > >We may also want to reconsider the process that is used to select > >WG chairs. In particular, ADs could be encouraged to announce WG > >chair openings within their areas and/or to identify and develop > >more potential leaders. [OPEN ISSUE: Is there IETF consensus that > >we have a problem in this area?] > > I don't think that we should change our official procedures > in this area. > > I do think it would be good if ADs would communicate open WG > chairs slots to the community and request input regarding > potential candidates. > > However, it is important for ADs and WG chairs to have a good > relationship, and for the AD to have authority over the WG > chair. I believe that the current reporting relationship > (AD chooses WG chair, chair serves at ADs pleasure) is > appropriate. Agreed Brian From problem-statement-bounces@alvestrand.no Fri May 16 09:11: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 JAA21842 for ; Fri, 16 May 2003 09:11:46 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E712E6256B; Fri, 16 May 2003 15:14:18 +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 DC4406233E for ; Fri, 16 May 2003 15:14:11 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.5]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA19331; Fri, 16 May 2003 06:14:01 -0700 (PDT) Message-Id: <5.1.0.14.2.20030516090020.03c8caf0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 16 May 2003 09:05:03 -0400 To: Brian E Carpenter From: Margaret Wasserman In-Reply-To: <3EC4DE50.D04E601C@hursley.ibm.com> References: <200305131200.IAA05317@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: I-D ACTION:draft-ietf-problem-process-00.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 5/16/2003 +0200, Brian E Carpenter wrote: > > 2 IETF Core Values > >I'm surprised not to find self-governance listed as a core value. Explain to me what it is, and if there is agreement, I'll add it! >There is a strong implication here that ADs might do this for >spurious reasons. But if one or both Security ADs are deeply >convinced that a draft constitutes a major security risk, or one >or both Routing ADs are convinced that a draft will lead to routing >loops, isn't it quite appropriate for them to block the document? >Such cases suggest failures much earlier in the process, not >misbehaviour by the IESG. So I don't think we should fix this, >because it is actually a vital back-stop, not a bug. I agree. On the poised list, John Klensin suggested some IESG charter wording that does a much better job of explaining what should happen than I have. In particular, he suggested adding the following wording to the "AD review" process: "The responsible ADs are expected to complete this review on a timely basis and, if a significant review period is required, to make the reasons for the delay public on an ongoing basis. WGs or document authors or editors may appeal unreasonable delays to the IETF Chair and, if necessary, to the full IESG, as described in BCP 9 and may, on that basis, request that the document be assigned to a different (or additional) AD." This is really what I'm trying to say... The processes should be changed so that it isn't possible for a document to get _stuck_ in the IESG (either in AD review or IESG review) for a lengthy period without a response. The I-D tracker has helped, because WG chairs can now detect when this is happening and figure out who to ask... But, some things still linger. BTW, I think that the IESG should retain control of its own internal processes and consider changes to correct this, not that the IETF should impose processes on the IESG. > > > > - Updates to RFC 2418, the Nomcom processes and the IESG and > > IAB charters (as needed) to define a more scaleable and > > effective organizational structure for the IETF. > >I have some difficulty with this. It's inconceivable to me to make >changes to the IAB charter, or to create an IESG charter, without >the overwhelming support of the current IAB or IESG respectively. So >I don't agree that the proposed WG can be "empowered" for this. It could >be chartered to make concrete proposals to the IAB|IESG but the only >workable outcome is consensus between the WG and IAB|IESG. I agree, but others do not. This disagreement could not be resolved insider our own editorial team, which is why the current document contains two different choices for WG oversight. Once we choose one type of WG oversight to pursue (which I hope happens fairly soon), it will be easier to make the rest of this section clearer. > > - Updates to RFC 2026 and other published processes to build > > an effective multi-level standards-track and to reflect any > > new organizational roles. > >Please specifically exclude updates to IPR policy, since we have just >reached consensus over in IPRWG not to do this. This raises sort of an interesting larger question... We have current efforts underway regarding our IPR policy (ipr WG) and our Nomcom process (nomcom WG). To what extent should the agreements of those groups be binding on the outcome of this WG? How would conflicts between the outcomes of those WGs and the recommendations of the improve WG be handled? >A very important step is missing here. All IETF process documents need >to be formally accepted by the ISOC Board, to ensure that we have the >necessary chain of authority to validate the liability insurance. Is this documented somewhere? If so, let me know and I will refer to it. If not, can you explain in more detail how this works and when the ISOC board enters the process, etc. Thanks, Margaret From problem-statement-bounces@alvestrand.no Fri May 16 09: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 JAA22545 for ; Fri, 16 May 2003 09:19:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3689862572; Fri, 16 May 2003 15:22:13 +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 A10D56233E for ; Fri, 16 May 2003 15:22:09 +0200 (CEST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) h4GDM5Um112790 for ; Fri, 16 May 2003 15:22:05 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4GDM3Ew040314 for ; Fri, 16 May 2003 15:22:04 +0200 Received: from dhcp22-123.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA19594 from ; Fri, 16 May 2003 15:22:01 +0200 Message-Id: <3EC4E617.90E18A01@hursley.ibm.com> Date: Fri, 16 May 2003 15:22:31 +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: <5.1.0.14.2.20030515113529.014ba800@mail.windriver.com> <014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Firstly, yes it's a problem. Secondly, this is a case where I think a simple first step may help quite a bit: simply merge Draft Standard and Standard into a single class, called Standard, but with the criteria now used for Draft Standard. Arguments: remove a process step that we basically never use, and make the step up from Proposed Standard worth the trouble. On James' point about Internet Drafts, maybe we could use a little clarification in the WG procedures, but the main point is to require a WG consensus before declaring a draft to be a WG draft. If that hasn't been happening, it's more of a WG Chair training issue than anything else. Brian James Kempf wrote: > > Margaret, > > I've felt for some time that there is a need for a change in this > area, but this analysis leaves out the issue of Working Group drafts, > which I think is a critical component. Right now, they have grey area > status. I've seen drafts move from individual contribution to Working > Group status only because nobody on the mailing list spoke up when the > Working Group chair put out the question about whether a draft should > move to Working Group status or not. Many vendors start implementing > when something becomes a Working Group draft, since realistically, > they view that move as entry into the standardization process, > regardless of what IETF's process RFCs say about it. > > Arguments have been made on this list that we should not touch the > current Proposed/Draft distinction, and I agree that the distinction > is useful even if Proposed is treated as "standard" by vendors for all > practical purposes (Full Standard, however, is largely useless except > as a historical distinction). However, I think some attention is > needed to how a draft becomes a Working Group draft. Perhaps that move > is when a preliminary review is made on the design, so that movement > to Working Group draft status does not happen for reasons that have > nothing to do with the technical aspects of the design. > > jak > > ----- Original Message ----- > From: "Margaret Wasserman" > To: > Sent: Thursday, May 15, 2003 8:41 AM > Subject: OPEN ISSUE: Standards Track > > > > > The process document current says: > > > > >There is also a more fundamental issue with the IETF's engineering > > >practices. Although our current standards track contains three > > >levels of maturity (Proposed Standard, Draft Standard and Full > > >Standard), we do not have sufficient differentiation regarding the > > >quality and completeness of documents required at each stage. The > > >bar is set very high for publication at Proposed Standard, and very > > >few documents advance beyond this stage. [OPEN ISSUE: Do we have > > >IETF consensus that this is a problem?] > > > > I believe that this is a real issue, and that we need to make > > some changes to our standards-track document processes to > > address this. > > > > In particular, I think that we have inadvertently reached a > > point where our proposed standards are treated as standards > > by most of the industry. I think that this was caused, in > > part, by the high level of scrutiny that we place on documents > > before we allowing them to reach this level. This also leads > > to a lack of motivation to move documents to draft standard, > > where there interoperability will be demonstrated. > > > > In general, I think that this damages the quality and > > integrity of the IETF standards-track documents, and we > > should do something to fix it. > > > > Margaret > > > > > > > > > > > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From problem-statement-bounces@alvestrand.no Fri May 16 09:27: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 JAA23032 for ; Fri, 16 May 2003 09:27:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CF9A46256B; Fri, 16 May 2003 15:30:31 +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 81DDD6233E for ; Fri, 16 May 2003 15:30:24 +0200 (CEST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])h4GDUND23650 for ; Fri, 16 May 2003 16:30:23 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com ; Fri, 16 May 2003 16:30:21 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 16 May 2003 16:30:21 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 16 May 2003 16:30: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: Fri, 16 May 2003 16:30:20 +0300 Message-ID: Thread-Topic: OPEN ISSUE: Nomcom Process Thread-Index: AcMbqxKL82Q1dB5nQqWeiPZQIRbpEAABBvFg From: To: , X-OriginalArrivalTime: 16 May 2003 13:30:21.0536 (UTC) FILETIME=[4CA11E00:01C31BAF] Cc: mrw@windriver.com Cc: problem-statement@alvestrand.no Subject: RE: OPEN ISSUE: Nomcom 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA23032 Hi Brian, > I would add that this was discussed *extensively* in the > current nomcom WG and there was no consensus to publish > the names. > > I would suggest that it would be ironic if the problem-statement > WG were to commit the sin of re-discussing a solution that another > WG has recently discussed and abandoned. Then maybe the document should just say this was discuss under nomcom WG and no consensus was reached (i.e. - it is not part of this WG's charter). John From problem-statement-bounces@alvestrand.no Fri May 16 09:32: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 JAA23485 for ; Fri, 16 May 2003 09:32:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A6C76256B; Fri, 16 May 2003 15:34:41 +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 0BF5F6256B for ; Fri, 16 May 2003 15:34:33 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.5]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA28507; Fri, 16 May 2003 06:34:22 -0700 (PDT) Message-Id: <5.1.0.14.2.20030516092556.03b67930@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 16 May 2003 09:30:29 -0400 To: Brian E Carpenter From: Margaret Wasserman In-Reply-To: <3EC4E617.90E18A01@hursley.ibm.com> References: <5.1.0.14.2.20030515113529.014ba800@mail.windriver.com> <014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 03:22 PM 5/16/2003 +0200, Brian E Carpenter wrote: >On James' point about Internet Drafts, maybe we could use a >little clarification in the WG procedures, but the main point >is to require a WG consensus before declaring a draft to be >a WG draft. If that hasn't been happening, it's more of a WG >Chair training issue than anything else. I've included this in recent WG chair training sessions (since I started doing them in Atlanta). I've also included information about the WG chairs' responsibility to choose and manage document editors. It takes a while though, for this type of change to propagate throughout the organization, and there are still many WGs where there are no acceptance criteria applied before documents are given WG draft status. Margaret From problem-statement-bounces@alvestrand.no Fri May 16 09:33: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 JAA23632 for ; Fri, 16 May 2003 09:33:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 91D986256B; Fri, 16 May 2003 15:36:23 +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 578866233E for ; Fri, 16 May 2003 15:36:20 +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 h4GDaGJh011590; Fri, 16 May 2003 09:36:17 -0400 (EDT) Received: from rdroms-w2k.cisco.com ([161.44.65.206]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id JAA26834; Fri, 16 May 2003 09:36:16 -0400 (EDT) Message-Id: <4.3.2.7.2.20030516093047.01b16530@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 May 2003 09:31:43 -0400 To: Margaret Wasserman From: Ralph Droms In-Reply-To: <3EC3EF99.9050709@piuha.net> References: <5.1.0.14.2.20030515113529.014ba800@mail.windriver.com> <5.1.0.14.2.20030515113529.014ba800@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 this issue is a problem. - Ralph At 10:50 PM 5/15/2003 +0300, Jari Arkko wrote: >Margaret Wasserman wrote: >>The process document current says: >> >>>There is also a more fundamental issue with the IETF's engineering >>>practices. Although our current standards track contains three >>>levels of maturity (Proposed Standard, Draft Standard and Full >>>Standard), we do not have sufficient differentiation regarding the >>>quality and completeness of documents required at each stage. The >>>bar is set very high for publication at Proposed Standard, and very >>>few documents advance beyond this stage. [OPEN ISSUE: Do we have >>>IETF consensus that this is a problem?] > >It is a problem. > >--Jari > > > From problem-statement-bounces@alvestrand.no Fri May 16 09: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 JAA24432 for ; Fri, 16 May 2003 09:45:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 98F986259C; Fri, 16 May 2003 15:48:28 +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 C733E6233E for ; Fri, 16 May 2003 15:48:26 +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 19GfZN-0002En-00; Fri, 16 May 2003 06:48:21 -0700 Date: Fri, 16 May 2003 09:47:33 -0400 From: Keith Moore To: Margaret Wasserman Message-Id: <20030516094733.0369a1a6.moore@cs.utk.edu> In-Reply-To: <5.1.0.14.2.20030515113529.014ba800@mail.windriver.com> References: <5.1.0.14.2.20030515113529.014ba800@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: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 Thu, 15 May 2003 11:41:27 -0400 Margaret Wasserman wrote: > > The process document current says: > > >There is also a more fundamental issue with the IETF's engineering > >practices. Although our current standards track contains three > >levels of maturity (Proposed Standard, Draft Standard and Full > >Standard), we do not have sufficient differentiation regarding the > >quality and completeness of documents required at each stage. The > >bar is set very high for publication at Proposed Standard, and very > >few documents advance beyond this stage. [OPEN ISSUE: Do we have > >IETF consensus that this is a problem?] > > I believe that this is a real issue, and that we need to make > some changes to our standards-track document processes to > address this. I think there are multiple issues here: 1. insufficient differentiation of quality between the stages 2. we don't consider Proposed "done" (officially it's not even deemed ready for wide deployment), yet the industry does consider proposed "done" unless serious bugs are found. > In particular, I think that we have inadvertently reached a > point where our proposed standards are treated as standards > by most of the industry. I think that this was caused, in > part, by the high level of scrutiny that we place on documents > before we allowing them to reach this level. I think this is caused by multiple factors: - Proposed is the first stable publication of a standards-track document, in the sense that the RFC won't expire and it won't be changed. (Maybe implementors just want a stable, referencable spec before deployment, and they don't care so much about IETF's blessing.) - The word "standard" appears in the document status. - By the time a document is published as Proposed, the working group is typically burned out, and there's insufficient energy to revise the document further. Getting a document moved to Draft Standard is extremely difficult not because the changes are extensive (usually they're fairly trivial) but because it requires a lot of attention to detail, and coordination between lots of people for interoperability reports, for what is seen as minimal gain. (and Draft Standard actually sounds less mature than Proposed Standard) If I'm reading this right, then this means we have a conflict: On one hand we'd like to have a lower bar for initial publication than what is currently deemed Proposed Standard, so that we provide some incentive, some indication of externally-recognizable progress, and can get wider review of a document (perhaps even implementation) before we get to the level that the industry recognizes as ready for shipping in product. Oh the other hand if what the industry is really waiting for is a stable, referencable spec, then publishing RFCs with less scrutiny than is currently required for Proposed means that quality of deployed protocols could decrease. And if the process of moving from the earlier stage to one which has a similar level of scrutiny to what is currently Proposed ends up being as difficult as moving a Proposed document to Draft, we may find that in the future we rarely get as far as (what used to be called) Proposed. From problem-statement-bounces@alvestrand.no Fri May 16 10:30: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 KAA27356 for ; Fri, 16 May 2003 10:30:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B75886256B; Fri, 16 May 2003 16:32:41 +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 E6F166233E for ; Fri, 16 May 2003 16:32:33 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.5]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA25559; Fri, 16 May 2003 07:32:22 -0700 (PDT) Message-Id: <5.1.0.14.2.20030516100823.014d0568@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 16 May 2003 10:28:15 -0400 To: Brian E Carpenter From: Margaret Wasserman In-Reply-To: <3EC4E0DB.AA829841@hursley.ibm.com> References: <013b01c31b02$0d7baf40$176015ac@DCLKEMPFTP> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Nomcom 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 Brian, At 03:00 PM 5/16/2003 +0200, Brian E Carpenter wrote: >I would add that this was discussed *extensively* in the >current nomcom WG and there was no consensus to publish >the names. > >I would suggest that it would be ironic if the problem-statement >WG were to commit the sin of re-discussing a solution that another >WG has recently discussed and abandoned. I think that ironic is too mild... perhaps "counter-productive"? However, there are many ways to increase community input and visibility into the process without publishing the names of all of the candidates... For instance, the criteria that will be used to select candidates could be published and reviewed by the community. Or, the final slates could be published for community comment before being approved. I don't know whether the nomcom WG has considered these alternatives. The real question is whether we think that there is a problem here that needs to be solved. On the problem list, people identified three problems with the nomcom: - The process is too closed and/or does not include enough input from non-leaders within the community. - The nomcom shouldn't include IESG/IAB liaisons, as this gives the IESG/IAB too much influence on the selection process. - The number of qualified people willing to serve on the IESG is too small -- perhaps due to the level of commitment required? Since we have a WG currently evaluating the Nomcom process, do you think that the people who raised these issues should just take them to that WG? Margaret From problem-statement-bounces@alvestrand.no Fri May 16 10:42: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 KAA27827 for ; Fri, 16 May 2003 10:42:34 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A95EA62581; Fri, 16 May 2003 16:45:07 +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 7848B6233E for ; Fri, 16 May 2003 16:44:59 +0200 (CEST) Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4609120 for problem-statement@alvestrand.no; Fri, 16 May 2003 10:44:58 -0400 Message-Id: <5.1.0.14.0.20030516103921.0188a7c8@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 16 May 2003 10:44:56 -0400 To: problem-statement@alvestrand.no From: "Joel M. Halpern" In-Reply-To: <3EC4E263.7E39555D@hursley.ibm.com> References: <5.1.0.14.2.20030515114433.04767ac8@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: OPEN ISSUE: 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 There are actually two very different cases. For simplicity, let me discuss them both in terms of an existing working group (both cases exist for new working groups, but there are other issues that cloud things.) One case is where you have a chair who for one or another reason has chosen to step down. You are going to have to find a new chair. Announcing the opening would not in and of itself cause a problem. The other case is where the AD wants / needs to replace the chair when the chair would not on his own step down. (Presume the AD has already discussed the causes with the current chair, but probably not the intended action.) The AD probably does not want to force the issue until there is a good replacement chair available. As such, making a public announcement would be "interesting". And of course, having two different procedures would mean that one was publicising which case actually applied... We can make personnel management harder if we want, but is that really a good idea? Note that having said all that, it would be really good to have better mechanisms for finding chairs, and for finding new blood to serve as chairs. Appointing chairs was the part of the AD job I hated when I was doing that. I just think it is more complex than the exchange below suggests. Yours, Joel At 03:06 PM 5/16/2003 +0200, Brian E Carpenter wrote: >Margaret Wasserman wrote: > > > > Currently, the process document says: > > > > >We may also want to reconsider the process that is used to select > > >WG chairs. In particular, ADs could be encouraged to announce WG > > >chair openings within their areas and/or to identify and develop > > >more potential leaders. [OPEN ISSUE: Is there IETF consensus that > > >we have a problem in this area?] > > > > I don't think that we should change our official procedures > > in this area. > > > > I do think it would be good if ADs would communicate open WG > > chairs slots to the community and request input regarding > > potential candidates. > > > > However, it is important for ADs and WG chairs to have a good > > relationship, and for the AD to have authority over the WG > > chair. I believe that the current reporting relationship > > (AD chooses WG chair, chair serves at ADs pleasure) is > > appropriate. > >Agreed > > Brian From problem-statement-bounces@alvestrand.no Fri May 16 10:54: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 KAA28047 for ; Fri, 16 May 2003 10:54:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 587A76256B; Fri, 16 May 2003 16:56:56 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from one.elistx.com (one.elistx.com [209.116.252.130]) by eikenes.alvestrand.no (Postfix) with ESMTP id 872EB6233E for ; Fri, 16 May 2003 16:56:48 +0200 (CEST) Received: from localhost (one.elistx.com [209.116.252.130]) <0HEZ005J6IVIDE@eListX.com> for problem-statement@alvestrand.no; Fri, 16 May 2003 10:57:18 -0400 (EDT) Date: Fri, 16 May 2003 10:56:59 -0400 (Eastern Daylight Time) From: James M Galvin In-reply-to: <5.1.0.14.2.20030516100823.014d0568@mail.windriver.com> To: Margaret Wasserman Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <013b01c31b02$0d7baf40$176015ac@DCLKEMPFTP> <5.1.0.14.2.20030516100823.014d0568@mail.windriver.com> Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Nomcom 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, 16 May 2003, Margaret Wasserman wrote: The real question is whether we think that there is a problem here that needs to be solved. On the problem list, people identified three problems with the nomcom: - The process is too closed I know we're not supposed to talk about solutions but during this iteration of the NOMCOM document it was decided to spell out the responsibilitites of all the parties in the process. Of interest here is the liaisons and the past Chair, who's responsibilities include watching over the process and reporting anomalies. No, it does not "open" up the process but it does ensure the internal, normally confidential workings of the NOMCOM have some review. We even added a dispute resolution process for addressing any issues that may arise. and/or does not include enough input from non-leaders within the community. I'm having trouble believing this is really a problem. While it is true the actual discussions of the NOMCOM are confidential, recent NOMCOMs in particular have worked very hard to get community input. There are multiple paths for getting input into the NOMCOM -- email to committee email address or to individual members via email or directly (they wear orange dots at IETF meetings) -- and the NOMCOM solicits for input in multiple ways (multiple requests to ietf, ietf-announce, and wgchairs). There's also the fact that the NOMCOM operates at a "regular time." If you are part of the community you know this and when it's time it is not that difficult to get input into the process. - The nomcom shouldn't include IESG/IAB liaisons, as this gives the IESG/IAB too much influence on the selection process. This is a management problem inside the NOMCOM. Certainly a liaison could dominate a discussion but (again with the solutions, I apologize) hopefully setting responsibilities for the players and creating a process for resolving disputes will improve the latter part of the issue. - The number of qualified people willing to serve on the IESG is too small -- perhaps due to the level of commitment required? This is not a NOMCOM process issue, per se, but I agree it is an IETF issue. In my opinion it is not an issue for the NOMCOM working group to address. Since we have a WG currently evaluating the Nomcom process, do you think that the people who raised these issues should just take them to that WG? I believe the NOMCOM working group has addressed the first two issues you suggested in this iteration. Personally, I do not believe the last issue is a NOMCOM working group issue but I agree it is a problem to be addressed by some working group. Jim From problem-statement-bounces@alvestrand.no Fri May 16 10: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 KAA28168 for ; Fri, 16 May 2003 10:59:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8760962581; Fri, 16 May 2003 17:01:51 +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 76E5B6233E for ; Fri, 16 May 2003 17:01:48 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.5]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA10634; Fri, 16 May 2003 08:01:37 -0700 (PDT) Message-Id: <5.1.0.14.2.20030516104735.038bd7f0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 16 May 2003 10:57:43 -0400 To: "Joel M. Halpern" From: Margaret Wasserman In-Reply-To: <5.1.0.14.0.20030516103921.0188a7c8@mail.stevecrocker.com> References: <3EC4E263.7E39555D@hursley.ibm.com> <5.1.0.14.2.20030515114433.04767ac8@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: 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 10:44 AM 5/16/2003 -0400, Joel M. Halpern wrote: >The other case is where the AD wants / needs to replace the chair when the >chair would not on his own step down. (Presume the AD has already >discussed the causes with the current chair, but probably not the intended >action.) The AD probably does not want to force the issue until there is >a good replacement chair available. As such, making a public announcement >would be "interesting". This _would_ be difficult in the case where there is only one chair. If there are co-chairs, though, it might be okay to announce that one chair is leaving, and then open that slot for replacement. It also might be possible to keep a pool of willing victims^H^H^H :-) folks who are willing to be considered for WG chair slots within an area. There is also the possibility of bringing in a co-chair and then retiring a non-performing single chair, but that could be painful. >We can make personnel management harder if we want, but is that really a >good idea? Yes. I think that we should be willing to make some extra effort to expand our leadership pool and make our selection processes fairer and more inclusive. Anti-discrimination and work-for-hire laws also make personnel management harder in the corporate sector, but they are worth it. It is a lot easier to just give the leadership positions to our friends and the members of our existing "trust network", but that practice limits the pool of leaders and is known to be discriminatory (people tend to be friends with other people who are like themselves -- cultural background, age preferred language, gender, interests, etc.). I have hired over 150 people into various companies throughout my career. It _is_ much more complicated than this exchange indicates. And, doing it in a way that is fair and non- discriminatory is even harder. But, the results are worth it. Margaret From problem-statement-bounces@alvestrand.no Fri May 16 11:03: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 LAA28314 for ; Fri, 16 May 2003 11:03:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 866106256B; Fri, 16 May 2003 17:05:36 +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 521656233E for ; Fri, 16 May 2003 17:05:16 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.5]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA12612; Fri, 16 May 2003 08:05:06 -0700 (PDT) Message-Id: <5.1.0.14.2.20030516105820.03b69e90@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 16 May 2003 11:01:07 -0400 To: James M Galvin From: Margaret Wasserman In-Reply-To: References: <5.1.0.14.2.20030516100823.014d0568@mail.windriver.com> <013b01c31b02$0d7baf40$176015ac@DCLKEMPFTP> <5.1.0.14.2.20030516100823.014d0568@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Nomcom 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 10:56 AM 5/16/2003 -0400, James M Galvin wrote: >Of interest here >is the liaisons and the past Chair, who's responsibilities include >watching over the process and reporting anomalies. Sounds good. To whom do they report the anomalies? >We even added a dispute resolution process for addressing any issues >that may arise. Good! It sounds like you guys are doing good work over there. BTW, the issues I listed are not all my personal issues. They are things that were raised on the list. For instance, I personally think that the nomcom *should* have liaisons from the IESG and IAB. Margaret From problem-statement-bounces@alvestrand.no Fri May 16 11:04: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 LAA28362 for ; Fri, 16 May 2003 11:04:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 688BC6256B; Fri, 16 May 2003 17:07:00 +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 C257B6233E for ; Fri, 16 May 2003 17:06:56 +0200 (CEST) Message-ID: <008401c31bbc$9553e210$176015ac@DCLKEMPFTP> From: "James Kempf" To: , "Margaret Wasserman" References: <014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> <5.1.0.14.2.20030515113529.014ba800@mail.windriver.com> <014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> <5.1.0.14.2.20030516050623.038bd7f0@mail.windriver.com> Date: Fri, 16 May 2003 08:05:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 example, I think that it should be possible for several different > proposals that solve the same problem to be published in an enduring > form by the IETF, and for a subsequent process to determine which > one(s) will advance on the standards-track. This would solve some > of the problems that we have in the v6ops WG, for example. But, we > have no tools to do this in a way that makes the status of these > documents visible to our "customers". > My understanding is that that is one purpose of the Experimental designation. jak From problem-statement-bounces@alvestrand.no Fri May 16 11:07: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 LAA28455 for ; Fri, 16 May 2003 11:07:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 769026259C; Fri, 16 May 2003 17:09:32 +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 E3F5B6256B for ; Fri, 16 May 2003 17:09:28 +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 h4GF9PkL023288; Fri, 16 May 2003 11:09:25 -0400 (EDT) Message-Id: <200305161509.h4GF9PkL023288@rtp-core-1.cisco.com> To: Brian E Carpenter In-reply-to: Your message of Fri, 16 May 2003 14:49:20 +0200. <3EC4DE50.D04E601C@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, 16 May 2003 11:09:25 -0400 From: Eric Rosen Cc: problem-statement@alvestrand.no Subject: Re: I-D ACTION:draft-ietf-problem-process-00.txt 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 > 5.1 Near-Term Improvements ... > 5. Modify IESG-internal processes to make it impossible for one > or two IESG members to block a document. Brian> There is a strong implication here that ADs might do this for Brian> spurious reasons. Well, yes, that's the "problem". Brian> But if one or both Security ADs are deeply Brian> convinced that a draft constitutes a major security risk, or one Brian> or both Routing ADs are convinced that a draft will lead to routing Brian> loops, isn't it quite appropriate for them to block the document? Brian> Such cases suggest failures much earlier in the process, not Brian> misbehaviour by the IESG. So I don't think we should fix this, Brian> because it is actually a vital back-stop, not a bug. You can't remove a problem by declaring it not to be a problem; that's called a "whitewash". And the fact that the ADs sometimes act properly doesn't mean that they don't sometimes act improperly. The problem is that there is no effective and open process by which such decisions can be reviewed and evaluated to determine whether they are proper or improper. From problem-statement-bounces@alvestrand.no Fri May 16 11: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 LAA28523 for ; Fri, 16 May 2003 11:08:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 21F776256B; Fri, 16 May 2003 17:11:30 +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 E8C716233E for ; Fri, 16 May 2003 17:11:27 +0200 (CEST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) h4GFBQDI022120 for ; Fri, 16 May 2003 17:11:26 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4GFBQaY245880 for ; Fri, 16 May 2003 17:11:26 +0200 Received: from dhcp22-123.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA54520 from ; Fri, 16 May 2003 17:11:24 +0200 Message-Id: <3EC4FFBA.5FB56D69@hursley.ibm.com> Date: Fri, 16 May 2003 17:11:54 +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: <5.1.0.14.2.20030516100823.014d0568@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: OPEN ISSUE: Nomcom 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 Margaret Wasserman wrote: > > Hi Brian, > > At 03:00 PM 5/16/2003 +0200, Brian E Carpenter wrote: > >I would add that this was discussed *extensively* in the > >current nomcom WG and there was no consensus to publish > >the names. > > > >I would suggest that it would be ironic if the problem-statement > >WG were to commit the sin of re-discussing a solution that another > >WG has recently discussed and abandoned. > > I think that ironic is too mild... perhaps "counter-productive"? > > However, there are many ways to increase community input and > visibility into the process without publishing the names of all > of the candidates... For instance, the criteria that will be > used to select candidates could be published and reviewed by > the community. Or, the final slates could be published for > community comment before being approved. I don't know whether > the nomcom WG has considered these alternatives. > > The real question is whether we think that there is a problem > here that needs to be solved. On the problem list, people > identified three problems with the nomcom: > > - The process is too closed and/or does not include > enough input from non-leaders within the > community. > - The nomcom shouldn't include IESG/IAB liaisons, as > this gives the IESG/IAB too much influence on > the selection process. > - The number of qualified people willing to serve on > the IESG is too small -- perhaps due to the > level of commitment required? > > Since we have a WG currently evaluating the Nomcom process, do > you think that the people who raised these issues should just > take them to that WG? Without checking the archive, I can't be sure, but I suspect all of these points have been made on the ietf-nomcom list already. But Avri is better placed to comment on this. Brian From problem-statement-bounces@alvestrand.no Fri May 16 11:10: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 LAA28561 for ; Fri, 16 May 2003 11:10:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D63436233E; Fri, 16 May 2003 17:12:57 +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 674D861BA7 for ; Fri, 16 May 2003 17:12: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 h4GFCpkL024356; Fri, 16 May 2003 11:12:51 -0400 (EDT) Message-Id: <200305161512.h4GFCpkL024356@rtp-core-1.cisco.com> To: Brian E Carpenter In-reply-to: Your message of Fri, 16 May 2003 15:22:31 +0200. <3EC4E617.90E18A01@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, 16 May 2003 11:12:51 -0400 From: Eric Rosen Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Standards Track 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 Brian> Secondly, this is a case where I think a simple first step may Brian> help quite a bit: simply merge Draft Standard and Standard Brian> into a single class, called Standard, but with the criteria Brian> now used for Draft Standard. Brian> Arguments: remove a process step that we basically never use, Brian> and make the step up from Proposed Standard worth the trouble. Could you explain how this makes the step up from PS worth the trouble? From problem-statement-bounces@alvestrand.no Fri May 16 11:16: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 LAA28726 for ; Fri, 16 May 2003 11:16:14 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C7111625B5; Fri, 16 May 2003 17:18:39 +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 7D8006233E for ; Fri, 16 May 2003 17:18:36 +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 h4GFIZH3022961; Fri, 16 May 2003 11:18:35 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h4GFIZf9022960; Fri, 16 May 2003 11:18:35 -0400 (EDT) Date: Fri, 16 May 2003 11:18:35 -0400 (EDT) From: Scott Bradner Message-Id: <200305161518.h4GFIZf9022960@newdev.harvard.edu> To: brian@hursley.ibm.com, mrw@windriver.com In-Reply-To: <5.1.0.14.2.20030516100823.014d0568@mail.windriver.com> Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Nomcom 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 > Since we have a WG currently evaluating the Nomcom process, do > you think that the people who raised these issues should just > take them to that WG? yes From problem-statement-bounces@alvestrand.no Fri May 16 11:19: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 LAA28876 for ; Fri, 16 May 2003 11:19:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F22F6625C3; Fri, 16 May 2003 17:22:26 +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 709E9625C3 for ; Fri, 16 May 2003 17:22: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 IAA46568 for ; Fri, 16 May 2003 08:22:07 -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 t6C0PBI2 Fri, 16 May 2003 08:22:07 -0700 (PDT) Message-ID: <092701c31bbe$eb2284b0$0300a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <200305131200.IAA05317@ietf.org> <5.1.0.14.2.20030516090020.03c8caf0@mail.windriver.com> Date: Fri, 16 May 2003 10:22:09 -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: I-D ACTION:draft-ietf-problem-process-00.txt 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 Margaret, Actually, I thought the NEXT working group was supposed to do the Real Core Values, and the list in this draft were a placeholder from Harald's presentations on the subject. Was this not the plan? I'm still trying to figure out what "cares for the Internet" means in concrete terms, right? If we ARE going to have a "Real Core Values" section in the current draft, we sure haven't had much input on the subject yet... Spencer ----- Original Message ----- From: "Margaret Wasserman" To: "Brian E Carpenter" Cc: Sent: Friday, May 16, 2003 8:05 AM Subject: Re: I-D ACTION:draft-ietf-problem-process-00.txt > > Hi Brian, > > At 02:49 PM 5/16/2003 +0200, Brian E Carpenter wrote: > > > 2 IETF Core Values > > > >I'm surprised not to find self-governance listed as a core value. > > Explain to me what it is, and if there is agreement, I'll add > it! From problem-statement-bounces@alvestrand.no Fri May 16 11: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 LAA28893 for ; Fri, 16 May 2003 11:20:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CB4846257B; Fri, 16 May 2003 17:22:34 +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 660FA62589 for ; Fri, 16 May 2003 17:22:23 +0200 (CEST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) h4GFMMUm092502 for ; Fri, 16 May 2003 17:22:22 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4GFMJaY279884 for ; Fri, 16 May 2003 17:22:20 +0200 Received: from dhcp22-123.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA61294 from ; Fri, 16 May 2003 17:22:16 +0200 Message-Id: <3EC50246.8B40E893@hursley.ibm.com> Date: Fri, 16 May 2003 17:22:46 +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: <200305131200.IAA05317@ietf.org> <5.1.0.14.2.20030516090020.03c8caf0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Self-governance [Re: I-D ACTION:draft-ietf-problem-process-00.txt] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 Wasserman wrote: > > Hi Brian, > > At 02:49 PM 5/16/2003 +0200, Brian E Carpenter wrote: > > > 2 IETF Core Values > > > >I'm surprised not to find self-governance listed as a core value. > > Explain to me what it is, and if there is agreement, I'll add > it! Self-governance The IETF is not controlled by a higher authority. The community, i.e. the group of engineers actively participating as individuals, appoints the Chair and the main committees (currently the IESG and IAB) by a process agreed by the community itself. Although the lack of a formal membership structure means that this process cannot be based on formal voting, it is designed to be as open and democratic as reasoanbly possible. It includes appropriate checks and balances against abuse of power within the IETF. Brian From problem-statement-bounces@alvestrand.no Fri May 16 11:24: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 LAA29004 for ; Fri, 16 May 2003 11:24:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7E5A1625C3; Fri, 16 May 2003 17:26:39 +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 5186A6257B for ; Fri, 16 May 2003 17:26:37 +0200 (CEST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) h4GFQaUm076182 for ; Fri, 16 May 2003 17:26:36 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4GFQZEw062176 for ; Fri, 16 May 2003 17:26:36 +0200 Received: from dhcp22-123.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA30510 from ; Fri, 16 May 2003 17:26:34 +0200 Message-Id: <3EC50348.17CE55A0@hursley.ibm.com> Date: Fri, 16 May 2003 17:27: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: <200305131200.IAA05317@ietf.org> <5.1.0.14.2.20030516090020.03c8caf0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: sort of an interesting larger question [Re: I-D ACTION:draft-ietf-problem-process-00.txt] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 Wasserman wrote: ... > This raises sort of an interesting larger question... We have current > efforts underway regarding our IPR policy (ipr WG) and our Nomcom > process (nomcom WG). To what extent should the agreements of those > groups be binding on the outcome of this WG? How would conflicts > between the outcomes of those WGs and the recommendations of the > improve WG be handled? I think improve should be excluded by charter from changing the IPR and Nomcom results for some period of time (at least a year). It would be foolish to have spent a lot of effort on those two topics and then not even take the time needed to see if the next documents actually fix the known problems in the old ones. Brian From problem-statement-bounces@alvestrand.no Fri May 16 11:24: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 LAA29043 for ; Fri, 16 May 2003 11:24:21 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E33A0625D2; Fri, 16 May 2003 17:26:52 +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 7931F625CE for ; Fri, 16 May 2003 17:26:42 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.5]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA25151; Fri, 16 May 2003 08:26:33 -0700 (PDT) Message-Id: <5.1.0.14.2.20030516112039.03c8caf0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 16 May 2003 11:22:39 -0400 To: Spencer Dawkins From: Margaret Wasserman In-Reply-To: <092701c31bbe$eb2284b0$0300a8c0@DFNJGL21> References: <200305131200.IAA05317@ietf.org> <5.1.0.14.2.20030516090020.03c8caf0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: I-D ACTION:draft-ietf-problem-process-00.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 Spencer, At 10:22 AM 5/16/2003 -0500, Spencer Dawkins wrote: >Actually, I thought the NEXT working group was supposed to >do the Real Core Values, and the list in this draft were >a placeholder from Harald's presentations on the subject. > >Was this not the plan? Good point. I guess that the WG should decide what we want to do about this... >I'm still trying to figure out what "cares for the Internet" means >in concrete terms, right? Ask Harald? >If we ARE going to have a "Real Core Values" section in the >current draft, we sure haven't had much input on the subject >yet... Actually, we haven't had much input on the process parts of the document either. People barely responded to my earlier requests on the list and to my WG presentation. I am hoping we'll get more input on the process now that there is a strawman available, and (today, at least) that seems to be working. Margaret From problem-statement-bounces@alvestrand.no Fri May 16 11:25: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 LAA29116 for ; Fri, 16 May 2003 11:25:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 30339625C9; Fri, 16 May 2003 17:27: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 C331F625C9 for ; Fri, 16 May 2003 17:27:38 +0200 (CEST) Message-ID: <010401c31bbf$79975450$176015ac@DCLKEMPFTP> From: "James Kempf" To: "Brian E Carpenter" , References: <5.1.0.14.2.20030515113529.014ba800@mail.windriver.com><014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> <3EC4E617.90E18A01@hursley.ibm.com> Date: Fri, 16 May 2003 08:26:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > Firstly, yes it's a problem. > > Secondly, this is a case where I think a simple first step may > help quite a bit: simply merge Draft Standard and Standard > into a single class, called Standard, but with the criteria > now used for Draft Standard. > > Arguments: remove a process step that we basically never use, > and make the step up from Proposed Standard worth the trouble. > I agree that merging Draft Standard and Standard would simplify the process. The distinction between the new Standard and Proposed Standard would be the need for two interoperable implementations and give the opportunity to debug at Proposed. > On James' point about Internet Drafts, maybe we could use a > little clarification in the WG procedures, but the main point > is to require a WG consensus before declaring a draft to be > a WG draft. If that hasn't been happening, it's more of a WG > Chair training issue than anything else. > The point I was trying to make, which perhaps wasn't at all clear, was that this can be viewed in the same category as "earlier feedback is more helpful than later." It is perfectly possible for a draft to have WG concensus to become a WG draft and for it to contain fundamental architectural flaws that don't get worked out in subsequent discussion, until the draft ends up at the IESG and is rejected. By recognizing the step from individual contribution to WG draft more formally, and requiring some formal level of review rather than just that some group of people in the WG think it is OK and say so might help to catch those cases. The level of review should not be burdensome or as extensive as required for the draft to go to RFC, and could be entirely at the discretion of the shepherding AD and WG chair. Right now, the step from individual contribution to WG draft is left to the WG chair's discretion. jak From problem-statement-bounces@alvestrand.no Fri May 16 11:28: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 LAA29261 for ; Fri, 16 May 2003 11:28:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6F19E625CC; Fri, 16 May 2003 17:31:17 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from one.elistx.com (one.elistx.com [209.116.252.130]) by eikenes.alvestrand.no (Postfix) with ESMTP id D6F56625C6 for ; Fri, 16 May 2003 17:31:06 +0200 (CEST) Received: from localhost (one.elistx.com [209.116.252.130]) <0HEZ005NNKGNDD@eListX.com> for problem-statement@alvestrand.no; Fri, 16 May 2003 11:31:36 -0400 (EDT) Date: Fri, 16 May 2003 11:31:16 -0400 (Eastern Daylight Time) From: James M Galvin In-reply-to: <5.1.0.14.2.20030516105820.03b69e90@mail.windriver.com> To: Margaret Wasserman Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <5.1.0.14.2.20030516100823.014d0568@mail.windriver.com> <013b01c31b02$0d7baf40$176015ac@DCLKEMPFTP> <5.1.0.14.2.20030516100823.014d0568@mail.windriver.com> <5.1.0.14.2.20030516105820.03b69e90@mail.windriver.com> Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Nomcom 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, 16 May 2003, Margaret Wasserman wrote: At 10:56 AM 5/16/2003 -0400, James M Galvin wrote: >Of interest here >is the liaisons and the past Chair, who's responsibilities include >watching over the process and reporting anomalies. Sounds good. To whom do they report the anomalies? As with most things in the document, the liaison first reports the anomaly to the NOMCOM Chair. If it can not be successfully resolved between them, the liaison reports the alleged issue to the body they represent. If that body agrees there is an issue then the liaison reports it according to the dispute resolution process: 1. Written notice to ISOC President 2. Appointment of arbiter by ISOC President 3. Investigation by arbiter (considered in-the-fold of the NOMCOM and the confidentiality requirements so complete cooperation is expected) 4. Decision by arbiter - final, no appeal 5. Summary report that does not violate confidentiality is prepared by arbiter and included by NOMCOM Chair in their report when the NOMCOM job is completed. The NOMCOM continues its duties during all of this with one exception: it may not submit candidates to a confirming body. Jim From problem-statement-bounces@alvestrand.no Fri May 16 11: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 LAA29681 for ; Fri, 16 May 2003 11:34:42 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 322B8625D5; Fri, 16 May 2003 17:37: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 91C43625CC for ; Fri, 16 May 2003 17:37:07 +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 h4GFb2k07256; Fri, 16 May 2003 11:37:02 -0400 (EDT) Date: Fri, 16 May 2003 11:37:01 -0400 From: Keith Moore To: Margaret Wasserman Message-Id: <20030516113701.0708a278.moore@cs.utk.edu> In-Reply-To: <5.1.0.14.2.20030515114129.04754880@mail.windriver.com> References: <5.1.0.14.2.20030515114129.04754880@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: OPEN ISSUE: Nomcom 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 > >We may also need to modify our Nomcom processes so that IETF > >participants who are not part of the IETF leadership can have more > >visibility into the Nomcom process and more proportional input into > >leadership selection. [OPEN ISSUE: Do we have consensus that these > >are real problems that need to be solved?] > > I believe that this is a real problem, and that we should > modify our Nomcom processes to do two (related) things: > > - Give the community more visibility into the > process. > - Get more feedback on potential candidates from > the community. Currently, some candidates > are discussed with the leaders (IESG/IAB > members and WG chairs), but the greater > community doesn't even know who is being > considered. I think it's reasonable for nomcom to make public their selection criteria, and perhaps even to invite public comment on them, as long as it doesn't get to the point of discussing individual candidates (either by name or by being too specific). I am not sure whether it's reasonable for noncom to disclose the list of parties under consideration. On one hand it would invite wider public feedback about specific individuals, which would help avoid unpleasant surprises. On the other hand it would expose would-be candidates to potential "loss of face" at not being chosen - and invite comparison to those who were chosen - even if the reason for that particular choice turned out to be unrelated to the candidates' technical or personal qualifications. Keith From problem-statement-bounces@alvestrand.no Fri May 16 11:38: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 LAA29779 for ; Fri, 16 May 2003 11:38:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5E649625A8; Fri, 16 May 2003 17:40:58 +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 E2FF66256B for ; Fri, 16 May 2003 17:40:52 +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 h4GFemk07280; Fri, 16 May 2003 11:40:48 -0400 (EDT) Date: Fri, 16 May 2003 11:40:48 -0400 From: Keith Moore To: Margaret Wasserman Message-Id: <20030516114048.214d7b79.moore@cs.utk.edu> In-Reply-To: <5.1.0.14.2.20030515114433.04767ac8@mail.windriver.com> References: <5.1.0.14.2.20030515114433.04767ac8@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: OPEN ISSUE: 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 > >We may also want to reconsider the process that is used to select > >WG chairs. In particular, ADs could be encouraged to announce WG > >chair openings within their areas and/or to identify and develop > >more potential leaders. [OPEN ISSUE: Is there IETF consensus that > >we have a problem in this area?] I think we need to get rid of the widely-held assumptions that - the BOF chair will be a WG chair, and/or - WG chairs are chosen by the WG. also I personally found it very difficult to identify good candidates for WG chairs. having IESG explicitly invite nominations for WG chairs, and request recommendations about those nominiated, might help in both of these areas. but we wouldn't want a long drawn-out selection process. Keith From problem-statement-bounces@alvestrand.no Fri May 16 11:39: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 LAA29837 for ; Fri, 16 May 2003 11:39:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8ECEB625A8; Fri, 16 May 2003 17:41:52 +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 6B0BF6256B for ; Fri, 16 May 2003 17:41:48 +0200 (CEST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4GFfku9014762 for ; Fri, 16 May 2003 17:41:46 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4GFfkEw079480 for ; Fri, 16 May 2003 17:41:46 +0200 Received: from dhcp22-123.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA30568 from ; Fri, 16 May 2003 17:41:42 +0200 Message-Id: <3EC506D4.68BF04E9@hursley.ibm.com> Date: Fri, 16 May 2003 17:42:12 +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: <200305131200.IAA05317@ietf.org> <5.1.0.14.2.20030516090020.03c8caf0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: ISOC Board [Re: I-D ACTION:draft-ietf-problem-process-00.txt] X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 Wasserman wrote: ... > >A very important step is missing here. All IETF process documents need > >to be formally accepted by the ISOC Board, to ensure that we have the > >necessary chain of authority to validate the liability insurance. > > Is this documented somewhere? If so, let me know and I will refer > to it. If not, can you explain in more detail how this works and > when the ISOC board enters the process, etc. I don't think it is documented. In the past, the ISOC VP Standards has simply forwarded the RFCs concerned to to the ISOC Board and requested that they be accepted, resulting in a Board resolution such as > Resolution 96-11. Adoption of POISED Documents > > RESOLVED, that the Board accept the POISED Documents: The Organisations Involved in the IETF Standards Process, IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees, and The Internet Standards Process -- Revision 3, and accept the responsibilities of ISOC as described in these documents. I think it would be good to document the fact this should be done, for any process document that might affect the chain of responsibility for liability insurance purposes. Brian From problem-statement-bounces@alvestrand.no Fri May 16 11:40: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 LAA29882 for ; Fri, 16 May 2003 11:40:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EE35E625A8; Fri, 16 May 2003 17:42:53 +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 938F06256B for ; Fri, 16 May 2003 17:42:50 +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 h4GFgkk08292; Fri, 16 May 2003 11:42:46 -0400 (EDT) Date: Fri, 16 May 2003 11:42:46 -0400 From: Keith Moore To: Margaret Wasserman Message-Id: <20030516114246.0fad5f52.moore@cs.utk.edu> In-Reply-To: <5.1.0.14.2.20030515114755.014cedb8@mail.windriver.com> References: <5.1.0.14.2.20030515114755.014cedb8@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: OPEN ISSUE: Quality Process WG Charter X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 the process document says: > > >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: > > > [OPEN ISSUE: Should the Problem Statement WG propose a charter > > for this group, or leave that to the General AD and selected > > chair(s)?] > I don't think this group should propose a charter for that group. And I'm not sure I even agree with the text in the process document about how that group should proceed. From problem-statement-bounces@alvestrand.no Fri May 16 11:41: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 LAA29930 for ; Fri, 16 May 2003 11:41:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BB3F7625A8; Fri, 16 May 2003 17:43: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 0374C6256B for ; Fri, 16 May 2003 17:43:44 +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 IAA53599 for ; Fri, 16 May 2003 08:43:42 -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 8wD0e0K2 Fri, 16 May 2003 08:43:42 -0700 (PDT) Message-ID: <092e01c31bc1$ef14ed30$0300a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <5.1.0.14.2.20030515113529.014ba800@mail.windriver.com><014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> <3EC4E617.90E18A01@hursley.ibm.com> Date: Fri, 16 May 2003 10:43:44 -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: OPEN ISSUE: Standards Track 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 Err, but you'll notice that we are discussing a "working group draft" that was initially published as a working group draft (not accepted as a working group draft from an existing submission). The draft is a process draft, not a protocol draft, but we sure do this a lot if we're doing it wrong! Having said this - I like Brian's suggestion. I think we would STILL have a "three-stage standards track", but it would be: - working group draft for chartered specification, - Proposed Standard, - Standard and it accomplishes what we had discussed about being able to publish "Proposed Standard"/"first rung" specifications in a more timely fashion without devaluing the RFC logo, and giving us a clearer conscience when we CHANGE something because of implementation/deployment experience. Spencer ----- Original Message ----- From: "Brian E Carpenter" To: Sent: Friday, May 16, 2003 8:22 AM Subject: Re: OPEN ISSUE: Standards Track > Firstly, yes it's a problem. > > Secondly, this is a case where I think a simple first step may > help quite a bit: simply merge Draft Standard and Standard > into a single class, called Standard, but with the criteria > now used for Draft Standard. > > Arguments: remove a process step that we basically never use, > and make the step up from Proposed Standard worth the trouble. > > On James' point about Internet Drafts, maybe we could use a > little clarification in the WG procedures, but the main point > is to require a WG consensus before declaring a draft to be > a WG draft. If that hasn't been happening, it's more of a WG > Chair training issue than anything else. > > Brian From problem-statement-bounces@alvestrand.no Fri May 16 11:46: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 LAA00318 for ; Fri, 16 May 2003 11:46:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7F142625DA; Fri, 16 May 2003 17:49: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 EBB27625A8 for ; Fri, 16 May 2003 17:49: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 h4GFnOk09132; Fri, 16 May 2003 11:49:25 -0400 (EDT) Date: Fri, 16 May 2003 11:49:24 -0400 From: Keith Moore To: "James Kempf" Message-Id: <20030516114924.667717ec.moore@cs.utk.edu> In-Reply-To: <014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> References: <5.1.0.14.2.20030515113529.014ba800@mail.windriver.com> <014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> 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: mrw@windriver.com Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit I'm in general agreement that it's necessary to consider the role of internet-drafts (including working group drafts) when trying to understand the problems with our current maturity levels. And I'm also in agreement that some working groups too easily adopt drafts as work items - though my concern here is mostly about WG resources being spread too thin. I'm not sure it's appropriate to constrain WGs to only adopt drafts that they believe will end up being products of the WGs. And while it's fine for people to start implementing drafts (especially if we'll benefit from the input of those implementing them) it may be that we need to find a way to discourage people from assuming that they'll end up as standards. > I've felt for some time that there is a need for a change in this > area, but this analysis leaves out the issue of Working Group drafts, > which I think is a critical component. Right now, they have grey area > status. I've seen drafts move from individual contribution to Working > Group status only because nobody on the mailing list spoke up when the > Working Group chair put out the question about whether a draft should > move to Working Group status or not. Many vendors start implementing > when something becomes a Working Group draft, since realistically, > they view that move as entry into the standardization process, > regardless of what IETF's process RFCs say about it. > > Arguments have been made on this list that we should not touch the > current Proposed/Draft distinction, and I agree that the distinction > is useful even if Proposed is treated as "standard" by vendors for all > practical purposes (Full Standard, however, is largely useless except > as a historical distinction). However, I think some attention is > needed to how a draft becomes a Working Group draft. Perhaps that move > is when a preliminary review is made on the design, so that movement > to Working Group draft status does not happen for reasons that have > nothing to do with the technical aspects of the design. Keith From problem-statement-bounces@alvestrand.no Fri May 16 11:54: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 LAA00616 for ; Fri, 16 May 2003 11:54:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 660C1625A8; Fri, 16 May 2003 17:57: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 E4F626257B; Fri, 16 May 2003 17:57:23 +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 h4GFvNk09618; Fri, 16 May 2003 11:57:23 -0400 (EDT) Date: Fri, 16 May 2003 11:57:22 -0400 From: Keith Moore To: Harald Tveit Alvestrand Message-Id: <20030516115722.08874695.moore@cs.utk.edu> In-Reply-To: <1689790900.1053038959@localhost> References: <5.1.0.14.2.20030515113529.014ba800@mail.windriver.com> <014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> <1689790900.1053038959@localhost> 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: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 like to suggest that rather than thinking in terms of lowering the bar for Proposed, that we instead think in terms of creating a more explicit preliminary step before getting to Proposed, treating what is now called Proposed as more mature than we do now, and probably eliminating Full Standard. Because what seems to have happened is that both the industry and IESG are now treating Proposed as "ready for shipping product". I don't think it's realistic to expect IESG (or IETF) to lower the bar for Proposed unless the industry also lowers its expectations, and I don't know how to make the latter happen. I assume that we'd probably want to rename the current maturity levels and change the status of existing documents to match their positions in the new scheme. From problem-statement-bounces@alvestrand.no Fri May 16 11:57: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 LAA00700 for ; Fri, 16 May 2003 11:57:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C158C62589; Fri, 16 May 2003 17:59:57 +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 AA4DA6257B for ; Fri, 16 May 2003 17:59:50 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.5]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA13794; Fri, 16 May 2003 08:59:40 -0700 (PDT) Message-Id: <5.1.0.14.2.20030516115353.03c92960@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 16 May 2003 11:54:31 -0400 To: Keith Moore From: Margaret Wasserman In-Reply-To: <20030516114246.0fad5f52.moore@cs.utk.edu> References: <5.1.0.14.2.20030515114755.014cedb8@mail.windriver.com> <5.1.0.14.2.20030515114755.014cedb8@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Quality Process WG Charter X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 Keith, At 11:42 AM 5/16/2003 -0400, Keith Moore wrote: > > Currently the process document says: > > > > >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: > > > > > [OPEN ISSUE: Should the Problem Statement WG propose a charter > > > for this group, or leave that to the General AD and selected > > > chair(s)?] > > > >I don't think this group should propose a charter for that group. > >And I'm not sure I even agree with the text in the process document >about how that group should proceed. Would you like to propose an alternative? Margaret From problem-statement-bounces@alvestrand.no Fri May 16 12:13: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 MAA01119 for ; Fri, 16 May 2003 12:13:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B24FC625A8; Fri, 16 May 2003 18:15:35 +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 6F1046259C for ; Fri, 16 May 2003 18:15:33 +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.1b1); Fri, 16 May 2003 11:15:46 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <3EC4DE50.D04E601C@hursley.ibm.com> References: <200305131200.IAA05317@ietf.org> <3EC4DE50.D04E601C@hursley.ibm.com> X-Mailer: Eudora [Macintosh version 6.0a15] Date: Fri, 16 May 2003 11:15:29 -0500 To: Brian E Carpenter From: Pete Resnick Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: problem-statement@alvestrand.no Subject: Document Blocking (Was: I-D ACTION:draft-ietf-problem-process-00.txt) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 5/16/03 at 2:49 PM +0200, Brian E Carpenter wrote: > > 5. Modify IESG-internal processes to make it impossible for one >> or two IESG members to block a document. > >There is a strong implication here that ADs might do this for >spurious reasons. I don't think it makes a difference to the issue, but let's even assume that it is *not* done for spurious reasons. >But if one or both Security ADs are deeply convinced that a draft >constitutes a major security risk, or one or both Routing ADs are >convinced that a draft will lead to routing loops, isn't it quite >appropriate for them to block the document? Absolutely not, but *not* because the document shouldn't be stopped. The ADs who think that there is a serious problem with a document should convince the rest of the IESG that the document is a bad idea. Then, the IESG can come to consensus (or unanimity) to reject a document (or at least stop it until the problem is fixed). The problem with the current process (as I understand it) is that it allows documents to be blocked by one or two IESG members without the consensus of the group. The current procedure assumes that one or two IESG members must be able to block a document because the rest of the IESG is so stupid or ignorant that they cannot be convinced that the document is a bad idea, even if one or two experts on the IESG know that it is. If that were actually the case, it points to a much worse state of affairs, where IESG members don't trust each other to do the right thing. >Such cases suggest failures much earlier in the process, not >misbehaviour by the IESG. For case where the entire IESG comes to consensus that a document should be stopped, yes, that suggests a very early process failure. But cases where it is required that one or two IESG members can, without consensus, block a document, suggests serious misbehavior on the part of the rest of the IESG. >So I don't think we should fix this, because it is actually a vital >back-stop, not a bug. We already have a backstop for each of the cases: 1. In the case of a bad document, the IESG can come to consensus that a document is bad. 2. In the case of a bad document where one or two IESG members can't convince the rest of the IESG, the one or two members can appeal, or initiate recall procedures on the rest of the IESG. I really wish someone could explain to me why we think it is necessary to have IESG members vetoing each other's decisions as a backstop. -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From problem-statement-bounces@alvestrand.no Fri May 16 12:19: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 MAA01360 for ; Fri, 16 May 2003 12:19:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 26B026259C; Fri, 16 May 2003 18:21:36 +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 01C6762589 for ; Fri, 16 May 2003 18:21:30 +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 JAA00873; Fri, 16 May 2003 09:21:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4GGLR431058; Fri, 16 May 2003 09:21:27 -0700 X-mProtect: <200305161621> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2YmbRl; Fri, 16 May 2003 09:21:26 PDT Message-ID: <3EC51006.12A69FB2@iprg.nokia.com> Date: Fri, 16 May 2003 09:21:26 -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: <5.1.0.14.2.20030515114129.04754880@mail.windriver.com> <20030516113701.0708a278.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Nomcom 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 Keith Moore wrote: > I am not sure whether it's reasonable for noncom to disclose the list of > parties under consideration. On one hand it would invite wider public > feedback about specific individuals, which would help avoid unpleasant > surprises. On the other hand it would expose would-be candidates to > potential "loss of face" at not being chosen - and invite comparison > to those who were chosen - even if the reason for that particular choice > turned out to be unrelated to the candidates' technical or personal > qualifications. Somehow I'm imagining that anyone with enough experience and management skills to be a good AD should also have enough experience and stability to be able to handle rejection. What about all the IEEE and other organizations, where candidates sometimes lose? What makes IETF special in this matter? I think we should enable community input to nomcom about all nominees. To be fair, though, I am sure that the nomcom _does_ get input about returning IESG members. Regards, Charlie P. From problem-statement-bounces@alvestrand.no Fri May 16 12:54: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 MAA02857 for ; Fri, 16 May 2003 12:54:49 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1E2826258E; Fri, 16 May 2003 18:57: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 0D4966257C for ; Fri, 16 May 2003 18:57:19 +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 h4GGvEk09849; Fri, 16 May 2003 12:57:14 -0400 (EDT) Date: Fri, 16 May 2003 12:57:14 -0400 From: Keith Moore To: Margaret Wasserman Message-Id: <20030516125714.14cc73eb.moore@cs.utk.edu> In-Reply-To: <5.1.0.14.2.20030516050623.038bd7f0@mail.windriver.com> References: <014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> <5.1.0.14.2.20030515113529.014ba800@mail.windriver.com> <014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> <5.1.0.14.2.20030516050623.038bd7f0@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: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 like to suggest that if we're going to change our document maturity levels and/or their criteria, that we first need to understand what set of maturity levels would be a good impedance match with what "the industry" (including non-commercial implementors) needs, while still serving the needs of the broader Internet community. Then we need to figure out what are appropriate criteria to impose at each stage, given those needs, keeping in mind the level of energy we can reasonably expect to bring to each transition between stages. Then we need to figure out how to label/market each level of maturity. This might include deciding what is or is not labeled as "RFC". Keith From problem-statement-bounces@alvestrand.no Fri May 16 13:00: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 NAA03057 for ; Fri, 16 May 2003 13:00:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7134362589; Fri, 16 May 2003 19:03:32 +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 426546257C for ; Fri, 16 May 2003 19:03:26 +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 h4GH3OH3023566 for ; Fri, 16 May 2003 13:03:24 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h4GH3ODi023565 for problem-statement@alvestrand.no; Fri, 16 May 2003 13:03:24 -0400 (EDT) Date: Fri, 16 May 2003 13:03:24 -0400 (EDT) From: Scott Bradner Message-Id: <200305161703.h4GH3ODi023565@newdev.harvard.edu> To: problem-statement@alvestrand.no Subject: Re: Document Blocking (Was: I-D X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no some background on the blocking documents thread based on my experience on the IESG lets split documents that the IESG looks at into two piles 1/ documents forwarded to the IESG by the RFC Editor to get the IESG's recommendation 2/ documents that are the product of IETF working groups or independent documents (mostly for standards track) that are being evaluated as if they were WG documents case 1: the document is normally assigned to a specific AD - that AD does an evaluation and comes up with a suggestion as to what the IESG should say to the RFC Editor - this can take an arbitrarily long time when the designated AD has done the review the document is put onto the agenda for an IESG teleconference the IESG then discusses the document during the teleconference - most of the time the IESG winds up sending a note to the RFC Editor saying that it has no objections to the document being published sometimes the AD will work with the document authors/editors to deal with issues that the AD finds during their review, sometimes this happens before the document getting on the IESG agenda sometime after the IESG discussion it is not common for the IESG to recommend that the RFC Editor not publish a document (but it does happen a few times a year) - when it does happen the RFC Editor is sent a 'do not publish' (DNP) recommendation. The DNP is written by one or two ADs - this can take an arbitrarily long time The RFC Editor uses the IESG response in deciding whether to publish the document case 2: it is quite common for issues/questions to be raised by one or more ADs during the IESG evaluation of a document - if the AD(s) feel strongly enough that there is an issue that needs to be addresses they vote "discuss" - this will block a document until the AD(s) are satisfied by revisions in the document or as a result of discussion when an AD has an issue with a document and has voted "discuss" the document and the issues are discussed during an IESG teleconference - sometimes the discussion results in the AD changing their evaluation and removing their "discuss" generally when an AD keeps their "discuss" after the IESG teleconference there is some level of consensus in the IESG that the issues raised are real and do need to get fixed - in this case it is generally the case that other ADs to not also vote "discuss" to indicate their agreement, they delegate one AD as the discuss holder - that AD will evaluate the document changes and give a OK when they are happy - i.e. the fact that only one security AD is recorded as having a discuss on a document should not be read to say that the rest of the IESG does not support that discuss in my experience, from time to time it was the case that I did not see IESG consensus support for the concerns of a specific AD but the normal IESG process does not make it easy to get around a single AD's discuss - there is a process that was defined to do this but it has never been used, and that process would not get around a case where two ADs had issues that the rest of the IESG did not share I do not recall that the IESG has ever specifically decided to not publish a document in this group but since it can take an arbitrarily long time for the working group (or document authors/editors) to respond to the concerns and an arbitrarily long time for the back and forth between the AD for the working group, the AD holding the discuss, the working group chairs, and the working group the effect of the process may not be distinguishable from a decision to not publish. Scott From problem-statement-bounces@alvestrand.no Fri May 16 13:08: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 NAA03302 for ; Fri, 16 May 2003 13:08:44 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9BCDB6257C; Fri, 16 May 2003 19:11:18 +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 8FCC56257B for ; Fri, 16 May 2003 19:11:16 +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 h4GHB9k09898; Fri, 16 May 2003 13:11:10 -0400 (EDT) Date: Fri, 16 May 2003 13:11:09 -0400 From: Keith Moore To: "Charles E. Perkins" Message-Id: <20030516131109.71d64f98.moore@cs.utk.edu> In-Reply-To: <3EC51006.12A69FB2@iprg.nokia.com> References: <5.1.0.14.2.20030515114129.04754880@mail.windriver.com> <20030516113701.0708a278.moore@cs.utk.edu> <3EC51006.12A69FB2@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: OPEN ISSUE: Nomcom 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 am not sure whether it's reasonable for noncom to disclose the > > list of parties under consideration. On one hand it would invite > > wider public feedback about specific individuals, which would help > > avoid unpleasant surprises. On the other hand it would expose > > would-be candidates to potential "loss of face" at not being chosen > > - and invite comparison to those who were chosen - even if the > > reason for that particular choice turned out to be unrelated to the > > candidates' technical or personal qualifications. > > Somehow I'm imagining that anyone with enough experience > and management skills to be a good AD should also have enough > experience and stability to be able to handle rejection. oh, I agree. actually I almost said in the earlier message that you need a fairly tough skin to be a good AD anyway - you *will* get sharply criticized no matter what decisions you make or how good they are. but at least once you are an AD you get the prestige of the AD job as compensation. and "rejection" isn't always a good description of the the reason that another candidate is chosen- though it will widely be assumed to be the reason. put it this way - there are already enough barriers to discourage potential IESG (and to some extent IAB) candidates. do you want to narrow the pool of available candidates even further? Keith From problem-statement-bounces@alvestrand.no Fri May 16 13:09: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 NAA03382 for ; Fri, 16 May 2003 13:09:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C226C625B7; Fri, 16 May 2003 19:11:52 +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 4ECFA6257B for ; Fri, 16 May 2003 19:11:50 +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 h4GHBjk09904; Fri, 16 May 2003 13:11:45 -0400 (EDT) Date: Fri, 16 May 2003 13:11:45 -0400 From: Keith Moore To: Margaret Wasserman Message-Id: <20030516131145.500f783e.moore@cs.utk.edu> In-Reply-To: <5.1.0.14.2.20030516115353.03c92960@mail.windriver.com> References: <5.1.0.14.2.20030515114755.014cedb8@mail.windriver.com> <5.1.0.14.2.20030515114755.014cedb8@mail.windriver.com> <5.1.0.14.2.20030516115353.03c92960@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: OPEN ISSUE: Quality Process WG Charter X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 this group should propose a charter for that group. > > > >And I'm not sure I even agree with the text in the process document > >about how that group should proceed. > > Would you like to propose an alternative? maybe, but I need more time to think about it. From problem-statement-bounces@alvestrand.no Fri May 16 14:34: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 OAA06197 for ; Fri, 16 May 2003 14:34:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 42BCC625B9; Fri, 16 May 2003 20:36: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 2B718625B7 for ; Fri, 16 May 2003 20:36:37 +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 h4GIaZk10143; Fri, 16 May 2003 14:36:35 -0400 (EDT) Date: Fri, 16 May 2003 14:36:35 -0400 From: Keith Moore To: Scott Bradner Message-Id: <20030516143635.593e977a.moore@cs.utk.edu> In-Reply-To: <200305161703.h4GH3ODi023565@newdev.harvard.edu> References: <200305161703.h4GH3ODi023565@newdev.harvard.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 Subject: Re: Document Blocking (Was: I-D X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 background on the blocking documents thread based on my > experience on the IESG > > lets split documents that the IESG looks at into two piles > 1/ documents forwarded to the IESG by the RFC Editor to get the > IESG's recommendation > 2/ documents that are the product of IETF working groups or > independent documents (mostly for standards track) that are being > evaluated as if they were WG documents > > case 1: > the document is normally assigned to a specific AD - that AD does an > evaluation and comes up with a suggestion as to what the IESG should > say to the RFC Editor - this can take an arbitrarily long time does the RFC editor no longer impose a timeout on IESG feedback for such documents? (where such feedback could say "we need more time" or "we're discussing with the author") > case 2: > it is quite common for issues/questions to be raised by one or more > ADs during the IESG evaluation of a document - if the AD(s) feel > strongly enough that there is an issue that needs to be addresses they > vote "discuss" - this will block a document until the AD(s) are > satisfied by revisions in the document or as a result of discussion > > when an AD has an issue with a document and has voted "discuss" the > document and the issues are discussed during an IESG teleconference - > sometimes the discussion results in the AD changing their evaluation > and removing their "discuss" > > generally when an AD keeps their "discuss" after the IESG > teleconference there is some level of consensus in the IESG that the > issues raised are real and do need to get fixed - in this case it is > generally the case that other ADs to not also vote "discuss" to > indicate their agreement, they delegate one AD as the discuss holder - > that AD will evaluate the document changes and give a OK when they are > happy - i.e. the fact that only one security AD is recorded as having > a discuss on a document should not be read to say that the rest of the > IESG does not support that discuss maybe now that the votes are being publicized the IESG might want to consider changing that. it was handy to have only one discuss holder because only one vote had to be changed to move the document forward. but now perhaps it would be useful for IESG to separate the notion of "who thinks this document has problems" from the notion of "who has the token to say when the problems with this document are fixed" > in my experience, from time to time it was the case that I did not see > IESG consensus support for the concerns of a specific AD but the > normal IESG process does not make it easy to get around a single AD's > discuss - there is a process that was defined to do this but it has > never been used, and that process would not get around a case where > two ADs had issues that the rest of the IESG did not share concur. very occasionally, it seemed to me that another IESG member's concerns were either unfounded or too trivial to hold up passage of the document. and at least while I was there, we didn't have a good way to work past those problems. (I should clarify that IMHO the vast majority of IESG Discuss concerns were well-founded and appropriate.) Keith From problem-statement-bounces@alvestrand.no Fri May 16 14:45: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 OAA06433 for ; Fri, 16 May 2003 14:45:49 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4BD256259C; Fri, 16 May 2003 20:48:24 +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 5223E621B8 for ; Fri, 16 May 2003 20:48:22 +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 h4GImEk10184; Fri, 16 May 2003 14:48:14 -0400 (EDT) Date: Fri, 16 May 2003 14:48:14 -0400 From: Keith Moore To: Pete Resnick Message-Id: <20030516144814.24774f62.moore@cs.utk.edu> In-Reply-To: References: <200305131200.IAA05317@ietf.org> <3EC4DE50.D04E601C@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 Cc: brian@hursley.ibm.com Subject: Re: Document Blocking (Was: I-D ACTION:draft-ietf-problem-process-00.txt) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 if one or both Security ADs are deeply convinced that a draft > >constitutes a major security risk, or one or both Routing ADs are > >convinced that a draft will lead to routing loops, isn't it quite > >appropriate for them to block the document? > > Absolutely not, but *not* because the document shouldn't be stopped. > The ADs who think that there is a serious problem with a document > should convince the rest of the IESG that the document is a bad idea. > Then, the IESG can come to consensus (or unanimity) to reject a > document (or at least stop it until the problem is fixed). > > The problem with the current process (as I understand it) is that it > allows documents to be blocked by one or two IESG members without the > consensus of the group. I don't see this as a problem at all. Many of the issues that hold up document publication are not easily understood without expertise in that particular area. Also, IESG does not "block" documents, it explains what is wrong with them and sends them back to the working group. It's simply infeasible to expect all of IESG to reach consensus on every issue that requires a change to a document. For a deep technical issue, there *might* be four people on IESG who really have enough appreciation for that issue to express an informed opinion - and two of those might have to stretch to understand it. > But cases where it is required that one or two IESG members can, > without consensus, block a document, suggests serious misbehavior on > the part of the rest of the IESG. No, it just means that a wide range of expertise is required to evaluate all of the proposals that come through IETF. > 1. In the case of a bad document, the IESG can come to consensus that > a document is bad. > > 2. In the case of a bad document where one or two IESG members can't > convince the rest of the IESG, the one or two members can appeal, or > initiate recall procedures on the rest of the IESG. > > I really wish someone could explain to me why we think it is > necessary to have IESG members vetoing each other's decisions as a > backstop. It's a misleading to think of a vote as a veto, particularly when most of the votes are usually "no objection". Usually you vote "no objection" when you recognize that you don't have enough expertise to evaluate the proposal. A common case is to have one or two Yes votes, one or two Discuss votes, and the rest No Objection. That's not a case of one or two people holding up the document against an overwhelming majority. It's more like a tie. Keith From problem-statement-bounces@alvestrand.no Fri May 16 15:09: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 PAA07719 for ; Fri, 16 May 2003 15:09:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C51AB6259C; Fri, 16 May 2003 21:11:53 +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 24BF3621B8 for ; Fri, 16 May 2003 21:11:52 +0200 (CEST) Received: from adsl-68-120-231-209.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4GJBXN16912 for ; Fri, 16 May 2003 12:11:33 -0700 Date: Fri, 16 May 2003 12:13:58 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <875040577.20030516121358@brandenburg.com> To: problem-statement@alvestrand.no In-Reply-To: References: <200305131200.IAA05317@ietf.org> <3EC4DE50.D04E601C@hursley.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Document Blocking (Was: I-D ACTION:draft-ietf-problem-process-00.txt) 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, PR> The ADs who think that there is a serious problem with a document PR> should convince the rest of the IESG that the document is a bad idea. PR> Then, the IESG can come to consensus (or unanimity) to reject a PR> document (or at least stop it until the problem is fixed). Exactly right. No matter how stellar the expertise of someone, if they cannot convince others that their views are correct, something is very, very wrong. Permitting them to single- (or double-) handedly block something removes the the incentive for that person to work at convincing others. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Fri May 16 15: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 PAA08708 for ; Fri, 16 May 2003 15:25:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5D2256257C; Fri, 16 May 2003 21:27:50 +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 CEEFB6256B for ; Fri, 16 May 2003 21:27:39 +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 h4GJRcH3024034; Fri, 16 May 2003 15:27:38 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h4GJRcHV024033; Fri, 16 May 2003 15:27:38 -0400 (EDT) Date: Fri, 16 May 2003 15:27:38 -0400 (EDT) From: Scott Bradner Message-Id: <200305161927.h4GJRcHV024033@newdev.harvard.edu> To: moore@cs.utk.edu, sob@harvard.edu In-Reply-To: <20030516143635.593e977a.moore@cs.utk.edu> Cc: problem-statement@alvestrand.no Subject: Re: Document Blocking (Was: I-D X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > does the RFC editor no longer impose a timeout on IESG feedback for > such documents? (where such feedback could say "we need more time" > or "we're discussing with the author") formally, they do, but it is meangingless Scott From problem-statement-bounces@alvestrand.no Fri May 16 15:35: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 PAA08981 for ; Fri, 16 May 2003 15:35:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F39326257C; Fri, 16 May 2003 21:37:59 +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 8975A6256B for ; Fri, 16 May 2003 21:37:53 +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.1b1); Fri, 16 May 2003 14:38:05 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <20030516143635.593e977a.moore@cs.utk.edu> References: <200305161703.h4GH3ODi023565@newdev.harvard.edu> <20030516143635.593e977a.moore@cs.utk.edu> X-Mailer: Eudora [Macintosh version 6.0a15] Date: Fri, 16 May 2003 14:37:48 -0500 To: Keith Moore From: Pete Resnick Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: problem-statement@alvestrand.no Cc: Scott Bradner Subject: Re: Document Blocking (Was: I-D X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 5/16/03 at 2:36 PM -0400, Keith Moore wrote: >[Scott Bradner:] >>in my experience, from time to time it was the case that I did not >>see IESG consensus support for the concerns of a specific AD but >>the normal IESG process does not make it easy to get around a >>single AD's discuss - there is a process that was defined to do >>this but it has never been used, and that process would not get >>around a case where two ADs had issues that the rest of the IESG >>did not share > >concur. very occasionally, it seemed to me that another IESG >member's concerns were either unfounded or too trivial to hold up >passage of the document. and at least while I was there, we didn't >have a good way to work past those problems. I don't understand how that jibes with: >>The problem with the current process (as I understand it) is that >>it allows documents to be blocked by one or two IESG members >>without the consensus of the group. > >I don't see this as a problem at all. You concur with the problem outlined by Scott above: There have been (perhaps rare) cases where someone claimed there to be a serious enough problem to hold up a document where the other IESG member's concerns were unfounded, yet there was no way to work past this hold up. >Many of the issues that hold up document publication are not easily >understood without expertise in that particular area. But if the expert in that area can't explain to the rest of the IESG why all should agree with the "discuss", then: a) Perhaps it's unfounded b) How on earth is that "expert" going to explain it sufficiently to the working group whose document is being held up. As Dave said, "No matter how stellar the expertise of someone, if they cannot convince others that their views are correct, something is very, very wrong." >Also, IESG does not "block" documents, it explains what is wrong >with them and sends them back to the working group. But, as Scott said: >>...since it can take an arbitrarily long time for the working group >>(or document authors/editors) to respond to the concerns and an >>arbitrarily long time for the back and forth between the AD for the >>working group, the AD holding the discuss, the working group >>chairs, and the working group the effect of the process may not be >>distinguishable from a decision to not publish. Quite often, "discuss" (especially in the absence of an understandable explanation) ends up being, for all intents and purposes, identical to "block". >It's simply infeasible to expect all of IESG to reach consensus on >every issue that requires a change to a document. For a deep >technical issue, there *might* be four people on IESG who really >have enough appreciation for that issue to express an informed >opinion - and two of those might have to stretch to understand it. We're not talking about cases where some members of the IESG have a technical issue and the rest say, "Well, I don't understand that well enough to have a technical opinion on this, but you've convinced me it's a serious enough issue to warrant discussing the document further." That *is* consensus to discuss the document. It's when the objecting members *don't* explain the problem sufficiently to convince the others that there even *is* a serious issue. The IESG certainly *must* come to consensus that there is a real issue before stopping a document from moving along. >A common case is to have one or two Yes votes, one or two Discuss >votes, and the rest No Objection. That's not a case of one or two >people holding up the document against an overwhelming majority. >It's more like a tie. I would be deeply concerned if there were one or two Discuss, two Yes, and the rest No Objection *and* the Discuss voter(s) couldn't convince any of the Yes or No Objection people to change their votes to Discuss. Unfortunately, the current process allows that to hold up a document, and as both you and Scott have said, it has happened at least a few times during each of your tenors on the IESG. >(I should clarify that IMHO the vast majority of IESG Discuss >concerns were well-founded and appropriate.) That might be true. Understand, though, that given the current process, it is impossible to tell the difference between the ones the IESG considers well-founded and the one's it does not. Hence: >>the fact that only one security AD is recorded as having a discuss >>on a document should not be read to say that the rest of the IESG >>does not support that discuss > >maybe now that the votes are being publicized the IESG might want to >consider changing that. I agree completely. But that doesn't change the fact that in those cases where the IESG does not support the discuss of one or two members, there should be some (simple) way to over-rule the "discuss" and move the document forward. That's why there needs to be a process change. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From problem-statement-bounces@alvestrand.no Fri May 16 15:37: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 PAA09085 for ; Fri, 16 May 2003 15:37:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C41E3625A8; Fri, 16 May 2003 21:40: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 10A1C6257C for ; Fri, 16 May 2003 21:40:12 +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 h4GJe7k10370; Fri, 16 May 2003 15:40:07 -0400 (EDT) Date: Fri, 16 May 2003 15:40:07 -0400 From: Keith Moore To: Margaret Wasserman Message-Id: <20030516154007.2ac656b9.moore@cs.utk.edu> In-Reply-To: <5.1.0.14.2.20030516072814.04754080@mail.windriver.com> References: <1689790900.1053038959@localhost> <014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> <5.1.0.14.2.20030515113529.014ba800@mail.windriver.com> <014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> <5.1.0.14.2.20030516072814.04754080@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: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 documents are reviewed, it would be useful if we could > get two types of (clearly delineated) feedback: > > (1) Blocking issues that would prevent the publication > of the document at PS. In the opinion of the > reviewer (currently the IESG), it is worth > delaying publication of the document to fix > this problem. > (2) Non-blocking issues that should be fixed in the > next revision (and certainly before the > document goes to the next stage). as long as implementors feel free to widely deploy PS protocols, the two are nearly indistinguishable. From problem-statement-bounces@alvestrand.no Fri May 16 15:39: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 PAA09131 for ; Fri, 16 May 2003 15:39:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BFFE66257C; Fri, 16 May 2003 21:41:57 +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 640226256B for ; Fri, 16 May 2003 21:41:48 +0200 (CEST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])h4GJfkb29206 for ; Fri, 16 May 2003 14:41:46 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com ; Fri, 16 May 2003 14:41:46 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 16 May 2003 12:41:42 -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, 16 May 2003 14:41:38 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44013EFB0D@daebe007.americas.nokia.com> Thread-Topic: OPEN ISSUE: Standards Track Thread-Index: AcMbvNvOPrDLdx9ySC2Tr68c8CdTNQAJbDog From: To: , , X-OriginalArrivalTime: 16 May 2003 19:41:42.0648 (UTC) FILETIME=[2D34FF80:01C31BE3] Subject: RE: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 PAA09131 > > For example, I think that it should be possible for several > different > > proposals that solve the same problem to be published in an enduring > > form by the IETF, and for a subsequent process to determine which > > one(s) will advance on the standards-track. This would solve some > > of the problems that we have in the v6ops WG, for example. But, we > > have no tools to do this in a way that makes the status of these > > documents visible to our "customers". > > > > My understanding is that that is one purpose of the Experimental > designation. Which unfortunately I believe is not done as much by WGs in the IETF. > > jak -bp From problem-statement-bounces@alvestrand.no Fri May 16 15:50: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 PAA09383 for ; Fri, 16 May 2003 15:50:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 339A9625C4; Fri, 16 May 2003 21:53:25 +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 6600F625B6 for ; Fri, 16 May 2003 21:53:23 +0200 (CEST) Received: from AwducheHPlapt (68.100.145.226) by mta1.wss.scd.yahoo.com (7.0.015.1) (authenticated as awduche@awduche.com) id 3EBA91C10051ACBA; Fri, 16 May 2003 12:53:16 -0700 From: "Daniel O. Awduche" To: "'Dave Crocker'" , Date: Fri, 16 May 2003 15:52:24 -0400 Message-ID: <00c901c31be4$ac6ec5a0$e2916444@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: <875040577.20030516121358@brandenburg.com> Subject: RE: Document Blocking (Was: I-DACTION:draft-ietf-problem-process-00.txt) 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 concur with the sentiments... Granting an individual (who purports to be an expert) the authority to block a document (that has passed through WG consensus) without a clear, convincing, and rational explanation demeans the entire process. Cheers, /Dan -----Original Message----- From: problem-statement-bounces@alvestrand.no [mailto:problem-statement-bounces@alvestrand.no] On Behalf Of Dave Crocker Sent: Friday, May 16, 2003 3:14 PM To: problem-statement@alvestrand.no Subject: Re: Document Blocking (Was: I-DACTION:draft-ietf-problem-process-00.txt) Folks, PR> The ADs who think that there is a serious problem with a document PR> should convince the rest of the IESG that the document is a bad PR> idea. Then, the IESG can come to consensus (or unanimity) to reject PR> a document (or at least stop it until the problem is fixed). Exactly right. No matter how stellar the expertise of someone, if they cannot convince others that their views are correct, something is very, very wrong. Permitting them to single- (or double-) handedly block something removes the the incentive for that person to work at convincing others. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Fri May 16 16: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 QAA09593 for ; Fri, 16 May 2003 16:01:37 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 910A86257C; Fri, 16 May 2003 22:04:09 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5E3DC6257B for ; Fri, 16 May 2003 22:04:02 +0200 (CEST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) id h4GK3wB27895; Fri, 16 May 2003 16:03:58 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 May 2003 16:03:58 -0400 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6061E82F9@zcard0ke.ca.nortel.com> From: "Bilel Jamoussi" To: "'awduche@awduche.com'" Date: Fri, 16 May 2003 16:03:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31BE6.452D9D92" Cc: "'problem-statement@alvestrand.no'" Subject: Re: Document Blocking (Was: I-DACTION:draft-ietf-problem-process- 00.txt) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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_01C31BE6.452D9D92 Content-Type: text/plain Agreed. Bilel -------------------------- bnj -----Original Message----- From: Daniel O. Awduche To: 'Dave Crocker' ; problem-statement@alvestrand.no Sent: Fri May 16 15:52:24 2003 Subject: RE: Document Blocking (Was: I-DACTION:draft-ietf-problem-process-00.txt) I concur with the sentiments... Granting an individual (who purports to be an expert) the authority to block a document (that has passed through WG consensus) without a clear, convincing, and rational explanation demeans the entire process. Cheers, /Dan -----Original Message----- From: problem-statement-bounces@alvestrand.no [mailto:problem-statement-bounces@alvestrand.no] On Behalf Of Dave Crocker Sent: Friday, May 16, 2003 3:14 PM To: problem-statement@alvestrand.no Subject: Re: Document Blocking (Was: I-DACTION:draft-ietf-problem-process-00.txt) Folks, PR> The ADs who think that there is a serious problem with a document PR> should convince the rest of the IESG that the document is a bad PR> idea. Then, the IESG can come to consensus (or unanimity) to reject PR> a document (or at least stop it until the problem is fixed). Exactly right. No matter how stellar the expertise of someone, if they cannot convince others that their views are correct, something is very, very wrong. Permitting them to single- (or double-) handedly block something removes the the incentive for that person to work at convincing others. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , ------_=_NextPart_001_01C31BE6.452D9D92 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Re: Document Blocking (Was: = I-DACTION:draft-ietf-problem-process-00.txt)

Agreed.

Bilel
--------------------------
bnj


-----Original Message-----
From: Daniel O. Awduche = <awduche@awduche.com>
To: 'Dave Crocker' <dcrocker@brandenburg.com>; = problem-statement@alvestrand.no = <problem-statement@alvestrand.no>
Sent: Fri May 16 15:52:24 2003
Subject: RE: Document Blocking (Was: = I-DACTION:draft-ietf-problem-process-00.txt)

I concur with the sentiments...

Granting an individual (who purports to be an expert) = the authority to
block a document (that has passed through WG = consensus) without a clear,

convincing, and rational explanation demeans the = entire process.

Cheers,
/Dan

-----Original Message-----
From: problem-statement-bounces@alvestrand.no
[mailto:problem-s= tatement-bounces@alvestrand.no] On Behalf Of Dave
Crocker
Sent: Friday, May 16, 2003 3:14 PM
To: problem-statement@alvestrand.no
Subject: Re: Document Blocking (Was:
I-DACTION:draft-ietf-problem-process-00.txt)


Folks,

PR> The ADs who think that there is a serious = problem with a document
PR> should convince the rest of the IESG that the = document is a bad
PR> idea. Then, the IESG can come to consensus = (or unanimity) to reject
PR> a document (or at least stop it until the = problem is fixed).

Exactly right.

No matter how stellar the expertise of someone, if = they cannot convince
others that their views are correct, something is = very, very wrong.
Permitting them to single- (or double-) handedly = block something removes
the the incentive for that person to work at = convincing others.


d/
--
 Dave Crocker <mailto:dcrocker@brandenburg.com= >
 Brandenburg InternetWorking <http://www.brandenburg.com>  Sunnyvale, = CA
USA <tel:+1.408.246.8253>, = <fax:+1.866.358.5301>

------_=_NextPart_001_01C31BE6.452D9D92-- From problem-statement-bounces@alvestrand.no Fri May 16 16:13: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 QAA09937 for ; Fri, 16 May 2003 16:13:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 781B96257C; Fri, 16 May 2003 22:15:49 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from nit.isi.edu (nit.isi.edu [128.9.160.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id B9B026257C for ; Fri, 16 May 2003 22:15:27 +0200 (CEST) Received: (from falk@localhost) by nit.isi.edu (8.11.6/8.11.6) id h4GKFOG04985; Fri, 16 May 2003 13:15:24 -0700 Date: Fri, 16 May 2003 13:15:24 -0700 From: Aaron Falk To: Keith Moore Message-ID: <20030516201524.GA2247@isi.edu> Mail-Followup-To: Keith Moore , Scott Bradner , problem-statement@alvestrand.no References: <200305161703.h4GH3ODi023565@newdev.harvard.edu> <20030516143635.593e977a.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030516143635.593e977a.moore@cs.utk.edu> User-Agent: Mutt/1.4i Cc: problem-statement@alvestrand.no Cc: Scott Bradner Subject: Re: Document Blocking (Was: I-D X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 wrote: > > > > generally when an AD keeps their "discuss" after the IESG > > teleconference there is some level of consensus in the IESG that the > > issues raised are real and do need to get fixed - in this case it is > > generally the case that other ADs to not also vote "discuss" to > > indicate their agreement, they delegate one AD as the discuss holder - > > that AD will evaluate the document changes and give a OK when they are > > happy - i.e. the fact that only one security AD is recorded as having > > a discuss on a document should not be read to say that the rest of the > > IESG does not support that discuss > > maybe now that the votes are being publicized the IESG might want to > consider changing that. it was handy to have only one discuss holder > because only one vote had to be changed to move the document forward. > but now perhaps it would be useful for IESG to separate the notion of > "who thinks this document has problems" from the notion of "who has the > token to say when the problems with this document are fixed" This seems like a good suggestion. --aaron From problem-statement-bounces@alvestrand.no Fri May 16 16:16: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 QAA09984 for ; Fri, 16 May 2003 16:15:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DFCBC6257C; Fri, 16 May 2003 22:18:12 +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 6E551625A4 for ; Fri, 16 May 2003 22:17:13 +0200 (CEST) Received: from adsl-68-120-231-209.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4GKGmN20142; Fri, 16 May 2003 13:16:48 -0700 Date: Fri, 16 May 2003 13:19:13 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1058954876.20030516131913@brandenburg.com> To: Jonne.Soininen@nokia.com In-Reply-To: <4D7B558499107545BB45044C63822DDEEBDCB0@mvebe001.americas.nokia.com> References: <4D7B558499107545BB45044C63822DDEEBDCB0@mvebe001.americas.nokia.com> 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: My thoughts about the problems of the IETF 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 Jonne, JSnc> Hi, JSnc> but isn't IETF last-call there for catching the inter WG/inter Area issues? A Last Call -- whether within the working group or for the larger IETF community -- is intended ONLY as a safety net, to catch unusual concerns that have been missed. The Last Call mechanism is pretty much pessimal (the opposite of optimal) as a tool for improving specifications. It comes to late in the effort and is certain to frustrate the heck out of workers, and well might invalidate years of design effort. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Fri May 16 16: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 QAA09998 for ; Fri, 16 May 2003 16:16:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 48248625CA; Fri, 16 May 2003 22:18:16 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5F1A5625C6 for ; Fri, 16 May 2003 22:17:18 +0200 (CEST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) id h4GKGwV14639; Fri, 16 May 2003 16:16:58 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 May 2003 16:16:58 -0400 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6061E82FB@zcard0ke.ca.nortel.com> From: "Bilel Jamoussi" To: "'Basavaraj.Patil@nokia.com'" , "'kempf@docomolabs-usa.com'" , "'problem-statement@alvestrand.no'" , "'mrw@windriver.com'" Date: Fri, 16 May 2003 16:16:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31BE8.17FC28F0" Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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_01C31BE8.17FC28F0 Content-Type: text/plain This highlights the need for 'mandatory' training that new ADs and WG chairs have to go through before they assume their duty. -------------------------- bnj -----Original Message----- From: Basavaraj.Patil@nokia.com To: kempf@docomolabs-usa.com ; problem-statement@alvestrand.no ; mrw@windriver.com Sent: Fri May 16 15:41:38 2003 Subject: RE: OPEN ISSUE: Standards Track > > For example, I think that it should be possible for several > different > > proposals that solve the same problem to be published in an enduring > > form by the IETF, and for a subsequent process to determine which > > one(s) will advance on the standards-track. This would solve some > > of the problems that we have in the v6ops WG, for example. But, we > > have no tools to do this in a way that makes the status of these > > documents visible to our "customers". > > > > My understanding is that that is one purpose of the Experimental > designation. Which unfortunately I believe is not done as much by WGs in the IETF. > > jak -bp ------_=_NextPart_001_01C31BE8.17FC28F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Re: OPEN ISSUE: Standards Track

This highlights the need for 'mandatory' training = that new ADs and WG chairs have to go through before they assume their = duty.


--------------------------
bnj


-----Original Message-----
From: Basavaraj.Patil@nokia.com = <Basavaraj.Patil@nokia.com>
To: kempf@docomolabs-usa.com = <kempf@docomolabs-usa.com>; problem-statement@alvestrand.no = <problem-statement@alvestrand.no>; mrw@windriver.com = <mrw@windriver.com>

Sent: Fri May 16 15:41:38 2003
Subject: RE: OPEN ISSUE:  Standards = Track

> > For example, I think that it should be = possible for several
> different
> > proposals that solve the same problem to = be published in an enduring
> > form by the IETF, and for a subsequent = process to determine which
> > one(s) will advance on the = standards-track.  This would solve some
> > of the problems that we have in the v6ops = WG, for example.  But, we
> > have no tools to do this in a way that = makes the status of these
> > documents visible to our = "customers".
> >
>
> My understanding is that that is one purpose of = the Experimental
> designation.

Which unfortunately I believe is not done as much by = WGs in the
IETF.
>
>         = jak

-bp

------_=_NextPart_001_01C31BE8.17FC28F0-- From problem-statement-bounces@alvestrand.no Fri May 16 16:18: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 QAA10035 for ; Fri, 16 May 2003 16:18:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A40C36257C; Fri, 16 May 2003 22:20:41 +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 7DD8B6257B for ; Fri, 16 May 2003 22:20:39 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.5]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA21158 for ; Fri, 16 May 2003 13:20:30 -0700 (PDT) Message-Id: <5.1.0.14.2.20030516161520.0405c2f8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 16 May 2003 16:16:37 -0400 To: problem-statement@alvestrand.no From: Margaret Wasserman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Apropos... X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 found this quote while looking for something else: "If you don't understand how things are connected, the cause of problems is solutions." - Amory B. Lovins, Rocky Mountain Institute This is probably a good thought to keep in mind, as we move ahead with this effort. Margaret From problem-statement-bounces@alvestrand.no Fri May 16 16:25: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 QAA10150 for ; Fri, 16 May 2003 16:25:21 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9DD976257C; Fri, 16 May 2003 22:27:52 +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 1D5FA6257B for ; Fri, 16 May 2003 22:27:50 +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 h4GKRhk10496; Fri, 16 May 2003 16:27:43 -0400 (EDT) Date: Fri, 16 May 2003 16:27:43 -0400 From: Keith Moore To: Pete Resnick Message-Id: <20030516162743.3b4091e5.moore@cs.utk.edu> In-Reply-To: References: <200305161703.h4GH3ODi023565@newdev.harvard.edu> <20030516143635.593e977a.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: sob@harvard.edu Subject: Re: Document Blocking (Was: I-D X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > >[Scott Bradner:] > >>in my experience, from time to time it was the case that I did not > >>see IESG consensus support for the concerns of a specific AD but > >>the normal IESG process does not make it easy to get around a > >>single AD's discuss - there is a process that was defined to do > >>this but it has never been used, and that process would not get > >>around a case where two ADs had issues that the rest of the IESG > >>did not share > > > >concur. very occasionally, it seemed to me that another IESG > >member's concerns were either unfounded or too trivial to hold up > >passage of the document. and at least while I was there, we didn't > >have a good way to work past those problems. > > I don't understand how that jibes with: > > >>The problem with the current process (as I understand it) is that > >>it allows documents to be blocked by one or two IESG members > >>without the consensus of the group. > > > >I don't see this as a problem at all. > > You concur with the problem outlined by Scott above: There have been > (perhaps rare) cases where someone claimed there to be a serious > enough problem to hold up a document where the other IESG member's > concerns were unfounded, yet there was no way to work past this hold > up. I think my biggest problem was with the suggestion that IESG consensus should be required to block a document, when that's clearly not feasible. I do think it would be useful to have some sort of mechanism (lighter weight than an appeal) by which a WG or IESG could push back on a single IESG member's objections when they seemed trivial or poorly founded. I don't have a good suggestion for how to do that, but I do feel certain that requiring IESG consensus on every Discuss is too onerous. > >Many of the issues that hold up document publication are not easily > >understood without expertise in that particular area. > > But if the expert in that area can't explain to the rest of the IESG > why all should agree with the "discuss", then: > > a) Perhaps it's unfounded Perhaps, but on balance it is safer to give the objecting IESG member the benefit of the doubt. And these days the co-AD often serves as a moderating influence in practice, even if he doesn't have formal power to veto his co-AD's Discuss. > b) How on earth is that "expert" going to explain it sufficiently to > the working group whose document is being held up. Often this is difficult, because the WG lacks the very expertise that is needed to understand the problem. But we shouldn't blame the IESG for the WG's lack of expertise. > As Dave said, "No matter how stellar the expertise of someone, if > they cannot convince others that their views are correct, something > is very, very wrong." And sometimes Dave is very, very wrong. What I might argue instead is that if success of a protocol hinges on something that is too subtle for most of its implementors and designers to understand, that success is doubtful even if the protocol specification properly considers that subtlety. But even that isn't always true. > >Also, IESG does not "block" documents, it explains what is wrong > >with them and sends them back to the working group. > > But, as Scott said: > > >>...since it can take an arbitrarily long time for the working group > >>(or document authors/editors) to respond to the concerns and an > >>arbitrarily long time for the back and forth between the AD for the > >>working group, the AD holding the discuss, the working group > >>chairs, and the working group the effect of the process may not be > >>distinguishable from a decision to not publish. Right, but IESG has timeouts in place for almost all phases of its deliberative process. It's the WG that can hold up things for arbitrary amounts of time (sometimes because the authors and/or chair are sitting on the document and the WG doesn't know what is happening, sometimes because the WG refuses to make changes and doesn't know what to do next). Now it might be useful to have a well-documented process by which IESG provides feedback to a WG on a document, including public disclosure of the feedback on a web page, and to have an explicit timeout by which a WG is expected to: a. revise the document and resubmit to IESG b. outline a plan for fixing the document and ask for approval of that plan c. abandon the document d. appeal But it would be even more useful to try to get an explicit dialogue going between the relevant ADs and the relevant WG participants, because most problems can be solved in this way. It's a real trick to outline a process that both streamlines getting things fixed that need to be fixed (hopefully the normal case), and at the same time provides mechanisms to safeguard against abuse. Most problems will be solved by dialogue, but it's hard to engage in productive dialogue under a deadline, say if you know you've got to resolve things in X days or you'll get burned. > >It's simply infeasible to expect all of IESG to reach consensus on > >every issue that requires a change to a document. For a deep > >technical issue, there *might* be four people on IESG who really > >have enough appreciation for that issue to express an informed > >opinion - and two of those might have to stretch to understand it. > > We're not talking about cases where some members of the IESG have a > technical issue and the rest say, "Well, I don't understand that well > enough to have a technical opinion on this, but you've convinced me > it's a serious enough issue to warrant discussing the document > further." That *is* consensus to discuss the document. It's when the > objecting members *don't* explain the problem sufficiently to > convince the others that there even *is* a serious issue. The IESG > certainly *must* come to consensus that there is a real issue before > stopping a document from moving along. Sometimes only one person on IESG really understands the problem. Maybe that AD should need to come up with some more support for his position somehow, if not on IESG than somewhere else. Maybe he should get to write a dissenting opinion. But I don't think it's reasonable to dismiss those concerns simply because nobody else on IESG understands them. And I think that at least initially the presumption should be that the AD is right - because he usually is, and he's having to stick out his neck to raise this objection. (Even before we had public disclosure of the IESG ballots, new ADs learned fairly quickly that raising substantial objections could cost them both in terms of ease of working with other IESG peoople, and in temrs of the time spent in discussion with the relevant parties to try to work out the differences. So there's a significant incentive to avoid raising non-trivial objections, sometimes even when they're fairly important. One result is that ADs raise trivial objections when more serious objections are really warranted.) > >A common case is to have one or two Yes votes, one or two Discuss > >votes, and the rest No Objection. That's not a case of one or two > >people holding up the document against an overwhelming majority. > >It's more like a tie. > > I would be deeply concerned if there were one or two Discuss, two > Yes, and the rest No Objection *and* the Discuss voter(s) couldn't > convince any of the Yes or No Objection people to change their votes > to Discuss. That's not the way it works. Since every Discuss vote has to be explicitly changed before the document can move forward, issues get resolved faster when there are fewer Discuss votes, and the polite thing to do is to not vote Discuss when someone else has already raised the same objection. so if you get multiple Discuss votes only when there is a very strong and widespread objection to a document, or when there are widely varying objections to a document. > >(I should clarify that IMHO the vast majority of IESG Discuss > >concerns were well-founded and appropriate.) > > That might be true. Understand, though, that given the current > process, it is impossible to tell the difference between the ones the > IESG considers well-founded and the one's it does not. I don't know whether this can be fixed. What seems to one person to be a trivial or unfounded concern might actually be deep wisdom. Keith From problem-statement-bounces@alvestrand.no Fri May 16 18:27: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 SAA13361 for ; Fri, 16 May 2003 18:27:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E4BDD62589; Sat, 17 May 2003 00:29: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 E9BF36257C for ; Sat, 17 May 2003 00:29:47 +0200 (CEST) Date: Sat, 17 May 2003 00:29:09 +0200 From: Harald Tveit Alvestrand To: problem-statement@alvestrand.no Message-ID: <27255260.1053131349@localhost> In-Reply-To: <5.1.0.14.2.20030516072814.04754080@mail.windriver.com> References: <1689790900.1053038959@localhost> <014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> <5.1.0.14.2.20030515113529.014ba800@mail.windriver.com> <014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> <5.1.0.14.2.20030516072814.04754080@mail.windriver.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: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 16. mai 2003 07:32 -0400 Margaret Wasserman wrote: > When documents are reviewed, it would be useful if we could > get two types of (clearly delineated) feedback: > > (1) Blocking issues that would prevent the publication > of the document at PS. In the opinion of the > reviewer (currently the IESG), it is worth > delaying publication of the document to fix > this problem. > (2) Non-blocking issues that should be fixed in the > next revision (and certainly before the > document goes to the next stage). > > Right now, any issue raised by the IESG (through a DISCUSS) is > treated as a blocking issue. The IESG tries to distinguish between blocking issues (DISCUSS comments) and non-blocking issues ("if the document is revised for other reasons, you might want to look at this too"). This will be made even more explicit in the upcoming more-automated process for IESG opininon-gathering. But - for instance quite a few of the "I-D Nits" are regarded as blocking issues (like "too many authors" or "formatting of code samples is broken" or "ABNF does not pass syntax check"). So a DISCUSS doesn't necessarily mean that it's an important architectural issue - just that it's something that, in the IESG's opinion, has to be fixed before publication. Harald From problem-statement-bounces@alvestrand.no Fri May 16 19:15: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 TAA14316 for ; Fri, 16 May 2003 19:15:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 85B2C6257C; Sat, 17 May 2003 01:17:51 +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 188CC6257B for ; Sat, 17 May 2003 01:17:48 +0200 (CEST) Received: from adsl-68-120-230-143.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4GNHTN29291 for ; Fri, 16 May 2003 16:17:29 -0700 Date: Fri, 16 May 2003 16:19:57 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <374107566.20030516161957@brandenburg.com> To: problem-statement@alvestrand.no In-Reply-To: <5.1.0.14.2.20030515115014.014db9f0@mail.windriver.com> References: <5.1.0.14.2.20030515115014.014db9f0@mail.windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: OPEN ISSUE: Improvement WG Oversight 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, I urge having ISOC oversight. Let's remember where the current effort came from. It was during an IESG Plenary during which a great many folks got up to the microphone and expressed serious displeasure, much of it with the IESG. It does not matter whether one agrees or disagrees with any or all of those speakers. What is important is that a broad base of discontent was demonstrated to exist. It *is* important to note that the kinds of concerns being expressed are largely identical to ones that were expressed 10 years ago, so the core issues are structural, rather than personal. However all of this is ultimately personal. Having the IESG control the IETF change process is a very pure structural conflict of interest. Having ISOC oversee the process is identical to ISOC's role with respect to NOMCOM, including minor items like choosing a chair for the effort. When change comes from broad-based discontent, it is essential that the principal managers of the change process be detached from either side of the discontent. d/ ps. For those who enjoy irony, I'll note that I was prompted to post my thoughts by Margaret, who knows full well the details of my disagreement with her... -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Fri May 16 19:17: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 TAA14346 for ; Fri, 16 May 2003 19:17:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D01B06258F; Sat, 17 May 2003 01:20:11 +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 9E4E36257B for ; Sat, 17 May 2003 01:20:05 +0200 (CEST) Received: from adsl-68-120-230-143.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4GNJiN29424; Fri, 16 May 2003 16:19:44 -0700 Date: Fri, 16 May 2003 16:22:12 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1464242340.20030516162212@brandenburg.com> To: Margaret Wasserman In-Reply-To: <5.1.0.14.2.20030515115941.014dbb30@mail.windriver.com> References: <5.1.0.14.2.20030515115941.014dbb30@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: OPEN ISSUE: Appeals Path 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> I think that a well-defined appeals process is needed for any MW> activity the size and scope of the proposed Improvement WG. There is no higher appeal than the IETF Plenary. Worrying about invoking "normal" appeals processes entirely misses the nature of this IETF change effort. This effort is not a typical technical specification effort, so let's not pretend that it must conform to our typical working group process. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Fri May 16 19:17: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 TAA14360 for ; Fri, 16 May 2003 19:17:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 297F8625A9; Sat, 17 May 2003 01:20:21 +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 7047F625A8 for ; Sat, 17 May 2003 01:20:18 +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 54B59B9AD; Fri, 16 May 2003 19:20: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); Fri, 16 May 2003 19:20:16 -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, 16 May 2003 19:20:15 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD899@tayexc13.americas.cpqcorp.net> Thread-Topic: OPEN ISSUE: Improvement WG Oversight Thread-Index: AcMcAWTpAn/yi08ARoi2fiDNMHQAjAAAD6TQ From: "Bound, Jim" To: "Dave Crocker" , X-OriginalArrivalTime: 16 May 2003 23:20:16.0210 (UTC) FILETIME=[B57FC320:01C31C01] Subject: RE: OPEN ISSUE: Improvement WG Oversight X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 TAA14360 This might be a good idea but also a slippery slope in that is ISOC going to do any better and all we have done is add more process to our system? /jim > -----Original Message----- > From: Dave Crocker [mailto:dhc@dcrocker.net] > Sent: Friday, May 16, 2003 7:20 PM > To: problem-statement@alvestrand.no > Subject: Re: OPEN ISSUE: Improvement WG Oversight > > > Folks, > > > I urge having ISOC oversight. > > Let's remember where the current effort came from. It was > during an IESG Plenary during which a great many folks got up > to the microphone and expressed serious displeasure, much of > it with the IESG. > > It does not matter whether one agrees or disagrees with any > or all of those speakers. What is important is that a broad > base of discontent was demonstrated to exist. > > It *is* important to note that the kinds of concerns being > expressed are largely identical to ones that were expressed > 10 years ago, so the core issues are structural, rather than > personal. However all of this is ultimately personal. > > Having the IESG control the IETF change process is a very > pure structural conflict of interest. > > Having ISOC oversee the process is identical to ISOC's role > with respect to NOMCOM, including minor items like choosing a > chair for the effort. > > When change comes from broad-based discontent, it is > essential that the principal managers of the change process > be detached from either side of the discontent. > > > d/ > > ps. For those who enjoy irony, I'll note that I was prompted > to post my thoughts by Margaret, who knows full well the > details of my disagreement with her... > > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > > From problem-statement-bounces@alvestrand.no Fri May 16 19:26: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 TAA14488 for ; Fri, 16 May 2003 19:26:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AF4986258E; Sat, 17 May 2003 01:29:03 +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 2CC376257B for ; Sat, 17 May 2003 01:29:00 +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 17815B9A0; Fri, 16 May 2003 19:28: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, 16 May 2003 19:28: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: Fri, 16 May 2003 19:28:58 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0324125E@tayexc13.americas.cpqcorp.net> Thread-Topic: OPEN ISSUE: Nomcom Process Thread-Index: AcMa+qL9lL8ppEE9SlSzRZrOvU2I7ABB0oZg From: "Bound, Jim" To: "Margaret Wasserman" , X-OriginalArrivalTime: 16 May 2003 23:28:58.0894 (UTC) FILETIME=[ED0B02E0:01C31C02] Subject: RE: OPEN ISSUE: Nomcom 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA14488 I do not believe we should take this discussion to the NOMCOM that process needs fixing too. Our job is to document the problem and the NOMCOM has problems. I do believe sending mail to the nomcom with specifics is fine but the problems there should be aired here too as they affect the very fabric of the only open process we have for the community to be able to add or remove IESG members. Now if someone would like me to send my issue to NOMCOM please send me what mail list to send to I have not the desire or time to get into another WG debate. My issue is I want the IESG out of the room at nomcom meetings unless called in for clarifications. They should NOT be present during the deliberations it is wrong and as I said it is like having the government in the voting booth with me. It is philosophically and morally wrong for the IESG to be in that room. Period. Also the statements around existing IESG members should receive special treatment during deliberations is completely bogus they should be judged on their results, their action, and their ability to guide an Area to success. If they did a bad job they should be removed (in multiple areas) if they did a good job they should be kept given that a more qualified candidate does not show up. The above two issues are a problem because they smell of academic tenure viewpoint and the IETF is not an academic exercise or institution but a standards body that is suppose to produce results and work. If that is not done the IETF has failed. /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Thursday, May 15, 2003 11:44 AM > To: problem-statement@alvestrand.no > Subject: OPEN ISSUE: Nomcom Process > > > > The process document currently says: > > >We may also need to modify our Nomcom processes so that IETF > >participants who are not part of the IETF leadership can have more > >visibility into the Nomcom process and more proportional input into > >leadership selection. [OPEN ISSUE: Do we have consensus > that these are > >real problems that need to be solved?] > > I believe that this is a real problem, and that we should > modify our Nomcom processes to do two (related) things: > > - Give the community more visibility into the > process. > - Get more feedback on potential candidates from > the community. Currently, some candidates > are discussed with the leaders (IESG/IAB > members and WG chairs), but the greater > community doesn't even know who is being > considered. > > Margaret > > > > From problem-statement-bounces@alvestrand.no Fri May 16 19:45: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 TAA14685 for ; Fri, 16 May 2003 19:45:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 60873625B6; Sat, 17 May 2003 01:48:06 +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 5C8D2625A8 for ; Sat, 17 May 2003 01:48:00 +0200 (CEST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) h4GNlv6I023704; Fri, 16 May 2003 16:47:57 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) h4GNlsBC005045; Fri, 16 May 2003 16:47:55 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <1464242340.20030516162212@brandenburg.com> References: <5.1.0.14.2.20030515115941.014dbb30@mail.windriver.com> <1464242340.20030516162212@brandenburg.com> Date: Fri, 16 May 2003 16:47:51 -0700 To: Dave Crocker , Margaret Wasserman From: hardie@qualcomm.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: problem-statement@alvestrand.no Cc: Dave Crocker Subject: Re: OPEN ISSUE: Appeals Path X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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:22 PM -0700 5/16/03, Dave Crocker wrote: >Margaret, > > >MW> I think that a well-defined appeals process is needed for any >MW> activity the size and scope of the proposed Improvement WG. > >There is no higher appeal than the IETF Plenary. Dave, Could you expand on how that actually works? I see the IETF plenary as a very important tool for ensuring that anyone in the community has a voice that carries beyond a particular working group or area. I am not sure that it can be an effective appeals body or what process it would use if we decided it should be one. Fundamentally, the time allotted to Plenary meetings by our current schedule is very short, and the issues we are dealing with very complex. Even assuming that we limited folks' time and trips to the microphone, we seem unlikely to resolve any substantive issues inside a meeting. The one appeal I heard in my short term on the IAB took a great deal of both focused time discussing the issue and even more wording a response; I don't think we have that in Plenary meetings. To put it another way, the open mic at a plenary ensures that issues can be raised, but it seems a poor context for actually resolving the issues or appeals. It also fundamentally misses our usual point that participating in the IETF can take place outside the face-to-face meetings, as it requires those not attending a particular meeting to make some other arrangements for participation. With the jabber conferences, it is easier, though time shifting and other barriers remain. regards, Ted Hardie >Worrying about invoking "normal" appeals processes entirely misses the >nature of this IETF change effort. > >This effort is not a typical technical specification effort, so let's >not pretend that it must conform to our typical working group process. > > > >d/ >-- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Fri May 16 20:09: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 UAA14998 for ; Fri, 16 May 2003 20:09:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6359E625A8; Sat, 17 May 2003 02:11: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 D434F6257B for ; Sat, 17 May 2003 02:11:35 +0200 (CEST) Received: from adsl-68-120-230-143.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4H0BEN31805; Fri, 16 May 2003 17:11:14 -0700 Date: Fri, 16 May 2003 17:13:42 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <577331692.20030516171342@brandenburg.com> To: Brian E Carpenter In-Reply-To: <3EC4DE50.D04E601C@hursley.ibm.com> References: <200305131200.IAA05317@ietf.org> <3EC4DE50.D04E601C@hursley.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: I-D ACTION:draft-ietf-problem-process-00.txt 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 Brian, >> 5. Modify IESG-internal processes to make it impossible for one >> or two IESG members to block a document. BEC> There is a strong implication here that ADs might do this for BEC> spurious reasons. At base, the reasons do not matter. It simply is not reasonable for any one (or two) people to weild that much power. A group based on Rough Consensus should rely on those having a point of view being able to recruit others to support that view. If they cannot succeed in their recruitment effort, there is something wrong with their view. We believe in technical expertise, not technical deities. Expertise is compelling, when the expertise is real. Only deities warrant individual veto authority in this community. BEC> But if one or both Security ADs are deeply BEC> convinced that a draft constitutes a major security risk, or one BEC> or both Routing ADs are convinced that a draft will lead to routing BEC> loops, isn't it quite appropriate for them to block the document? If they cannot convince others of the correctness in their views, then no. The failure to make a compelling case strongly suggests that the case is itself problematic. BEC> A very important step is missing here. All IETF process documents need BEC> to be formally accepted by the ISOC Board, to ensure that we have the BEC> necessary chain of authority to validate the liability insurance. Thanks for catching this. >> 5.2.2.2 ISOC-Directed Approach >> >> Another approach would be to ask the ISOC President and the ISOC >> Board of Trustees (ISOC BoT) to assume responsibility for the >> oversight of the IETF Improvement WG, similar to our current >> Nominations Committee processes, as defined in RFC 2727 [RFC2727]. >> BEC> Although I am currently an ISOC Trustee, I certainly can't speak for BEC> the ISOC on this. However, I wouldn't advocate it. Only a few members BEC> of the ISOC Board are truly familiar with the IETF's internal workings. BEC> Having the Board accept the final documents, as noted above, is enough. The idea is to model the process after the ISOC portion of the Nomcom process. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Fri May 16 20:26: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 UAA15273 for ; Fri, 16 May 2003 20:26:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 65D96625A4; Sat, 17 May 2003 02:28:58 +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 EBD1A6257B for ; Sat, 17 May 2003 02:28:55 +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.1b1); Fri, 16 May 2003 19:29:10 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <20030516162743.3b4091e5.moore@cs.utk.edu> References: <200305161703.h4GH3ODi023565@newdev.harvard.edu> <20030516143635.593e977a.moore@cs.utk.edu> <20030516162743.3b4091e5.moore@cs.utk.edu> X-Mailer: Eudora [Macintosh version 6.0a15] Date: Fri, 16 May 2003 19:28:51 -0500 To: Keith Moore From: Pete Resnick Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: problem-statement@alvestrand.no Subject: Re: Document Blocking (Was: I-D X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 5/16/03 at 4:27 PM -0400, Keith Moore wrote: >I do think it would be useful to have some sort of mechanism >(lighter weight than an appeal) by which a WG or IESG could push >back on a single IESG member's objections when they seemed trivial >or poorly founded. Agree completely. I think that's what I've been looking for. >I don't have a good suggestion for how to do that, but I do feel >certain that requiring IESG consensus on every Discuss is too >onerous. Actually, I think with such a lightweight mechanism in place, this is exactly what you get: If someone says "discuss" and the rest of the IESG thinks it is reasonable (even if they don't exactly understand the details of the problem), then the IESG as a whole has rough consensus to discuss. If a large proportion of the IESG thinks it is trivial or poorly founded, then the IESG does not have consensus and the mechanism can be used to push back on the "discuss". Don't get hung up on "consensus" when thinking about it in the context of the current process. In the current process, I consider one "discuss" and the rest "no objection and the discuss seems legit" to be consensus to discuss. It's just that in the current process, that is indistinguishable from one "discuss" and the rest "no objection and the discuss sounds like complete nonsense to me and no one has explained to me what the problem is." The latter isn't consensus, and I think we agree that we don't like the latter, however rare it might be. >>As Dave said, "No matter how stellar the expertise of someone, if >>they cannot convince others that their views are correct, something >>is very, very wrong." > >And sometimes Dave is very, very wrong. Thanks, that really helped progress this discussion. :-( (Let's try to keep this nonsense out of the discussion from now on.) >What I might argue instead is that if success of a protocol hinges >on something that is too subtle for most of its implementors and >designers to understand, that success is doubtful even if the >protocol specification properly considers that subtlety. But even >that isn't always true. Perhaps, but again, if these occurrences are rare anyway, I don't see why we cannot expect an expert to explain this to the satisfaction of at least the rest of the IESG, if not the WG. >Right, but IESG has timeouts in place for almost all phases of its >deliberative process. It's the WG that can hold up things for >arbitrary amounts of time (sometimes because the authors and/or >chair are sitting on the document and the WG doesn't know what is >happening, sometimes because the WG refuses to make changes and >doesn't know what to do next). Let's not get into finger pointing here. We both know of situations where a document is stuck in the WG (for both unreasonable and reasonable cause), we both know of situations where the IESG has ignored timeouts (for both unreasonable and reasonable cause), and we both know of cases where the token has gotten lost (which can occur even now with the tracker, when there is a discuss item that the WG doesn't understand and can't get enough feedback to fix). We've been talking about unsticking at one point, within the IESG. It is a separate problem to deal with unsticking within the WG, which is probably even trickier. >Now it might be useful to have a well-documented process by which >IESG provides feedback to a WG on a document, including public >disclosure of the feedback on a web page, and to have an explicit >timeout by which a WG is expected to: > >a. revise the document and resubmit to IESG >b. outline a plan for fixing the document and ask for approval of that plan >c. abandon the document >d. appeal Agree wholeheartedly. >But it would be even more useful to try to get an explicit dialogue >going between the relevant ADs and the relevant WG participants, >because most problems can be solved in this way. Most of the time, I think that actually exists. I think what we are talking about here is solving the problem for the times that it doesn't, because those failures are what sticks out like a sore thumb (and engenders distrust between the IESG and the rest of the IETF). >(Even before we had public disclosure of the IESG ballots, new ADs >learned fairly quickly that raising substantial objections could >cost them both in terms of ease of working with other IESG peoople, >and in temrs of the time spent in discussion with the relevant >parties to try to work out the differences. So there's a significant >incentive to avoid raising non-trivial objections, sometimes even >when they're fairly important. One result is that ADs raise trivial >objections when more serious objections are really warranted.) I've heard this from several former ADs, and perhaps it indicates a further problem: The idea that because one AD raises substantial objections, other ADs would make life difficult for him or her, and that trivial objections do not cause that, is unbelievably bad. It is a further indication of distrust among the ADs in the IESG, the very same thing that would make anyone think that "a way to stop bad things from happening" type of veto is necessary. I find the idea that any AD would behave this way instant grounds for recall. The IESG is supposed to be acting as a group to do global-issue review. If new ADs are forced to hold their tongues, we need to start replacing the old ADs. As far as time spent discussing the problems, it seems that a knowledgeable directorate would solve that problem. >>I would be deeply concerned if there were one or two Discuss, two >>Yes, and the rest No Objection *and* the Discuss voter(s) couldn't >>convince any of the Yes or No Objection people to change their >>votes to Discuss. > >That's not the way it works. Since every Discuss vote has to be >explicitly changed before the document can move forward, issues get >resolved faster when there are fewer Discuss votes, and the polite >thing to do is to not vote Discuss when someone else has already >raised the same objection. so if you get multiple Discuss votes only >when there is a very strong and widespread objection to a document, >or when there are widely varying objections to a document. I know that's not the way it works now. But now that the process is becoming more public (due to the tracker), I really think it needs to be that way. At the very least, you should never see a single Discuss and two Yes votes; that would be an indication (to an outside observer) of serious disagreement in the IESG and something that needs explanation. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From problem-statement-bounces@alvestrand.no Fri May 16 21:25: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 VAA16237 for ; Fri, 16 May 2003 21:25:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 336BB62588; Sat, 17 May 2003 03:27:45 +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 072AB6256B for ; Sat, 17 May 2003 03:27:42 +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 19GqTy-0003v2-00; Fri, 16 May 2003 18:27:30 -0700 Date: Fri, 16 May 2003 21:26:41 -0400 From: Keith Moore To: Pete Resnick Message-Id: <20030516212641.3f206f49.moore@cs.utk.edu> In-Reply-To: References: <200305161703.h4GH3ODi023565@newdev.harvard.edu> <20030516143635.593e977a.moore@cs.utk.edu> <20030516162743.3b4091e5.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 Subject: Re: Document Blocking (Was: I-D X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > >Right, but IESG has timeouts in place for almost all phases of its > >deliberative process. It's the WG that can hold up things for > >arbitrary amounts of time (sometimes because the authors and/or > >chair are sitting on the document and the WG doesn't know what is > >happening, sometimes because the WG refuses to make changes and > >doesn't know what to do next). > > Let's not get into finger pointing here. We both know of situations > where a document is stuck in the WG (for both unreasonable and > reasonable cause), we both know of situations where the IESG has > ignored timeouts (for both unreasonable and reasonable cause), actually, no. I don't know of a case where the latter has occurred. > and we both know of cases where the token has gotten lost (which can > occur even now with the tracker, when there is a discuss item that > the WG doesn't understand and can't get enough feedback to fix). > We've been talking about unsticking at one point, within the IESG. > It is a separate problem to deal with unsticking within the WG, > which is probably even trickier. I'm all for unsticking things. But I suspect we're to the point that IESG is largely unstuck, and that most of the documents that get stuck are stuck either within a WG or because of poor communications. So I'm interested in focusing on these sources of stickiness. Also, I think that unsticking IESG is better left to IESG - i.e. to people who understand the subtleties of that environment, and who have more than adequate interest in working more effectively. > >(Even before we had public disclosure of the IESG ballots, new ADs > >learned fairly quickly that raising substantial objections could > >cost them both in terms of ease of working with other IESG peoople, > >and in temrs of the time spent in discussion with the relevant > >parties to try to work out the differences. So there's a significant > >incentive to avoid raising non-trivial objections, sometimes even > >when they're fairly important. One result is that ADs raise trivial > >objections when more serious objections are really warranted.) > > I've heard this from several former ADs, and perhaps it indicates a > further problem: The idea that because one AD raises substantial > objections, other ADs would make life difficult for him or her, and > that trivial objections do not cause that, is unbelievably bad. It is > a further indication of distrust among the ADs in the IESG, the very > same thing that would make anyone think that "a way to stop bad > things from happening" type of veto is necessary. I find the idea > that any AD would behave this way instant grounds for recall. I agree with you that ADs don't (or at least didn't when I was on IESG) always have enough trust of one another. I hope things are better now, but I suspect some of the distrust is inherent in the combination of diversity of backgrounds and workload. Regarding the veto and recall, I don't follow what you are saying. I don't know that anyone deliberately tried to make life difficult for me because I raised technical objections when I was on IESG. I do think there was an atmosphere of "hey, we have enough work to do as it is, please don't make things more difficult unless you have a good reason" along with (sometimes) a failure to recognize good reasons. > >>I would be deeply concerned if there were one or two Discuss, two > >>Yes, and the rest No Objection *and* the Discuss voter(s) couldn't > >>convince any of the Yes or No Objection people to change their > >>votes to Discuss. > > > >That's not the way it works. Since every Discuss vote has to be > >explicitly changed before the document can move forward, issues get > >resolved faster when there are fewer Discuss votes, and the polite > >thing to do is to not vote Discuss when someone else has already > >raised the same objection. so if you get multiple Discuss votes only > >when there is a very strong and widespread objection to a document, > >or when there are widely varying objections to a document. > > I know that's not the way it works now. But now that the process is > becoming more public (due to the tracker), I really think it needs to > be that way. At the very least, you should never see a single Discuss > and two Yes votes; that would be an indication (to an outside > observer) of serious disagreement in the IESG and something that > needs explanation. Well, again, I think changes to how IESG works internally are better left for IESG to make. They have plenty of incentive and they are more likely to understand the effects of those changes than non-members or even former members. Keith From problem-statement-bounces@alvestrand.no Fri May 16 21:26: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 VAA16273 for ; Fri, 16 May 2003 21:26:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DAED96257B; Sat, 17 May 2003 03:29:27 +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 455076256B for ; Sat, 17 May 2003 03:29:25 +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 30960A8C9; Fri, 16 May 2003 21:29: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); Fri, 16 May 2003 21:29: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: Fri, 16 May 2003 21:29:23 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0324125F@tayexc13.americas.cpqcorp.net> Thread-Topic: OPEN ISSUE: Appeals Path Thread-Index: AcMcBZ5r8WrwqSLMS/uu9u6NEekOZgAC7ktg From: "Bound, Jim" To: , "Dave Crocker" , "Margaret Wasserman" X-OriginalArrivalTime: 17 May 2003 01:29:24.0066 (UTC) FILETIME=[BF94C420:01C31C13] Cc: problem-statement@alvestrand.no Cc: Dave Crocker Subject: RE: OPEN ISSUE: Appeals Path X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 VAA16273 The IETF plenary is less than a jesters court and I cannot think of one thing that has changed because of it? Be glad to hear if others can tell us? Why do any beleive the current appeals process does not work? I say it does. This is not broken in the IETF is my view. I find plenary's totally boring though usually, and it should also not be a forum to trash the IESG that is not good I believe today. The IESG is trying to do a job if there is an issue take it to them if one still has an issue use the appeals. For example running code I believe has been forgotten as good input to whether a standards tracked document is in fact useful as input. Whether that is true or not is not the debate here but going to the plenary and complaining about it is stupid and a waste of ones time. We also don't want PS to become held up for running code in most cases.Also if I were IESG member and someone said they had running code I would grill them to prove it and demonsrate it, or point to bake-off where it is running. Just because one hacks up a kernel for one part of a spec does not mean the spec or code is correct for the standard. But, it does demonstrate a serious effort and belief in the work. But Avri's talk on the IETF problem space work was an EXCELLENT use of IESG Plenary time at the San Francisco meeting. That is what it can do well which is the communications to masses stated below. That I agree with. Also Haralds update on the finanical condition. Those talks were useful information. But in Yokohamma the implementors were completely misrepresented for IPv6 and the community heard only one side of that story it was completely biased. Nothing is perfect so I for one let it go though I was prodded by well over 20 members to go bitch about it to the IESG I just stated it is not worth our time nor will it affect anything regarding IPv6 implementation momentum. Also getting any real work done in a room with > 300 people is absurd. /jim > -----Original Message----- > From: hardie@qualcomm.com [mailto:hardie@qualcomm.com] > Sent: Friday, May 16, 2003 7:48 PM > To: Dave Crocker; Margaret Wasserman > Cc: problem-statement@alvestrand.no; Dave Crocker > Subject: Re: OPEN ISSUE: Appeals Path > > > At 4:22 PM -0700 5/16/03, Dave Crocker wrote: > >Margaret, > > > > > >MW> I think that a well-defined appeals process is needed for any > >MW> activity the size and scope of the proposed Improvement WG. > > > >There is no higher appeal than the IETF Plenary. > > Dave, > > Could you expand on how that actually works? > > I see the IETF plenary as a very important tool for ensuring > that anyone in the community has a voice that carries beyond > a particular working group or area. I am not sure that it > can be an effective appeals body or what process it would use > if we decided it should be one. Fundamentally, the time > allotted to Plenary meetings by our current schedule is very > short, and the issues we are dealing with very complex. Even > assuming that we limited folks' time and trips to the > microphone, we seem unlikely to resolve any substantive > issues inside a meeting. The one appeal I heard in my short > term on the IAB took a great deal of both focused time > discussing the issue and even more wording a response; I > don't think we have that in Plenary meetings. > > To put it another way, the open mic at a plenary ensures that > issues can be raised, but it seems a poor context for > actually resolving the issues or appeals. > > It also fundamentally misses our usual point that > participating in the IETF can take place outside the > face-to-face meetings, as it requires those not attending a > particular meeting to make some other arrangements for > participation. With the jabber conferences, it is easier, > though time shifting and other barriers remain. > > regards, > Ted Hardie > > > >Worrying about invoking "normal" appeals processes entirely > misses the > >nature of this IETF change effort. > > > >This effort is not a typical technical specification effort, > so let's > >not pretend that it must conform to our typical working > group process. > > > > > > > >d/ > >-- > > Dave Crocker > > Brandenburg InternetWorking > > Sunnyvale, CA USA , > > From problem-statement-bounces@alvestrand.no Fri May 16 21:32: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 VAA16379 for ; Fri, 16 May 2003 21:32:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2367E625C3; Sat, 17 May 2003 03:35: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 D7F956256B for ; Sat, 17 May 2003 03:35: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 C61C17F1C; Fri, 16 May 2003 21:35:12 -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, 16 May 2003 21:35: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: Fri, 16 May 2003 21:35:12 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD8A1@tayexc13.americas.cpqcorp.net> Thread-Topic: Document Blocking (Was: I-D Thread-Index: AcMcC1cGW+3+PZz3TgegdKkAygVocwACMFrg From: "Bound, Jim" To: "Pete Resnick" , "Keith Moore" X-OriginalArrivalTime: 17 May 2003 01:35:12.0642 (UTC) FILETIME=[8F593E20:01C31C14] Cc: problem-statement@alvestrand.no Subject: RE: Document Blocking (Was: I-D X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 VAA16379 I don't disagree with the lightweight process but I think it far easier just to have an IESG member defend their pushback or whatever on the mail list and working group. Discuss it with the members have debate. If we use this as a more and folkway as part of the role and job of an IESG member and document it we don't need yet another process. The IESG is suppose to be our partners and we just need to make a rule or something that our partners have to the same as any member in this community and defend and debate their push back if they want to overrule a WG and Chair. Now if that don't create compromise then the IESG can be swayed by the AD to reject a proposal and document why. Then one uses the appeal process we have. /jim > -----Original Message----- > From: Pete Resnick [mailto:presnick@qualcomm.com] > Sent: Friday, May 16, 2003 8:29 PM > To: Keith Moore > Cc: problem-statement@alvestrand.no > Subject: Re: Document Blocking (Was: I-D > > > On 5/16/03 at 4:27 PM -0400, Keith Moore wrote: > > >I do think it would be useful to have some sort of mechanism > >(lighter weight than an appeal) by which a WG or IESG could push > >back on a single IESG member's objections when they seemed trivial > >or poorly founded. > > Agree completely. I think that's what I've been looking for. > > >I don't have a good suggestion for how to do that, but I do feel > >certain that requiring IESG consensus on every Discuss is too > >onerous. > > Actually, I think with such a lightweight mechanism in place, this is > exactly what you get: If someone says "discuss" and the rest of the > IESG thinks it is reasonable (even if they don't exactly understand > the details of the problem), then the IESG as a whole has rough > consensus to discuss. If a large proportion of the IESG thinks it is > trivial or poorly founded, then the IESG does not have consensus and > the mechanism can be used to push back on the "discuss". > > Don't get hung up on "consensus" when thinking about it in the > context of the current process. In the current process, I consider > one "discuss" and the rest "no objection and the discuss seems legit" > to be consensus to discuss. It's just that in the current process, > that is indistinguishable from one "discuss" and the rest "no > objection and the discuss sounds like complete nonsense to me and no > one has explained to me what the problem is." The latter isn't > consensus, and I think we agree that we don't like the latter, > however rare it might be. > > >>As Dave said, "No matter how stellar the expertise of someone, if > >>they cannot convince others that their views are correct, something > >>is very, very wrong." > > > >And sometimes Dave is very, very wrong. > > Thanks, that really helped progress this discussion. :-( > > (Let's try to keep this nonsense out of the discussion from now on.) > > >What I might argue instead is that if success of a protocol hinges > >on something that is too subtle for most of its implementors and > >designers to understand, that success is doubtful even if the > >protocol specification properly considers that subtlety. But even > >that isn't always true. > > Perhaps, but again, if these occurrences are rare anyway, I don't see > why we cannot expect an expert to explain this to the satisfaction of > at least the rest of the IESG, if not the WG. > > >Right, but IESG has timeouts in place for almost all phases of its > >deliberative process. It's the WG that can hold up things for > >arbitrary amounts of time (sometimes because the authors and/or > >chair are sitting on the document and the WG doesn't know what is > >happening, sometimes because the WG refuses to make changes and > >doesn't know what to do next). > > Let's not get into finger pointing here. We both know of situations > where a document is stuck in the WG (for both unreasonable and > reasonable cause), we both know of situations where the IESG has > ignored timeouts (for both unreasonable and reasonable cause), and we > both know of cases where the token has gotten lost (which can occur > even now with the tracker, when there is a discuss item that the WG > doesn't understand and can't get enough feedback to fix). We've been > talking about unsticking at one point, within the IESG. It is a > separate problem to deal with unsticking within the WG, which is > probably even trickier. > > >Now it might be useful to have a well-documented process by which > >IESG provides feedback to a WG on a document, including public > >disclosure of the feedback on a web page, and to have an explicit > >timeout by which a WG is expected to: > > > >a. revise the document and resubmit to IESG > >b. outline a plan for fixing the document and ask for > approval of that > >plan c. abandon the document d. appeal > > Agree wholeheartedly. > > >But it would be even more useful to try to get an explicit dialogue > >going between the relevant ADs and the relevant WG participants, > >because most problems can be solved in this way. > > Most of the time, I think that actually exists. I think what we are > talking about here is solving the problem for the times that it > doesn't, because those failures are what sticks out like a sore thumb > (and engenders distrust between the IESG and the rest of the IETF). > > >(Even before we had public disclosure of the IESG ballots, new ADs > >learned fairly quickly that raising substantial objections could > >cost them both in terms of ease of working with other IESG peoople, > >and in temrs of the time spent in discussion with the relevant > >parties to try to work out the differences. So there's a significant > >incentive to avoid raising non-trivial objections, sometimes even > >when they're fairly important. One result is that ADs raise trivial > >objections when more serious objections are really warranted.) > > I've heard this from several former ADs, and perhaps it indicates a > further problem: The idea that because one AD raises substantial > objections, other ADs would make life difficult for him or her, and > that trivial objections do not cause that, is unbelievably bad. It is > a further indication of distrust among the ADs in the IESG, the very > same thing that would make anyone think that "a way to stop bad > things from happening" type of veto is necessary. I find the idea > that any AD would behave this way instant grounds for recall. The > IESG is supposed to be acting as a group to do global-issue review. > If new ADs are forced to hold their tongues, we need to start > replacing the old ADs. > > As far as time spent discussing the problems, it seems that a > knowledgeable directorate would solve that problem. > > >>I would be deeply concerned if there were one or two Discuss, two > >>Yes, and the rest No Objection *and* the Discuss voter(s) couldn't > >>convince any of the Yes or No Objection people to change their > >>votes to Discuss. > > > >That's not the way it works. Since every Discuss vote has to be > >explicitly changed before the document can move forward, issues get > >resolved faster when there are fewer Discuss votes, and the polite > >thing to do is to not vote Discuss when someone else has already > >raised the same objection. so if you get multiple Discuss votes only > >when there is a very strong and widespread objection to a document, > >or when there are widely varying objections to a document. > > I know that's not the way it works now. But now that the process is > becoming more public (due to the tracker), I really think it needs to > be that way. At the very least, you should never see a single Discuss > and two Yes votes; that would be an indication (to an outside > observer) of serious disagreement in the IESG and something that > needs explanation. > > pr > -- > Pete Resnick > QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: > (858)651-1102 > From problem-statement-bounces@alvestrand.no Fri May 16 21:38: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 VAA16537 for ; Fri, 16 May 2003 21:38:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 66CB9625C7; Sat, 17 May 2003 03:41:19 +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 19B17625C6 for ; Sat, 17 May 2003 03:41:16 +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 19Gqh7-0007W3-00; Fri, 16 May 2003 18:41:05 -0700 Date: Fri, 16 May 2003 21:40:16 -0400 From: Keith Moore To: "Bound, Jim" Message-Id: <20030516214016.6b5fc3c0.moore@cs.utk.edu> In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD8A1@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD8A1@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: presnick@qualcomm.com Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: Document Blocking (Was: I-D X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 disagree with the lightweight process but I think it far easier > just to have an IESG member defend their pushback or whatever on the > mail list and working group. Discuss it with the members have debate. > If we use this as a more and folkway as part of the role and job of an > IESG member and document it we don't need yet another process. My intuitive sense is that IESG has more than enough process already, which is part of why I'm resisting suggestions to impose more requirements on them. From problem-statement-bounces@alvestrand.no Fri May 16 21:40: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 VAA16594 for ; Fri, 16 May 2003 21:40:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 768BE625C6; Sat, 17 May 2003 03:43:15 +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 296BD6256B for ; Sat, 17 May 2003 03:43: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 79559A565; Fri, 16 May 2003 21:43: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); Fri, 16 May 2003 21:43: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: Fri, 16 May 2003 21:43:11 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD8A4@tayexc13.americas.cpqcorp.net> Thread-Topic: Document Blocking (Was: I-D Thread-Index: AcMcFWXQ91dalXRYTT+2LT2aSXge4QAADboQ From: "Bound, Jim" To: "Keith Moore" X-OriginalArrivalTime: 17 May 2003 01:43:12.0406 (UTC) FILETIME=[AD4F6B60:01C31C15] Cc: presnick@qualcomm.com Cc: problem-statement@alvestrand.no Subject: RE: Document Blocking (Was: I-D X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 VAA16594 I agree with adding more process. I want them to be accountable to explain their actions and in writing somewhere that is all. /jim > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Friday, May 16, 2003 9:40 PM > To: Bound, Jim > Cc: moore@cs.utk.edu; presnick@qualcomm.com; > problem-statement@alvestrand.no > Subject: Re: Document Blocking (Was: I-D > > > > I don't disagree with the lightweight process but I think it far > > easier just to have an IESG member defend their pushback or > whatever > > on the mail list and working group. Discuss it with the > members have > > debate. If we use this as a more and folkway as part of the > role and > > job of an IESG member and document it we don't need yet another > > process. > > My intuitive sense is that IESG has more than enough process > already, which is part of why I'm resisting suggestions to > impose more requirements on them. > > From problem-statement-bounces@alvestrand.no Fri May 16 21:46: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 VAA16707 for ; Fri, 16 May 2003 21:46:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E181E625CC; Sat, 17 May 2003 03:48:56 +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 3401A625CA for ; Sat, 17 May 2003 03:48: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 7D02A1EDE; Fri, 16 May 2003 21:48: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); Fri, 16 May 2003 21:48: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: Fri, 16 May 2003 21:48:53 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD8A6@tayexc13.americas.cpqcorp.net> Thread-Topic: Document Blocking (Was: I-D Thread-Index: AcMcFWXQ91dalXRYTT+2LT2aSXge4QAADboQAAA2kRA= From: "Bound, Jim" To: "Bound, Jim" , "Keith Moore" X-OriginalArrivalTime: 17 May 2003 01:48:54.0387 (UTC) FILETIME=[79259430:01C31C16] Cc: presnick@qualcomm.com Cc: problem-statement@alvestrand.no Subject: RE: Document Blocking (Was: I-D X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 VAA16707 meaning agree to add no more process if at all possible. /jim > -----Original Message----- > From: Bound, Jim > Sent: Friday, May 16, 2003 9:43 PM > To: Keith Moore > Cc: presnick@qualcomm.com; problem-statement@alvestrand.no > Subject: RE: Document Blocking (Was: I-D > > > I agree with adding more process. I want them to be > accountable to explain their actions and in writing somewhere > that is all. /jim > > > -----Original Message----- > > From: Keith Moore [mailto:moore@cs.utk.edu] > > Sent: Friday, May 16, 2003 9:40 PM > > To: Bound, Jim > > Cc: moore@cs.utk.edu; presnick@qualcomm.com; > > problem-statement@alvestrand.no > > Subject: Re: Document Blocking (Was: I-D > > > > > > > I don't disagree with the lightweight process but I think it far > > > easier just to have an IESG member defend their pushback or > > whatever > > > on the mail list and working group. Discuss it with the > > members have > > > debate. If we use this as a more and folkway as part of the > > role and > > > job of an IESG member and document it we don't need yet another > > > process. > > > > My intuitive sense is that IESG has more than enough process > > already, which is part of why I'm resisting suggestions to > > impose more requirements on them. > > > > > From problem-statement-bounces@alvestrand.no Fri May 16 23:00: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 XAA17875 for ; Fri, 16 May 2003 23:00:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A307062207; Sat, 17 May 2003 05:03:31 +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 8D4FF621FA for ; Sat, 17 May 2003 05:03:28 +0200 (CEST) Received: from adsl-68-120-230-143.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4H336N05927; Fri, 16 May 2003 20:03:06 -0700 Date: Fri, 16 May 2003 20:05:34 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <4517643810.20030516200534@brandenburg.com> To: Margaret Wasserman In-Reply-To: <5.1.0.14.2.20030515114433.04767ac8@mail.windriver.com> References: <5.1.0.14.2.20030515114433.04767ac8@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: OPEN ISSUE: WG Chair Selection 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> However, it is important for ADs and WG chairs to have a good MW> relationship, and for the AD to have authority over the WG MW> chair. I believe that the current reporting relationship MW> (AD chooses WG chair, chair serves at ADs pleasure) is MW> appropriate. So the chair and working group who well might specify changes to the IESG are to be managed by someone in the IESG? I always thought that "conflict of interest" was a pretty simple concept. How many of us would like to be hired by someone who gives us the job of telling them what their job will be? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Fri May 16 23:01: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 XAA17905 for ; Fri, 16 May 2003 23:01:33 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EB0AE625CF; Sat, 17 May 2003 05:04: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 1AD31625CF for ; Sat, 17 May 2003 05:03:40 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id UAA10997; Fri, 16 May 2003 20:03:25 -0700 (PDT) Message-Id: <5.1.0.14.2.20030516225741.0409ee40@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 16 May 2003 22:59:25 -0400 To: Dave Crocker From: Margaret Wasserman In-Reply-To: <1464242340.20030516162212@brandenburg.com> References: <5.1.0.14.2.20030515115941.014dbb30@mail.windriver.com> <5.1.0.14.2.20030515115941.014dbb30@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Appeals Path X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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:22 PM 5/16/2003 -0700, Dave Crocker wrote: >MW> I think that a well-defined appeals process is needed for any >MW> activity the size and scope of the proposed Improvement WG. > >There is no higher appeal than the IETF Plenary. So, if a WG member has a problem with an action taken by the WG chair, how will that be appealed to the plenary? Or will the aggrieved party have to wait until the conclusion of the process, when consensus on the results is sought during the plenary? At that point, how would an appeal on a months- old action be constructively raised? Margaret From problem-statement-bounces@alvestrand.no Fri May 16 23:01: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 XAA17927 for ; Fri, 16 May 2003 23:01:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 28C6C625D5; Sat, 17 May 2003 05:04:11 +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 6DAB7621FA for ; Sat, 17 May 2003 05:03:40 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id UAA10981; Fri, 16 May 2003 20:03:23 -0700 (PDT) Message-Id: <5.1.0.14.2.20030516225105.0407f378@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 16 May 2003 22:57:36 -0400 To: Dave Crocker From: Margaret Wasserman In-Reply-To: <374107566.20030516161957@brandenburg.com> References: <5.1.0.14.2.20030515115014.014db9f0@mail.windriver.com> <5.1.0.14.2.20030515115014.014db9f0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Improvement WG Oversight X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 04:19 PM 5/16/2003 -0700, Dave Crocker wrote: >Let's remember where the current effort came from. It was during an >IESG Plenary during which a great many folks got up to the microphone >and expressed serious displeasure, much of it with the IESG. > >It does not matter whether one agrees or disagrees with any or all of >those speakers. What is important is that a broad base of discontent >was demonstrated to exist. In my opinion, the existence of discontent does not necessarily indicate the desire to overthrow the leadership. If there is consensus at a plenary that a serious problem exists, I think that it is the IESG's job to address that problem. As long as the IESG acknowledges the problem and is responsive to it, I don't think that there is any reason to take the IESG out of the loop. >Having the IESG control the IETF change process is a very pure >structural conflict of interest. In what sense? It is quite common for the executive staff of a company to lead a reorganization, or for other types of groups to make changes to their own organization and processes. The U.S. Congress, for example, can pass legislation that changes the roles and responsibilities of Congressmen, and they can even give themselves a raise. As far as I know, none of this is seen as "conflict of interest". >Having ISOC oversee the process is identical to ISOC's role with respect >to NOMCOM, including minor items like choosing a chair for the effort. Not really. The Nomcom is a closed body. It isn't intended to run an open process or produce documents. >ps. For those who enjoy irony, I'll note that I was prompted to post my >thoughts by Margaret, who knows full well the details of my disagreement >with her... Why is this ironic. I raised the issues because I wanted them to be discussed. I think it is only fair that views from both major sides of each issues should be expressed, so that members of the WG can make an informed decision between the choices. I stated my views, but I didn't think that I could fairly state the pro-ISOC-directed view. Margaret From problem-statement-bounces@alvestrand.no Fri May 16 23:21: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 XAA18160 for ; Fri, 16 May 2003 23:21:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 23E37625D8; Sat, 17 May 2003 05:24:12 +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 54F7D625D2 for ; Sat, 17 May 2003 05:24:10 +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 81B63CD9B; Fri, 16 May 2003 23:24:09 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 16 May 2003 23:24:09 -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, 16 May 2003 23:24:08 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD8C0@tayexc13.americas.cpqcorp.net> Thread-Topic: OPEN ISSUE: WG Chair Selection Thread-Index: AcMcIOrFjWpiSM6mRLiZQTBVspAgqgAAs7qQ From: "Bound, Jim" To: "Dave Crocker" , "Margaret Wasserman" X-OriginalArrivalTime: 17 May 2003 03:24:09.0335 (UTC) FILETIME=[C7857070:01C31C23] Cc: problem-statement@alvestrand.no Subject: RE: OPEN ISSUE: 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA18160 conflict of interest is the key phrase whereever we see this it is a problem. good catch Dave. /jim > -----Original Message----- > From: Dave Crocker [mailto:dhc@dcrocker.net] > Sent: Friday, May 16, 2003 11:06 PM > To: Margaret Wasserman > Cc: problem-statement@alvestrand.no > Subject: Re: OPEN ISSUE: WG Chair Selection > > > Margaret, > > > MW> However, it is important for ADs and WG chairs to have a good > MW> relationship, and for the AD to have authority over the > WG chair. I > MW> believe that the current reporting relationship (AD chooses WG > MW> chair, chair serves at ADs pleasure) is appropriate. > > > So the chair and working group who well might specify changes to the > IESG are to be managed by someone in the IESG? > > I always thought that "conflict of interest" was a pretty simple > concept. > > How many of us would like to be hired by someone who gives us > the job of > telling them what their job will be? > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > > From problem-statement-bounces@alvestrand.no Fri May 16 23:25: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 XAA18200 for ; Fri, 16 May 2003 23:25:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 16863625D2; Sat, 17 May 2003 05:27:38 +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 4A4C6625CA for ; Sat, 17 May 2003 05:27:31 +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 881A0A802; Fri, 16 May 2003 23:27:30 -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, 16 May 2003 23:27: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: Fri, 16 May 2003 23:27:29 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD8C1@tayexc13.americas.cpqcorp.net> Thread-Topic: OPEN ISSUE: Appeals Path Thread-Index: AcMcIP5auXASI5rZRRWwh7DjfV9dVAAAukbQ From: "Bound, Jim" To: "Margaret Wasserman" , "Dave Crocker" X-OriginalArrivalTime: 17 May 2003 03:27:30.0380 (UTC) FILETIME=[3F5A78C0:01C31C24] Cc: problem-statement@alvestrand.no Subject: RE: OPEN ISSUE: Appeals Path X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 XAA18200 the member should go to the AD, if the AD is not enough the IETF Chair and if that don't work go to IAB and if that don't work feed WG chair to pig or give up :--) the key is that there is no conflict of interest in the chain and all parties are in positions based on absolute skill set and a nomcom process that has no conflict of interest to elect IAB and IESG updates who in turn appoints WG chairs. /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Friday, May 16, 2003 10:59 PM > To: Dave Crocker > Cc: problem-statement@alvestrand.no > Subject: Re: OPEN ISSUE: Appeals Path > > > At 04:22 PM 5/16/2003 -0700, Dave Crocker wrote: > >MW> I think that a well-defined appeals process is needed for any > >MW> activity the size and scope of the proposed Improvement WG. > > > >There is no higher appeal than the IETF Plenary. > > So, if a WG member has a problem with an action taken by the > WG chair, how will that be appealed to the plenary? > > Or will the aggrieved party have to wait until the conclusion > of the process, when consensus on the results is sought > during the plenary? At that point, how would an appeal on a > months- old action be constructively raised? > > Margaret > > > > From problem-statement-bounces@alvestrand.no Fri May 16 23: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 XAA18318 for ; Fri, 16 May 2003 23:29:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E5B57625E1; Sat, 17 May 2003 05:31: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 0C64B625DF for ; Sat, 17 May 2003 05:31:20 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id UAA18818; Fri, 16 May 2003 20:31:04 -0700 (PDT) Message-Id: <5.1.0.14.2.20030516232427.0337d7d0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 16 May 2003 23:27:10 -0400 To: "Bound, Jim" From: Margaret Wasserman In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD8C1@tayexc13.americas .cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Dave Crocker Cc: problem-statement@alvestrand.no Subject: RE: OPEN ISSUE: Appeals Path X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 Jim, At 11:27 PM 5/16/2003 -0400, Bound, Jim wrote: >the member should go to the AD, if the AD is not enough the IETF Chair >and if that don't work go to IAB and if that don't work feed WG chair to >pig or give up :--) The only case where we are currently discussing the appeals process is the ISOC-driven approach. In this case, the ISOC President serves as the "responsible AD". So, the appeals process would go to the ISOC President, then to the IESG, then up the chain? This might work if we choose this approach, but it would need to be documented. >the key is that there is no conflict of interest in the chain and all >parties are in positions based on absolute skill set and a nomcom >process that has no conflict of interest to elect IAB and IESG updates >who in turn appoints WG chairs. The question of whether the process will be IESG-driven or ISOC-driven is separate from chair selection. We could use a nomcom-like method to select the WG chairs, regardless of which group provides WG oversight. Margaret From problem-statement-bounces@alvestrand.no Fri May 16 23:53: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 XAA18630 for ; Fri, 16 May 2003 23:53:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6DE2D62589; Sat, 17 May 2003 05:56: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 BFBFD6257C for ; Sat, 17 May 2003 05:56:02 +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 B41A79FE9; Fri, 16 May 2003 23:56:01 -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, 16 May 2003 23:56: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: Fri, 16 May 2003 23:56:01 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241264@tayexc13.americas.cpqcorp.net> Thread-Topic: OPEN ISSUE: Appeals Path Thread-Index: AcMcJMYr/LT2sBcJTd24q9ZWZYSJMAAAuW9A From: "Bound, Jim" To: "Margaret Wasserman" X-OriginalArrivalTime: 17 May 2003 03:56:01.0620 (UTC) FILETIME=[3B54F940:01C31C28] Cc: Dave Crocker Cc: problem-statement@alvestrand.no Subject: RE: OPEN ISSUE: Appeals Path X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 XAA18630 OK. I am not in favor of ISOC being brought into the loop till the very end. But they should be part of the process as logic check for sure if required. Why do you up the chain? It is going down the chain? I don't think nomcom process for wg chairs is good idea and overkill. The process should be as follows for all grievances by a member. WG Chair IESG IAB ISOC THis is standard open door policy in any company I know of too. thanks /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Friday, May 16, 2003 11:27 PM > To: Bound, Jim > Cc: Dave Crocker; problem-statement@alvestrand.no > Subject: RE: OPEN ISSUE: Appeals Path > > > > Hi Jim, > > At 11:27 PM 5/16/2003 -0400, Bound, Jim wrote: > >the member should go to the AD, if the AD is not enough the > IETF Chair > >and if that don't work go to IAB and if that don't work feed > WG chair > >to pig or give up :--) > > The only case where we are currently discussing the appeals > process is the ISOC-driven approach. In this case, the ISOC > President serves as the "responsible AD". So, the appeals > process would go to the ISOC President, then to the IESG, > then up the chain? > > This might work if we choose this approach, but it would need > to be documented. > > >the key is that there is no conflict of interest in the > chain and all > >parties are in positions based on absolute skill set and a nomcom > >process that has no conflict of interest to elect IAB and > IESG updates > >who in turn appoints WG chairs. > > The question of whether the process will be IESG-driven or > ISOC-driven is separate from chair selection. We could use a > nomcom-like method to select the WG chairs, regardless of > which group provides WG oversight. > > Margaret > > > > From problem-statement-bounces@alvestrand.no Sat May 17 07:12: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 HAA05454 for ; Sat, 17 May 2003 07:12:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BBB9E6257B; Sat, 17 May 2003 13:15: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 B90DF62579 for ; Sat, 17 May 2003 13:15:10 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id EAA24713; Sat, 17 May 2003 04:14:53 -0700 (PDT) Message-Id: <5.1.0.14.2.20030517070253.040a0ec8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 17 May 2003 07:08:09 -0400 To: "Bound, Jim" From: Margaret Wasserman In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241264@tayexc13.americas .cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Dave Crocker Cc: problem-statement@alvestrand.no Subject: RE: OPEN ISSUE: Appeals Path X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 Jim, At 11:56 PM 5/16/2003 -0400, Bound, Jim wrote: >OK. I am not in favor of ISOC being brought into the loop till the very >end. But they should be part of the process as logic check for sure if >required. Yes, I already got this correction from Scott Bradner and Brian Carpenter, as well. Even if we use the usual IESG-driven approach, there is a final step where the ISOC BOTs accepts the new or modified process description. Apparently this is required for insurance reasons. I hadn't worked on any previous process documents, so I didn't know about this step. >WG Chair >IESG >IAB >ISOC > >This is standard open door policy in any company I know of too. Yes, and this also matches the standard appeals process for IETF WG activities. Margaret From problem-statement-bounces@alvestrand.no Sat May 17 07:58: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 HAA05875 for ; Sat, 17 May 2003 07:58:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CBF646257B; Sat, 17 May 2003 14:01: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 E5BC762579 for ; Sat, 17 May 2003 14:01:15 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19H0NF-0007mg-00 for problem-statement@alvestrand.no; Sat, 17 May 2003 07:01:13 -0500 Date: Sat, 17 May 2003 08:01:13 -0400 From: John C Klensin To: "problem-statement@alvestrand.no" Message-ID: <6459658.1053158473@p3.JCK.COM> In-Reply-To: <200305161703.h4GH3ODi023565@newdev.harvard.edu> References: <200305161703.h4GH3ODi023565@newdev.harvard.edu> 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: Document Blocking (Was: I-D X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 few observations on "document blocking". Others are covering the "discuss" theme, but there is another one that might be slipping toward the cracks... In his note of Friday, 16 May, 2003 13:03 -0400 Scott Bradner wrote: > some background on the blocking documents thread based on my > experience on the IESG > > lets split documents that the IESG looks at into two piles > 1/ documents forwarded to the IESG by the RFC Editor to get > the IESG's recommendation > 2/ documents that are the product of IETF working groups or > independent documents (mostly for standards track) that are > being evaluated as if they were WG documents > > case 1: > the document is normally assigned to a specific AD - that AD > does an evaluation and comes up with a suggestion as to what > the IESG should say to the RFC Editor - this can take an > arbitrarily long time >... > sometimes the AD will work with the document authors/editors > to deal with issues that the AD finds during their review, > sometimes this happens before the document getting on the IESG > agenda sometime after the IESG discussion And sometimes the AD has other things on his or her mind, and this can take an arbitrarily long time no matter how responsive the author is. > it is not common for the IESG to recommend that the RFC Editor > not publish a document (but it does happen a few times a year) > - when it does happen the RFC Editor is sent a 'do not > publish' (DNP) recommendation. The DNP is written by one or > two ADs - this can take an arbitrarily long time >... > case 2: > it is quite common for issues/questions to be raised by one or > more ADs during the IESG evaluation of a document - if the > AD(s) feel strongly enough that there is an issue that needs >... > to be addresses they vote "discuss" - this will block a > document until the AD(s) are satisfied by revisions in the > document or as a result of discussion > > when an AD has an issue with a document and has voted > "discuss" the document and the issues are discussed during an > IESG teleconference - sometimes the discussion results in the > AD changing their evaluation and removing their "discuss" And sometimes, it results in the AD saying, more or less, "I will explain my reasons in a note or draft writeup". At that stage, unless there is a clear consensus that the AD is off base, the IESG will give the AD as much time as needed to do that writeup (after all, each AD might be in the same position next time). That can take an arbitrarily long time. > I do not recall that the IESG has ever specifically decided to > not publish a document in this group but since it can take an > arbitrarily long time for the working group (or document > authors/editors) to respond to the concerns and an arbitrarily > long time for the back and forth between the AD for the >... Also, Keith raised a question and Scott responded on Friday, 16 May, 2003 15:27 -0400: >> does the RFC editor no longer impose a timeout on IESG >> feedback for such documents? (where such feedback could say >> "we need more time" or "we're discussing with the author") > > formally, they do, but it is meangingless And Keith later wrote, on Friday, 16 May, 2003 16:27 -0400: > Right, but IESG has timeouts in place for almost all phases of > its deliberative process. It's the WG that can hold up > things for arbitrary amounts of time (sometimes because the > authors and/or chair are sitting on the document and the WG > doesn't know what is happening, sometimes because the WG > refuses to make changes and doesn't know what to do next). Now, my first observation is that phrases equivalent to "arbitrarily long time" appear much too often above, especially when they are linked to experience in which things have taken a very long time. There is certainly a difference procedurally and formally between blocking by "discuss" and "just tie it up for an "arbitrarily long time" while something is ostensibly being done. But, in practical terms, there really is no difference at the end of the day: the document isn't getting out and isn't getting cleanly rejected with clear reasons either. Part of the problem is that, as with the "RFC Editor timeout" on non-WG/ non-standards track submissions (Scott's "case 1"), the timeouts to which Keith refers are, in my observation, routinely ignored. Certainly sometimes, probably often, the delays can be pinned on the WGs as Keith suggests. But there is a loop in that particular bit of finger-pointing too. Most of us who have observed or worked with long-lived WGs have noticed that it is possible for them to reach a point of exhaustion in which everything happens slowly, if at all, getting a reasonable number of people to focus on an issue or decision or to carefully review a document. So, suppose I were an AD holding the token on a WG document and wanted to _cause_ that to happen (for the record, I'm not aware of any cases in which this has been done deliberately. But the intent is less important than the effect). I would send the WG a long-ish list of things that I insisted be fixed, some important, some trivial, and at least a few guaranteed to irritate them (possibly by raising old issues that the WG thought it had already become exhausted discussing). I would wait for a response, possibly a whole new draft. I might insist that the new draft be Last Called within the WG, just to be sure that consensus still existed. If the WG asked me questions about my position, I'd take my time answering. I'd count all of the time the WG spent on that process as "WG delay" and the current structure of the tracking system would help me document that. Then I'd do it again -- I'd review the revised document, find more stuff to object too (even if it was completely trivial) and send the document back again. If the WG Chair and Editor(s) shared the issues with the WG, the odds are good that frustration and exhaustion would set in quickly. If they didn't, but tried to negotiate the trivia (remembering that opinions about what is, and is not, trivial can vary widely depending on one's perspective) privately, but that took a while (it always does), the WG members would get frustrated about the apparent "black hole" situation. My conclusion is that we need to have timeouts, and they need to be meaningful. Meaningless timeouts may be worse than no timeouts at all. The problem is how to make, and keep, them meaningful, especially when the rules we already have are --it seems regularly-- ignored. And we should figure out ways to do that which don't compromise quality of review. Examples (I'm not really proposing solutions here, just possible ways to think about the problem): * After an AD gets a document from a WG with a request for Last Call, or after Last Call completes, he or she has N weeks to get the Last Call issued or to get the document in front of the IESG. The document may, instead, be returned to the WG during that window with an explanation. But, if it is neither returned nor processed within N weeks, the AD must provide a public explanation of why the added delay is needed. And, at 2 or 3 times N, there needs to be IESG consensus --and another public statement-- as to the importance and reasonableness of more delay. * For "case 1" documents, remember that "sometimes the AD will work with the document authors/editors to deal with issues that the AD finds during their review" (from Scott's explanation quoted above)is a process violation. For those documents, the IESG is permitted only to tell the RFC Editor that there is an end-run going on, or that the suggestion, if implemented, would be harmful to the Internet. "Make an AD happy" or "resolve any 'issues' the AD has" are not on that very short list. Certainly we should not discourage an AD who has the time and interest from trying to sort "issues" out with an author. But, until and unless we change the procedures, that should occur by the AD --more or less as an individual member of the community-- saying to the author "I've got some problems with this and would like to work with you on them". The author can then pull the document out of the queue and get to work. Or he or she can decline to do that, at which point the AD --again, acting strictly as an individual-- could reasonably tell the RFC Editor that the discussion/interaction occurred as input into the RFC Editor decision about publication. But an AD's sitting on an individual submission to "work on issues" under the umbrella of doing "an evaluation and com[ing] up with a suggestion as to what the IESG should say..." is abuse of authority. There will certainly be times when the initial "timeout" period is insufficient to conduct even the minimal review that 2026 requires and permits. But, then, let's get a public notation that a delay has been requested and an explanation for it: it might help move things along, or, at worst, provide the community with a paper track to help evaluate whether the particular AD should continue to hold that position. john From problem-statement-bounces@alvestrand.no Sat May 17 08:14: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 IAA06154 for ; Sat, 17 May 2003 08:14:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 50F186257B; Sat, 17 May 2003 14:16: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 5D95062579 for ; Sat, 17 May 2003 14:16:45 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19H0cG-0007ne-00; Sat, 17 May 2003 07:16:44 -0500 Date: Sat, 17 May 2003 08:16:44 -0400 From: John C Klensin To: Margaret Wasserman , "problem-statement@alvestrand.no" Message-ID: <7390136.1053159404@p3.JCK.COM> In-Reply-To: <5.1.0.14.2.20030516050623.038bd7f0@mail.windriver.com> References: <014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> <5.1.0.14.2.20030515113529.014ba800@mail.windriver.com> <014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> <5.1.0.14.2.20030516050623.038bd7f0@mail.windriver.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: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, 16 May, 2003 05:26 -0400 Margaret Wasserman wrote: > For example, I think that it should be possible for several > different proposals that solve the same problem to be > published in an enduring form by the IETF, and for a > subsequent process to determine which one(s) will advance on > the standards-track. This would solve some of the problems > that we have in the v6ops WG, for example. But, we have no > tools to do this in a way that makes the status of these > documents visible to our "customers". Sure we do. Let's separate two issues. The first is "our customers" (or, more to the point, marketing organizations who will do anything they can get away with to promote products -- I'd decided over the years that I'm even more upset by equating "posted as an individual I-D" with "under IETF consideration and review" than I am about "RFC equals standard") distorting the status/maturity level of documents. That is a problem, of course, but not one that we can easily solve. In particular, I'm not at all convinced that renaming this will help -- I'm convinced that most of these distortions are deliberate and not honest errors and misunderstandings. The second is whether we have the mechanisms you describe above. We do: the several documents are published as Experimental and, once things shake out, someone proposes that one of them be reevaluated for Proposed Standard. That doesn't respond to the desire you have expressed elsewhere to be able to move a well-tested and deployed specification directly to Draft. Perhaps it is worth thinking about criteria for Experimental -> Draft to supplement Proposed -> Draft but that is a separate issue, I think. john From problem-statement-bounces@alvestrand.no Sat May 17 10:24: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 KAA09059 for ; Sat, 17 May 2003 10:24:01 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E8CCE6257B; Sat, 17 May 2003 16:26:33 +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 BA163623D6 for ; Sat, 17 May 2003 16:26:27 +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 19H2dl-0000ko-00; Sat, 17 May 2003 07:26:25 -0700 Date: Sat, 17 May 2003 10:25:34 -0400 From: Keith Moore To: John C Klensin Message-Id: <20030517102534.5c15ae5f.moore@cs.utk.edu> In-Reply-To: <6459658.1053158473@p3.JCK.COM> References: <200305161703.h4GH3ODi023565@newdev.harvard.edu> <6459658.1053158473@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: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: Document Blocking (Was: I-D X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 an AD has an issue with a document and has voted > > "discuss" the document and the issues are discussed during an > > IESG teleconference - sometimes the discussion results in the > > AD changing their evaluation and removing their "discuss" > > And sometimes, it results in the AD saying, more or less, "I > will explain my reasons in a note or draft writeup". At that > stage, unless there is a clear consensus that the AD is off > base, the IESG will give the AD as much time as needed to do > that writeup (after all, each AD might be in the same position > next time). That can take an arbitrarily long time. My recollection is that during the time that I was on IESG it became much less acceptable for an AD to explain his reasons for a Discuss at a later time. By the end of my 2nd term we were expected to exlain our reasons at the time we voted Discuss. The explanations could be brief, or the AD could vote Defer for one telechat (usually two weeks) and then change it to Discuss once the explanation was supplied, but "I'll write it up later" wasn't acceptable anymore. And a Defer automatically changed to No Objection if not explicitly changed by the next telechat. From problem-statement-bounces@alvestrand.no Sat May 17 10:45: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 KAA09358 for ; Sat, 17 May 2003 10:45:49 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A58B462588; Sat, 17 May 2003 16:48:22 +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 95D3D623D6 for ; Sat, 17 May 2003 16:48:20 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4HEm1e27864; Sat, 17 May 2003 17:48:02 +0300 Date: Sat, 17 May 2003 17:48:00 +0300 (EEST) From: Pekka Savola To: Margaret Wasserman In-Reply-To: <5.1.0.14.2.20030517070253.040a0ec8@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Dave Crocker Cc: problem-statement@alvestrand.no Subject: RE: OPEN ISSUE: Appeals Path X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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, 17 May 2003, Margaret Wasserman wrote: > >WG Chair > >IESG > >IAB > >ISOC > > > >This is standard open door policy in any company I know of too. > > Yes, and this also matches the standard appeals process for > IETF WG activities. "IETF WG activities" is ambiguous. The path holds for process appeals, but for technical appeals, the IAB is the highest you can go. -- 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 May 17 18:01: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 SAA15884 for ; Sat, 17 May 2003 18:01:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D4B0B6257B; Sun, 18 May 2003 00:04: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 2EC41623D6 for ; Sun, 18 May 2003 00:04:16 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19H9mj-000AMy-00; Sat, 17 May 2003 17:04:09 -0500 Date: Sat, 17 May 2003 18:04:09 -0400 From: John C Klensin To: "hardie@qualcomm.com" Message-ID: <42634535.1053194649@p3.JCK.COM> In-Reply-To: References: <5.1.0.14.2.20030515115941.014dbb30@mail.windriver.com > <1464242340.20030516162212@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: Dave Crocker Cc: Margaret Wasserman Cc: "problem-statement@alvestrand.no" Subject: Re: OPEN ISSUE: Appeals Path X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, 16 May, 2003 16:47 -0700 "hardie@qualcomm.com" wrote: Dave Crocker wrote... > There is no higher appeal than the IETF Plenary. >... > It also fundamentally misses our usual point that > participating in the IETF can take place outside the > face-to-face meetings, as it requires those not attending a > particular meeting to make some other arrangements for > participation. With the jabber conferences, it is easier, > though time shifting and other barriers remain. For whatever it is worth, I think this is the key issue. Regardless of the other advantages and disadvantages of unusual models for this work, I believe it is vital that we not violate the principle that we make decisions (technical or otherwise) on mailing lists, not in face to face meetings, even plenary sessions. I hope the reasons for that are obvious to everyone, especially in these troubled times of travel restrictions, etc. But it seems to me that decisions about changes in process are even less, rather than more, appropriately made in a way that excludes people who can't manage to show up at a given meeting (or even establish remote communication with it). I do have some misgivings with the notion of assigning this to the "General Area". That is partially because of general concerns about that "area" and its relationship to the IETF Chair position/role that I've expressed elsewhere. It is also partially because of some of the same issues that have, I think, led others to recommend relatives active ISOC roles in managing the WG. But perhaps we can find an intermediate position. For example, I would be more comfortable if the IESG as a whole took responsibility for the WG, chair selection, etc., rather than assigning it to a single AD or a single area. The WG and its chair will be operating under an unusual level of general IETF scrutiny. If the chair is chosen through a relatively open/public process, if there is IESG consensus about the choice, and if it is generally understood that any issues are going to require appeals to the full IESG and not a single AD (or the Chair), then I think we are probably adequately protected against abuse or conflict of interest without introducing some "cure" that is worse than the problem it is solving. Similarly, it would obviously behoove the IESG to be exceptionally open and responsive about its handling of any recommendations or drafts emerging from such a WG, as even the slightest hint of burying ideas that one or more IESG didn't like --rather than debating those ideas openly in the community-- would presumably lead to a level of community frustration that would, in turn, justify, not appeals, but recalls. And I don't think we need any specific rules to that effect -- the IESG is more than capable of figuring these things out on their own and I think we can trust them to do so. regards, john From problem-statement-bounces@alvestrand.no Sat May 17 20:55: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 UAA18539 for ; Sat, 17 May 2003 20:55:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AA388623D6; Sun, 18 May 2003 02:58:14 +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 44B486223F for ; Sun, 18 May 2003 02:58:11 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA06013; Sat, 17 May 2003 17:57:48 -0700 (PDT) Message-Id: <5.1.0.14.2.20030517205310.0409b850@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 17 May 2003 20:53:55 -0400 To: Keith Moore From: Margaret Wasserman In-Reply-To: <20030517102534.5c15ae5f.moore@cs.utk.edu> References: <6459658.1053158473@p3.JCK.COM> <200305161703.h4GH3ODi023565@newdev.harvard.edu> <6459658.1053158473@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: Document Blocking (Was: I-D X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 10:25 AM 5/17/2003 -0400, Keith Moore wrote: >My recollection is that during the time that I was on IESG it became much >less acceptable for an AD to explain his reasons for a Discuss at a later >time. By the end of my 2nd term we were expected to exlain our reasons at the >time we voted Discuss. Explain them to whom? The rest of the IESG? What good does that do for the WG, if the reasons aren't documented and mailed to the WG mailing list? Margaret From problem-statement-bounces@alvestrand.no Sun May 18 00:14: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 AAA20529 for ; Sun, 18 May 2003 00:14:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4572E62594; Sun, 18 May 2003 06:17:12 +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 24E746257F for ; Sun, 18 May 2003 06:17:09 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=cs.utk.edu) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19HFbY-0001Eu-00; Sat, 17 May 2003 21:17:00 -0700 Date: Sun, 18 May 2003 00:17:04 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Margaret Wasserman From: Keith Moore In-Reply-To: <5.1.0.14.2.20030517205310.0409b850@mail.windriver.com> Message-Id: <94FA09A8-88E7-11D7-91A9-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: John C Klensin Cc: problem-statement@alvestrand.no Cc: Keith Moore Subject: Re: Document Blocking (Was: I-D X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, May 17, 2003, at 08:53 PM, Margaret Wasserman wrote: > At 10:25 AM 5/17/2003 -0400, Keith Moore wrote: >> My recollection is that during the time that I was on IESG it became >> much >> less acceptable for an AD to explain his reasons for a Discuss at a >> later >> time. By the end of my 2nd term we were expected to exlain our >> reasons at the >> time we voted Discuss. > > Explain them to whom? The rest of the IESG? What good does that > do for the WG, if the reasons aren't documented and mailed to the > WG mailing list? well...there's a fair amount of presumption in those questions. providing an explanation to IESG forced the objecting AD to come up with some explanation within two weeks, rather than waiting until he found the time to figure out how to explain what was wrong. essentially, it made providing such explanations a high-priority task where it wasn't so beforehand, and this substantially reduced the amount of time it took to get feedback to WGs. it also made it at least somewhat more difficult for an IESG member to block a document on trivial grounds, since the other IESG members could and did push back on ADs whose objections seemed trivial. of course the responsible AD _was_ expected to communicate those objections to the appropriate parties, which generally meant the document authors for minor fixes and the WG mailing list for major changes. and these days the IESG member's discuss comments also end up on the web via the document tracker. From problem-statement-bounces@alvestrand.no Sun May 18 10:49: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 KAA10978 for ; Sun, 18 May 2003 10:49:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EA4446220B; Sun, 18 May 2003 16:51:40 +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 4F73762205 for ; Sun, 18 May 2003 16:51:39 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19HPVh-000FL5-00; Sun, 18 May 2003 09:51:37 -0500 Date: Sun, 18 May 2003 10:51:37 -0400 From: John C Klensin To: Margaret Wasserman Message-ID: <59370269.1053255097@p3.JCK.COM> In-Reply-To: <5.1.0.14.2.20030516115353.03c92960@mail.windriver.com> References: <5.1.0.14.2.20030515114755.014cedb8@mail.windriver.com > <5.1.0.14.2.20030515114755.014cedb8@mail.windriver.com> <5.1.0.14.2.20030516115353.03c92960@mail.windriver.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: Charters, "normal process" versus ISOC, etc. (was: Re: OPEN ISSUE: Quality Process WG Charter) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, 16 May, 2003 11:54 -0400 Margaret Wasserman wrote: >> I don't think this group should propose a charter for that >> group. >> >> And I'm not sure I even agree with the text in the process >> document about how that group should proceed. > > Would you like to propose an alternative? Margaret, I'd like to propose something as a strawman, partially based on further thought after my comments about process yesterday. This is a radical suggestion and may not be a good idea, but I'd like to see if it resonates with others or at least stimulates some discussion and other suggestions. We seem to have three perspectives/ camps at the moment: (1) Use the normal process, including assigning these working groups to the IETF Chair (i.e., the "General Area"). That means having the Chair appointed by, and serving at the pleasure of, the IETF Chair, the IETF Chair making decisions about what WG decisions get processed by the IESG, etc. (2) Some people are deeply concerned about this, seeing the IESG as the problem and resistant to reform and the IESG generally, and perhaps the Chair in particular, as subject to inherent conflicts of interest in a reform process. Many of them lean toward an ISOC-controlled process. (3) Some (perhaps very few) of us are more trustful of the IESG as a group, but are uncomfortable about the General Area, the notion of the IETF Chair wearing this hat in addition to all of the others, and the implications the first approach causes with the appeals process. We also don't see an ISOC-based approach as really being feasible. So, again, at least as something to think about, I suggest a fourth option: We ask the IESG to expeditiously create a new, but temporary, area for process review and reform, with, say, a one-year expiration period requiring community assent to keep it going any longer. We ask the Nomcom to select an AD for that area, again asking them to expedite the action. The IESG appoints one of its number (with the Chair/ General Area AD being the obvious choice since the workload would be the same as under option (1)) to fill in during the interim. What does this do for us? * Like the ISOC plan, it puts someone in as "responsible AD" for this work who is selected/ designated for the purpose and who is not part of the existing IESG. The reduces suspicions about conflicts of interest. And... * It also reduces concerns about available skill sets (since the Nomcom would be selecting someone specifically for this role) and time availability (since the chosen AD would have no other WG or external responsibilities). * It is very much part of the existing process model, doesn't raise special concerns about appeals, etc. * And I think we can assume that a person who was designated as responsible for this area would raise a public outcry --if necessary to the point of filing recall petitions-- if any of the blocking actions of which the IESG has been accused occurred wrt the outputs these relevant WGs. Indeed, if I were to advise the Nomcom, I would suggest that willingness to go that far --and good sense about when or whether to do so-- would be an important criterion for a prospective candidate. And, to preempt any paranoid speculations, I don't want the job. john From problem-statement-bounces@alvestrand.no Sun May 18 10:55: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 KAA11071 for ; Sun, 18 May 2003 10:55:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AC5C96257F; Sun, 18 May 2003 16:58:31 +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 C6E8062205 for ; Sun, 18 May 2003 16:58:28 +0200 (CEST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) h4IEwQCi045352; Sun, 18 May 2003 16:58:27 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4IEwR5e242002; Sun, 18 May 2003 16:58:27 +0200 Received: from gsine01.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA57526 from ; Sun, 18 May 2003 16:58:22 +0200 Message-Id: <3EC79A85.B2C0C41D@hursley.ibm.com> Date: Sun, 18 May 2003 16:36: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: erosen@cisco.com References: <200305161509.h4GF9PkL023288@rtp-core-1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: I-D ACTION:draft-ietf-problem-process-00.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit below... Eric Rosen wrote: > > > 5.1 Near-Term Improvements > ... > > 5. Modify IESG-internal processes to make it impossible for one > > or two IESG members to block a document. > > Brian> There is a strong implication here that ADs might do this for > Brian> spurious reasons. > > Well, yes, that's the "problem". > > Brian> But if one or both Security ADs are deeply > Brian> convinced that a draft constitutes a major security risk, or one > Brian> or both Routing ADs are convinced that a draft will lead to routing > Brian> loops, isn't it quite appropriate for them to block the document? > Brian> Such cases suggest failures much earlier in the process, not > Brian> misbehaviour by the IESG. So I don't think we should fix this, > Brian> because it is actually a vital back-stop, not a bug. > > You can't remove a problem by declaring it not to be a problem; that's > called a "whitewash". And the fact that the ADs sometimes act properly > doesn't mean that they don't sometimes act improperly. > > The problem is that there is no effective and open process by which such > decisions can be reviewed and evaluated to determine whether they are proper > or improper. This generated its own sub-thread, but I want to say here that Eric's response clearly indicates that point 5. quoted above is *not* the actual issue. The actual issue is 5. Modify IESG-internal processes to make reasons for the IESG's blocking of a document visible to the public. Brian From problem-statement-bounces@alvestrand.no Sun May 18 10:56: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 KAA11095 for ; Sun, 18 May 2003 10:56:34 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CAF336230E; Sun, 18 May 2003 16:59:09 +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 E8D7C6259F for ; Sun, 18 May 2003 16:58:34 +0200 (CEST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) h4IEwWCi049398 for ; Sun, 18 May 2003 16:58:32 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4IEwWLe084822 for ; Sun, 18 May 2003 16:58:33 +0200 Received: from gsine01.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA60758 from ; Sun, 18 May 2003 16:58:29 +0200 Message-Id: <3EC79B89.9750408B@hursley.ibm.com> Date: Sun, 18 May 2003 16:41:13 +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: <200305131200.IAA05317@ietf.org> <577331692.20030516171342@brandenburg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: ISOC-Directed Approach [Re: I-D ACTION:draft-ietf-problem-process-00.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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: ... > > >> 5.2.2.2 ISOC-Directed Approach > >> > >> Another approach would be to ask the ISOC President and the ISOC > >> Board of Trustees (ISOC BoT) to assume responsibility for the > >> oversight of the IETF Improvement WG, similar to our current > >> Nominations Committee processes, as defined in RFC 2727 [RFC2727]. > >> > BEC> Although I am currently an ISOC Trustee, I certainly can't speak for > BEC> the ISOC on this. However, I wouldn't advocate it. Only a few members > BEC> of the ISOC Board are truly familiar with the IETF's internal workings. > BEC> Having the Board accept the final documents, as noted above, is enough. > > The idea is to model the process after the ISOC portion of the Nomcom > process. Bad idea. That works essentially as a process check, since most ISOC Board members don't know most of the IAB nominees. We need more than a process check in this case, imho. Brian From problem-statement-bounces@alvestrand.no Sun May 18 10:56: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 KAA11109 for ; Sun, 18 May 2003 10:56:48 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B66A56259F; Sun, 18 May 2003 16:59:10 +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 82932625A0 for ; Sun, 18 May 2003 16:58:41 +0200 (CEST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) h4IEwcUm091654 for ; Sun, 18 May 2003 16:58:38 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4IEwcLe087108 for ; Sun, 18 May 2003 16:58:38 +0200 Received: from gsine01.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA49112 from ; Sun, 18 May 2003 16:58:35 +0200 Message-Id: <3EC79E61.4A62F7F7@hursley.ibm.com> Date: Sun, 18 May 2003 16:53:21 +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 Cc: problem-statement@alvestrand.no References: <200305161512.h4GFCpkL024356@rtp-core-1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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: > > Brian> Secondly, this is a case where I think a simple first step may > Brian> help quite a bit: simply merge Draft Standard and Standard > Brian> into a single class, called Standard, but with the criteria > Brian> now used for Draft Standard. > > Brian> Arguments: remove a process step that we basically never use, > Brian> and make the step up from Proposed Standard worth the trouble. > > Could you explain how this makes the step up from PS worth the trouble? Because you know that the effort of documenting the interoperable implementations will be rewarded by immediately getting to the final status, rather than just getting to an intermediate plateau (and one with a very confusing name, since to outsiders it sounds like a step backwards). Brian From problem-statement-bounces@alvestrand.no Sun May 18 11:10: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 LAA11287 for ; Sun, 18 May 2003 11:10:41 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AA32262573; Sun, 18 May 2003 17:13:15 +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 054A662205 for ; Sun, 18 May 2003 17:13:14 +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 h4IFCxH3009843 for ; Sun, 18 May 2003 11:12:59 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h4IFCxGC009842 for problem-statement@alvestrand.no; Sun, 18 May 2003 11:12:59 -0400 (EDT) Date: Sun, 18 May 2003 11:12:59 -0400 (EDT) From: Scott Bradner Message-Id: <200305181512.h4IFCxGC009842@newdev.harvard.edu> To: problem-statement@alvestrand.no Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 trying to figure out what to say in this debate I strongly do not like the idea of distorting the normal IETF process in this or any other "special" case and was having a hard time figuring out the threat model that said we needed to do so. I do think that there are quite real problems that need to be fixed but I do not think that the IETF chair or the IESG are so broken to think that they could control the evolutionary process by picking a chair that would do so or to reject the output of a process revision working group even though they have the structural ability to do so. I have not seen an indication that the current IESG members (or the Chair) are so disconnected from the rest of the IETF to think that they could do that. (But then again, I've not seen much input from the current IETF members on this list so I suppose I could be wrong but I do not think so.) My preference would be to just do the normal thing and form a working group in the General Area with the chair(s) for the group being selected by the IETF Chair (using, for example, the process he used to select the chairs for the problem statement WG - a quite public process) But, if some people are so distrustful of the Chair to keep them from being able to support the IETF just using IETF processes to change the IETF (which is what we did the last time) then I think that John's suggestion of a temporary area is a reasonable one, we have done temporary areas in the past (with which I have some familiarity) and it is not a distortion of the basic IETF process. Scott From problem-statement-bounces@alvestrand.no Sun May 18 11:23: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 LAA11482 for ; Sun, 18 May 2003 11:23:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 23CD062582; Sun, 18 May 2003 17:25:39 +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 062B9621FA for ; Sun, 18 May 2003 17:25:36 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19HQ2Y-000Fav-00; Sun, 18 May 2003 10:25:34 -0500 Date: Sun, 18 May 2003 11:25:34 -0400 From: John C Klensin To: Dave Crocker Message-ID: <61407549.1053257134@p3.JCK.COM> In-Reply-To: <577331692.20030516171342@brandenburg.com> References: <200305131200.IAA05317@ietf.org> <3EC4DE50.D04E601C@hursley.ibm.com> <577331692.20030516171342@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: I-D ACTION:draft-ietf-problem-process-00.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, 16 May, 2003 17:13 -0700 Dave Crocker wrote: > At base, the reasons do not matter. It simply is not > reasonable for any one (or two) people to weild that much > power. A group based on Rough Consensus should rely on those > having a point of view being able to recruit others to support > that view. If they cannot succeed in their recruitment > effort, there is something wrong with their view. > > We believe in technical expertise, not technical deities. > > Expertise is compelling, when the expertise is real. Only > deities warrant individual veto authority in this community. Dave, I agree with all of this, except that there is a conflict of roles (if not of interest) built into the process. I believe that we either need to eliminate that conflict (which would, I suspect, require some really radical changes) or that we need to be very careful about how far we go in the direction you (and the document) are suggesting. Explanation... We expect an AD to take a the lead role in creating a WG, to appoint its leadership, and to maintain oversight management on its work. We also expect that AD to carry the WG's work into the IESG and to strongly advocate the WG's results. If I remember correctly, current IESG procedures won't permit a WG document to advance unless the AD responsible for that WG is on record as favoring it. The portion of the community who believe that a WG should be able to determine what becomes a standard and whether issues raised from other perspectives are important enough to justify revisions would presumably consider a responsible AD to be derelict in his or her duties if there wasn't strong advocacy for the WG position. That sets up a poor environment for prohibiting the type of substantive "even if this is fine from the perspective of X, it will wreck global routing and those issues need to be at least addressed" stopping rules that Brian is advocating. I think that there are several other, less risky, solutions for the problem you are concerned about. The first, and most important, is much more openness about what is happening -- any action within the IESG that is likely to produce a long delay should be required to be accompanied by a public explanation (see my suggestion on the Poised list about IESG Charter language). The IESG should be able to approve more time for processing a document --or convincing each other-- when specific, but not-yet-convincing, objections are raised from one area about a proposal from another, but that approval should be accompanied by a public statement about what is going on and what the objection-placeholder text is. Finally, procedurally, I don't think we have a mechanism for a veto today so there really shouldn't be a discussion about ways to eliminate that mechanism. What we have instead are circumstances in which there is a potential for a de facto veto when procedures are not followed and a tolerance for that behavior based partially on an IESG dynamic of "we have to work together tomorrow regardless of what happens to this document, and therefore must defer when one of us feels strongly". That dynamic is natural, and we shouldn't try to change it significantly -- but it can also be used to cover up, or even encourage, well-meaning but pathological behavior... and we need to explore ways to stop that set of cycles. john From problem-statement-bounces@alvestrand.no Sun May 18 11:38: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 LAA11749 for ; Sun, 18 May 2003 11:38:29 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 926286258B; Sun, 18 May 2003 17:41: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 BC9DC621FA for ; Sun, 18 May 2003 17:41:00 +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 8F45F7C3E; Sun, 18 May 2003 11:40: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); Sun, 18 May 2003 11:40: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: Sun, 18 May 2003 11:40:54 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD8DB@tayexc13.americas.cpqcorp.net> Thread-Topic: OPEN ISSUE: Appeals Path Thread-Index: AcMcg1WHxw/YQrTfSWSrAqPYlsbREgA0H4lA From: "Bound, Jim" To: "Pekka Savola" , "Margaret Wasserman" X-OriginalArrivalTime: 18 May 2003 15:40:54.0741 (UTC) FILETIME=[DE68D850:01C31D53] Cc: Dave Crocker Cc: problem-statement@alvestrand.no Subject: RE: OPEN ISSUE: Appeals Path X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 LAA11749 Yep I knew that about tech appeals. Suggesting we discuss if we want ISOC also for tech appeals but did not directly in the mail. Sorry. /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Saturday, May 17, 2003 10:48 AM > To: Margaret Wasserman > Cc: Bound, Jim; Dave Crocker; problem-statement@alvestrand.no > Subject: RE: OPEN ISSUE: Appeals Path > > > On Sat, 17 May 2003, Margaret Wasserman wrote: > > >WG Chair > > >IESG > > >IAB > > >ISOC > > > > > >This is standard open door policy in any company I know of too. > > > > Yes, and this also matches the standard appeals process for IETF WG > > activities. > > "IETF WG activities" is ambiguous. The path holds for > process appeals, > but for technical appeals, the IAB is the highest you can go. > > -- > 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 Sun May 18 12:29: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 MAA12303 for ; Sun, 18 May 2003 12:29:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A5525621FA; Sun, 18 May 2003 18:31:33 +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 B351C61DEC for ; Sun, 18 May 2003 18:31:31 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=cs.utk.edu) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19HR4I-00039o-00; Sun, 18 May 2003 09:31:26 -0700 Date: Sun, 18 May 2003 12:31:31 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: John C Klensin From: Keith Moore In-Reply-To: <59370269.1053255097@p3.JCK.COM> Message-Id: <2ED69F07-894E-11D7-91A9-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: Margaret Wasserman Cc: "problem-statement@alvestrand.no" Cc: Keith Moore Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re: OPEN ISSUE: Quality Process WG Charter) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 John's proposal is a reasonable way to proceed. It is as fair and impartial as we can hope to be, and it gets us past this issue so we can actually start to do the work. Keith From problem-statement-bounces@alvestrand.no Sun May 18 12: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 MAA12350 for ; Sun, 18 May 2003 12:33:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 18FA9625A0; Sun, 18 May 2003 18:36:06 +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 6ED4C621B8 for ; Sun, 18 May 2003 18:36:03 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=cs.utk.edu) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19HR8j-0000Nw-00; Sun, 18 May 2003 09:36:01 -0700 Date: Sun, 18 May 2003 12:36:07 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: John C Klensin From: Keith Moore In-Reply-To: <61407549.1053257134@p3.JCK.COM> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: Dave Crocker Cc: "problem-statement@alvestrand.no" Cc: Keith Moore Subject: Re: I-D ACTION:draft-ietf-problem-process-00.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit On Sunday, May 18, 2003, at 11:25 AM, John C Klensin wrote: > Finally, procedurally, I don't think we have a mechanism for a veto > today so there really shouldn't be a discussion about ways to > eliminate that mechanism. What we have instead are circumstances in > which there is a potential for a de facto veto when procedures are not > followed and a tolerance for that behavior based partially on an IESG > dynamic of "we have to work together tomorrow regardless of what > happens to this document, and therefore must defer when one of us > feels strongly". That dynamic is natural, and we shouldn't try to > change it significantly -- but it can also be used to cover up, or > even encourage, well-meaning but pathological behavior... and we need > to explore ways to stop that set of cycles. this dynamic works both ways - sometimes it causes a document to be delayed without what looks like a good reason, but in my experience far more often it causes a bad document to get approved despite good reasons to not approve it. both of these should IMHO be viewed as undesirable. Keith From problem-statement-bounces@alvestrand.no Sun May 18 13:34: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 NAA13208 for ; Sun, 18 May 2003 13:34:33 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 41FEF6259A; Sun, 18 May 2003 19:37:06 +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 91D9062598 for ; Sun, 18 May 2003 19:37:04 +0200 (CEST) Received: from medea.wz-berlin.de ([193.174.6.5]) by athene.wz-berlin.de with esmtp (Exim 4.20) id 19HS5k-00026X-UF; Sun, 18 May 2003 19:37:00 +0200 Received: from ERDE/SpoolDir by medea.wz-berlin.de (Mercury 1.48); 18 May 03 19:37:01 +0200 Received: from SpoolDir by ERDE (Mercury 1.48); 18 May 03 19:36:41 +0200 From: "Jeanette Hofmann" Organization: Wissenschaftszentrum Berlin To: John C Klensin Date: Sun, 18 May 2003 19:36:31 +0200 MIME-Version: 1.0 Message-ID: <3EC7E0C0.944.551DAB@localhost> Priority: normal In-reply-to: <59370269.1053255097@p3.JCK.COM> References: <5.1.0.14.2.20030516115353.03c92960@mail.windriver.com> 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: Amavis with NAI VirusScan on athene.wz-berlin.de Cc: "problem-statement@alvestrand.no" Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re: OPEN ISSUE: Quality Process WG Charter) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 18 May 2003 at 10:51, John C Klensin wrote: > John, your fourth option sounds like a very good solution to me. For principle reasons, the IESG should rather not lead the reform process. Even if the IESG members in general, and the General Area AD in particular, are wise, experienced and diplomatic enough to lead this process in a neutral way, a new AD selected specifically for this purpose would provide for a cleaner mechanism, which gave less reason for suspicion. Jeanette > > --On Friday, 16 May, 2003 11:54 -0400 Margaret Wasserman > wrote: > > >> I don't think this group should propose a charter for that > >> group. > >> > >> And I'm not sure I even agree with the text in the process > >> document about how that group should proceed. > > > > Would you like to propose an alternative? > > Margaret, I'd like to propose something as a strawman, partially > based on further thought after my comments about process > yesterday. This is a radical suggestion and may not be a good > idea, but I'd like to see if it resonates with others or at > least stimulates some discussion and other suggestions. > > We seem to have three perspectives/ camps at the moment: > > (1) Use the normal process, including assigning these > working groups to the IETF Chair (i.e., the "General > Area"). That means having the Chair appointed by, and > serving at the pleasure of, the IETF Chair, the IETF > Chair making decisions about what WG decisions get > processed by the IESG, etc. > > (2) Some people are deeply concerned about this, seeing > the IESG as the problem and resistant to reform and the > IESG generally, and perhaps the Chair in particular, as > subject to inherent conflicts of interest in a reform > process. Many of them lean toward an ISOC-controlled > process. > > (3) Some (perhaps very few) of us are more trustful of > the IESG as a group, but are uncomfortable about the > General Area, the notion of the IETF Chair wearing this > hat in addition to all of the others, and the > implications the first approach causes with the appeals > process. We also don't see an ISOC-based approach as > really being feasible. > > So, again, at least as something to think about, I suggest a > fourth option: We ask the IESG to expeditiously create a new, > but temporary, area for process review and reform, with, say, a > one-year expiration period requiring community assent to keep it > going any longer. We ask the Nomcom to select an AD for that > area, again asking them to expedite the action. The IESG > appoints one of its number (with the Chair/ General Area AD > being the obvious choice since the workload would be the same as > under option (1)) to fill in during the interim. > > What does this do for us? > > * Like the ISOC plan, it puts someone in as "responsible > AD" for this work who is selected/ designated for the > purpose and who is not part of the existing IESG. The > reduces suspicions about conflicts of interest. And... > > * It also reduces concerns about available skill sets > (since the Nomcom would be selecting someone > specifically for this role) and time availability (since > the chosen AD would have no other WG or external > responsibilities). > > * It is very much part of the existing process model, > doesn't raise special concerns about appeals, etc. > > * And I think we can assume that a person who was > designated as responsible for this area would raise a > public outcry --if necessary to the point of filing > recall petitions-- if any of the blocking actions of > which the IESG has been accused occurred wrt the outputs > these relevant WGs. Indeed, if I were to advise the > Nomcom, I would suggest that willingness to go that far > --and good sense about when or whether to do so-- would > be an important criterion for a prospective candidate. > > And, to preempt any paranoid speculations, I don't want the job. > > john > > From problem-statement-bounces@alvestrand.no Sun May 18 15:37: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 PAA16130 for ; Sun, 18 May 2003 15:37:15 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7722E62598; Sun, 18 May 2003 21:39:51 +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 60EC662594 for ; Sun, 18 May 2003 21:39:48 +0200 (CEST) Received: from adsl-68-120-231-239.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4IJdPN18394; Sun, 18 May 2003 12:39:25 -0700 Date: Sun, 18 May 2003 12:41:55 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <603105205.20030518124155@brandenburg.com> To: John C Klensin In-Reply-To: <59370269.1053255097@p3.JCK.COM> References: <5.1.0.14.2.20030515114755.014cedb8@mail.windriver.com > <5.1.0.14.2.20030515114755.014cedb8@mail.windriver.com> <5.1.0.14.2.20030516115353.03c92960@mail.windriver.com> <59370269.1053255097@p3.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman Cc: "problem-statement@alvestrand.no" Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re: OPEN ISSUE: Quality Process WG Charter) 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> fourth option: We ask the IESG to expeditiously create a new, JCK> but temporary, area for process review and reform, with, say, a JCK> one-year expiration period requiring community assent to keep it JCK> going any longer. very creative. I like it a lot. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Sun May 18 21: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 VAA21922 for ; Sun, 18 May 2003 21:00:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5CE3A6259D; Mon, 19 May 2003 03:00:01 +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 3A2D8621B8 for ; Mon, 19 May 2003 02:59:59 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA16044; Sun, 18 May 2003 17:59:37 -0700 (PDT) Message-Id: <5.1.0.14.2.20030518203335.04027ba0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 18 May 2003 20:55:40 -0400 To: John C Klensin From: Margaret Wasserman In-Reply-To: <59370269.1053255097@p3.JCK.COM> References: <5.1.0.14.2.20030516115353.03c92960@mail.windriver.com> <5.1.0.14.2.20030515114755.014cedb8@mail.windriver.com > <5.1.0.14.2.20030515114755.014cedb8@mail.windriver.com> <5.1.0.14.2.20030516115353.03c92960@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "problem-statement@alvestrand.no" Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re: OPEN ISSUE: Quality Process WG Charter) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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, First, a point of clarification... The current process document suggests two WGs: - A long-term WG to work on IETF organization and standards-track process. - A near-term WG to focus on iterative improvements to WG quality processes. Would your proposal apply to both WGs? Would it apply to other ongoing process-oriented WGs, such as the nomcom WG? At 10:51 AM 5/18/2003 -0400, John C Klensin wrote: >>Would you like to propose an alternative? > >Margaret, I'd like to propose something as a strawman, partially based on >further thought after my comments about process yesterday. This is a >radical suggestion and may not be a good idea, but I'd like to see if it >resonates with others or at least stimulates some discussion and other >suggestions. I think that this is an interesting suggestion. It may present a reasonable compromise between the people who would demand that an "outsider" (i.e. someone who isn't a current I* member) oversee this process, and those who would insist on keeping control of the IETF's process definition inside the IETF. Honestly, I don't know enough about the IETF Chair's work load to know if serving as the responsible AD for these WGs would present an overloading problem for the IETF chair, and I would trust the IETF chair to run this process both fairly and openly, but I do understand that having the IETF chair serve as a responsible AD effectively removes one step in the appeals process (since responsible AD == IETF chair), which isn't great. > (3) Some (perhaps very few) of us are more trustful of > the IESG as a group, but are uncomfortable about the > General Area, the notion of the IETF Chair wearing this > hat in addition to all of the others, and the > implications the first approach causes with the appeals > process. We also don't see an ISOC-based approach as > really being feasible. I don't really fall into this area -- I'm trust the IESG both individually and as a group. However, I consider your alternative _much_ better than the ISOC-driven approach. >So, again, at least as something to think about, I suggest a fourth >option: We ask the IESG to expeditiously create a new, but temporary, >area for process review and reform, with, say, a one-year expiration >period requiring community assent to keep it going any longer. We ask the >Nomcom to select an AD for that area, again asking them to expedite the >action. The IESG appoints one of its number (with the Chair/ General Area >AD being the obvious choice since the workload would be the same as under >option (1)) to fill in during the interim. In general, this looks like a workable proposal to me. I'm not sure that your approach is necessary, but I also don't have any serious objections to it. I am not sure about the one year period -- I think that two years is a better initial period, given the scope of this work, perhaps with one year extensions after that? We also might want to consider something like a ~1-1/2 year initial term to sync up the renewals with the regular nomcom cycle. Would this person serve like a regular member of the IESG in other respects (i.e. attend IESG meetings, review documents, etc.)? I've been told that there are already some problems with the size of the IESG -- too many people for certain types of decision making. How bad is this problem? And how much would it affect the group to add one more IESG member? >What does this do for us? [...] > * It is very much part of the existing process model, > doesn't raise special concerns about appeals, etc. This is very important. Inventing a new process, or making major modifications to an existing process, just for one or two WGs seems like a very bad idea. >And, to preempt any paranoid speculations, I don't want the job. ...which might be an important qualification ;-). Margaret From problem-statement-bounces@alvestrand.no Sun May 18 21: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 VAA22440 for ; Sun, 18 May 2003 21:23:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9F0F5625A5; Mon, 19 May 2003 03:26:19 +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 7E4CA62594 for ; Mon, 19 May 2003 03:26:18 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19HZPt-000IZ9-00; Sun, 18 May 2003 20:26:17 -0500 Date: Sun, 18 May 2003 21:26:17 -0400 From: John C Klensin To: Margaret Wasserman Message-ID: <97449895.1053293177@p3.JCK.COM> In-Reply-To: <5.1.0.14.2.20030518203335.04027ba0@mail.windriver.com> References: <5.1.0.14.2.20030516115353.03c92960@mail.windriver.com > <5.1.0.14.2.20030515114755.014cedb8@mail.windriver.com > <5.1.0.14.2.20030515114755.014cedb8@mail.windriver.com> <5.1.0.14.2.20030516115353.03c92960@mail.windriver.com> <5.1.0.14.2.20030518203335.04027ba0@mail.windriver.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: Charters, "normal process" versus ISOC, etc. (was: Re: OPEN ISSUE: Quality Process WG Charter) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On Sunday, 18 May, 2003 20:55 -0400 Margaret Wasserman wrote: > Hi John, > > First, a point of clarification... > > The current process document suggests two WGs: > > - A long-term WG to work on IETF organization > and standards-track process. > - A near-term WG to focus on iterative > improvements to WG quality processes. > > Would your proposal apply to both WGs? Would it apply to other > ongoing process-oriented WGs, such as the nomcom WG? I believe that current procedure leaves the decision as to which WGs to assign to a particular area in the hands of the IESG. I don't see any reason to change that. From my point of view, this special/temporary area should be a "normal" as possible and should not require exceptional procedures. I do assume that the community would form opinions about the IESG -- opinions that might potentially alter the results of the problem-statement WG -- but the community is free to form such opinions about unrelated WG assignments and other IESG actions as well. That is, I guess, my advice to this WG if the WG wants to make that "temporary area" recommendation to the IESG: assignment of WGs to areas is an IESG responsibility, not something that is appropriately micromanaged from the bottom up. If I were advising the IESG on the subject, I would suggest to them that this area get all of the process-related activities now assigned to (and being contemplated in/for) the General Area, include both of the above, problem-statement, IPR, nomcom and any other vestiges of Poission, and, if they determine that it should involve a WG or BOF, rather than just a Last Call, any review efforts on the IESG Charter or related documents. I would also suggest to them that, if they retained some of these WGs in the General Area or elsewhere --which I believe they should continue to have the perfect right to do-- a brief explanation to the community would be courteous and appropriate. regards, john From problem-statement-bounces@alvestrand.no Sun May 18 23:14: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 XAA23993 for ; Sun, 18 May 2003 23:14:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B5E42625A9; Mon, 19 May 2003 05:16:36 +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 C8AF0625A7 for ; Mon, 19 May 2003 05:16:34 +0200 (CEST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])h4J3GXD27947 for ; Mon, 19 May 2003 06:16:34 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com for ; Mon, 19 May 2003 06:16:33 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 19 May 2003 06:16:33 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 19 May 2003 06:16: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, 19 May 2003 06:16:33 +0300 Message-ID: Thread-Topic: I-D ACTION:draft-ietf-problem-process-00.txt Thread-Index: AcMdUccQXXeTOCVSR+eoEQtHEoja7QAYs+nw From: To: X-OriginalArrivalTime: 19 May 2003 03:16:33.0660 (UTC) FILETIME=[0CBE73C0:01C31DB5] Subject: Some examples from realatively new IETFers X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 XAA23993 Hi all, I've recieved the following mail (specifics are changed) from a collegue who is new to the IETF. I'm just posting this as an example of problems that people face when trying to get work done in the IETF. Take it as you will, but from my point of view, it shows that the system is not transparent. br, John ==================== I've got a funny effect of having preliminary work for XYZ technology "approved" for the BYOB WG charter at the end of IETF-xx. There was a two month delay with no real idea what was going on except that the decision had already taken place. This time we got caught out as we planned to work publicly on the new chartered items when the items became officially public, and lost (only) a month - but I won't repeat that error next time (assuming the problem statement remains valid for a few more months). Since we are attempting to "fast track" this XYZ work item (go from the real work on IDs start to finish in 12 months), it seems amazing that at least half of the time (I guess 6 months - 3½ already this year) will be working with the lights off - not knowing whether the "IETF powers that be" will kill or praise it at the next day break. Is this normal to be working 50% in the "don't crush me please" dark? From problem-statement-bounces@alvestrand.no Mon May 19 03:11: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 DAA10324 for ; Mon, 19 May 2003 03:11:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 83980625A1; Mon, 19 May 2003 09:14:14 +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 56A13621B8 for ; Mon, 19 May 2003 09:14:12 +0200 (CEST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) h4J7E9Ci049990 for ; Mon, 19 May 2003 09:14:11 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4J7E5ha244346 for ; Mon, 19 May 2003 09:14:06 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA62364 from ; Mon, 19 May 2003 09:14:03 +0200 Message-Id: <3EC88458.47B0E75A@hursley.ibm.com> Date: Mon, 19 May 2003 09:14:32 +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: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD8DB@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: OPEN ISSUE: Appeals Path X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit "Bound, Jim" wrote: > > Yep I knew that about tech appeals. Suggesting we discuss if we want > ISOC also for tech appeals but did not directly in the mail. Sorry. Not if you believe that technical appeals should be heard by people who understand them. The ISOC Board is simply not competent for technical discussions; it relies on the IAB for technical advice. Brian > /jim > > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: Saturday, May 17, 2003 10:48 AM > > To: Margaret Wasserman > > Cc: Bound, Jim; Dave Crocker; problem-statement@alvestrand.no > > Subject: RE: OPEN ISSUE: Appeals Path > > > > > > On Sat, 17 May 2003, Margaret Wasserman wrote: > > > >WG Chair > > > >IESG > > > >IAB > > > >ISOC > > > > > > > >This is standard open door policy in any company I know of too. > > > > > > Yes, and this also matches the standard appeals process for IETF WG > > > activities. > > > > "IETF WG activities" is ambiguous. The path holds for > > process appeals, > > but for technical appeals, the IAB is the highest you can go. > > > > -- > > 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 May 19 03:30: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 DAA10698 for ; Mon, 19 May 2003 03:30:30 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E95FD625A7; Mon, 19 May 2003 09:33:06 +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 EBED5621B8 for ; Mon, 19 May 2003 09:33:04 +0200 (CEST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) h4J7WwUm055830 for ; Mon, 19 May 2003 09:33:00 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4J7WCut086166 for ; Mon, 19 May 2003 09:32:12 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA66172 from ; Mon, 19 May 2003 09:32:11 +0200 Message-Id: <3EC88898.D3378D0E@hursley.ibm.com> Date: Mon, 19 May 2003 09:32:40 +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: <200305181512.h4IFCxGC009842@newdev.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 Scott. I trust Harald and I would be entirely happy for this work to be done in the General area. But there is no problem about doing it in an interim area, except that it means finding an interim AD as well as WG Chairs. Cobbling together an ad hoc process involving the ISOC Board would be a big mistake, however. The ISOC Board is automatically part of the standard process anyway. Brian Scott Bradner wrote: > > I've been trying to figure out what to say in this debate > > I strongly do not like the idea of distorting the normal IETF process in > this or any other "special" case and was having a hard time figuring out > the threat model that said we needed to do so. > > I do think that there are quite real problems that need to be fixed but I > do not think that the IETF chair or the IESG are so broken to think that > they could control the evolutionary process by picking a chair that would > do so or to reject the output of a process revision working group even > though they have the structural ability to do so. I have not seen an > indication that the current IESG members (or the Chair) are so disconnected > from the rest of the IETF to think that they could do that. (But then > again, I've not seen much input from the current IETF members on this list > so I suppose I could be wrong but I do not think so.) > > My preference would be to just do the normal thing and form a working group > in the General Area with the chair(s) for the group being selected by the > IETF Chair (using, for example, the process he used to select the chairs > for the problem statement WG - a quite public process) > > But, if some people are so distrustful of the Chair to keep them from being > able to support the IETF just using IETF processes to change the IETF > (which is what we did the last time) then I think that John's suggestion of > a temporary area is a reasonable one, we have done temporary areas in the > past (with which I have some familiarity) and it is not a distortion of the > basic IETF process. > > Scott From problem-statement-bounces@alvestrand.no Mon May 19 04:03: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 EAA11361 for ; Mon, 19 May 2003 04:03:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 80D2A6238F; Mon, 19 May 2003 10:06:04 +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 23ABF621B8 for ; Mon, 19 May 2003 10:06:02 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4J85wZ15537; Mon, 19 May 2003 11:05:58 +0300 Date: Mon, 19 May 2003 11:05:58 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter In-Reply-To: <3EC88898.D3378D0E@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: problem-statement@alvestrand.no Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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, 19 May 2003, Brian E Carpenter wrote: > I agree with Scott. I trust Harald and I would be entirely happy for > this work to be done in the General area. But there is no problem about > doing it in an interim area, except that it means finding an interim AD > as well as WG Chairs. I'm fine with either approach. But remember that one of the other problems was the shallowness of the pool for IESG positions. The chosen AD would have to sit on all IESG teleconferences and take part in those ballots, read the drafts put before the IESG etc.etc. too. (Except if these are specifically designated out of scope when chartering the temporary AD "position".) Depending on the level of responsibility, it would be huge task -- and I rather think that a relatively open process to pick a chair, like with problem-statement, would be both the fastest and the easiest approach. -- 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 May 19 07:45: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 HAA17833 for ; Mon, 19 May 2003 07:45:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9AF38625A3; Mon, 19 May 2003 13:47:38 +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 89C3E623F9 for ; Mon, 19 May 2003 13:47:36 +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 7C3BEC553; Mon, 19 May 2003 07:47:35 -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, 19 May 2003 07:47: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: Mon, 19 May 2003 07:47:34 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD8FD@tayexc13.americas.cpqcorp.net> Thread-Topic: Charters, "normal process" versus ISOC, etc. (was: Re Thread-Index: AcMd2PC97KM+kNJoQ/atunhLU3rBJAAI4W5A From: "Bound, Jim" To: "Brian E Carpenter" , X-OriginalArrivalTime: 19 May 2003 11:47:35.0379 (UTC) FILETIME=[708D7A30:01C31DFC] Subject: RE: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 HAA17833 I agree too. /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Monday, May 19, 2003 3:33 AM > To: problem-statement@alvestrand.no > Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re > > > I agree with Scott. I trust Harald and I would be entirely > happy for this work to be done in the General area. But there > is no problem about doing it in an interim area, except that > it means finding an interim AD as well as WG Chairs. > > Cobbling together an ad hoc process involving the ISOC Board > would be a big mistake, however. The ISOC Board is > automatically part of the standard process anyway. > > Brian > > Scott Bradner wrote: > > > > I've been trying to figure out what to say in this debate > > > > I strongly do not like the idea of distorting the normal > IETF process > > in this or any other "special" case and was having a hard time > > figuring out the threat model that said we needed to do so. > > > > I do think that there are quite real problems that need to be fixed > > but I do not think that the IETF chair or the IESG are so broken to > > think that they could control the evolutionary process by picking a > > chair that would do so or to reject the output of a process > revision > > working group even though they have the structural ability > to do so. > > I have not seen an indication that the current IESG members (or the > > Chair) are so disconnected from the rest of the IETF to think that > > they could do that. (But then again, I've not seen much input from > > the current IETF members on this list so I suppose I could be wrong > > but I do not think so.) > > > > My preference would be to just do the normal thing and form > a working > > group in the General Area with the chair(s) for the group being > > selected by the IETF Chair (using, for example, the process > he used to > > select the chairs for the problem statement WG - a quite public > > process) > > > > But, if some people are so distrustful of the Chair to keep > them from > > being able to support the IETF just using IETF processes to > change the > > IETF (which is what we did the last time) then I think that John's > > suggestion of a temporary area is a reasonable one, we have done > > temporary areas in the past (with which I have some > familiarity) and > > it is not a distortion of the basic IETF process. > > > > Scott > From problem-statement-bounces@alvestrand.no Mon May 19 08:50: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 IAA19471 for ; Mon, 19 May 2003 08:50:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5CF5A625B5; Mon, 19 May 2003 14:53: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 7BB95621B8 for ; Mon, 19 May 2003 14:53:03 +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 62C5595CD; Mon, 19 May 2003 08:53:02 -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, 19 May 2003 08:53: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: Mon, 19 May 2003 08:53:00 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD904@tayexc13.americas.cpqcorp.net> Thread-Topic: OPEN ISSUE: Appeals Path Thread-Index: AcMd1k2eA4voF6lMQQes9ZhGRlAwqgALz69w From: "Bound, Jim" To: "Brian E Carpenter" , X-OriginalArrivalTime: 19 May 2003 12:53:01.0351 (UTC) FILETIME=[949D4370:01C31E05] Subject: RE: OPEN ISSUE: Appeals Path X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 IAA19471 I agree I stated it so someone else would say this not me. Your a brave man :--) OK thats over. thanks /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Monday, May 19, 2003 3:15 AM > To: problem-statement@alvestrand.no > Subject: Re: OPEN ISSUE: Appeals Path > > > "Bound, Jim" wrote: > > > > Yep I knew that about tech appeals. Suggesting we discuss > if we want > > ISOC also for tech appeals but did not directly in the mail. Sorry. > > Not if you believe that technical appeals should be heard by > people who understand them. The ISOC Board is simply not > competent for technical discussions; it relies on the IAB for > technical advice. > > Brian > > > /jim > > > > > -----Original Message----- > > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > > Sent: Saturday, May 17, 2003 10:48 AM > > > To: Margaret Wasserman > > > Cc: Bound, Jim; Dave Crocker; problem-statement@alvestrand.no > > > Subject: RE: OPEN ISSUE: Appeals Path > > > > > > > > > On Sat, 17 May 2003, Margaret Wasserman wrote: > > > > >WG Chair > > > > >IESG > > > > >IAB > > > > >ISOC > > > > > > > > > >This is standard open door policy in any company I know of too. > > > > > > > > Yes, and this also matches the standard appeals process > for IETF > > > > WG activities. > > > > > > "IETF WG activities" is ambiguous. The path holds for process > > > appeals, but for technical appeals, the IAB is the > highest you can > > > go. > > > > > > -- > > > 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 May 19 09:08: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 JAA19864 for ; Mon, 19 May 2003 09:07:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 40C83625C0; Mon, 19 May 2003 15:10: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 3A22F625BA; Mon, 19 May 2003 15:10:31 +0200 (CEST) Date: Mon, 19 May 2003 12:02:11 +0200 From: Harald Tveit Alvestrand To: John C Klensin , "problem-statement@alvestrand.no" Message-ID: <241628984.1053345731@localhost> In-Reply-To: <6459658.1053158473@p3.JCK.COM> References: <200305161703.h4GH3ODi023565@newdev.harvard.edu> <6459658.1053158473@p3.JCK.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: Document Blocking (Was: I-D X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 17. mai 2003 08:01 -0400 John C Klensin wrote: >> when an AD has an issue with a document and has voted >> "discuss" the document and the issues are discussed during an >> IESG teleconference - sometimes the discussion results in the >> AD changing their evaluation and removing their "discuss" > > And sometimes, it results in the AD saying, more or less, "I will explain > my reasons in a note or draft writeup". At that stage, unless there is a > clear consensus that the AD is off base, the IESG will give the AD as > much time as needed to do that writeup (after all, each AD might be in > the same position next time). That can take an arbitrarily long time. replying to a sub-point of a sub-point in this thread (more later...) actually we imposed a deadline on ourselves last year. Discuss writeups are due before the next telechat, or the Discuss will be considered lifted. Most Discusses that are communicated vocally on the call have their writeups on the list before the end of the call; Discusses that come in on email have their writeup with them, of course. Note that not all writeups need to be long - for instance, Randy's DISCUSS comment on EPP was about one sentence long, but it re-triggered a huge debate within the WG about appropriate considerations for privacy. (tangential..... I am sometimes frustrated that WGs seem to take a Discuss as "declaration from on high that a technical decision needs to be changed", rather than as a challenge asking them to explain their positions better; afrter all, what has happened is that the IESG has failed to understand that the WG position is reasonable; either the WG is wrong, or the documents have insufficient convincing power - increasing the convincing power SHOULD be the right answer in some cases. But that seems rare....) Harald From problem-statement-bounces@alvestrand.no Mon May 19 09:24: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 JAA20196 for ; Mon, 19 May 2003 09:24:01 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 13930625B6; Mon, 19 May 2003 15:26:37 +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 DE95A621B8; Mon, 19 May 2003 15:26:29 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19Hker-000MVI-00; Mon, 19 May 2003 08:26:29 -0500 Date: Mon, 19 May 2003 09:26:28 -0400 From: John C Klensin To: Harald Tveit Alvestrand , "problem-statement@alvestrand.no" Message-ID: <140660909.1053336388@p3.JCK.COM> In-Reply-To: <241628984.1053345731@localhost> References: <200305161703.h4GH3ODi023565@newdev.harvard.edu> <6459658.1053158473@p3.JCK.COM> <241628984.1053345731@localhost> 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: Document Blocking (Was: I-D X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, 19 May, 2003 12:02 +0200 Harald Tveit Alvestrand wrote: > --On 17. mai 2003 08:01 -0400 John C Klensin > wrote: > >>> when an AD has an issue with a document and has voted >>> "discuss" the document and the issues are discussed during an >>> IESG teleconference - sometimes the discussion results in the >>> AD changing their evaluation and removing their "discuss" >> >> And sometimes, it results in the AD saying, more or less, "I >> will explain my reasons in a note or draft writeup". At that >>... > replying to a sub-point of a sub-point in this thread (more > later...) > > actually we imposed a deadline on ourselves last year. > Discuss writeups are due before the next telechat, or the > Discuss will be considered lifted. Most Discusses that are > communicated vocally on the call have their writeups on the > list before the end of the call; Discusses that come in on > email have their writeup with them, of course. This is a significant improvement. Have you seen the difference in throughput? Just for clarification, this applies to _all_ documents -- standards-track and not, and both WG-originated and individual submissions. Right? > (tangential..... I am sometimes frustrated that WGs seem to > take a Discuss as "declaration from on high that a technical > decision needs to be changed", rather than as a challenge > asking them to explain their positions better; afrter all, > what has happened is that the IESG has failed to understand > that the WG position is reasonable; either the WG is wrong, or > the documents have insufficient convincing power - increasing > the convincing power SHOULD be the right answer in some cases. > But that seems rare....) It seems to me that this is a call for more WG training and/or for an explicit, boilerplate, cover note from IESG members to WGs (and individual authors) indicating precisely that additional explanation would be as welcome as a change. The latter, at least, would seem to be easy to implement. john From problem-statement-bounces@alvestrand.no Mon May 19 09: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 JAA20788 for ; Mon, 19 May 2003 09:48:46 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 44422625B8; Mon, 19 May 2003 15:51: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 5ED86623F9 for ; Mon, 19 May 2003 15:51: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 GAA61023 for ; Mon, 19 May 2003 06:51:17 -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 AsF0gwL2 Mon, 19 May 2003 06:51:17 -0700 (PDT) Message-ID: <026201c31e0d$b95f3b20$0300a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <200305161703.h4GH3ODi023565@newdev.harvard.edu> <6459658.1053158473@p3.JCK.COM> <241628984.1053345731@localhost> <140660909.1053336388@p3.JCK.COM> Date: Mon, 19 May 2003 08:51: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: Document Blocking (Was: I-D 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'm glad to see Harald and John making this point. I see two common reactions, based on whether the WG sees IESG as gatekeepers ("you can't do this") or as questioners ("we don't understand why you want to do this"). Using a feedback template that emphasizes the IETF' role as "questioners" seems helpful. Spencer ----- Original Message ----- From: "John C Klensin" To: "Harald Tveit Alvestrand" ; Sent: Monday, May 19, 2003 8:26 AM Subject: Re: Document Blocking (Was: I-D > --On Monday, 19 May, 2003 12:02 +0200 Harald Tveit Alvestrand > wrote: > > > --On 17. mai 2003 08:01 -0400 John C Klensin > > wrote: > > > > (tangential..... I am sometimes frustrated that WGs seem to > > take a Discuss as "declaration from on high that a technical > > decision needs to be changed", rather than as a challenge > > asking them to explain their positions better; afrter all, > > what has happened is that the IESG has failed to understand > > that the WG position is reasonable; either the WG is wrong, or > > the documents have insufficient convincing power - increasing > > the convincing power SHOULD be the right answer in some cases. > > But that seems rare....) > > It seems to me that this is a call for more WG training and/or > for an explicit, boilerplate, cover note from IESG members to > WGs (and individual authors) indicating precisely that > additional explanation would be as welcome as a change. The > latter, at least, would seem to be easy to implement. > > john > From problem-statement-bounces@alvestrand.no Mon May 19 09:54: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 JAA20888 for ; Mon, 19 May 2003 09:54:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 23C0C625B7; Mon, 19 May 2003 15:56:55 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1E494625B7 for ; Mon, 19 May 2003 15:56:48 +0200 (CEST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4JDukXD267388; Mon, 19 May 2003 09:56:46 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-239-250.mts.ibm.com [9.65.239.250])h4JDujlE166438; Mon, 19 May 2003 07:56:46 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h4JDuUU30442; Mon, 19 May 2003 09:56:30 -0400 Message-Id: <200305191356.h4JDuUU30442@cichlid.adsl.duke.edu> To: Pete Resnick In-Reply-To: Message from presnick@qualcomm.com of "Fri, 16 May 2003 11:15:29 CDT." Date: Mon, 19 May 2003 09:56:30 -0400 From: Thomas Narten Cc: problem-statement@alvestrand.no Subject: Re: Document Blocking (Was: I-D ACTION:draft-ietf-problem-process-00.txt) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Pete Resnick writes: > On 5/16/03 at 2:49 PM +0200, Brian E Carpenter wrote: > > > 5. Modify IESG-internal processes to make it impossible for one > >> or two IESG members to block a document. > > > >There is a strong implication here that ADs might do this for > >spurious reasons. > I don't think it makes a difference to the issue, but let's even > assume that it is *not* done for spurious reasons. I have to say something here, as this issue keeps being brought up. Reading this list, one could easily get the idea that the ADs love to block documents, usually don't have a good reason for doing so (and thus fall back to procedural tricks), and that the ADs actually are hostile towards each others with tit-for-tat happening if one AD blocks a document belonging to someone else. That is not the IESG I know or that I would want to be a part of. It is my assumption and belief that when an AD puts in a discuss, other ADs _do_ support that. [Note: this is a topic I will bring up explicitely within the IESG, in case I'm totally clueless about how others really feel here.] When this isn't the case, the shepherding AD will object, argue the issue isn't worth pushing back on, or provide other context for why raising the issue doesn't make sense. Then there is discussion and give and take. Sometimes the objecting AD will withdraw their discuss, sometimes not. In fact, it is quite common for other ADs to agree, but to explicitely NOT put in a formal discuss, trusting the one AD to deal with the issue satisfactoraly and not wanting to add more process overhead (i.e., another AD that must clear their discuss). One of the common "votes" that happens during the telechats is "no further objection" which formally means "no objection" but in practice means "I agree with others, but don't have more to add and don't need to be in the process loop to see that the document gets fixed". Forcing the IESG to have "consensus" or "unanimity" (those words have been used on this thread) on all discusses procedurally seems like a high overhead approach for dealing with a particular problem. I'd actually like to better understand how much of a REAL problem it is that individual ADs are impropropely blocking documents with the "single AD veto". There are many comments that imply it happens "all the time" and that "everyone has examples". But I wonder sometimes if we are all thinking of the same document from 3 years ago. We can't fix what happened 3 years ago, but we can fix things that are broken _today_. > >But if one or both Security ADs are deeply convinced that a draft > >constitutes a major security risk, or one or both Routing ADs are > >convinced that a draft will lead to routing loops, isn't it quite > >appropriate for them to block the document? > Absolutely not, but *not* because the document shouldn't be stopped. > The ADs who think that there is a serious problem with a document > should convince the rest of the IESG that the document is a bad > idea. This in effect is happening AFAIK. The IESG does support the security ADs when this happens. > Then, the IESG can come to consensus (or unanimity) to reject a > document (or at least stop it until the problem is fixed). I think it would be inefficient at best to force this level of process onto discusses. > The problem with the current process (as I understand it) is that it > allows documents to be blocked by one or two IESG members without the > consensus of the group. In theory, yes. But in practice? It would be instructive for the IESG to ask itself where this has happened, and I will bring up the topic. My sense is very rarely, but I could be wrong. But at least some on the community assume this happens often enough that we need more procedure to prevent it from happening. Concrete examples would be useful to provide context. > The current procedure assumes that one or two IESG members must be > able to block a document because the rest of the IESG is so stupid > or ignorant that they cannot be convinced that the document is a bad > idea, even if one or two experts on the IESG know that it is. That is one way to look at it, but it would be inconsistent with my understanding of things. The way I see it is is that when someone raises an issue, and the IESG supports the objection, a one-person discuss is the staightforward way to deal with the problem. Should responses to every discuss get reviewed by the entire IESG? There is a scaling issue here... > If that were actually the case, it points to a much worse state of > affairs, where IESG members don't trust each other to do the right > thing. This is not the case, from what I know. Note: This note might come across as sounding like I don't think there are any problems that need fixing. There are. But I am unconvinced that the "one AD veto" is one of the real problems. Given that at least some in the community appear to think it is a problem, I'd really appreciate some concrete examples. My suspicion is that if we look at specifics, the reality may be quite a bit different than the appearance. Thomas From problem-statement-bounces@alvestrand.no Mon May 19 09:55: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 JAA20914 for ; Mon, 19 May 2003 09:55:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 47199625BB; Mon, 19 May 2003 15:57:42 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by eikenes.alvestrand.no (Postfix) with ESMTP id 36F7A623F9 for ; Mon, 19 May 2003 15:57:40 +0200 (CEST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id B16F56BA58 for ; Mon, 19 May 2003 09:57:38 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.grc.nasa.gov [139.88.87.35]) h4JDvcuW010671 for ; Mon, 19 May 2003 09:57:38 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id JAA98002; Mon, 19 May 2003 09:57:37 -0400 (EDT) Message-Id: <200305191357.JAA98002@guns.lerc.nasa.gov> To: problem-statement@alvestrand.no From: Mark Allman Organization: BBN Technologies/NASA GRC Song-of-the-Day: Lift Me Up Date: Mon, 19 May 2003 09:57:37 -0400 Subject: non-problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mallman@grc.nasa.gov List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Folks- This isn't a problem. It's not a solution, either. So, I am not sure where to throw it. I have not read the PS list as a whole in great detail because (a) you guys move too fast for me! and (b) I think we're wandering in the minutia a little more than we need to be at this point. So, maybe someone has brought this up.... But, I would like to encourage folks to pop-up a level and consider the fundemental problems we have discussed (e.g., "transparency of document flow", or "late surprises", not "choosing a WG chair") **in addition to** our "non-problems". We have written a whole lot of standards using the current process. We have to be doing something right. No? (Maybe not ... maybe we did something right and the whole system doesn't scale.) I am not necessarily encouraging folks to do this exercise on this mailing list (the chairs would likely be getting their rulers ready for my knuckles). I am encouraging musing about this in preparation for the next phase of this whole process on what we should do about all of our problems. Examples: If the solutions phase started and someone threw out a proposal that rid us of a central body that has tight control of all output (ala the IESG) would people squirm? What if someone proposed realigning WGs in a different way (say, a looser, longer-lived way)? Would that cause alarm? (With appologies to Dave Clark,) What if it was proposed that SIRs get to *vote* on documents? Would that be wrong? I am not really asking the questions above -- they are just examples of things that might get the juices flowing. I believe that we have concurred that we have a healthy number of fundemental problems. If we were going to fundementally change the state of the IETF, what would be off limits in your mind? And, why? Just something to think about if you're inclined. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ From problem-statement-bounces@alvestrand.no Mon May 19 10:17: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 KAA22706 for ; Mon, 19 May 2003 10:17:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 54980625BD; Mon, 19 May 2003 16:20:27 +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 E6062623F9 for ; Mon, 19 May 2003 16:20: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 D664E9D46; Mon, 19 May 2003 10:20:15 -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, 19 May 2003 10:20: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, 19 May 2003 10:19:10 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0324127D@tayexc13.americas.cpqcorp.net> Thread-Topic: Document Blocking (Was: I-DACTION:draft-ietf-problem-process-00.txt) Thread-Index: AcMeDpS9KN/GxwXMQYyUSPXi6z5LNgAAJTcg From: "Bound, Jim" To: "Thomas Narten" , "Pete Resnick" X-OriginalArrivalTime: 19 May 2003 14:20:15.0632 (UTC) FILETIME=[C47D2900:01C31E11] Cc: problem-statement@alvestrand.no Subject: RE: Document Blocking (Was: I-DACTION:draft-ietf-problem-process-00.txt) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 KAA22706 Thomas, OK here is one example not a document real-time. multi6 is working through their process to get to point where they can discuss next steps for a very complex technology effort. The WG and WG Chairs want to meet in Vienna and multiple specs and ideas have been provided. The WG team is working and an agenda is being worked. The AD says we have nothing to discuss because no proposal. None of us agree with the AD. The AD was asked to please be more specific what they want and all we got so far is one liners that have no depth or explanation and what we are doing wrong. That is a problem. It also is real time example of us getting one liners in the IETF that are completely not helpful to us in the community. The AD should defend now their case with explicit positioning. Rather than try to change this as multi6 has before we have created a non IETF mutli6 list by invitation only and several solutions are being implemented now for commercial use and will be driven in the market. In addition we try to meet offline at the IETF on our own dime and time. In the Interim many of us propose RFC 3178 as temporary solution with users doing SLAs that have multiple providers which will work for now. This is happening with RDMA, Teredo, DSTM, ISATAP out of the IETF now and will be deployed and in some cases are currently in the market on IPv6 pre-production test beds and RDMA for IPv4. Note the same AD would not permit the latter transition mechanisms to be part of v6ops till a set of scenarios are going to be defined. OK fine we will do it out of the IETF and drive it in the market without the IETF. These were worked on with consensus for 3 years. We the WG were never permitted in the debate to work on existing ngtrans work or if we all agreed with the method of v6ops. Don't get me wrong I am doing the v6ops thing and we all are but the technology from ngtrans in fact was useful, is being deployed, and will be used. Just without the IETF. I believe all will put up experimental RFCs to put it in some IETF process. So this is a REAL problem and we in the market are NOT going to wait for the IETF any more I highly suggest we do have blockage at the AD level and it is hurting the IETF and possibly its image because all of this out of IETF work would not be supported or happening if real customers includinug Providers, Industry, and Government were not intereested. And no we are not going to reveal our customer efforts within a standards body so don't ask (thats not to you really but general comment and we do not lie and I suggest if I hear that response will be legal one from me). The IETF has to realize their scope and that is to do standards they are not the visionaries or responsible for the deployment of the Internet. If the IESG could get that around their brain and just do the job they were hired for and that is specs based on IP architecture I think progress would be better. So blockage is a problem in some cases. Respectfully, /jim > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Monday, May 19, 2003 9:57 AM > To: Pete Resnick > Cc: problem-statement@alvestrand.no > Subject: Re: Document Blocking (Was: > I-DACTION:draft-ietf-problem-process-00.txt) > > > Pete Resnick writes: > > > On 5/16/03 at 2:49 PM +0200, Brian E Carpenter wrote: > > > > > 5. Modify IESG-internal processes to make it > impossible for one > > >> or two IESG members to block a document. > > > > > >There is a strong implication here that ADs might do this for > > >spurious reasons. > > > I don't think it makes a difference to the issue, but let's even > > assume that it is *not* done for spurious reasons. > > I have to say something here, as this issue keeps being > brought up. Reading this list, one could easily get the idea > that the ADs love to block documents, usually don't have a > good reason for doing so (and thus fall back to procedural > tricks), and that the ADs actually are hostile towards each > others with tit-for-tat happening if one AD blocks a document > belonging to someone else. > > That is not the IESG I know or that I would want to be a part of. > > It is my assumption and belief that when an AD puts in a > discuss, other ADs _do_ support that. [Note: this is a topic > I will bring up explicitely within the IESG, in case I'm > totally clueless about how others really feel here.] When > this isn't the case, the shepherding AD will object, argue > the issue isn't worth pushing back on, or provide other > context for why raising the issue doesn't make sense. Then > there is discussion and give and take. Sometimes the > objecting AD will withdraw their discuss, sometimes not. In > fact, it is quite common for other ADs to agree, but to > explicitely NOT put in a formal discuss, trusting the one AD > to deal with the issue satisfactoraly and not wanting to add > more process overhead (i.e., another AD that must clear their > discuss). One of the common "votes" that happens during the > telechats is "no further objection" which formally means "no > objection" but in practice means "I agree with others, but > don't have more to add and don't need to be in the process > loop to see that the document gets fixed". > > Forcing the IESG to have "consensus" or "unanimity" (those > words have been used on this thread) on all discusses > procedurally seems like a high overhead approach for dealing > with a particular problem. > > I'd actually like to better understand how much of a REAL > problem it is that individual ADs are impropropely blocking > documents with the "single AD veto". There are many comments > that imply it happens "all the time" and that "everyone has > examples". But I wonder sometimes if we are all thinking of > the same document from 3 years ago. We can't fix what > happened 3 years ago, but we can fix things that are broken _today_. > > > >But if one or both Security ADs are deeply convinced that a draft > > >constitutes a major security risk, or one or both Routing ADs are > > >convinced that a draft will lead to routing loops, isn't it quite > > >appropriate for them to block the document? > > > Absolutely not, but *not* because the document shouldn't be stopped. > > The ADs who think that there is a serious problem with a document > > should convince the rest of the IESG that the document is a bad > > idea. > > This in effect is happening AFAIK. The IESG does support the > security ADs when this happens. > > > Then, the IESG can come to consensus (or unanimity) to reject a > > document (or at least stop it until the problem is fixed). > > I think it would be inefficient at best to force this level > of process onto discusses. > > > The problem with the current process (as I understand it) is that it > > allows documents to be blocked by one or two IESG members > without the > > consensus of the group. > > In theory, yes. But in practice? It would be instructive for > the IESG to ask itself where this has happened, and I will > bring up the topic. My sense is very rarely, but I could be wrong. > > But at least some on the community assume this happens often > enough that we need more procedure to prevent it from > happening. Concrete examples would be useful to provide context. > > > The current procedure assumes that one or two IESG members must be > > able to block a document because the rest of the IESG is so > stupid or > > ignorant that they cannot be convinced that the document is a bad > > idea, even if one or two experts on the IESG know that it is. > > That is one way to look at it, but it would be inconsistent > with my understanding of things. The way I see it is is that > when someone raises an issue, and the IESG supports the > objection, a one-person discuss is the staightforward way to > deal with the problem. Should responses to every discuss get > reviewed by the entire IESG? There is a scaling issue here... > > > If that were actually the case, it points to a much worse state of > > affairs, where IESG members don't trust each other to do the right > > thing. > > This is not the case, from what I know. > > Note: This note might come across as sounding like I don't > think there are any problems that need fixing. There are. But > I am unconvinced that the "one AD veto" is one of the real > problems. Given that at least some in the community appear to > think it is a problem, I'd really appreciate some concrete > examples. My suspicion is that if we look at specifics, the > reality may be quite a bit different than the appearance. > > Thomas > From problem-statement-bounces@alvestrand.no Mon May 19 10:18: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 KAA22750 for ; Mon, 19 May 2003 10:18:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5AC0A625BC; Mon, 19 May 2003 16:21:24 +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 C0DFF623F9 for ; Mon, 19 May 2003 16:21:21 +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 HAA87210 for ; Mon, 19 May 2003 07:21:20 -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 yfM0UkS2 Mon, 19 May 2003 07:21:19 -0700 (PDT) Message-ID: <02b801c31e11$ebb76d50$0300a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <200305191356.h4JDuUU30442@cichlid.adsl.duke.edu> Date: Mon, 19 May 2003 09:21:20 -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: Document Blocking (Was: I-DACTION:draft-ietf-problem-process-00.txt) 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 Thomas has good instincts for research design. I'm remembering from the book "Flaws and Fallacies in Statistical Thinking" about the estimates of the rat population in New York during the 1970s, when someone finally figured out that if a researcher saw a rat on the third floor of a slum, and a rat on the seventh floor, and a rat on the ninth floor, they could all be the same rat... Spencer ----- Original Message ----- From: "Thomas Narten" To: "Pete Resnick" Cc: Sent: Monday, May 19, 2003 8:56 AM Subject: Re: Document Blocking (Was: I-DACTION:draft-ietf-problem-process-00.txt) > > I'd actually like to better understand how much of a REAL problem it > is that individual ADs are impropropely blocking documents with the > "single AD veto". There are many comments that imply it happens "all > the time" and that "everyone has examples". But I wonder sometimes if > we are all thinking of the same document from 3 years ago. From problem-statement-bounces@alvestrand.no Mon May 19 10:23: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 KAA22939 for ; Mon, 19 May 2003 10:23:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6A45A625C3; Mon, 19 May 2003 16:26:26 +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 3356E625C1; Mon, 19 May 2003 16:26:23 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA07999; Mon, 19 May 2003 07:26:11 -0700 (PDT) Message-Id: <5.1.0.14.2.20030519101737.041cbf50@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 19 May 2003 10:22:17 -0400 To: Harald Tveit Alvestrand From: Margaret Wasserman In-Reply-To: <241628984.1053345731@localhost> References: <6459658.1053158473@p3.JCK.COM> <200305161703.h4GH3ODi023565@newdev.harvard.edu> <6459658.1053158473@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "problem-statement@alvestrand.no" Subject: Re: Document Blocking (Was: I-D X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 12:02 PM 5/19/2003 +0200, Harald Tveit Alvestrand wrote: >(tangential..... I am sometimes frustrated that WGs seem to take a Discuss >as "declaration from on high that a technical decision needs to be >changed", rather than as a challenge asking them to explain their >positions better; I agree with other comments that this could be made clearer in how IESG DISCUSS comments are communicated to the WG. For example, why doesnt' the IESG member with the DISCUSS send a message directly to the WG raising the issue? >after all, what has happened is that the IESG has failed to understand >that the WG position is reasonable; either the WG is wrong, or the >documents have insufficient convincing power - increasing the convincing >power SHOULD be the right answer in some cases. But that seems rare....) Why are there only two choices that "the WG is wrong, or the documents have insufficient convincing power"? While I don't think it happens very often, couldn't the IESG be wrong? Also, some AD review comments and DISCUSS comments are really about matters of taste -- the belief that a section should be removed from a document because it is redundant (not wrong, just redundant), the opinion that some historical note should be added explaining why something was done a particular way, etc. In those cases, there may be no right or wrong. In general, the IESG wins because they can block publication of the document. Do you think that's reasonable? Margaret From problem-statement-bounces@alvestrand.no Mon May 19 11:02: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 LAA23764 for ; Mon, 19 May 2003 11:01:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1300C625CA; Mon, 19 May 2003 17:01:38 +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 4B95E625BE; Mon, 19 May 2003 17:01:35 +0200 (CEST) Date: Mon, 19 May 2003 17:00:56 +0200 From: Harald Tveit Alvestrand To: John C Klensin , "problem-statement@alvestrand.no" Message-ID: <259553818.1053363656@localhost> In-Reply-To: <140660909.1053336388@p3.JCK.COM> References: <200305161703.h4GH3ODi023565@newdev.harvard.edu> <6459658.1053158473@p3.JCK.COM> <241628984.1053345731@localhost> <140660909.1053336388@p3.JCK.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: Document Blocking (Was: I-D X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 19. mai 2003 09:26 -0400 John C Klensin wrote: >> actually we imposed a deadline on ourselves last year. >> Discuss writeups are due before the next telechat, or the >> Discuss will be considered lifted. Most Discusses that are >> communicated vocally on the call have their writeups on the >> list before the end of the call; Discusses that come in on >> email have their writeup with them, of course. > > This is a significant improvement. Have you seen the difference in > throughput? We haven't really measured throughput... Eric Rescorla's numbers might show a change....? > > Just for clarification, this applies to _all_ documents -- > standards-track and not, and both WG-originated and individual > submissions. Right? Just for standards-track, since we don't formally ballot informationals. we've actually found that tracking the comments on informationals was problematic - ie we have had cases where we had comments on WG documents, a new version arrived 3 months later that purported to fix the comments, and we couldn't figure out from the logs what the original comment was. We've got a new system for ballot handling being built now (as part of the I-D tracker), and we decided that we'd simply add ballots for non-standards-track too - but with different approval rules (no need to wait for "enough" people to say no-objection; the document is OK if it's been on a telechat agenda and nobody objects). Trying to fix things where we can....... Harald From problem-statement-bounces@alvestrand.no Mon May 19 11:04: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 LAA23830 for ; Mon, 19 May 2003 11:04:37 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4A9F9625BE; Mon, 19 May 2003 17:07:13 +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 AB2D862582 for ; Mon, 19 May 2003 17:07:10 +0200 (CEST) Message-ID: <001a01c31e18$1c0342d0$b16015ac@DCLKEMPFTP> From: "James Kempf" To: "John C Klensin" , "Margaret Wasserman" References: <5.1.0.14.2.20030515114755.014cedb8@mail.windriver.com > <5.1.0.14.2.20030515114755.014cedb8@mail.windriver.com> <5.1.0.14.2.20030516115353.03c92960@mail.windriver.com> <59370269.1053255097@p3.JCK.COM> Date: Mon, 19 May 2003 08:05:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re: OPEN ISSUE: Quality Process WG Charter) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 like this idea. We should kick it around a little to see if anybody comes up with any potential unintended consequences, but I can't think of any. jak ----- Original Message ----- From: "John C Klensin" To: "Margaret Wasserman" Cc: Sent: Sunday, May 18, 2003 7:51 AM Subject: Charters, "normal process" versus ISOC, etc. (was: Re: OPEN ISSUE: Quality Process WG Charter) > > > --On Friday, 16 May, 2003 11:54 -0400 Margaret Wasserman > wrote: > > >> I don't think this group should propose a charter for that > >> group. > >> > >> And I'm not sure I even agree with the text in the process > >> document about how that group should proceed. > > > > Would you like to propose an alternative? > > Margaret, I'd like to propose something as a strawman, partially > based on further thought after my comments about process > yesterday. This is a radical suggestion and may not be a good > idea, but I'd like to see if it resonates with others or at > least stimulates some discussion and other suggestions. > > We seem to have three perspectives/ camps at the moment: > > (1) Use the normal process, including assigning these > working groups to the IETF Chair (i.e., the "General > Area"). That means having the Chair appointed by, and > serving at the pleasure of, the IETF Chair, the IETF > Chair making decisions about what WG decisions get > processed by the IESG, etc. > > (2) Some people are deeply concerned about this, seeing > the IESG as the problem and resistant to reform and the > IESG generally, and perhaps the Chair in particular, as > subject to inherent conflicts of interest in a reform > process. Many of them lean toward an ISOC-controlled > process. > > (3) Some (perhaps very few) of us are more trustful of > the IESG as a group, but are uncomfortable about the > General Area, the notion of the IETF Chair wearing this > hat in addition to all of the others, and the > implications the first approach causes with the appeals > process. We also don't see an ISOC-based approach as > really being feasible. > > So, again, at least as something to think about, I suggest a > fourth option: We ask the IESG to expeditiously create a new, > but temporary, area for process review and reform, with, say, a > one-year expiration period requiring community assent to keep it > going any longer. We ask the Nomcom to select an AD for that > area, again asking them to expedite the action. The IESG > appoints one of its number (with the Chair/ General Area AD > being the obvious choice since the workload would be the same as > under option (1)) to fill in during the interim. > > What does this do for us? > > * Like the ISOC plan, it puts someone in as "responsible > AD" for this work who is selected/ designated for the > purpose and who is not part of the existing IESG. The > reduces suspicions about conflicts of interest. And... > > * It also reduces concerns about available skill sets > (since the Nomcom would be selecting someone > specifically for this role) and time availability (since > the chosen AD would have no other WG or external > responsibilities). > > * It is very much part of the existing process model, > doesn't raise special concerns about appeals, etc. > > * And I think we can assume that a person who was > designated as responsible for this area would raise a > public outcry --if necessary to the point of filing > recall petitions-- if any of the blocking actions of > which the IESG has been accused occurred wrt the outputs > these relevant WGs. Indeed, if I were to advise the > Nomcom, I would suggest that willingness to go that far > --and good sense about when or whether to do so-- would > be an important criterion for a prospective candidate. > > And, to preempt any paranoid speculations, I don't want the job. > > john > > > From problem-statement-bounces@alvestrand.no Mon May 19 11:33: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 LAA24572 for ; Mon, 19 May 2003 11:33:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E598A625C5; Mon, 19 May 2003 16:59:16 +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 A3A9B625CA; Mon, 19 May 2003 16:56:50 +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 h4JEufk12495; Mon, 19 May 2003 10:56:42 -0400 (EDT) Date: Mon, 19 May 2003 10:56:41 -0400 From: Keith Moore To: Margaret Wasserman Message-Id: <20030519105641.6b77e50f.moore@cs.utk.edu> In-Reply-To: <5.1.0.14.2.20030519101737.041cbf50@mail.windriver.com> References: <6459658.1053158473@p3.JCK.COM> <200305161703.h4GH3ODi023565@newdev.harvard.edu> <6459658.1053158473@p3.JCK.COM> <5.1.0.14.2.20030519101737.041cbf50@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: harald@alvestrand.no Cc: moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: Re: Document Blocking (Was: I-D X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 12:02 PM 5/19/2003 +0200, Harald Tveit Alvestrand wrote: > >(tangential..... I am sometimes frustrated that WGs seem to take a > >Discuss as "declaration from on high that a technical decision needs > >to be changed", rather than as a challenge asking them to explain > >their positions better; > > I agree with other comments that this could be made clearer in > how IESG DISCUSS comments are communicated to the WG. For > example, why doesnt' the IESG member with the DISCUSS send a > message directly to the WG raising the issue? Sometimes they do, or they engage the document authors. But this doesn't always work well. It can produce long protracted discussions that don't terminate. If multiple IESG members have objections then it can be hard to keep track of when all the objections are satisfied. At the same time, my experience was that there were often disconnects in communicating Discuss concerns to WGs and document authors - not because of a failure to try, but because the ADs and WG members were working from very different sets of assumptions (often not well-articulated) and/or speaking different languages. The situation was made worse when one AD had to be an intermediary between another AD and the WG. So I think some form of direct communication from the objecting ADs to the WG is appropriate, but having the responsible AD send the Discuss comments to the WG mailing list would serve that purpose. I also think it's useful if the WG chairs and document authors could get the relevant ADs on a conference call - it's often easier to resolve differences over the phone than over email, and this could save weeks of delay. > >after all, what has happened is that the IESG has failed to > >understand that the WG position is reasonable; either the WG is > >wrong, or the documents have insufficient convincing power - > >increasing the convincing power SHOULD be the right answer in some > >cases. But that seems rare....) > > Why are there only two choices that "the WG is wrong, or the > documents have insufficient convincing power"? While I don't > think it happens very often, couldn't the IESG be wrong? Of course. Though if the document is misunderstood by IESG the chances that it will be misunderstood by ordinary readers seems high. > Also, some AD review comments and DISCUSS comments are really > about matters of taste -- the belief that a section should be > removed from a document because it is redundant (not wrong, > just redundant), the opinion that some historical note should be > added explaining why something was done a particular way, etc. > In those cases, there may be no right or wrong. In general, > the IESG wins because they can block publication of the document. > Do you think that's reasonable? Yes -- not because the IESG is always right, but because *somebody* has to decide, and the IESG is in a better position to make a determination as to whether a document is suitable for the Internet as a whole than the WG is. You could move the burden of that decision to some other body, but you'd still have the same problem. Either somebody can trump the other's desicion or you end up with a process that doesn't terminate. From problem-statement-bounces@alvestrand.no Mon May 19 13:50: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 NAA28470 for ; Mon, 19 May 2003 13:50:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5634E62573; Mon, 19 May 2003 19:53:01 +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 6EC91622B1 for ; Mon, 19 May 2003 19:52:50 +0200 (CEST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) h4JHqkXF004279 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 19 May 2003 10:52:47 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) h4JHqhix000497; Mon, 19 May 2003 10:52:43 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: Date: Mon, 19 May 2003 10:52:47 -0700 To: Pekka Savola , Brian E Carpenter From: hardie@qualcomm.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: problem-statement@alvestrand.no Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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:05 AM +0300 5/19/03, Pekka Savola wrote: >On Mon, 19 May 2003, Brian E Carpenter wrote: > > I agree with Scott. I trust Harald and I would be entirely happy for >> this work to be done in the General area. But there is no problem about >> doing it in an interim area, except that it means finding an interim AD >> as well as WG Chairs. > >I'm fine with either approach. > >But remember that one of the other problems was the shallowness of the >pool for IESG positions. The chosen AD would have to sit on all IESG >teleconferences and take part in those ballots, read the drafts put before >the IESG etc.etc. too. (Except if these are specifically designated out of >scope when chartering the temporary AD "position".) > >Depending on the level of responsibility, it would be huge task -- and I >rather think that a relatively open process to pick a chair, like with >problem-statement, would be both the fastest and the easiest approach. The corollary work load also worries me. If one of the concerns here is to get someone who can focus very tightly on these issues, then asking them to take on the role of an AD seems to be an issue. There is also a strong risk that having to do the work *as it is now* on a daily basis may limit the individual's ability to imagine it in new ways. From the outside, I know I personally had a concern about how focused on tool development the IESG seemed to me to be. While I retain the concern, there is no question that having to do the work now leads me to anticipate the new balloting system and other planned tools. That may, in turn, limit my ability to wonder whether the basic question of how review gets done should or should not include a ballot. That I still do wonder about it may be an artefact of the question being raised in the wider IETF, or it may reflect my own cussedness. But that tension would, I believe, be something any new AD for this effort would face. This may not be an issue if the real work of imagining the future is done by the working group, and the chair(s) of the working groups are taking the lead role in developing the consensus around that vision. If that is the case, then who takes the documents from the working group to the wider community seems to me almost a non-issue. The real question is how to get a chair or set of chairs. To make a concrete proposal, then, let me suggest that we do something akin to our normal process but upside-down. Have the working group in the General Area, with Harald as AD tasked with finding the chairs, but have the working group chairs be confirmed by the NomCom (or a special purpose NomCom). This will allow the community to have a voice in the selection in a way that derives from our current process. Have any replacement of the chairs require confirmation by this group as well, so that this oversight by the community continues. Given the confidentiality of that body, normal personnel confidentiality can be maintained, and those being considered can keep their privacy until a selection is announced. regards, Ted Hardie From problem-statement-bounces@alvestrand.no Mon May 19 13:57: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 NAA28636 for ; Mon, 19 May 2003 13:57:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 81520625A0; Mon, 19 May 2003 19:59:52 +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 E31D6622B1 for ; Mon, 19 May 2003 19:59:44 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA20381; Mon, 19 May 2003 10:59:22 -0700 (PDT) Message-Id: <5.1.0.14.2.20030519135431.041f6568@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 19 May 2003 13:55:25 -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 Cc: Pekka Savola Cc: Brian E Carpenter Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 Ted, At 10:52 AM 5/19/2003 -0700, hardie@qualcomm.com wrote: >To make a concrete proposal, then, let me suggest that we do something >akin to our normal process but upside-down. Have the working group >in the General Area, with Harald as AD tasked with finding the chairs, >but have the working group chairs be confirmed by the NomCom >(or a special purpose NomCom). This will allow the community to have >a voice in the selection in a way that derives from our current process. >Have any replacement of the chairs require confirmation by this group >as well, so that this oversight by the community continues. Given the >confidentiality of that body, normal personnel confidentiality can be >maintained, and those being considered can keep their privacy until >a selection is announced. To me, this seems less "open" than the process that Harald used to choose chairs for the problem-statement WG. In that case, he listed candidates on a web site and ask for community feedback. Margaret From problem-statement-bounces@alvestrand.no Mon May 19 14:56: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 OAA00861 for ; Mon, 19 May 2003 14:56:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 06A206258B; Mon, 19 May 2003 20:59:05 +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 6DAD26257F for ; Mon, 19 May 2003 20:58:59 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19Hpqc-000OEi-00; Mon, 19 May 2003 13:58:58 -0500 Date: Mon, 19 May 2003 14:58:58 -0400 From: John C Klensin To: "hardie@qualcomm.com" Message-ID: <160610315.1053356338@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 Cc: "problem-statement@alvestrand.no" Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Ted, Let me play devil's advocate for a moment here... --On Monday, 19 May, 2003 10:52 -0700 "hardie@qualcomm.com" wrote: >> But remember that one of the other problems was the >> shallowness of the pool for IESG positions. The chosen AD >> would have to sit on all IESG teleconferences and take part >> in those ballots, read the drafts put before the IESG >> etc.etc. too. (Except if these are specifically designated >> out of scope when chartering the temporary AD "position".) For whatever it is worth, if we can't find a pool of people, even if it is small, to fill an IESG position of this type, most of the problem-statement effort is on the wrong track because real solutions are impossible unless we can dramatically reduce the IESG workload or de-skill the AD roles. I haven't seen proposals, or even real "problem statements" lately that address either of those topics. We are still assuming that, while the system needs tuning, it is not fundamentally broken. If we can't find people to serve on the IESG for each a one-year term, we are "fundamentally broken" and had better deal with that. I don't think we are in that state, but maybe I'm wrong. >> Depending on the level of responsibility, it would be huge >> task -- and I rather think that a relatively open process to >> pick a chair, like with problem-statement, would be both the >> fastest and the easiest approach. > > The corollary work load also worries me. If one of the > concerns here is to get someone who can focus very tightly on > these issues, then asking them to take on the role of an AD > seems to be an issue. There is also a strong risk that having > to do the work *as it is now* on a daily basis may limit the > individual's ability to imagine it in new ways. From the > outside, I know I personally had a concern about how focused > on tool development the IESG seemed to me to be. While I >... This is a reasonable concern. But, again in my devil's advocate role, let's turn it around. We've heard multiple statements to the effect that "IETF Chair" is a full-time job. No one has come forward and said that it is really a walk in the park that can be done effectively with a few mornings a week. So, we are going to add at least a couple of WGs to the IETF Chair's workload, and expect that he will be able to effectively coordinate the efforts and output of those WGs with the nomcom, lpr, and maybe some other efforts that potentially overlap it. That is potentially a lot of work. If Harald can say "I've got the extra cycles, no problem", then there is no argument for a separate area independent of the concerns others have had about the process of the current IESG supervising this work. But I haven't heard him say that yet. Similarly, being expected to participate in the work of the IESG is both an advantage and a disadvantage. You've identified the latter. The advantage is that such an AD would get a realistic view of what might, and might not, be feasible (at least barring the very radical sort of change I hypothesize above if we really can't fill IESG positions). That view would be, IMO, very important in managing the relevant WG(s). And its absence is one of the reasons why some of us have been reluctant to see the "ISOC management" plan go forward. And, of course, the IESG and the community could agree --and make sure the nomcom knows it-- that this particular AD was expected to take "no objection" positions on any technical documents originating in other areas. I don't know whether that is desirable of not, but it would have a big impact on the workload for that AD and doesn't require any new procedures (see below). One couldn't prevent such an AD from reading all the documents and taking positions, of course, but, if the question is the total workload, that option would change the equation. > This may not be an issue if the real work of imagining the > future is done by the working group, and the chair(s) of the > working groups are taking the lead role in developing the > consensus around that vision. If that is the case, then who > takes the documents from the working group to the wider > community seems to me almost a non-issue. The real question > is how to get a chair or set of chairs. Absolutely, as long as things go smoothly. If, for whatever reason, they don't, someone is going to need to act like an AD with all of the usual authority and responsibility of oversee the work of chairs and editors, mediate disagreements and first-stage appeals, etc. > To make a concrete proposal, then, let me suggest that we do > something akin to our normal process but upside-down. Have > the working group in the General Area, with Harald as AD > tasked with finding the chairs, but have the working group > chairs be confirmed by the NomCom (or a special purpose > NomCom). This will allow the community to have a voice in the > selection in a way that derives from our current process. Have > any replacement of the chairs require confirmation by this > group as well, so that this oversight by the community > continues. Given the confidentiality of that body, normal > personnel confidentiality can be maintained, and those being > considered can keep their privacy until a selection is > announced. Ted, I think we need to be very pragmatic about this. Pragmatism argues for no new procedures if there is any other option. "The 'General AD' does it" does not require any new procedures. "Make a new area with a temporary appointment from within the IESG and a longer-term one by the Nomcom" requires no new procedures. In both cases, the WG(s) are plain, ordinary, WGs, with normal reporting chains to an AD, which obviously requires no new procedures. In either case, the AD using an open process, such as the one used to select this WG's co-chairs, to pick the WG leadership does not require any new procedures. But your suggestion above, which might have considerable merit if we had infinite time, seems to me to be fraught with requirements for new procedures and loose ends that should be tied before, rather than during or after, problems or ambiguous situations. For example, the Nomcom has never chosen a WG chair. Would the procedures for ADs suffice, or would some tuning be needed? The Nomcom also has no procedures for "confirming" a choice made by some other process. How much time would the Nomcom spend working through those issues, and does the framework of 2727 or its I-D successor provide it sufficient scope/ authority/ guidance to do so? Assuming that the WG Chair is selected (or confirmed) by the Nomcom, does he or she still serve at the pleasure of the AD, or does the AD have to initiate a formal recall action to make a change? If such a WG Chair resigns for any reason, does the nomcom have to be reconvened to deal with an interim vacancy, and what happens to the WG in the interim? Pragmatically, just too many loose ends, I think. If the workload is acceptable and the community is willing to trust the current IESG and IETF Chair to do this, that is a reasonable solution. If either of those conditions is not met, then a new area may be a reasonable solution. There may be others out there and, as I said in the note that started this thread, my main interest was to stimulate thinking about those possibilities. But I think that new ideas that require new procedures are too likely to take us on some rathole tour that would unreasonably delay the real work. Just my opinion, of course. john From problem-statement-bounces@alvestrand.no Mon May 19 16:37: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 QAA05096 for ; Mon, 19 May 2003 16:37:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9D16B6238F; Mon, 19 May 2003 22:40:02 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7BAD76230E for ; Mon, 19 May 2003 22:39:59 +0200 (CEST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4JKduWn106276; Mon, 19 May 2003 16:39:56 -0400 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) h4JKdroH025140; Mon, 19 May 2003 16:39:53 -0400 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) h4JKbBGZ001954; Mon, 19 May 2003 16:37:11 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) h4JKbBmf001949; Mon, 19 May 2003 16:37:11 -0400 Message-Id: <200305192037.h4JKbBmf001949@rotala.raleigh.ibm.com> To: "Bound, Jim" In-Reply-To: Message from Jim.Bound@hp.com <9C422444DE99BC46B3AD3C6EAFC9711B0324127D@tayexc13.americas.cpqcorp.net> Date: Mon, 19 May 2003 16:37:11 -0400 From: Thomas Narten Cc: problem-statement@alvestrand.no Subject: Re: Document Blocking (Was: I-DACTION:draft-ietf-problem-process-00.txt) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 Jim. > OK here is one example not a document real-time. multi6 is working > through their process to get to point where they can discuss next steps > for a very complex technology effort. The WG and WG Chairs want to meet > in Vienna and multiple specs and ideas have been provided. The WG team > is working and an agenda is being worked. The AD says we have nothing > to discuss because no proposal. None of us agree with the AD. The AD > was asked to please be more specific what they want and all we got so > far is one liners that have no depth or explanation and what we are > doing wrong. That is a problem. It also is real time example of us > getting one liners in the IETF that are completely not helpful to us in > the community. The AD should defend now their case with explicit > positioning. There seems to be some misunderstanding. My understanding (after having happened to talk with Randy who doesn't have email access right now) is that multi6 will be allowed 2 slots, but that a request for 3 (yes _3_) was denied. > This is happening with RDMA, Teredo, DSTM, ISATAP out of the IETF now > and will be deployed and in some cases are currently in the market on > IPv6 pre-production test beds and RDMA for IPv4. Note the same AD would > not permit the latter transition mechanisms to be part of v6ops till a > set of scenarios are going to be defined. OK fine we will do it out of > the IETF and drive it in the market without the IETF. These were worked > on with consensus for 3 years. We the WG were never permitted in the > debate to work on existing ngtrans work or if we all agreed with the > method of v6ops. Don't get me wrong I am doing the v6ops thing and we > all are but the technology from ngtrans in fact was useful, is being > deployed, and will be used. Just without the IETF. I believe all will > put up experimental RFCs to put it in some IETF process. As you know, all of the specific transition proposals (excluding those already RFCs) are out-of-scope for v6ops until the scenarios work is done. The purpose of this is to make sure that we validate the actual transition scenarios that we believe are important and then find/develop the right transition tools for those scenarios. This was done to counter the seeming plethora of transition tools that the IETF was developing with no clear roadmap of which ones should be used when, where and by whom.. This was not a one AD decision. I (and other ADs) were involved in the recharter and I supported it (and still do). So let's be clear to separate the issue of what the WG is working on from the notion that the current activity is the unchecked action of a single AD. Thomas From problem-statement-bounces@alvestrand.no Mon May 19 17:07: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 RAA05750 for ; Mon, 19 May 2003 17:07:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 320AB62598; Mon, 19 May 2003 23:10:11 +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 4BC0C62573 for ; Mon, 19 May 2003 23:10:09 +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 4F4C595B9; Mon, 19 May 2003 17: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); Mon, 19 May 2003 17: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: Mon, 19 May 2003 17:10:07 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD939@tayexc13.americas.cpqcorp.net> Thread-Topic: Document Blocking (Was: I-DACTION:draft-ietf-problem-process-00.txt) Thread-Index: AcMeRtNXIafUlrXsSx2zDxjVw54djQAAzM4Q From: "Bound, Jim" To: "Thomas Narten" X-OriginalArrivalTime: 19 May 2003 21:10:08.0195 (UTC) FILETIME=[06CC7930:01C31E4B] Cc: problem-statement@alvestrand.no Subject: RE: Document Blocking (Was: I-DACTION:draft-ietf-problem-process-00.txt) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 RAA05750 Hi Thomas, > > OK here is one example not a document real-time. multi6 is working > > through their process to get to point where they can discuss next > > steps for a very complex technology effort. The WG and WG > Chairs want > > to meet in Vienna and multiple specs and ideas have been > provided. The > > WG team is working and an agenda is being worked. The AD > says we have > > nothing to discuss because no proposal. None of us agree > with the AD. > > The AD was asked to please be more specific what they want > and all we > > got so far is one liners that have no depth or explanation > and what we > > are doing wrong. That is a problem. It also is real time > example of > > us getting one liners in the IETF that are completely not > helpful to > > us in the community. The AD should defend now their case with > > explicit positioning. > > There seems to be some misunderstanding. My understanding > (after having happened to talk with Randy who doesn't have > email access right > now) is that multi6 will be allowed 2 slots, but that a > request for 3 (yes _3_) was denied. Yep. Big time. We did not get this on email and the chair just asked yesterday and I have been watching the list religiously. But could be chairs agreed in last few days with Randy. We did not even ask for two. We asked for one and would do the other on our own knowing how busy the IETF is and the ADs. So big confusion going on here. > > > This is happening with RDMA, Teredo, DSTM, ISATAP out of > the IETF now > > and will be deployed and in some cases are currently in the > market on > > IPv6 pre-production test beds and RDMA for IPv4. Note the same AD > > would not permit the latter transition mechanisms to be > part of v6ops > > till a set of scenarios are going to be defined. OK fine > we will do > > it out of the IETF and drive it in the market without the > IETF. These > > were worked on with consensus for 3 years. We the WG were never > > permitted in the debate to work on existing ngtrans work or > if we all > > agreed with the method of v6ops. Don't get me wrong I am doing the > > v6ops thing and we all are but the technology from ngtrans > in fact was > > useful, is being deployed, and will be used. Just without > the IETF. > > I believe all will put up experimental RFCs to put it in some IETF > > process. > > As you know, all of the specific transition proposals > (excluding those already RFCs) are out-of-scope for v6ops > until the scenarios work is done. The purpose of this is to > make sure that we validate the actual transition scenarios > that we believe are important and then find/develop the right > transition tools for those scenarios. This was done to > counter the seeming plethora of transition tools that the > IETF was developing with no clear roadmap of which ones > should be used when, where and by whom.. What really happened was the ones that were being used by the market which are Teredo, Tunnel Broker, DSTM, and ISATAP go lumped with all the other ones that were not being used at all and it was never we have 15 solutions. We had 7 and that is not to many at all and that is the discussion that the WG did not participate in and should have IMO. Transition will require many methods and that is just the nature of the beast. So plethora is hardly the correct description to my view. The point for this list is that we did not have a "discussion" but a decision. That is not an open process. > > This was not a one AD decision. I (and other ADs) were > involved in the recharter and I supported it (and still do). > So let's be clear to separate the issue of what the WG is > working on from the notion that the current activity is the > unchecked action of a single AD. This should have been communicated and those ADs should have come to the WG and discussed it with the WG. This is water under the bridge (or over) and we are all working on v6ops but doing the others for now out of the IETF and deploying them which is the end result we are not waiting for the v6ops or IETF process. The point for this list is that the decision caused a set of events that could have been avoided had there been more discussion and the ADs working with the WG and hearing them. Specifically on the issue of why there will be a few transition mechanisms. /jim > > Thomas > From problem-statement-bounces@alvestrand.no Mon May 19 18:03: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 SAA07394 for ; Mon, 19 May 2003 18:03:41 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8C2036238F; Tue, 20 May 2003 00:06:16 +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 C0F4F6230E for ; Tue, 20 May 2003 00:06:09 +0200 (CEST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) h4JM66XF018803 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 19 May 2003 15:06:06 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) h4JM64BC025456; Mon, 19 May 2003 15:06:04 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <160610315.1053356338@p3.JCK.COM> References: <160610315.1053356338@p3.JCK.COM> Date: Mon, 19 May 2003 15:05:59 -0700 To: John C Klensin From: hardie@qualcomm.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "problem-statement@alvestrand.no" Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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, Some responses inline. At 2:58 PM -0400 5/19/03, John C Klensin wrote: >Ted, > >Let me play devil's advocate for a moment here... > >--On Monday, 19 May, 2003 10:52 -0700 "hardie@qualcomm.com" > wrote: > >>>But remember that one of the other problems was the >>>shallowness of the pool for IESG positions. The chosen AD >>>would have to sit on all IESG teleconferences and take part >>>in those ballots, read the drafts put before the IESG >>>etc.etc. too. (Except if these are specifically designated >>>out of scope when chartering the temporary AD "position".) The above was written by Pekka, not me; I was quoting him in my note. Sorry if that was not clear. >For whatever it is worth, if we can't find a pool of people, even if >it is small, to fill an IESG position of this type, most of the >problem-statement effort is on the wrong track because real >solutions are impossible unless we can dramatically reduce the IESG >workload or de-skill the AD roles. I haven't seen proposals, or >even real "problem statements" lately that address either of those >topics. We are still assuming that, while the system needs tuning, >it is not fundamentally broken. If we can't find people to serve >on the IESG for each a one-year term, we are "fundamentally broken" >and had better deal with that. > >I don't think we are in that state, but maybe I'm wrong. I have seen folks indicating that the IESG role is sufficiently demanding that it requires essentially full time work, and that the requirement reduces the pool of folks who can serve in deleterious ways. In this case, I believe we could find someone to take on the role, but I believe that constraining the choices to the group of folks who can give that amount of time is a big restriction. As noted below, I think the attention the matter is receiving from the community as a whole makes who nominally oversees the group less a matter of concern than it might otherwise be. I would personally focus the issue on how to get and keep good chairs in these roles rather than focus on the appeals process or reporting chain. >>>Depending on the level of responsibility, it would be huge >>>task -- and I rather think that a relatively open process to >>>pick a chair, like with problem-statement, would be both the >>>fastest and the easiest approach. >> >>The corollary work load also worries me. If one of the >>concerns here is to get someone who can focus very tightly on >>these issues, then asking them to take on the role of an AD >>seems to be an issue. There is also a strong risk that having >>to do the work *as it is now* on a daily basis may limit the >>individual's ability to imagine it in new ways. From the >>outside, I know I personally had a concern about how focused >>on tool development the IESG seemed to me to be. While I >>... > >This is a reasonable concern. But, again in my devil's advocate >role, let's turn it around. We've heard multiple statements to the >effect that "IETF Chair" is a full-time job. No one has come >forward and said that it is really a walk in the park that can be >done effectively with a few mornings a week. So, we are going to >add at least a couple of WGs to the IETF Chair's workload, and >expect that he will be able to effectively coordinate the efforts >and output of those WGs with the nomcom, lpr, and maybe some other >efforts that potentially overlap it. That is potentially a lot of >work. If Harald can say "I've got the extra cycles, no problem", >then there is no argument for a separate area independent of the >concerns others have had about the process of the current IESG >supervising this work. But I haven't heard him say that yet. > >Similarly, being expected to participate in the work of the IESG is >both an advantage and a disadvantage. You've identified the latter. >The advantage is that such an AD would get a realistic view of what >might, and might not, be feasible (at least barring the very radical >sort of change I hypothesize above if we really can't fill IESG >positions). That view would be, IMO, very important in managing the >relevant WG(s). And its absence is one of the reasons why some of >us have been reluctant to see the "ISOC management" plan go forward. I agree that a realistic view of what fits the IETF community's goals and process is critical and that the ISOC management plan has some disadvantages in that regard (it trusts the ISOC to make the effort to discover whether an outcome fits the goals and process, which reduplicates effort done elsewhere at best and results in a bad fit at worst). >And, of course, the IESG and the community could agree --and make >sure the nomcom knows it-- that this particular AD was expected to >take "no objection" positions on any technical documents originating >in other areas. I don't know whether that is desirable of not, >but it would have a big impact on the workload for that AD and >doesn't require any new procedures (see below). One couldn't >prevent such an AD from reading all the documents and taking >positions, of course, but, if the question is the total workload, >that option would change the equation. Less-than-full membership seems to have a whole raft of other potential problems which we cannot predict, so I'm not sure why this doesn't fall under the same objections you cite below. >>This may not be an issue if the real work of imagining the >>future is done by the working group, and the chair(s) of the >>working groups are taking the lead role in developing the >>consensus around that vision. If that is the case, then who >>takes the documents from the working group to the wider >>community seems to me almost a non-issue. The real question >>is how to get a chair or set of chairs. > >Absolutely, as long as things go smoothly. If, for whatever reason, >they don't, someone is going to need to act like an AD with all of >the usual authority and responsibility of oversee the work of chairs >and editors, mediate disagreements and first-stage appeals, etc. >>To make a concrete proposal, then, let me suggest that we do >>something akin to our normal process but upside-down. Have >>the working group in the General Area, with Harald as AD >>tasked with finding the chairs, but have the working group >>chairs be confirmed by the NomCom (or a special purpose >>NomCom). This will allow the community to have a voice in the >>selection in a way that derives from our current process. Have >>any replacement of the chairs require confirmation by this >>group as well, so that this oversight by the community >>continues. Given the confidentiality of that body, normal >>personnel confidentiality can be maintained, and those being >>considered can keep their privacy until a selection is >>announced. > >Ted, I think we need to be very pragmatic about this. Pragmatism >argues for no new procedures if there is any other option. "The >'General AD' does it" does not require any new procedures. "Make a >new area with a temporary appointment from within the IESG and a >longer-term one by the Nomcom" requires no new procedures. In both >cases, the WG(s) are plain, ordinary, WGs, with normal reporting >chains to an AD, which obviously requires no new procedures. In >either case, the AD using an open process, such as the one used to >select this WG's co-chairs, to pick the WG leadership does not >require any new procedures. Pragmatism would then seem to argue against having a new AD for this area having less than complete responsibilities and rights, which in turn means we are back to the analysis above of the advantages and disadvantages. Pragmatism would also seem to suggest against creating a new AD slot for it, on the theory that the IETF has never before had an AD with a specifically non-technical remit, and that installing one in the current system might be a bad idea. An untidy memory reminds me of the arguments as to why there is no Lord High Steward as a permanent office in modern Britain, the right to hold coronations and try peers being both a temptation and a liability for the individual holding it. Not an issue for us, of course, having rejected kings and princes, but you see the point. >But your suggestion above, which might have considerable merit if we >had infinite time, seems to me to be fraught with requirements for >new procedures and loose ends that should be tied before, rather >than during or after, problems or ambiguous situations. For >example, the Nomcom has never chosen a WG chair. Would the >procedures for ADs suffice, or would some tuning be needed? The >Nomcom also has no procedures for "confirming" a choice made by some >other process. How much time would the Nomcom spend working through >those issues, and does the framework of 2727 or its I-D successor >provide it sufficient scope/ authority/ guidance to do so? I would argue that we can say: "We will choose N folks from among a volunteer pool by verifiably random means to confirm that those chairing Working group A and Working Group B are individuals appropriate to the task according to the views of the community. If they do not so confirm any individual proposed to the task, the relevant Area Director may propose one or more replacements if the individual was to serve as a single chair and zero or more replacements if the individual was to serve jointly." The issue may be fraught with potential issues or loose ends, but getting through it should neither take an infinite time nor be impossible. It may, of course, not be worth it. If having the method used by Harald to solicit community input on a slate of chairs serves the same purpose and seems more open, then let's close the issue and be done. I put it forward as a mechanism that might serve should the community's trust of the AD be an issue; if it is not, so much the better. > Assuming that the WG Chair is selected (or confirmed) by the >Nomcom, does he or she still serve at the pleasure of the AD, or >does the AD have to initiate a formal recall action to make a >change? If such a WG Chair resigns for any reason, does the nomcom >have to be reconvened to deal with an interim vacancy, and what >happens to the WG in the interim? > >Pragmatically, just too many loose ends, I think. > >If the workload is acceptable and the community is willing to trust >the current IESG and IETF Chair to do this, that is a reasonable >solution. If either of those conditions is not met, then a new >area may be a reasonable solution. There may be others out there >and, as I said in the note that started this thread, my main >interest was to stimulate thinking about those possibilities. But I >think that new ideas that require new procedures are too likely to >take us on some rathole tour that would unreasonably delay the real >work. > >Just my opinion, of course. > > john As John says, just my opinion, of course, regards, Ted Hardie From problem-statement-bounces@alvestrand.no Mon May 19 19:01: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 TAA09571 for ; Mon, 19 May 2003 19:01:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0C1796238F; Tue, 20 May 2003 01:04:15 +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 F16616230E for ; Tue, 20 May 2003 01:04:11 +0200 (CEST) Received: from adsl-68-120-70-229.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4JN3iN22669; Mon, 19 May 2003 16:03:44 -0700 Date: Mon, 19 May 2003 16:06:06 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <10534684934.20030519160606@brandenburg.com> To: hardie@qualcomm.com In-Reply-To: References: <160610315.1053356338@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: Charters, "normal process" versus ISOC, etc. (was: Re 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 hardie, hqc> below, I think the attention the matter is receiving from the community as a hqc> whole makes who nominally oversees the group less a matter of concern than hqc> it might otherwise be. I'd prefer to view it as desirable to have the criteria, for selecting the AD who will oversee strategic changes to the IETF organization, as being at least as stringent as we apply for other AD's. hqc> I would personally focus the issue on how to get and hqc> keep good chairs in these roles rather than focus on the appeals process or hqc> reporting chain. Indeed, the chair role has the most difficult, daily challenges for these activities. >>...that this particular AD was expected to >>take "no objection" positions on any technical documents ... >> One couldn't >>prevent such an AD from reading all the documents and taking >>positions, hqc> Less-than-full membership seems to have a whole raft of other potential hqc> problems which we cannot predict, so I'm not sure why this doesn't hqc> fall under the same objections you cite below. Because it really is at the choice of the new AD. The question is what is expected of them, not what they are "prohibited" from doing. hqc> Pragmatism would then seem to argue against having a new AD for this hqc> area having less hqc> than complete responsibilities and rights, There was no suggestion that their "rights" be limited, only the expectations on their use of those rights. So, yes, lessened responsibilities. But let's note that ADs have varied quite a bit, over the years, concerning just how much effort they put in and how broadly they range over IESG activities in other areas. hqc> Pragmatism would also seem hqc> to suggest against creating a new AD slot for it, on the theory that hqc> the IETF has hqc> never before had an AD with a specifically non-technical remit I was AD for the Standards Process, followed by Lyman Chapin holding that position. The slot was very specifically about IETF process and not about IETF technical work. And we had an AD for User Services. It was an important area and sometimes had a technical component to it, but I believe it mostly did not. (However indelicate, I have to express a meta-concern: We have been experiencing a recent community trend towards people making firm assertions about IETF history that are at variance with its actual history. I'm sure the utterances are offered as honest assessments, but I wonder what we can do to improve their accuracy?) hqc> I would argue that we can say: "We will choose N folks from among a hqc> volunteer pool hqc> by verifiably random means to confirm that those chairing Working hqc> group A and Working Group B 1. Whatever the procedure is, you are inventing a new procedure. Inventing new procedures involves substantial risk. I believe that was John's point. It certainly is mine. It can't be a good idea to add that unknown to this mix. (My lobbying for ISOC was based on essentially replicating the ISOC role for Nomcom.) John K's proposal involves even less cleverness than I was pursuing, in the sense that it invokes completely detailed and well-understood procedures about which there should be no questions. The appeal of that should be overwhelming to folks. Less cleverness is more better. 2. I am not sure I followed the nature and details of the "verifiably random" procedure you have in mind, but the IETF has a very consistent track record with use of statistics-based procedures in its analytic and procedure work. The track record makes very clear that we should keep the heck out of statistics and social processes. We wind up focussing on the math rather than the methodological validity of the procedure. I'm glad to discuss our lack of methodology skills at a bar bof. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Mon May 19 19:19: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 TAA10026 for ; Mon, 19 May 2003 19:19:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0A061625A0; Tue, 20 May 2003 01:21: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 545A36230E; Tue, 20 May 2003 01:21:39 +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 h4JNLck25997; Mon, 19 May 2003 19:21:38 -0400 (EDT) Date: Fri, 16 May 2003 12:01:52 -0400 From: Keith Moore To: Harald Tveit Alvestrand Message-Id: <20030516120152.0ca99a90.moore@cs.utk.edu> In-Reply-To: <1689790900.1053038959@localhost> References: <5.1.0.14.2.20030515113529.014ba800@mail.windriver.com> <014901c31b03$b75cccf0$176015ac@DCLKEMPFTP> <1689790900.1053038959@localhost> 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: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 sort of bugs, if detected, would make a protocol unsuitable for > Proposed Standard?* the way Proposed is treated by industry now, anything that would cause problems in wide deployment should make a protocol unsuitable for Proposed. certainly failure to interoperate would be in this list, but so would failure to scale, lack of robustness, failure to provide adequate security, and a lot of other problems. > A related issue is whether or not the restrictions on going to Draft > from Proposed are really appropriate; currently, we say that *only* > deletion of features is appropriate, and that any change or extension, > no matter how worthwhile the purpose or how sure we are that it makes > no problems, requires another round through Proposed. Is this really > best for the Internet? basically anything that would break compatibility should cause a reset. new features must be considered suspect, because they haven't been subjected to the same level of deployment and/or interop testing as the old ones. a new way of providing an old feature might be okay, if the new way were based on experience with the old feature and we had high confidence that the new way would work based on that experience. but I've seen multiple attempts to solve a problem fail. Keith From problem-statement-bounces@alvestrand.no Mon May 19 19:29: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 TAA10313 for ; Mon, 19 May 2003 19:29:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5DF906258B; Tue, 20 May 2003 01:31:39 +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 47CFC6230E for ; Tue, 20 May 2003 01:31:34 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19Hu6O-000Pd8-00; Mon, 19 May 2003 18:31:33 -0500 Date: Mon, 19 May 2003 19:31:32 -0400 From: John C Klensin To: "hardie@qualcomm.com" Message-ID: <176964341.1053372692@p3.JCK.COM> In-Reply-To: References: <160610315.1053356338@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 Cc: "problem-statement@alvestrand.no" Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, 19 May, 2003 15:05 -0700 "hardie@qualcomm.com" wrote: > John, > Some responses inline. > > At 2:58 PM -0400 5/19/03, John C Klensin wrote: >> Ted, >> >> Let me play devil's advocate for a moment here... >> >> --On Monday, 19 May, 2003 10:52 -0700 "hardie@qualcomm.com" >> wrote: >> >>>> But remember that one of the other problems was the >>>> shallowness of the pool for IESG positions. The chosen AD >>>> would have to sit on all IESG teleconferences and take part >>>> in those ballots, read the drafts put before the IESG >>>> etc.etc. too. (Except if these are specifically designated >>>> out of scope when chartering the temporary AD "position".) > > The above was written by Pekka, not me; I was quoting him in my > note. Sorry if that was not clear. I understood that, but the point seemed to be most easily responded to in the context of your note. Sorry for not being more clear about it. >> For whatever it is worth, if we can't find a pool of people, >> even if it is small, to fill an IESG position of this type, >> most of the problem-statement effort is on the wrong track >> because real solutions are impossible unless we can >> dramatically reduce the IESG workload or de-skill the AD >> roles. I haven't seen proposals, or even real "problem >> statements" lately that address either of those topics. We >> are still assuming that, while the system needs tuning, it >> is not fundamentally broken. If we can't find people to >> serve on the IESG for each a one-year term, we are >> "fundamentally broken" and had better deal with that. >> >> I don't think we are in that state, but maybe I'm wrong. > > I have seen folks indicating that the IESG role is > sufficiently demanding that it requires essentially full time > work, and that the requirement reduces the pool of folks who > can serve in deleterious ways. I've heard that. I believe it is true. But I note that there is nothing in draft-ietf-problem-issue-statement-01.txt that even vaguely implies "we need to make decisions in a way that sacrifices The Right Thing to Do to the total number of qualified people we can get to serve on the IESG at a time". If we think that is a problem, then we had better get it into the document. If we don't think it is a problem, then we shouldn't be injecting it into this, or any other, discussion. As an aside, I note that the closest relevant text is section 2.5, which talks about the management structure not scaling well. It then goes on to describe the 1992 changes as a scaling improvement. There were any number of good reasons for making changes in 1992, but scaling wasn't one of them: by taking a model in which one group (the IESG) managed the WG process and another one (the IAB) reviewed and approved standards-track documents and replacing it with the current model in which the IESG has all of those responsibilities, we significantly increased IESG workload. So, if viewed from a scaling standpoint along, the 1992 changes were pathological. > In this case, I believe we > could find someone to take on the role, but I believe that > constraining the choices to the group of folks who can give > that amount of time is a big restriction. As noted below, I > think the attention the matter is receiving from the community > as a whole makes who nominally oversees the group less a > matter of concern than it might otherwise be. I would > personally focus the issue on how to get and keep good chairs > in these roles rather than focus on the appeals process or > reporting chain. We may just need to disagree on this. I suggest... * One never needs to focus on the appeals process and reporting chain if things are guaranteed to go smoothly, if work of one WG never overlaps that of another, nothing ever goes wrong, chairs don't change jobs or otherwise become inactive, there are no disputes about consensus, etc. In those cases, one barely needs an AD except to swiftly process WG output through the IESG. On the other hand, if anything does go wrong, it is not the time to start devising procedures since whatever is done is likely to stir up more suspicions and unpleasantness. * We have seen, on this list and in plenaries, a good deal of concern and suspicion expressed about the IESG and its ultimate commitment to change and openness. I'm not nearly as concerned about that issue as those who have repeated raised it and proposed radical alternate procedures as a consequence. But it appears to me that having a process that is as much above suspicion as is practical (remembering that I consider anything that involves new procedures as impractical) is, at least, a good idea. [... text where we agree deleted ...] >> And, of course, the IESG and the community could agree --and >> make sure the nomcom knows it-- that this particular AD was >> expected to take "no objection" positions on any technical >> documents originating in other areas. I don't know >> whether that is desirable of not, but it would have a big >> impact on the workload for that AD and doesn't require any >> new procedures (see below). One couldn't prevent such an AD >> from reading all the documents and taking positions, of >> course, but, if the question is the total workload, that >> option would change the equation. > > Less-than-full membership seems to have a whole raft of other > potential problems which we cannot predict, so I'm not sure > why this doesn't fall under the same objections you cite below. Hmm. I didn't say anything that I would construe as "less than full membership". Unless things have changed recently, the typical IESG member, on a typical ballot outside his or her own area, records a "no objection" ballot. Sometimes, that means "I read the document really carefully and didn't see any problem", but that isn't often the case -- I have observed that, usually, if the document has been read that carefully, the person votes "yes". More often, it means, at best, "I glanced through it and didn't see any serious problems, so I'm happy leaving the decision to those who studied it more carefully". Now, if someone were to always vote "no objection" on everything outside his or her area, I'd assume that other IESG members would get on his or case about not pulling full weight. But neither doing that, nor not doing that, requires a procedural change -- there is no requirement that every IESG member personally review and take a position on every document. And I also haven't suggested anything that would reduce the "rights" of that AD in any way. In particular, if he or she analyses a document (on _any_ topic) and concludes that there are problems, the resulting "discuss" would presumably carry as much weight as any other "discuss". >>> To make a concrete proposal, then, let me suggest that we do >>> something akin to our normal process but upside-down. Have >>> the working group in the General Area, with Harald as AD >>> tasked with finding the chairs, but have the working group >>> chairs be confirmed by the NomCom (or a special purpose >>> NomCom). This will allow the community to have a voice in >>> the selection in a way that derives from our current >>> process. Have any replacement of the chairs require >>> confirmation by this group as well, so that this oversight >>> by the community continues. Given the confidentiality of >>> that body, normal personnel confidentiality can be >>> maintained, and those being considered can keep their >>> privacy until a selection is announced. >> >> Ted, I think we need to be very pragmatic about this. >> Pragmatism argues for no new procedures if there is any >> other option. "The 'General AD' does it" does not require >> any new procedures. "Make a new area with a temporary >> appointment from within the IESG and a longer-term one by >> the Nomcom" requires no new procedures. In both cases, the >> WG(s) are plain, ordinary, WGs, with normal reporting chains >> to an AD, which obviously requires no new procedures. In >> either case, the AD using an open process, such as the one >> used to select this WG's co-chairs, to pick the WG >> leadership does not require any new procedures. > > Pragmatism would then seem to argue against having a new AD > for this area having less than complete responsibilities and > rights, which in turn means we are back to the analysis above > of the advantages and disadvantages. You are killing a strawman here. I didn't suggest anything of the sort, merely a little IESG tolerance for a reduced out-of-area workload for an AD who was time-limited. And, of course, that sort of tolerance has been applied many times before --sometimes happily and sometimes not-- when an AD has simply not had the time to do all desired work due to external pressures. > Pragmatism would also > seem to suggest against creating a new AD slot for it, on the > theory that the IETF has never before had an AD with a > specifically non-technical remit, and that installing one in > the current system might be a bad idea. Uh... we actually had an AD whose area/job was "process" for a while. It didn't turn out to be a really good idea (the person who held the position is on this list and might want to comment), but the mission was different. > An untidy memory > reminds me of the arguments as to why there is no Lord High > Steward as a permanent office in modern Britain, the right to > hold coronations and try peers being both a temptation and a > liability for the individual holding it. Not an issue for us, > of course, having rejected kings and princes, but you see the > point. I would if there were any analogy. You will recall that I suggested this only in the context of a temporary area, with a limited duration and an explicit sunset/review date. I think we all recognize the risks of a "process AD" who was inclined to create all sorts of process WGs and BOFs to keep the area active and busy. I would hope that the Nomcom would avoid appointing anyone with those inclinations. And, if they developed after someone was seated, we would have not only the usual recall tools, but a one-year term and a one-year expiration for the area as protection. All within normal procedures. >> But your suggestion above, which might have considerable >> merit if we had infinite time, seems to me to be fraught >> with requirements for new procedures and loose ends that >> should be tied before, rather than during or after, problems >> or ambiguous situations. For example, the Nomcom has never >> chosen a WG chair. Would the procedures for ADs suffice, or >> would some tuning be needed? The Nomcom also has no >> procedures for "confirming" a choice made by some other >> process. How much time would the Nomcom spend working >> through those issues, and does the framework of 2727 or its >> I-D successor provide it sufficient scope/ authority/ >> guidance to do so? > > I would argue that we can say: "We will choose N folks from > among a volunteer pool by verifiably random means to confirm > that those chairing Working group A and Working Group B are > individuals appropriate to the task according to the views of > the community. If they do not so confirm any individual > proposed to the task, the relevant Area Director may propose > one or more replacements if the individual was to serve as a > single chair and zero or more replacements if the individual > was to serve jointly." The issue may be fraught with > potential issues or loose ends, but getting through it should > neither take an infinite time nor be impossible. It may, of > course, not be worth it. If having the method used by Harald > to solicit community input on a slate of chairs serves the > same purpose and seems more open, then let's close the issue > and be done. I put it forward as a mechanism that might serve > should the community's trust of the AD be an issue; if it is > not, so much the better. A completely new procedure that, as others have pointed out, could easily leave the AD with WG Chairs with whom he can't work effectively. And, if the community doesn't trust the AD, chair-appointment is not the only thing the AD does. >> Assuming that the WG Chair is selected (or confirmed) by >> the Nomcom, does he or she still serve at the pleasure of >> the AD, or does the AD have to initiate a formal recall >> action to make a change? If such a WG Chair resigns for any >> reason, does the nomcom have to be reconvened to deal with >> an interim vacancy, and what happens to the WG in the >> interim? >>... regards, john From problem-statement-bounces@alvestrand.no Mon May 19 19:33: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 TAA10422 for ; Mon, 19 May 2003 19:33:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3D7876258B; Tue, 20 May 2003 01:36:01 +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 5B4D66230E for ; Tue, 20 May 2003 01:35:57 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19HuAe-000PdP-00; Mon, 19 May 2003 18:35:56 -0500 Date: Mon, 19 May 2003 19:35:56 -0400 From: John C Klensin To: Dave Crocker Message-ID: <177227629.1053372956@p3.JCK.COM> In-Reply-To: <10534684934.20030519160606@brandenburg.com> References: <160610315.1053356338@p3.JCK.COM> <10534684934.20030519160606@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: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, 19 May, 2003 16:06 -0700 Dave Crocker wrote: >... > I was AD for the Standards Process, followed by Lyman Chapin > holding that position. The slot was very specifically about > IETF process and not about IETF technical work. My apologies to both you and Lyman -- I had forgotten, in a senior moment, that there were (at least?) two separate holders of that AD position before we gave up on it. john From problem-statement-bounces@alvestrand.no Mon May 19 20:49: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 UAA11797 for ; Mon, 19 May 2003 20:49:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BC19D6258B; Tue, 20 May 2003 02:51:51 +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 42D4D6238F for ; Tue, 20 May 2003 02:51:48 +0200 (CEST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) h4K0pi6I021652; Mon, 19 May 2003 17:51:45 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) h4K0pgBC023444; Mon, 19 May 2003 17:51:43 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <10534684934.20030519160606@brandenburg.com> References: <160610315.1053356338@p3.JCK.COM> <10534684934.20030519160606@brandenburg.com> Date: Mon, 19 May 2003 17:51:35 -0700 To: Dave Crocker From: hardie@qualcomm.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "problem-statement@alvestrand.no" Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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:06 PM -0700 5/19/03, Dave Crocker wrote: > >hqc> Less-than-full membership seems to have a whole raft of other potential >hqc> problems which we cannot predict, so I'm not sure why this doesn't >hqc> fall under the same objections you cite below. > >Because it really is at the choice of the new AD. The question is what >is expected of them, not what they are "prohibited" from doing. John has also commented on this, but just to make it clear, I understood his original remark indicating an "expectation" that they would register "no objection" as tantamount to saying "this isn't your business". He has since corrected my misunderstanding, and I agree that this is different from having less-than-full membership. > >hqc> Pragmatism would also seem >hqc> to suggest against creating a new AD slot for it, on the theory that >hqc> the IETF has >hqc> never before had an AD with a specifically non-technical remit > >I was AD for the Standards Process, followed by Lyman Chapin holding >that position. The slot was very specifically about IETF process and not >about IETF technical work. Thanks for this correction. I had thought that this was always held in tandem with a technical remit, but I see from: http://www.ietf.org/iesg_mem.html that both you and Lyman held it at times when you were not also managing technical areas. >And we had an AD for User Services. It was an important area and >sometimes had a technical component to it, but I believe it mostly did >not. My experience of it (and I did some work in it both with Joyce and April) was that it was technical, often in complex ways. In many ways a document like RFC 2635 is a harder to get right than a MIB. On the larger question of how to get history right, hopefully we will be able to count on our longer term members to correct us when these things are misquoted for a good while. I'm not sure what to suggest for making sure the misunderstandings don't arise. >hqc> I would argue that we can say: "We will choose N folks from among a >hqc> volunteer pool >hqc> by verifiably random means to confirm that those chairing Working >hqc> group A and Working Group B > >1. Whatever the procedure is, you are inventing a new procedure. >Inventing new procedures involves substantial risk. I believe that was >John's point. It certainly is mine. It can't be a good idea to add that >unknown to this mix. (My lobbying for ISOC was based on essentially >replicating the ISOC role for Nomcom.) John K's proposal involves even >less cleverness than I was pursuing, in the sense that it invokes >completely detailed and well-understood procedures about which there >should be no questions. The appeal of that should be overwhelming to >folks. Less cleverness is more better. "Everything should be made as simple as possible, but not simpler." (attributed to Albert Einstein). I grant the premise, but I am not sure that selecting a new AD for a short-term process IESG role follows from it. Making the working groups normal groups under General seems to be simpler; the reason not to do that seem like it might be distrust that the sitting IESG or IETF chair would follow community wishes in regards to the working group outcome. That implied to me that some oversight role derived from our existing procedures was warranted. Using the NomCom as a model for that was simply because the NomCom process is community-driven and not selected by any of the sitting bodies. It is, granted, different from the usual role of the NomCom, and it would require specification. Whether that is needed or not seems to me to rest more on whether re-using the existing processes will or will not garner trust in the outcome having been fair enough and open to satisfy the current need. As I said in my conclusion to the previous message, if that trust is not at issue, then I'm happy to move on. >2. I am not sure I followed the nature and details of the "verifiably >random" procedure you have in mind, I was referring to RFC2777 ,"Publicly Verifiable Nomcom Random Selection"; sorry if the atypical shortening was confusing. regards, Ted Hardie From problem-statement-bounces@alvestrand.no Mon May 19 21:31: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 VAA12411 for ; Mon, 19 May 2003 21:31:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5908862598; Tue, 20 May 2003 03:34:15 +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 E5C296258B for ; Tue, 20 May 2003 03:34:11 +0200 (CEST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) h4K1Y86I023335; Mon, 19 May 2003 18:34:09 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) h4K1Y6sh013866; Mon, 19 May 2003 18:34:06 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <176964341.1053372692@p3.JCK.COM> References: <160610315.1053356338@p3.JCK.COM> <176964341.1053372692@p3.JCK.COM> Date: Mon, 19 May 2003 18:33:57 -0700 To: John C Klensin From: hardie@qualcomm.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "problem-statement@alvestrand.no" Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 7:31 PM -0400 5/19/03, John C Klensin wrote: >Ted Hardie writes: >>>For whatever it is worth, if we can't find a pool of people, >>>even if it is small, to fill an IESG position of this type, >...snip... >>sufficiently demanding that it requires essentially full time >>work, and that the requirement reduces the pool of folks who >>can serve in deleterious ways. > >I've heard that. I believe it is true. But I note that there is >nothing in draft-ietf-problem-issue-statement-01.txt that even >vaguely implies "we need to make decisions in a way that sacrifices >The Right Thing to Do to the total number of qualified people we can >get to serve on the IESG at a time". If we think that is a problem, >then we had better get it into the document. If we don't think it >is a problem, then we shouldn't be injecting it into this, or any >other, discussion. I don't think that phrasing belongs in the document, but I would put "We need to be able to get the right thing done without requiring full-time effort for every leadership role" into the document, and I would put the AD position you posit firmly in the category "leadership role". >* We have seen, on this list and in plenaries, a good deal of >concern and suspicion expressed about the IESG and its ultimate >commitment to change and openness. I'm not nearly as concerned >about that issue as those who have repeated raised it and proposed >radical alternate procedures as a consequence. But it appears to me >that having a process that is as much above suspicion as is >practical (remembering that I consider anything that involves new >procedures as impractical) is, at least, a good idea. And it is here that we do disagree. We have a different view of the balance between: (new procedures which may alleviate suspicion and may contain bugs) and (reuse of old procedures which may not alleviate suspicion and may contain mismatches between original aims and current use). Fair enough; you may be right. I suspect a lot of the answer as to where to put the emphasis depends on how much suspicion there is. The rest of it may be my over-optimism on how easy it is to create new procedures whose bugs are less than fatal. >[... text where we agree deleted ...] > >>>And, of course, the IESG and the community could agree --and >>>make sure the nomcom knows it-- that this particular AD was >...snip... >>potential problems which we cannot predict, so I'm not sure >>why this doesn't fall under the same objections you cite below. > >Hmm. I didn't say anything that I would construe as "less than full >membership". As I noted in my reply to Dave, it is obvious now that I misread your meaning on "expectation that they would vote no objection" to mean that they would be told, in essence, "these are not your concern". I am sorry for misconstruing your remarks. I believe my other concerns on timing and viewpoint still apply. > >>An untidy memory >>reminds me of the arguments as to why there is no Lord High >>Steward as a permanent office in modern Britain, the ... >>...snip... >>liability for the individual holding it. Not an issue for us, >>of course, having rejected kings and princes, but you see the >>point. > >I would if there were any analogy. You will recall that I suggested >this only in the context of a temporary area, with a limited >duration and an explicit sunset/review date. I think we all >recognize the risks of a "process AD" who was inclined to create all >sorts of process WGs and BOFs to keep the area active and busy. I >would hope that the Nomcom would avoid appointing anyone with those >inclinations. And, if they developed after someone was seated, we >would have not only the usual recall tools, but a one-year term and >a one-year expiration for the area as protection. All within normal >procedures. I am sorry that you do not see the merit of the analogy. I'm afraid I continue to see the risks of both ostracism and abuse as real. Frankly, the advantage of having someone like the IETF chair do the job is the other IESG members know that they too will have to live with the result; that seems likely to limit the risk that they will be treated like a pariah. On the risk of abuse, given the arguments which Margaret and others have given on the realism of a one-year term, I think the sunset clause is likely to get stretched. As for the NomCom's recall powers--have they been exercised? I don't think they have since 2727, but I have already proved myself no historian once today. Even if they have been, using them to recall someone tasked with shepherding a reform process seems both highly charged and pretty unlikely. So we are back to trusting the NomCom to pick the right person. I recognize that picking ADs has been done by the NomCom and picking chairs has not, but I don't see the same issues others do. In one case, they pick the right people to pick the right chairs, and in the proposal I made they confirm that the person picking picked right. Certainly different; not chalk and cheese. Since it bears repeating, just my opinion, regards, Ted HArdie From problem-statement-bounces@alvestrand.no Tue May 20 01:07: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 BAA16524 for ; Tue, 20 May 2003 01:07:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3A115625A3; Tue, 20 May 2003 07:09:56 +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 4AC9F625A2 for ; Tue, 20 May 2003 07:09:53 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4K59lG26941; Tue, 20 May 2003 08:09:48 +0300 Date: Tue, 20 May 2003 08:09:47 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD939@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Thomas Narten Cc: problem-statement@alvestrand.no Subject: RE: Document Blocking (Was: I-DACTION:draft-ietf-problem-process-00.txt) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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, 19 May 2003, Bound, Jim wrote: > > > OK here is one example not a document real-time. multi6 is working > > > through their process to get to point where they can discuss next > > > steps for a very complex technology effort. The WG and WG > > Chairs want > > > to meet in Vienna and multiple specs and ideas have been > > provided. The > > > WG team is working and an agenda is being worked. The AD > > says we have > > > nothing to discuss because no proposal. None of us agree > > with the AD. > > > The AD was asked to please be more specific what they want > > and all we > > > got so far is one liners that have no depth or explanation > > and what we > > > are doing wrong. That is a problem. It also is real time > > example of > > > us getting one liners in the IETF that are completely not > > helpful to > > > us in the community. The AD should defend now their case with > > > explicit positioning. > > > > There seems to be some misunderstanding. My understanding > > (after having happened to talk with Randy who doesn't have > > email access right > > now) is that multi6 will be allowed 2 slots, but that a > > request for 3 (yes _3_) was denied. > > Yep. Big time. We did not get this on email and the chair just asked > yesterday and I have been watching the list religiously. But could be > chairs agreed in last few days with Randy. We did not even ask for two. > We asked for one and would do the other on our own knowing how busy the > IETF is and the ADs. So big confusion going on here. I think folks are reading too much to Randy's email: --8<-- Date: Thu, 15 May 2003 18:36:38 +0200 From: Randy Bush To: Masataka Ohta Cc: multi6@ops.ietf.org Subject: Re: Agenda for Vienna > So, why not have three 2H sessions and stop saying "time constraint"? because you will need a different AD to approve it. this wg has yet to show good use of one session. you don't get any pudding unless you eat your meat. --8<-- (The history is that multi6 has not met in about a year because there has not really been a good agenda, etc.) This is a response to an individual who keeps pestering the WG to schedule 3 sessions so he could yet again present his own proposal (among other things). I may be biased in here, though.. Some may have read the message as "nyah nyah, you don't get even one session, suckers!!". I didn't. I read it to say that as there hasn't been a plan to schedule even one session before this, it is completely unrealistic to now bump to 3. So 3 is out of question, but others are still on the table. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From problem-statement-bounces@alvestrand.no Tue May 20 05:35: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 FAA03937 for ; Tue, 20 May 2003 05:35:29 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 61628625A3; Tue, 20 May 2003 11:38:05 +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 294AD62598; Tue, 20 May 2003 11:38:03 +0200 (CEST) Date: Tue, 20 May 2003 11:38:02 +0200 From: Harald Tveit Alvestrand To: mallman@grc.nasa.gov, problem-statement@alvestrand.no Message-ID: <326578585.1053430682@HALVESTR-W2K1.cisco.com> In-Reply-To: <200305191357.JAA98002@guns.lerc.nasa.gov> References: <200305191357.JAA98002@guns.lerc.nasa.gov> 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: non-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 --On 19. mai 2003 09:57 -0400 Mark Allman wrote: > I am not necessarily encouraging folks to do this exercise on this > mailing list (the chairs would likely be getting their rulers ready > for my knuckles). I am encouraging musing about this in preparation > for the next phase of this whole process on what we should do about > all of our problems. > > Examples: If the solutions phase started and someone threw out a > proposal that rid us of a central body that has tight control of all > output (ala the IESG) would people squirm? What if someone proposed > realigning WGs in a different way (say, a looser, longer-lived way)? > Would that cause alarm? (With appologies to Dave Clark,) What if it > was proposed that SIRs get to *vote* on documents? Would that be > wrong? Mark, good questions. I think the problem-process draft's initial section - "what are the core values of the IETF that we don't want to lose" - is the closest thing we have on the table now to a statemnet of what *not* to change, or criteria on which we can judge that change proposals are out of scope. [parenthesis - I think this would be better positioned as a separate document..... but it's not listed in the WG charter, so doing so would either take it out of the scope of this group's mandate or require WG consensus that it needs doing anyway] I encourage people to read that section most carefully, and suggest updates and improvements to it as a means of answering Mark's thoughtful questions. Harald From problem-statement-bounces@alvestrand.no Tue May 20 07:33: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 HAA06668 for ; Tue, 20 May 2003 07:33:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B6964625A7; Tue, 20 May 2003 13:36: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 0A28962206 for ; Tue, 20 May 2003 13:36:26 +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 EAA70506 for ; Tue, 20 May 2003 04:36:24 -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 8LI0ePO2 Tue, 20 May 2003 04:36:23 -0700 (PDT) Message-ID: <044a01c31ec4$0cee1a20$0300a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <200305191357.JAA98002@guns.lerc.nasa.gov> <326578585.1053430682@HALVESTR-W2K1.cisco.com> Date: Tue, 20 May 2003 06:36:26 -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: non-problems 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 Harald, Nested-parenthesis - the Problem Statement guys thought the Solutions guys were the ones producing a list of Core Values. We included the list from previous IETF Plenaries as a starting point, but haven't discussed them in much detail because we thought they WERE out of scope for this WG. It's possible that "we hold these truths to be self-evident", but we have seen minor feedback (from Brian Carpenter, suggesting that we add "self-governance", for instance), so there probably is a discussion that could usefully take place on this topic. If the discussion could/should be taking place here, that's good to know. Speaking for myself, I didn't realize it was on the table now. End-nested-parenthesis (when was the last time we did LISP in IETF?)... Spencer ----- Original Message ----- From: "Harald Tveit Alvestrand" To: ; Sent: Tuesday, May 20, 2003 4:38 AM Subject: Re: non-problems > > > --On 19. mai 2003 09:57 -0400 Mark Allman wrote: > > > I am not necessarily encouraging folks to do this exercise on this > > mailing list (the chairs would likely be getting their rulers ready > > for my knuckles). I am encouraging musing about this in preparation > > for the next phase of this whole process on what we should do about > > all of our problems. > > > > Examples: If the solutions phase started and someone threw out a > > proposal that rid us of a central body that has tight control of all > > output (ala the IESG) would people squirm? What if someone proposed > > realigning WGs in a different way (say, a looser, longer-lived way)? > > Would that cause alarm? (With appologies to Dave Clark,) What if it > > was proposed that SIRs get to *vote* on documents? Would that be > > wrong? > > Mark, > > good questions. > > I think the problem-process draft's initial section - "what are the core > values of the IETF that we don't want to lose" - is the closest thing we > have on the table now to a statemnet of what *not* to change, or criteria > on which we can judge that change proposals are out of scope. > > [parenthesis - I think this would be better positioned as a separate > document..... but it's not listed in the WG charter, so doing so would > either take it out of the scope of this group's mandate or require WG > consensus that it needs doing anyway] > > I encourage people to read that section most carefully, and suggest updates > and improvements to it as a means of answering Mark's thoughtful questions. > > Harald > > > From problem-statement-bounces@alvestrand.no Tue May 20 07:45: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 HAA06941 for ; Tue, 20 May 2003 07:45:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 53A76625A3; Tue, 20 May 2003 13:47:58 +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 13D2A62206 for ; Tue, 20 May 2003 13:47:55 +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 EAA72276 for ; Tue, 20 May 2003 04:47:54 -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 gnI0CsO2 Tue, 20 May 2003 04:47:53 -0700 (PDT) Message-ID: <047801c31ec5$a8203720$0300a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <200305161512.h4GFCpkL024356@rtp-core-1.cisco.com> <3EC79E61.4A62F7F7@hursley.ibm.com> Date: Tue, 20 May 2003 06:47:56 -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: OPEN ISSUE: Standards Track 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 haven't seen any followup to Brian's note, and wanted to (1) agree that moving from PS to full Standard is more likely interesting than moving from PS to Draft Standard, (2) agree that Draft Standard does NOT seem like a more impressive name than PS to anyone outside IETF (and it's been a while since someone has been confused about the difference between "draft standard" and "internet draft on the standards track" in my presence, but it has happened). Spencer ----- Original Message ----- From: "Brian E Carpenter" Cc: Sent: Sunday, May 18, 2003 9:53 AM Subject: Re: OPEN ISSUE: Standards Track > Eric Rosen wrote: > > > > Brian> Secondly, this is a case where I think a simple first step may > > Brian> help quite a bit: simply merge Draft Standard and Standard > > Brian> into a single class, called Standard, but with the criteria > > Brian> now used for Draft Standard. > > > > Brian> Arguments: remove a process step that we basically never use, > > Brian> and make the step up from Proposed Standard worth the trouble. > > > > Could you explain how this makes the step up from PS worth the trouble? > > Because you know that the effort of documenting the interoperable > implementations will be rewarded by immediately getting to the final > status, rather than just getting to an intermediate plateau (and one with > a very confusing name, since to outsiders it sounds like a step backwards). > > Brian > From problem-statement-bounces@alvestrand.no Tue May 20 07: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 HAA06999 for ; Tue, 20 May 2003 07:48:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6B896625B6; Tue, 20 May 2003 13:50: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 8B6C962206; Tue, 20 May 2003 13:50:37 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.2]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id EAA15096; Tue, 20 May 2003 04:50:26 -0700 (PDT) Message-Id: <5.1.0.14.2.20030520073059.0422abc0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 20 May 2003 07:46:18 -0400 To: Harald Tveit Alvestrand From: Margaret Wasserman In-Reply-To: <326578585.1053430682@HALVESTR-W2K1.cisco.com> References: <200305191357.JAA98002@guns.lerc.nasa.gov> <200305191357.JAA98002@guns.lerc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: non-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 At 11:38 AM 5/20/2003 +0200, Harald Tveit Alvestrand wrote: >I think the problem-process draft's initial section - "what are the core >values of the IETF that we don't want to lose" - is the closest thing we >have on the table now to a statemnet of what *not* to change, or criteria >on which we can judge that change proposals are out of scope. The intent of that section was to guide our thinking about the problem resolution process, so that our problem resolution process would be aligned with our stated purpose and core values. At this point, the core values section is only intended to paraphrase your presentations of our purpose and core values at the IESG plenary in Atlanta. Feel free to let me know if I got anything wrong. >[parenthesis - I think this would be better positioned as a separate >document..... but it's not listed in the WG charter, so doing so would >either take it out of the scope of this group's mandate or require WG >consensus that it needs doing anyway] In the process document, the task of documenting the real core values, mission and goals of the IETF is assigned to the IETF Improvement WG. That statement would be in a separate document (or two or three), and will represent community consensus. As part of the same phase (Phase One), the WG would also determine how to measure the performance of the IETF against our goals, and would take baseline measurements. This will allow us to quantify our current performance (where possible) before undertaking efforts to improve it. I believe that it is vitally important that we _understand_ the IETF, before we try to change it. In particular, I think that we need to understand what makes the IETF the IETF, so that we don't sacrifice our identity and strengths in an effort to improve our performance. As a relative newcomer to the IETF (~8 years), I'm not really sure that _I_ fully understand what makes the IETF the IETF... We've had something of an identity crisis for the past several years, brought on in part (I think) by the datacom/telecom convergence and a huge influx of new people, with different ways of thinking, into the IETF. Although I think that an historical perspective is important, this can't simply a matter of the IESG and a few old-timers _telling_ the rest of us what the IETF is. I think that this is a process that we need to go through as a community, so that we can internalize the results. Today, we have a bunch of unrest, but very little real understanding of what the mission and goals or strengths and weaknesses of the IETF actually are. I'm not saying that _you_ don't understand those things, but we don't have a critical mass of people with a common understanding of those things, so we can't reasonably say that the IETF understands them. >I encourage people to read that section most carefully, and suggest >updates and improvements to it as a means of answering Mark's thoughtful >questions. Actually, the chairs of the WG haven't responded to the questions about earlier suggested changes... Are we trying to write the _real_ core values statement here? Or just paraphrase your presentation? The division between this WG and the next is not carved in stone. But, right now, the assumption is that the _next_ WG will document our actual core values, perhaps using your presentation and/or the core values section of this document as a starting point. Margaret From problem-statement-bounces@alvestrand.no Tue May 20 08:01: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 IAA07703 for ; Tue, 20 May 2003 08:01:48 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0D8BC625B5; Tue, 20 May 2003 14:04:22 +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 95376625AB for ; Tue, 20 May 2003 14:04:17 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4KC4Eb30507; Tue, 20 May 2003 15:04:14 +0300 Date: Tue, 20 May 2003 15:04:14 +0300 (EEST) From: Pekka Savola To: Spencer Dawkins In-Reply-To: <047801c31ec5$a8203720$0300a8c0@DFNJGL21> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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, 20 May 2003, Spencer Dawkins wrote: > (1) agree that moving from PS to full Standard is more > likely interesting than moving from PS to Draft Standard, Moving from PS to Draft typically seems to include a lot of tuning of the spec, including removal of features and adding a few new ones (to replace/enhance/augment the ones killed for instance), or clarifying ones (in such a manner that all the old implementation are not compliant). If we went from PS to Full, the documents certainly would have to recycled at the PS stage far, far longer to ensure there are no glitches left. In addition, requiring more than 2 interop implementations of each feature should be required if we're to call something a Standard (unless we redefined the way it is, and engrave the "good old standards" in a golden plaque). > (2) agree that Draft Standard does NOT seem like a more > impressive name than PS to anyone outside IETF (and > it's been a while since someone has been confused about > the difference between "draft standard" and "internet draft > on the standards track" in my presence, but it has happened). True. > ----- Original Message ----- > From: "Brian E Carpenter" > Cc: > Sent: Sunday, May 18, 2003 9:53 AM > Subject: Re: OPEN ISSUE: Standards Track > > > > Eric Rosen wrote: > > > > > > Brian> Secondly, this is a case where I think a simple first step may > > > Brian> help quite a bit: simply merge Draft Standard and Standard > > > Brian> into a single class, called Standard, but with the criteria > > > Brian> now used for Draft Standard. > > > > > > Brian> Arguments: remove a process step that we basically never use, > > > Brian> and make the step up from Proposed Standard worth the trouble. > > > > > > Could you explain how this makes the step up from PS worth the trouble? > > > > Because you know that the effort of documenting the interoperable > > implementations will be rewarded by immediately getting to the final > > status, rather than just getting to an intermediate plateau (and one with > > a very confusing name, since to outsiders it sounds like a step > backwards). > > > > Brian > > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From problem-statement-bounces@alvestrand.no Tue May 20 08:03: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 IAA07832 for ; Tue, 20 May 2003 08:02:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 52DD6625B5; Tue, 20 May 2003 14:05: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 8E49C6220B for ; Tue, 20 May 2003 14:05:33 +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 FAA75207 for ; Tue, 20 May 2003 05:05: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 xYJ0TdP2 Tue, 20 May 2003 05:05:31 -0700 (PDT) Message-ID: <04c701c31ec8$1efb8b40$0300a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <5.1.0.14.2.20030515114433.04767ac8@mail.windriver.com> <4517643810.20030516200534@brandenburg.com> Date: Tue, 20 May 2003 07:05: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: OPEN ISSUE: 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 Dear Dave, I believe that this thread was actually about the general process of selecting a chair for any WG, not about the mechanisms we're discussing for choosing leadership for the Solutions WG (we seem to be converging on a "less change is better than more change" for the Solutions AD and WG chair(s), but we've seen other proposals for this unique selection process on this mailing list). Dear All, Having said this - I do agree with the expressed desire for more awareness that a WG chair position is open. I found Harald's process for choosing co-chairs for the Problem Statement working group to be encouraging, and would like to see something like this become more common in the IETF. Subject to the "ADs and WG chairs must have a good relationship" caveat that Margaret mentioned... Spencer ----- Original Message ----- From: "Dave Crocker" To: "Margaret Wasserman" Cc: Sent: Friday, May 16, 2003 10:05 PM Subject: Re: OPEN ISSUE: WG Chair Selection > Margaret, > > > MW> However, it is important for ADs and WG chairs to have a good > MW> relationship, and for the AD to have authority over the WG > MW> chair. I believe that the current reporting relationship > MW> (AD chooses WG chair, chair serves at ADs pleasure) is > MW> appropriate. > > > So the chair and working group who well might specify changes to the > IESG are to be managed by someone in the IESG? > > I always thought that "conflict of interest" was a pretty simple > concept. > > How many of us would like to be hired by someone who gives us the job of > telling them what their job will be? > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > From problem-statement-bounces@alvestrand.no Tue May 20 08:08: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 IAA08195 for ; Tue, 20 May 2003 08:08:41 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E1893625B5; Tue, 20 May 2003 14:11:17 +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 77DF0625AB for ; Tue, 20 May 2003 14:11:15 +0200 (CEST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])ESMTP id h4KCBD127158 for ; Tue, 20 May 2003 08:11:13 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10G2SN>; Tue, 20 May 2003 14:11:12 +0200 Message-ID: From: "Mak, L (Leen)" To: problem-statement@alvestrand.no Date: Tue, 20 May 2003 14:11:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: non-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 > I think the problem-process draft's initial section - "what are the core > values of the IETF that we don't want to lose" - is the closest thing we > have on the table now to a statemnet of what *not* to change, or criteria > on which we can judge that change proposals are out of scope. > Allow me to go out of scope. In section 2 of the ietf-problem-proces draft, I read: > As we consider changes to the IETF processes and organizational > structure, it is important to keep in mind the things about the > IETF that we don't want to change -- [snip] > "We reject kings, presidents and voting. We believe in rough > consensus and running code." -- Dave Clark I wonder whether I am really the only one who is thinking that this "things-about-the-IETF-that-we-don't-want-to-change" attitude threatens to make the whole attempt to improve futile. All over the world, civilisations found that the proces of having town meetings where everyone can talk and argue and talk and argue ad infinitum or until (rough) consensus, simply does not scale. Voting, and delegating executive power to presidents, has been found to be working, albeit far from ideal, instruments to deal with this scalability problem. To me it is a mystery why people seem to think that IETF can escape from these scalability problems and go on with the town meeting model. Take for example this problem-statement list. In the last month, about 400 emails were sent. More than 80% were written by less than 20 contributors (i.e. about 1 % of the average attendance of the 10 most recent IETF meetings). Just a few observations, based on the postings to the list. I concluded that, in order to contribute succesfully: 1) one needs to have plenty of spare time, not only to read but also to digest all these 100's of messages; 2) one should have more than average, intimate, personal knowledge of many years of IETF and IESG history, because many assertions are being made which cannot be valued if one lacks such knowledge; 3) it is very preferable to be a native English speaker, because sometimes the language is so subtle and sparse that the meaning is very difficult to grasp. For me these are serious signals that some of the core values (like "everyone can speak up and all opinions count") are already (irretrievably?) lost. I think it is better to acknowledge that and to improve given such context, than to try to stick to the belief that the old values are still valid. I have been taught that the internet is based on ideas of people who were able to really think out of the box. Why is it than, when it comes to organisation and processes, that this community appears to be so conservative? Leen Mak From problem-statement-bounces@alvestrand.no Tue May 20 08:17: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 IAA08594 for ; Tue, 20 May 2003 08:16:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 47685625BE; Tue, 20 May 2003 14:19:35 +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 B0674625AB for ; Tue, 20 May 2003 14:19: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 FAA77946 for ; Tue, 20 May 2003 05:19:31 -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 6HK0cLQ2 Tue, 20 May 2003 05:19:30 -0700 (PDT) Message-ID: <04d201c31eca$132a1d20$0300a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <5.1.0.14.2.20030515114433.04767ac8@mail.windriver.com> <5.1.0.14.0.20030516103921.0188a7c8@mail.stevecrocker.com> Date: Tue, 20 May 2003 07:19:34 -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: OPEN ISSUE: 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 Dear Joel, I understand your distinction between WG chairs leaving and "leaving with assistance". I've got to ask - how common IS the case where a WG chair is (1) not performing to the point where s/he should be replaced, and (2) not willing to step down? If this happens once a year, I'd say "tough, let the AD announce the impending replacement publically and ask for input anyway". It's not like anything is getting done in the WG anyway, right? If this happens once per IETF per area (for instance), that might be different. But I'd like to see more openness, and don't want to shut down an opportunity for more openness to accommodate an rare case, if it's really rare. Spencer ----- Original Message ----- From: "Joel M. Halpern" To: Sent: Friday, May 16, 2003 9:44 AM Subject: Re: OPEN ISSUE: WG Chair Selection > There are actually two very different cases. > For simplicity, let me discuss them both in terms of an existing working > group (both cases exist for new working groups, but there are other issues > that cloud things.) > > One case is where you have a chair who for one or another reason has chosen > to step down. You are going to have to find a new chair. Announcing the > opening would not in and of itself cause a problem. > > The other case is where the AD wants / needs to replace the chair when the > chair would not on his own step down. (Presume the AD has already > discussed the causes with the current chair, but probably not the intended > action.) The AD probably does not want to force the issue until there is a > good replacement chair available. As such, making a public announcement > would be "interesting". > > And of course, having two different procedures would mean that one was > publicising which case actually applied... > > We can make personnel management harder if we want, but is that really a > good idea? > > Note that having said all that, it would be really good to have better > mechanisms for finding chairs, and for finding new blood to serve as > chairs. Appointing chairs was the part of the AD job I hated when I was > doing that. I just think it is more complex than the exchange below suggests. > > Yours, > Joel From problem-statement-bounces@alvestrand.no Tue May 20 08:50: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 IAA10925 for ; Tue, 20 May 2003 08:50:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 48E67625C6; Tue, 20 May 2003 14:52:56 +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 86507625BE; Tue, 20 May 2003 14:52:52 +0200 (CEST) Date: Tue, 20 May 2003 14:42:51 +0200 From: Harald Tveit Alvestrand To: John C Klensin Message-ID: <337667099.1053441771@localhost> In-Reply-To: <160610315.1053356338@p3.JCK.COM> References: <160610315.1053356338@p3.JCK.COM> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: "problem-statement@alvestrand.no" Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 19. mai 2003 14:58 -0400 John C Klensin wrote: [quoting Ted] >> The corollary work load also worries me. If one of the >> concerns here is to get someone who can focus very tightly on >> these issues, then asking them to take on the role of an AD >> seems to be an issue. There is also a strong risk that having >> to do the work *as it is now* on a daily basis may limit the >> individual's ability to imagine it in new ways. From the >> outside, I know I personally had a concern about how focused >> on tool development the IESG seemed to me to be. While I >> ... > > This is a reasonable concern. But, again in my devil's advocate role, > let's turn it around. We've heard multiple statements to the effect that > "IETF Chair" is a full-time job. No one has come forward and said that > it is really a walk in the park that can be done effectively with a few > mornings a week. So, we are going to add at least a couple of WGs to the > IETF Chair's workload, and expect that he will be able to effectively > coordinate the efforts and output of those WGs with the nomcom, lpr, and > maybe some other efforts that potentially overlap it. That is potentially > a lot of work. If Harald can say "I've got the extra cycles, no > problem", then there is no argument for a separate area independent of > the concerns others have had about the process of the current IESG > supervising this work. But I haven't heard him say that yet. some pointers, not in alignment..... - no matter what else, the IETF Chair has to follow the work of the problem WG, the solutions WGs and anything else with that much potential IETF impact no matter whether he/she is the shepherding AD or not. - under our current understanding of the Nomcom rules, the IESG cannot add members at will; new members have to come through the nomcom process. This is one reason why temporary ADs are (so far) drawn only from existing ADs. And, as others have said, we've got no provisions for "AD, junior grade"; you're either on the IESG or you're not. - as Ted has indicated, spinning up into being an effective IESG member is quite a job, and involves a lot of learning. So if you need an AD to be effective "day before yesterday", adding a new IESG member isn't optimal. - one reason why we've gone to 2-AD areas is that there's always SOMEONE to talk to whose area of responsibility within the IESG is closely related to yours. - no, it's not a walk in the park. Drawing no conclusions at this point in time. From problem-statement-bounces@alvestrand.no Tue May 20 09:21: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 JAA12458 for ; Tue, 20 May 2003 09:21:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EE0A9625A0; Tue, 20 May 2003 15:23:55 +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 01CC9623CD for ; Tue, 20 May 2003 15:23:54 +0200 (CEST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) h4KDNcCi039866 for ; Tue, 20 May 2003 15:23:40 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4KDKcWO271882 for ; Tue, 20 May 2003 15:20:44 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA38200 from ; Tue, 20 May 2003 15:20:37 +0200 Message-Id: <3ECA2BC2.629FD0FE@hursley.ibm.com> Date: Tue, 20 May 2003 15:21:06 +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: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, 20 May 2003, Spencer Dawkins wrote: > > (1) agree that moving from PS to full Standard is more > > likely interesting than moving from PS to Draft Standard, > > Moving from PS to Draft typically seems to include a lot of tuning of the > spec, including removal of features and adding a few new ones (to > replace/enhance/augment the ones killed for instance), or clarifying ones > (in such a manner that all the old implementation are not compliant). > > If we went from PS to Full, the documents certainly would have to recycled > at the PS stage far, far longer to ensure there are no glitches left. Disagree. Good enough is good enough. If you find glitches later, and anybody cares, recycle at Standard. I do *not* suggest we should raise the bar for promotion from Proposed Standard by one millimetre. I am proposing that we simply abolish and forget the second bar. Brian From problem-statement-bounces@alvestrand.no Tue May 20 09: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 JAA12671 for ; Tue, 20 May 2003 09:30:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3707162598; Tue, 20 May 2003 15:32:54 +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 14F76623CD for ; Tue, 20 May 2003 15:32:50 +0200 (CEST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) h4KDWglr046454; Tue, 20 May 2003 15:32:43 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4KDWbWO182462; Tue, 20 May 2003 15:32:38 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA58500 from ; Tue, 20 May 2003 15:32:35 +0200 Message-Id: <3ECA2E91.7D29A5A6@hursley.ibm.com> Date: Tue, 20 May 2003 15:33:05 +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: "Mak, L (Leen)" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: non-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 "Mak, L (Leen)" wrote: ... > > I have been taught that the internet is based on ideas of people who > were able to really think out of the box. Why is it than, when it comes > to organisation and processes, that this community appears to be so > conservative? I think many of us are acutely aware that a) "if it isn't broken, don't fix it" is a vital engineering principle in complex systems. b) any change to a social system has unintended and largely unpredictable consequences, as well as the intended consequences. So personally, I am indeed in conservative mode except where we have a clearly understood problem and a proposed solution with clearly limited consequences. But then we should go for it. Brian From problem-statement-bounces@alvestrand.no Tue May 20 09: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 JAA13201 for ; Tue, 20 May 2003 09:48:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9EA1D62598; Tue, 20 May 2003 15:50:53 +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 7737C623CD for ; Tue, 20 May 2003 15:50:50 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.2]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA05508; Tue, 20 May 2003 06:50:26 -0700 (PDT) Message-Id: <5.1.0.14.2.20030520092216.04254020@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 20 May 2003 09:46:01 -0400 To: John C Klensin From: Margaret Wasserman In-Reply-To: <177227629.1053372956@p3.JCK.COM> References: <10534684934.20030519160606@brandenburg.com> <160610315.1053356338@p3.JCK.COM> <10534684934.20030519160606@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Problem Statement Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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've been thinking more about your proposal, and I'm having some serious reservations about it. The main advantage seems to be that it eliminates a minor issue in the appeals process when "responsible AD" == IETF chair. In particular, we end-up skipping a step because it wouldn't make any sense to go to Harald twice, so we would need to go straight from the responsible AD to the IESG. Not a biggie... Another possible advantage is that it would reduce overloading on the IETF chair. However, I haven't seen any mail from Harald that indicates that: - He is so overloaded that running the process groups would represent a problem for him, or - That his load would be significantly lessened by having a new AD run a new "Process Area". Another advantage is that this _might_ appease the people who do not want the current establishment to run the process of improving the IETF -- this would probably depend on who is chosen as the Process AD (see below). In the meantime, this proposal would exacerbate a known issue -- that the IESG is already too large (with 13 voting members and 17 or 18 people in attendance) to be an effective decision making body. And thinking a couple of steps ahead to who might be chosen... There would seem to be two primary options for who would be chosen to run the Process Area: - A past IESG member with experience in IETF process development. - Someone completely new to the IESG. The first choice probably wouldn't be acceptable to the people who don't want the effort to be run by the established leaders. And, the second option causes a further problem. The IESG is already dealing with the care and feeding of three new members. I've been told that training new members is very time-consuming for the experienced IESG members, and that it can take six months or more for a new AD to come fully on line. Do we really want an entire area run by a new, inexperienced IESG member? And, does it really _decrease_ the load on the IESG, and Harald in particular, to add a new member to run this area? I'd like to try to get to the core issue that is motivating this (and other) alternative proposal(s) -- some people (I'm not sure how many) don't trust the existing IESG, and Harald in particular, to run this process. I think that we need to determine where the consensus of the community lies on this issue. I believe that the vast majority of us _do_ trust our current leadership. I'm probably already on the record somewhere as saying that I trust the existing IESG, and Harald, to run this process. But, let me say something stronger... IMO, Harald is the best person in the IETF to run the improvement process. _Anyone_ that we pick to run the "Process Area" would, at best, be second choice. I supported Harald's candidacy with the nomcom specifically _because_ I wanted him to run the process of fixing the IETF. I also believe that the Nomcom chose Harald _knowing_ that he was planning to do this. If there was community consensus that someone else should be running this process, it should have been reflected in the Nomcom selection. Margaret From problem-statement-bounces@alvestrand.no Tue May 20 10:20: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 KAA15171 for ; Tue, 20 May 2003 10:20:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 377D56233E; Tue, 20 May 2003 16:23:01 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from seraph2.grc.nasa.gov (seraph2.grc.nasa.gov [128.156.10.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id 67276622A1 for ; Tue, 20 May 2003 16:22:59 +0200 (CEST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 57FFC689F3 for ; Tue, 20 May 2003 10:22:57 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.grc.nasa.gov [139.88.87.35]) h4KEMuuW017569; Tue, 20 May 2003 10:22:56 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id KAA14415; Tue, 20 May 2003 10:22:56 -0400 (EDT) Message-Id: <200305201422.KAA14415@guns.lerc.nasa.gov> To: "Mak, L (Leen)" From: Mark Allman In-Reply-To: Organization: BBN Technologies/NASA GRC Song-of-the-Day: If I Wanted To Date: Tue, 20 May 2003 10:22:56 -0400 Cc: problem-statement@alvestrand.no Subject: Re: non-problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mallman@grc.nasa.gov List-Id: Problem 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 wonder whether I am really the only one who is thinking that > this "things-about-the-IETF-that-we-don't-want-to-change" attitude > threatens to make the whole attempt to improve futile. A few thoughts: + I agree that taking certain changes we might make off the table without thought is a bad idea. Everything should be fair game for careful consideration with regards to changing our processes. + However, that doesn't mean that everything needs changed. + What I was musing about was whether there are things that we can take out of the "change this" pile because we have consensus that the status quo is working well. (That is, I don't think we want to change for the sake of change.) + The key is that we carefully consider everything and use what we have found to not work **and** what we have found to work well to make wise decisions about our future course. Or, we should not only take the "what are our problems" angle or, IMO, we have less of a chance of succeeding. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ From problem-statement-bounces@alvestrand.no Tue May 20 10:24: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 KAA15409 for ; Tue, 20 May 2003 10:24:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9E4F4623CD; Tue, 20 May 2003 16:26:41 +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 BA6A1622A1 for ; Tue, 20 May 2003 16:26:38 +0200 (CEST) Received: from medea.wz-berlin.de ([193.174.6.5]) by athene.wz-berlin.de with esmtp (Exim 4.20) id 19I84Y-0008Dx-Lu; Tue, 20 May 2003 16:26:34 +0200 Received: from ERDE/SpoolDir by medea.wz-berlin.de (Mercury 1.48); 20 May 03 16:26:35 +0200 Received: from SpoolDir by ERDE (Mercury 1.48); 20 May 03 16:26:30 +0200 From: "Jeanette Hofmann" Organization: Wissenschaftszentrum Berlin To: Margaret Wasserman Date: Tue, 20 May 2003 16:26:23 +0200 MIME-Version: 1.0 Message-ID: <3ECA572F.2746.F771A5@localhost> Priority: normal In-reply-to: <5.1.0.14.2.20030520092216.04254020@mail.windriver.com> References: <177227629.1053372956@p3.JCK.COM> 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: Amavis with NAI VirusScan on athene.wz-berlin.de Cc: Problem Statement Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 20 May 2003 at 9:46, Margaret Wasserman wrote: > Do we really want an entire area run by a new, inexperienced > IESG member? And, does it really _decrease_ the load on the > IESG, and Harald in particular, to add a new member to run > this area? In my understanding, the main reason for John's creative solution is to achieve to goals: 1. find a _neutral_ person to lead the reform process, preferably not being an IESG member 2. discuss and decide reform options on the basis of established procedures. > > I'd like to try to get to the core issue that is motivating > this (and other) alternative proposal(s) -- some people (I'm > not sure how many) don't trust the existing IESG, and Harald > in particular, to run this process. Now, you make it sound as if those who prefer a newly appointed AD do distrust Harald. This is certainly not the case as far as I am concerned. On the contrary. My point is that the chances of success of a reform process might decrease if the process is led by an authority structure that is obviously part of the problem. > > I think that we need to determine where the consensus of > the community lies on this issue. I believe that the > vast majority of us _do_ trust our current leadership. Again, I don't think that personal distrust is the main issue here. It is about creating sound preconditions for the reform process. Jeanette > > I'm probably already on the record somewhere as saying that > I trust the existing IESG, and Harald, to run this process. > But, let me say something stronger... > > IMO, Harald is the best person in the IETF to run the > improvement process. _Anyone_ that we pick to run the > "Process Area" would, at best, be second choice. I > supported Harald's candidacy with the nomcom specifically > _because_ I wanted him to run the process of fixing the > IETF. > > I also believe that the Nomcom chose Harald _knowing_ > that he was planning to do this. > > If there was community consensus that someone else > should be running this process, it should have been > reflected in the Nomcom selection. > > Margaret > > > From problem-statement-bounces@alvestrand.no Tue May 20 10:30: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 KAA15637 for ; Tue, 20 May 2003 10:30:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4B2736233E; Tue, 20 May 2003 16:32:53 +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 10A20622A1 for ; Tue, 20 May 2003 16:32:51 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.2]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA25141; Tue, 20 May 2003 07:32:06 -0700 (PDT) Message-Id: <5.1.0.14.2.20030520102444.0164f0a0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 20 May 2003 10:28:13 -0400 To: "Jeanette Hofmann" From: Margaret Wasserman In-Reply-To: <3ECA572F.2746.F771A5@localhost> References: <5.1.0.14.2.20030520092216.04254020@mail.windriver.com> <177227629.1053372956@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Problem Statement Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 Jeannette, At 04:26 PM 5/20/2003 +0200, Jeanette Hofmann wrote: > > I'd like to try to get to the core issue that is motivating > > this (and other) alternative proposal(s) -- some people (I'm > > not sure how many) don't trust the existing IESG, and Harald > > in particular, to run this process. > >Now, you make it sound as if those who prefer a newly appointed AD do >distrust Harald. This is certainly not the case as far as I am concerned. On >the contrary. My point is that the chances of success of a reform process >might decrease if the process is led by an authority structure that is >obviously >part of the problem. Thanks for making this point. This is what I meant by trying to get to the core issue that is motivating this discussion... I am not sure that I agree with your point, though. I guess it depends on your definition of "reform". Most of my experience regarding intentional change within organizations has been in corporate environments where change and reorganization is typically lead by the existing management. And, in many cases, this is quite successful. > > > I think that we need to determine where the consensus of > > the community lies on this issue. I believe that the > > vast majority of us _do_ trust our current leadership. > >Again, I don't think that personal distrust is the main issue here. It is >about >creating sound preconditions for the reform process. What leads you to believe that having a "neutral" person oversee the process is necessary to create a sound precondition for the reform process? Margaret From problem-statement-bounces@alvestrand.no Tue May 20 10:35: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 KAA15902 for ; Tue, 20 May 2003 10:35:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 733286233E; Tue, 20 May 2003 16:38:05 +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 B3C86622A1 for ; Tue, 20 May 2003 16:37:58 +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 19I8FW-000045-00; Tue, 20 May 2003 07:37:54 -0700 Date: Tue, 20 May 2003 10:36:53 -0400 From: Keith Moore To: Brian E Carpenter Message-Id: <20030520103653.622bfdd3.moore@cs.utk.edu> In-Reply-To: <3ECA2BC2.629FD0FE@hursley.ibm.com> References: <3ECA2BC2.629FD0FE@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: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 we went from PS to Full, the documents certainly would have to recycled > > at the PS stage far, far longer to ensure there are no glitches left. > > Disagree. Good enough is good enough. If you find glitches later, and > anybody cares, recycle at Standard. I do *not* suggest we should raise > the bar for promotion from Proposed Standard by one millimetre. I am > proposing that we simply abolish and forget the second bar. offhand I don't recall many cases where we recycled at draft. so I think the cases where we'd recycle at proposed in order to avoid having the document go to Standard would also be rare. one thing I'd like to see us consider is to issue more applicabliity statements, errata documents, and implementation notes, rather than revising an entire document to accomodate minor changes. we could do that even for Standard documents. From problem-statement-bounces@alvestrand.no Tue May 20 10:42: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 KAA16102 for ; Tue, 20 May 2003 10:42:27 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 012A1623CD; Tue, 20 May 2003 16:45:03 +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 267006233E for ; Tue, 20 May 2003 16:45:01 +0200 (CEST) Received: from medea.wz-berlin.de ([193.174.6.5]) by athene.wz-berlin.de with esmtp (Exim 4.20) id 19I8ML-000092-PA; Tue, 20 May 2003 16:44:57 +0200 Received: from ERDE/SpoolDir by medea.wz-berlin.de (Mercury 1.48); 20 May 03 16:44:58 +0200 Received: from SpoolDir by ERDE (Mercury 1.48); 20 May 03 16:44:55 +0200 From: "Jeanette Hofmann" Organization: Wissenschaftszentrum Berlin To: Margaret Wasserman Date: Tue, 20 May 2003 16:44:55 +0200 MIME-Version: 1.0 Message-ID: <3ECA5B87.27983.1086967@localhost> Priority: normal In-reply-to: <5.1.0.14.2.20030520102444.0164f0a0@mail.windriver.com> References: <3ECA572F.2746.F771A5@localhost> 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: Amavis with NAI VirusScan on athene.wz-berlin.de Cc: Problem Statement Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 20 May 2003 at 10:28, Margaret Wasserman wrote: > > Hi Jeannette, > > At 04:26 PM 5/20/2003 +0200, Jeanette Hofmann wrote: > > > I'd like to try to get to the core issue that is motivating > > > this (and other) alternative proposal(s) -- some people (I'm > > > not sure how many) don't trust the existing IESG, and Harald > > > in particular, to run this process. > > > >Now, you make it sound as if those who prefer a newly appointed AD do > >distrust Harald. This is certainly not the case as far as I am concerned. On > >the contrary. My point is that the chances of success of a reform process > >might decrease if the process is led by an authority structure that is > >obviously > >part of the problem. > > Thanks for making this point. This is what I meant by trying > to get to the core issue that is motivating this discussion... > > I am not sure that I agree with your point, though. I guess it > depends on your definition of "reform". Most of my experience > regarding intentional change within organizations has been in > corporate environments where change and reorganization is typically > lead by the existing management. And, in many cases, this is > quite successful. Margaret, you are right. Yet, many companies hire consultants to get input from a not affected, third party. (Whether that is a good way to get neutral input is a different question.) > > > > > I think that we need to determine where the consensus of > > > the community lies on this issue. I believe that the > > > vast majority of us _do_ trust our current leadership. > > > >Again, I don't think that personal distrust is the main issue here. It is > >about > >creating sound preconditions for the reform process. > > What leads you to believe that having a "neutral" person oversee > the process is necessary to create a sound precondition for the > reform process? By neutral I mean unbiased and open with regard to the solution space. I don't want to sound trivial, are you expecting a more thorough explanation? Jeanette > > Margaret > > > From problem-statement-bounces@alvestrand.no Tue May 20 10:44: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 KAA16168 for ; Tue, 20 May 2003 10:44:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2CB64625A0; Tue, 20 May 2003 16:46:54 +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 8DC936233E for ; Tue, 20 May 2003 16:46:51 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.2]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA03608; Tue, 20 May 2003 07:46:37 -0700 (PDT) Message-Id: <5.1.0.14.2.20030520104145.041fc040@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 20 May 2003 10:42:35 -0400 To: Keith Moore From: Margaret Wasserman In-Reply-To: <20030520103653.622bfdd3.moore@cs.utk.edu> References: <3ECA2BC2.629FD0FE@hursley.ibm.com> <3ECA2BC2.629FD0FE@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Cc: Brian E Carpenter Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 Keith, At 10:36 AM 5/20/2003 -0400, Keith Moore wrote: >one thing I'd like to see us consider is to issue more applicabliity >statements, errata documents, and implementation notes, rather than >revising an entire document to accomodate minor changes. we could do that >even for Standard documents. I would agree, if our existing document set was organized to make it easier for people to find associated documents. Maybe that is something we can change/fix? Margaret From problem-statement-bounces@alvestrand.no Tue May 20 11:15: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 LAA17287 for ; Tue, 20 May 2003 11:15:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 84813625A2; Tue, 20 May 2003 17:18:00 +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 E24EB6233E for ; Tue, 20 May 2003 17:17: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 IAA52104 for ; Tue, 20 May 2003 08:17:49 -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 KYD0qcJ2 Tue, 20 May 2003 08:17:48 -0700 (PDT) Message-ID: <054501c31ee2$fb8a4190$0300a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <3ECA2BC2.629FD0FE@hursley.ibm.com> <3ECA2BC2.629FD0FE@hursley.ibm.com> <5.1.0.14.2.20030520104145.041fc040@mail.windriver.com> Date: Tue, 20 May 2003 10:17: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: OPEN ISSUE: Standards Track 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 Margaret, Well, now that you mention it, I believe these items would help people find things: - actual use of the STD maturity level, so that many questions could be answered by "look at STD n", no matter what has happened to the underlying RFCs and errata sheets lately, - a severe pruning to Historical of protocols that aren't still widely used, - possibily even a severe pruning to Historical of protocols that aren't still being deployed (even if they are still in use), - decent STF organization (note that STD 5 includes SIX RFCs on IP and ICMP. Conversely, how many Telnet options are there? they're spread across SIX STDs). - I really like the Updated By/Obsoleted By information you get when you SEARCH for a document at http://www.rfc-editor.org/rfcsearch.html, but this information could appear other places, too (in document bodies would be nice, but I know we don't change RFCs without changing RFC numbers). Others? Spencer ----- Original Message ----- From: "Margaret Wasserman" To: "Keith Moore" Cc: ; "Brian E Carpenter" Sent: Tuesday, May 20, 2003 9:42 AM Subject: Re: OPEN ISSUE: Standards Track > > Hi Keith, > > At 10:36 AM 5/20/2003 -0400, Keith Moore wrote: > >one thing I'd like to see us consider is to issue more applicabliity > >statements, errata documents, and implementation notes, rather than > >revising an entire document to accomodate minor changes. we could do that > >even for Standard documents. > > I would agree, if our existing document set was organized to make > it easier for people to find associated documents. Maybe that > is something we can change/fix? > > Margaret From problem-statement-bounces@alvestrand.no Tue May 20 11:27: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 LAA17636 for ; Tue, 20 May 2003 11:27:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BE91A625A2; Tue, 20 May 2003 17:30:24 +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 839AD6233E for ; Tue, 20 May 2003 17:30:23 +0200 (CEST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) h4KFUAlr039962 for ; Tue, 20 May 2003 17:30:19 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4KFSgWO190656 for ; Tue, 20 May 2003 17:28:43 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA25424 from ; Tue, 20 May 2003 17:28:41 +0200 Message-Id: <3ECA49C5.141CE509@hursley.ibm.com> Date: Tue, 20 May 2003 17:29:09 +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: <3ECA2BC2.629FD0FE@hursley.ibm.com> <5.1.0.14.2.20030520104145.041fc040@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 Wasserman wrote: > > Hi Keith, > > At 10:36 AM 5/20/2003 -0400, Keith Moore wrote: > >one thing I'd like to see us consider is to issue more applicabliity > >statements, errata documents, and implementation notes, rather than > >revising an entire document to accomodate minor changes. we could do that > >even for Standard documents. > > I would agree, if our existing document set was organized to make > it easier for people to find associated documents. Maybe that > is something we can change/fix? http://www.rfc-editor.org/rfcxx00.html goes in this direction, but could use some more snazzy hyperlinking. Brian From problem-statement-bounces@alvestrand.no Tue May 20 11:32: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 LAA17832 for ; Tue, 20 May 2003 11:32:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A4773625A7; Tue, 20 May 2003 17:34:38 +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 AA5ED625A2 for ; Tue, 20 May 2003 17:34:31 +0200 (CEST) Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4641436 for problem-statement@alvestrand.no; Tue, 20 May 2003 11:34:30 -0400 Message-Id: <5.1.0.14.0.20030520112310.0281a958@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 20 May 2003 11:32:07 -0400 To: From: "Joel M. Halpern" In-Reply-To: <04d201c31eca$132a1d20$0300a8c0@DFNJGL21> References: <5.1.0.14.2.20030515114433.04767ac8@mail.windriver.com> <5.1.0.14.0.20030516103921.0188a7c8@mail.stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: OPEN ISSUE: 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 It appears to me that it is not a common problem to need to replace a WG chair. However, when a chair needs to be replaced it is often because they do not get it. You question suggests I was less than clear about the problem. The case is where the current chair is not seeking to step down. Presumably he is "willing to step down" since he has no choice. Presumably, the AD has already attempted to teach the current chair how to do a better job (that is always preferable to replacing the chair. I suppose if the current chair is doing a bad enough job, the cost of stalling the working group while you find a replacement is worth it, and since this is a rare case I guess we could deal with it. I suspect that in reality even if the rules require a public call for volunteers, an AD will not be likely to fire a chair unless he knows he has at least one good candidate lined up and willing. This may encourage gaming the system a little. But I may be worrying too much about optimizing a corner case. Getting good input and volunteers for chairing working groups is a good idea. Yours, Joel At 07:19 AM 5/20/2003 -0500, Spencer Dawkins wrote: >Dear Joel, > >I understand your distinction between WG chairs leaving and >"leaving with assistance". > >I've got to ask - how common IS the case where a WG chair is > >(1) not performing to the point where s/he should be replaced, and >(2) not willing to step down? > >If this happens once a year, I'd say "tough, let the AD announce >the impending replacement publically and ask for input anyway". >It's not like anything is getting done in the WG anyway, right? > >If this happens once per IETF per area (for instance), that might be >different. But I'd like to see more openness, and don't want to shut >down an opportunity for more openness to accommodate an rare >case, if it's really rare. > >Spencer > >----- Original Message ----- >From: "Joel M. Halpern" >To: >Sent: Friday, May 16, 2003 9:44 AM >Subject: Re: OPEN ISSUE: WG Chair Selection > > > > There are actually two very different cases. > > For simplicity, let me discuss them both in terms of an existing working > > group (both cases exist for new working groups, but there are other issues > > that cloud things.) > > > > One case is where you have a chair who for one or another reason has >chosen > > to step down. You are going to have to find a new chair. Announcing the > > opening would not in and of itself cause a problem. > > > > The other case is where the AD wants / needs to replace the chair when the > > chair would not on his own step down. (Presume the AD has already > > discussed the causes with the current chair, but probably not the intended > > action.) The AD probably does not want to force the issue until there is >a > > good replacement chair available. As such, making a public announcement > > would be "interesting". > > > > And of course, having two different procedures would mean that one was > > publicising which case actually applied... > > > > We can make personnel management harder if we want, but is that really a > > good idea? > > > > Note that having said all that, it would be really good to have better > > mechanisms for finding chairs, and for finding new blood to serve as > > chairs. Appointing chairs was the part of the AD job I hated when I was > > doing that. I just think it is more complex than the exchange below >suggests. > > > > Yours, > > Joel From problem-statement-bounces@alvestrand.no Tue May 20 11: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 LAA18076 for ; Tue, 20 May 2003 11:35:46 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BDD60625B6; Tue, 20 May 2003 17:38: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 B8E31625A7 for ; Tue, 20 May 2003 17:38:19 +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 IAA59675 for ; Tue, 20 May 2003 08:38:18 -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 LWF0raL2 Tue, 20 May 2003 08:38:17 -0700 (PDT) Message-ID: <055401c31ee5$d83609b0$0300a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: Date: Tue, 20 May 2003 10:38:21 -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: OPEN ISSUE: Standards Track 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 Pekka, My read of the Draft Standard concept was to say "we now have two distinct interoperable implementations, so the specs must be readable, but we haven't seen large-scale interoperation yet, because we haven't seen large-scale deployment yet. Come back in a short period of time, when we have large-scale deployment, and we'll tell you if we killed the Internet". Your note points up a problem we all know about but we haven't written down in the Problem Statement draft - reduced genetic diversity also means that the distinction between Draft Standard and Standard may mean less than previously. I'm thinking of cases like - OSPF - HTTP - closed-system IM, where the same people provide clients and servers as examples where there may not be a lot of additional impact on the Internet after one or two implementations are deployed :-{ ... because some large percentage of the affected systems already run that code. And if these examples aren't the right ones, I bet you can think of a couple more! Spencer ----- Original Message ----- From: "Pekka Savola" To: "Spencer Dawkins" Cc: Sent: Tuesday, May 20, 2003 7:04 AM Subject: Re: OPEN ISSUE: Standards Track > On Tue, 20 May 2003, Spencer Dawkins wrote: > > (1) agree that moving from PS to full Standard is more > > likely interesting than moving from PS to Draft Standard, > > Moving from PS to Draft typically seems to include a lot of tuning of the > spec, including removal of features and adding a few new ones (to > replace/enhance/augment the ones killed for instance), or clarifying ones > (in such a manner that all the old implementation are not compliant). > > If we went from PS to Full, the documents certainly would have to recycled > at the PS stage far, far longer to ensure there are no glitches left. In > addition, requiring more than 2 interop implementations of each feature > should be required if we're to call something a Standard (unless we > redefined the way it is, and engrave the "good old standards" in a > golden plaque). > > > (2) agree that Draft Standard does NOT seem like a more > > impressive name than PS to anyone outside IETF (and > > it's been a while since someone has been confused about > > the difference between "draft standard" and "internet draft > > on the standards track" in my presence, but it has happened). > > True. > > > ----- Original Message ----- > > From: "Brian E Carpenter" > > Cc: > > Sent: Sunday, May 18, 2003 9:53 AM > > Subject: Re: OPEN ISSUE: Standards Track > > > > > > > Eric Rosen wrote: > > > > > > > > Brian> Secondly, this is a case where I think a simple first step may > > > > Brian> help quite a bit: simply merge Draft Standard and Standard > > > > Brian> into a single class, called Standard, but with the criteria > > > > Brian> now used for Draft Standard. > > > > > > > > Brian> Arguments: remove a process step that we basically never use, > > > > Brian> and make the step up from Proposed Standard worth the trouble. > > > > > > > > Could you explain how this makes the step up from PS worth the trouble? > > > > > > Because you know that the effort of documenting the interoperable > > > implementations will be rewarded by immediately getting to the final > > > status, rather than just getting to an intermediate plateau (and one with > > > a very confusing name, since to outsiders it sounds like a step > > backwards). > > > > > > Brian > > > > > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > From problem-statement-bounces@alvestrand.no Tue May 20 11:37: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 LAA18163 for ; Tue, 20 May 2003 11:37:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 19C46625B5; Tue, 20 May 2003 17:40:21 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by eikenes.alvestrand.no (Postfix) with ESMTP id 17A80625A2 for ; Tue, 20 May 2003 17:40:15 +0200 (CEST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])ESMTP id h4KFeCN05409 for ; Tue, 20 May 2003 11:40:13 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10G38D>; Tue, 20 May 2003 17:40:11 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155019C238D@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Spencer Dawkins , problem-statement@alvestrand.no Date: Tue, 20 May 2003 17:40:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 this is just me... but I have difficulty keeping up with this mailing list... (In fact I am some 500 postings behind). So when I see postings like below... I wonder.... Is this really the task of this WG? It seems a problem, but are those core problems or root causes of problems that we need to get on the table? Thanks, Bert > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > Sent: dinsdag 20 mei 2003 17:18 > To: problem-statement@alvestrand.no > Subject: Re: OPEN ISSUE: Standards Track > > > Dear Margaret, > > Well, now that you mention it, I believe these items would > help people find > things: > > - actual use of the STD maturity level, so that many > questions could be > answered by "look at STD n", no matter what has happened to > the underlying > RFCs and errata sheets lately, > > - a severe pruning to Historical of protocols that aren't > still widely used, > > - possibily even a severe pruning to Historical of protocols > that aren't > still being deployed (even if they are still in use), > > - decent STF organization (note that STD 5 includes SIX RFCs > on IP and ICMP. > Conversely, how many Telnet options are there? they're spread > across SIX > STDs). > > - I really like the Updated By/Obsoleted By information you > get when you > SEARCH for a document at http://www.rfc-editor.org/rfcsearch.html, but this information could appear other places, too (in document bodies would be nice, but I know we don't change RFCs without changing RFC numbers). Others? Spencer ----- Original Message ----- From: "Margaret Wasserman" To: "Keith Moore" Cc: ; "Brian E Carpenter" Sent: Tuesday, May 20, 2003 9:42 AM Subject: Re: OPEN ISSUE: Standards Track > > Hi Keith, > > At 10:36 AM 5/20/2003 -0400, Keith Moore wrote: > >one thing I'd like to see us consider is to issue more applicabliity > >statements, errata documents, and implementation notes, rather than > >revising an entire document to accomodate minor changes. we could do that > >even for Standard documents. > > I would agree, if our existing document set was organized to make > it easier for people to find associated documents. Maybe that > is something we can change/fix? > > Margaret From problem-statement-bounces@alvestrand.no Tue May 20 15: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 PAA25593 for ; Tue, 20 May 2003 15:06:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C01CC6233E; Tue, 20 May 2003 21:05:27 +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 240A16225B for ; Tue, 20 May 2003 21:05:25 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4KJ5Nn02373; Tue, 20 May 2003 22:05:23 +0300 Date: Tue, 20 May 2003 22:05:23 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter In-Reply-To: <3ECA49C5.141CE509@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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, 20 May 2003, Brian E Carpenter wrote: > Margaret Wasserman wrote: > > > > Hi Keith, > > > > At 10:36 AM 5/20/2003 -0400, Keith Moore wrote: > > >one thing I'd like to see us consider is to issue more applicabliity > > >statements, errata documents, and implementation notes, rather than > > >revising an entire document to accomodate minor changes. we could do that > > >even for Standard documents. > > > > I would agree, if our existing document set was organized to make > > it easier for people to find associated documents. Maybe that > > is something we can change/fix? > > http://www.rfc-editor.org/rfcxx00.html goes in this direction, but > could use some more snazzy hyperlinking. http://www.ietf.org/ietf/1rfc_index.txt is your friend. Btw, I keep wonder why that's so ridiculously difficult to find. Really. It should be much more prominent. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From problem-statement-bounces@alvestrand.no Tue May 20 15:32: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 PAA27348 for ; Tue, 20 May 2003 15:32:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F3E076233E; Tue, 20 May 2003 21:32:13 +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 DC2986225B for ; Tue, 20 May 2003 21:32:10 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19ICqD-0006MW-00; Tue, 20 May 2003 14:32:05 -0500 Date: Tue, 20 May 2003 15:32:04 -0400 From: John C Klensin To: Spencer Dawkins , "problem-statement@alvestrand.no" Message-ID: <248995196.1053444724@p3.JCK.COM> In-Reply-To: <04d201c31eca$132a1d20$0300a8c0@DFNJGL21> References: <5.1.0.14.2.20030515114433.04767ac8@mail.windriver.com > <5.1.0.14.0.20030516103921.0188a7c8@mail.stevecrocker.com> <04d201c31eca$132a1d20$0300a8c0@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: OPEN ISSUE: 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 Spencer, For perhaps-obvious reasons, sitting IESG members may be a bit reluctant to answer this explicitly. As a variation, let me explain why you may not get an answer that is as clear as you like. In this, or any similar volunteer organization, occasions in which an AD becomes uncomfortable with WG, or WG Chair, performance are fairly common. On average, I'd guess that occurs at least a few times per WG per year, but the tails on that distribution are very long. Normally, depending somewhat on the personalities and style of the particular AD and Chair involved, that discomfort is followed by some combination of advice, encouragement, counselling, education, etc. If enough of those occur enough times, much more direct conversations, sometimes followed by threats, enter the equation. Now, for some WG chair personalities, especially in combination with particularly forceful ADs, there may be very little perceived difference between a "firm and frank exchange of views", especially if it occurs with a few accompanying threats, a demand for a resignation, or an outright firing. In other combinations of cases, the difference is very great indeed. Of course, ADs don't have infinite patience, and probably shouldn't. Frequent instances of discomfort or annoyance are as likely to lead to chair-removal (maybe more likely) as a few seriously bad actions. To complicate things further, I've observed that most ADs try to keep to keep the fact of forcing a Chair out fairly low profile and to try to avoid disrupting WGs more than necessary. So, e.g., what might appear to a WG as "adding a co-chair to help with the load" might actually be a "get someone new in and up to speed so that the disfunctional original chair can be dumped". There are also situations in which an AD concludes that the correct action is to fire a WG, not a chair. But sometimes that results from the conclusion that the chair isn't functioning but that no replacement would be likely to function any better. Again, you can't generally tell from the outside and that is often a good thing (especially when the chair might be perfectly appropriate for managing some other WG, under other circumstances). The "WG isn't getting anything done anyway" point that you make is important. It figures prominently in many of these decisions, but certainly not all of them. To take an extreme case as an example, suppose we had a WG that is working smoothly and effectively and has co-chairs. One of them is function and the other is not. Some ADs are going to be strongly inclined to force the disfunctional Co-chair out as a matter of principle if he or she can't be quickly persuaded to start pulling weight and contributing usefully. Other ADs would be inclined to just let this go, especially if the functional co-Chair isn't complaining, on the "why stir up trouble" or "it isn't broken, don't fix it" principles. I think there aren't any uniformly correct answers and the differences mess up the statistics. Those aren't numbers, but maybe the explanation will help a bit. john --On Tuesday, 20 May, 2003 07:19 -0500 Spencer Dawkins wrote: > I understand your distinction between WG chairs leaving and > "leaving with assistance". > > I've got to ask - how common IS the case where a WG chair is > > (1) not performing to the point where s/he should be replaced, > and (2) not willing to step down? > > If this happens once a year, I'd say "tough, let the AD > announce the impending replacement publically and ask for > input anyway". It's not like anything is getting done in the > WG anyway, right? >... From problem-statement-bounces@alvestrand.no Tue May 20 16:22: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 QAA28850 for ; Tue, 20 May 2003 16:22:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1840F6257F; Tue, 20 May 2003 22:22:00 +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 452DC6225B for ; Tue, 20 May 2003 22:21:53 +0200 (CEST) Received: from adsl-68-120-69-222.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4KKLXN14685 for ; Tue, 20 May 2003 13:21:33 -0700 Date: Tue, 20 May 2003 13:23:52 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <12456768659.20030520132352@brandenburg.com> To: Problem Statement In-Reply-To: <3ECA5B87.27983.1086967@localhost> References: <3ECA572F.2746.F771A5@localhost> <3ECA5B87.27983.1086967@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re 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 Jeanette, >> >Again, I don't think that personal distrust is the main issue here. >> >It is about creating sound preconditions for the reform process. >> What leads you to believe that having a "neutral" person oversee >> the process is necessary to create a sound precondition for the >> reform process? JH> By neutral I mean unbiased and open with regard to the solution space. I JH> don't want to sound trivial, are you expecting a more thorough explanation? Neutral also mean 'not identified with the problematic history'. The IETF community does not have to juggle concerns, when dealing with the new process leader. The person comes in fresh politically, as well as perspective-ly. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue May 20 16:29: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 QAA28978 for ; Tue, 20 May 2003 16:29:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BAD356233E; Tue, 20 May 2003 22:28: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 E6BB26225B for ; Tue, 20 May 2003 22:28: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 h4KKSKk17646; Tue, 20 May 2003 16:28:21 -0400 (EDT) Date: Tue, 20 May 2003 16:28:19 -0400 From: Keith Moore To: Dave Crocker Message-Id: <20030520162819.22348cf3.moore@cs.utk.edu> In-Reply-To: <12456768659.20030520132352@brandenburg.com> References: <3ECA572F.2746.F771A5@localhost> <3ECA5B87.27983.1086967@localhost> <12456768659.20030520132352@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: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > Neutral also mean 'not identified with the problematic history'. in other words, a neophyte. Keith From problem-statement-bounces@alvestrand.no Tue May 20 16:32: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 QAA29164 for ; Tue, 20 May 2003 16:32:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F39E06233E; Tue, 20 May 2003 22:32:15 +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 C00B96225B; Tue, 20 May 2003 22:32:04 +0200 (CEST) Received: from adsl-68-120-69-222.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4KKViN15318; Tue, 20 May 2003 13:31:44 -0700 Date: Tue, 20 May 2003 13:33:58 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <12857373889.20030520133358@brandenburg.com> To: Harald Tveit Alvestrand In-Reply-To: <337667099.1053441771@localhost> References: <160610315.1053356338@p3.JCK.COM> <337667099.1053441771@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: John C Klensin Cc: "problem-statement@alvestrand.no" Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re 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> - no matter what else, the IETF Chair has to follow the work of the problem HTA> WG, the solutions WGs and anything else with that much potential IETF HTA> impact no matter whether he/she is the shepherding AD or not. By that logic, so should all the ADs and IAB members. And you right. But it has nothing to do with the work of actually providing oversight. HTA> - under our current understanding of the Nomcom rules, the IESG cannot add HTA> members at will; new members have to come through the nomcom process. Unless the rules have changed, the IESG decides when it wants to create or eliminate AD slots. For new slot, it then asks Nomcom to find someone to fill it. Is there a problem with this procedure that you were highlighting, with respect to a Process AD slot? HTA> - as Ted has indicated, spinning up into being an effective IESG member is HTA> quite a job, and involves a lot of learning. So if you need an AD to be HTA> effective "day before yesterday", adding a new IESG member isn't optimal. We have a non-optimal situation. A number of folks seem to be spending far more time worrying about the procedural niceties than about the IETF performance problems and the community discontent that brought us to this point. HTA> - one reason why we've gone to 2-AD areas is that there's always SOMEONE to HTA> talk to whose area of responsibility within the IESG is closely related to HTA> yours. You are worred that a single Process AD won't have anyone to talk with about their efforts? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue May 20 16:39: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 QAA29308 for ; Tue, 20 May 2003 16:39:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 296EA6233E; Tue, 20 May 2003 22:39:23 +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 59A5A6225B for ; Tue, 20 May 2003 22:39:19 +0200 (CEST) Received: from [10.30.3.213] (129.46.77.29) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.1b1); Tue, 20 May 2003 15:39:38 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <200305191356.h4JDuUU30442@cichlid.adsl.duke.edu> References: <200305191356.h4JDuUU30442@cichlid.adsl.duke.edu> X-Mailer: Eudora [Macintosh version 6.0a15] Date: Tue, 20 May 2003 13:39:11 -0700 To: Thomas Narten From: Pete Resnick Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: problem-statement@alvestrand.no Subject: Re: Document Blocking (Was: I-D ACTION:draft-ietf-problem-process-00.txt) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 5/19/03 at 9:56 AM -0400, Thomas Narten wrote: >I have to say something here, as this issue keeps being brought up. >Reading this list, one could easily get the idea that the ADs love >to block documents, usually don't have a good reason for doing so >(and thus fall back to procedural tricks), and that the ADs actually >are hostile towards each others with tit-for-tat happening if one AD >blocks a document belonging to someone else. > >That is not the IESG I know or that I would want to be a part of. On the first two points (that ADs "love to block documents" and that they "usually don't have a good reason"), I think that you are simply caricaturing what's been said. I think everyone who has commented on this believes that ADs put discusses on documents almost always with all good intentions, and I think they believe that they usually do it with good reasons. For the most part, people are complaining about the (relatively few) instances where good reasons haven't been given or haven't been communicated well enough to the WG. However, on the last point, that ADs are hostile towards each other, I think you will see in the archive of this list several examples of former ADs saying exactly that. We have had people say that people will put trivial discusses on documents because putting a substantive discuss would get retaliation, that one or two ADs must have the power to stop a document without the other ADs signing on, etc. This isn't coming from folks who've never been on the IESG; it's coming from your former colleagues. Perhaps the current IESG doesn't have these problems; that would be really good. But all that aside, what I think you are seeing overall is: - Past history where it *appears* as if documents have been blackholed by a single AD during IESG review (whether or not it has actually happened); - Not enough experience with the document tracker to dissuade that feeling; - A procedure that the IESG is still using that encourages that feeling The first point I think I don't need to explain. That's the perception, whether true or not. The second point cannot be addressed by saying "let's see if the document tracker solves the problem." The distrust of the IESG already exists. The document tracker will, at times, indicate a discuss by one AD, yes or no objection by everyone else, and an explanation of the discuss that will not be satisfactory to a reader. The third point is the key one: The current procedure of the IESG *reinforces the perception* that one AD can block a document without the buy-in of the rest of the IESG, because on paper the rest of the IESG never buys in. And with the current perception that an AD might (however rarely) vote discuss for spurious reasons, the current policy makes for a bad feeling. For example, below you say: >One of the common "votes" that happens during the telechats is "no >further objection" which formally means "no objection" but in >practice means "I agree with others, but don't have more to add and >don't need to be in the process loop to see that the document gets >fixed". > >Forcing the IESG to have "consensus" or "unanimity" (those words >have been used on this thread) on all discusses procedurally seems >like a high overhead approach for dealing with a particular problem. So maybe the solution here is to formalize "no further objection". That is, if there is a discuss that you agree with, you can vote "concur with discuss". That's the equivalent of voting "no objection" but noting that you actually are on board with the discuss vote. If the IESG comes out with one discuss, one yes, and the rest "concur with discuss", I'd consider that consensus to discuss. However, if you get one discuss, one yes, and the rest "no objection", that's not consensus to discuss. That seems to me no more overhead, but now you've got the ability to make an IESG rule that says, "If there's only one discuss vote and no concur votes, the document passes." And from the outside, you'd be able to see what has happened. With the current process, there's no way to tell whether there's real consensus or it's one of those one-in-a-million "one AD is unreasonably holding things up" instances. >I'd actually like to better understand how much of a REAL problem it >is that individual ADs are impropropely blocking documents with the >"single AD veto". There are many comments that imply it happens "all >the time" I have heard no comments to the effect that "it happens all the time". Again, I think this is a caricature on your part. >and that "everyone has examples". I can think of a few, though only one on which I was smack in the middle of the fray. >But I wonder sometimes if we are all thinking of the same document >from 3 years ago. We can't >fix what happened 3 years ago, but we can fix things that are broken _today_. Even assuming it is extremely rare, leaving a procedure in place that allows it to happen in the future is a problem that needs fixing. Perhaps the current IESG is a wonderful set of folks who would never let such a thing happen. That doesn't mean we should leave the procedure as-is. >>The ADs who think that there is a serious problem with a document >>should convince the rest of the IESG that the document is a bad >>idea. > >This in effect is happening AFAIK. The IESG does support the >security ADs when this happens. It needs to be done publicly. >>The problem with the current process (as I understand it) is that >>it allows documents to be blocked by one or two IESG members >>without the consensus of the group. > >In theory, yes. But in practice? It would be instructive for the >IESG to ask itself where this has happened, and I will bring up the >topic. My sense is very rarely, but I could be wrong. > >But at least some on the community assume this happens often enough >that we need more procedure to prevent it from happening. Concrete >examples would be useful to provide context. Even "very rarely" is enough to change the procedure. >Note: This note might come across as sounding like I don't think >there are any problems that need fixing. There are. But I am >unconvinced that the "one AD veto" is one of the real problems. >Given that at least some in the community appear to think it is a >problem, I'd really appreciate some concrete examples. My suspicion >is that if we look at specifics, the reality may be quite a bit >different than the appearance. I've got to tell you that I'm not terribly sanguine about the results of you asking for "concrete examples" or your "bringing up explicitly within the IESG" the topic of whether other members of the IESG think there are examples of discuss votes that are not supported by the rest of the ADs. We've already been told that past ADs have held their tongues so that there wouldn't be retaliation within the IESG, and I for one don't feel like pointing fingers in public about the situations I've encountered, if only for lack of good taste and for the hurt feelings I suspect it might cause. I can't imagine that you're going to get a bunch of very open responses to your query. Look, we've got a procedure currently that can't publicly distinguish between single discuss votes which are supported by the rest of the IESG and those that aren't. I think the perceptual and trust problems it causes are obvious. I think I have outlined a very low-overhead solution to the problem (whether or not we choose that particular solution). What's the issue here? pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From problem-statement-bounces@alvestrand.no Tue May 20 17: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 RAA01300 for ; Tue, 20 May 2003 17:34:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 75206625A3; Tue, 20 May 2003 23:34:26 +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 1749B6225B; Tue, 20 May 2003 23:34:17 +0200 (CEST) Date: Tue, 20 May 2003 23:20:18 +0200 From: Harald Tveit Alvestrand To: Dave Crocker Message-ID: <368714022.1053472818@localhost> In-Reply-To: <12857373889.20030520133358@brandenburg.com> References: <160610315.1053356338@p3.JCK.COM> <337667099.1053441771@localhost> <12857373889.20030520133358@brandenburg.com> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: "problem-statement@alvestrand.no" Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 20. mai 2003 13:33 -0700 Dave Crocker wrote: > Harald, > > > > HTA> - no matter what else, the IETF Chair has to follow the work of the > >problem WG, the solutions WGs and anything else with that much > >potential IETF impact no matter whether he/she is the shepherding AD > >or not. > > By that logic, so should all the ADs and IAB members. And you right. Yes, and they are. But I follow it even more closely than the others. > > But it has nothing to do with the work of actually providing oversight. It has - oversight cannot be provided without following the work, and a significant portion of the work of oversight is to follow (in, ideally, near real time) discussions like this one. > HTA> - under our current understanding of the Nomcom rules, the IESG > >cannot add members at will; new members have to come through the > >nomcom process. > > Unless the rules have changed, the IESG decides when it wants to create > or eliminate AD slots. For new slot, it then asks Nomcom to find > someone to fill it. > > Is there a problem with this procedure that you were highlighting, with > respect to a Process AD slot? just that it takes time. > HTA> - as Ted has indicated, spinning up into being an effective IESG > >member is quite a job, and involves a lot of learning. So if you > >need an AD to be effective "day before yesterday", adding a new IESG > >member isn't optimal. > > We have a non-optimal situation. A number of folks seem to be spending > far more time worrying about the procedural niceties than about the IETF > performance problems and the community discontent that brought us to > this point. my point was that we either relax the requirement on "operative day before yesterday" or we (perhaps initially) load the hat on some existing IESG member. > > > HTA> - one reason why we've gone to 2-AD areas is that there's always > >SOMEONE to talk to whose area of responsibility within the IESG is > >closely related to yours. > > You are worred that a single Process AD won't have anyone to talk with > about their efforts? no - I was thinking about adding another AD to the General area - either assigning the hat to an existing IESG member or asking Nomcom to fill a new slot. Harald From problem-statement-bounces@alvestrand.no Tue May 20 17:51: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 RAA01558 for ; Tue, 20 May 2003 17:51:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B20E66233E; Tue, 20 May 2003 23:50:50 +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 F18BD6225B for ; Tue, 20 May 2003 23:50:48 +0200 (CEST) Received: from adsl-68-120-69-222.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4KLoSN19389; Tue, 20 May 2003 14:50:28 -0700 Date: Tue, 20 May 2003 14:52:56 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <13962112573.20030520145256@brandenburg.com> To: narten@us.ibm.com In-Reply-To: References: <200305191356.h4JDuUU30442@cichlid.adsl.duke.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Document Blocking (Was: I-D ACTION:draft-ietf-problem-process-00.txt) 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 Thomas, >>I'd actually like to better understand how much of a REAL problem it >>is that individual ADs are impropropely blocking documents with the >>"single AD veto". There are many comments that imply it happens "all >>the time" PR> I have heard no comments to the effect that "it happens all the PR> time". Again, I think this is a caricature on your part. You have done us the service of offering your candid views about the current discussion. He has shared his sense of the realities inside the IESG and his reactions to the public discussion. For these, I am appreciative. The problem with being candid is that it invites others to be candid. So I hope you won't mind, Thomas, if I return the favor. My perception of the Yokohama plenary was of two, very pronounced phenomena. One was of considerable community discontent about the current operation of the IETF and notably of the IESG. (I'm *always* disgruntled, my own criticisms don't matter much. But when I see quite a few other IETF folks disgruntled, it's another matter.) The other phenomenon of note was a frankly defensive reaction from most of the IESG. Please forgive me noting that Pete's assessment of your note matches mine: You seem to be reacting to things that have neither been said nor implied, and I am pretty sure they are not felt. Folks are generally trying to be very careful in what *is* said. Folks are generally trying very hard to avoid making personal criticisms. Folks are generally trying very hard to make constructive suggestions, including suggesting compromise paths. (A reminder: Most of the current problems have a long history, beyond any particular individuals. Individuals do the actions, but the problems appear to be structural. However, individuals who have been participating in the problem have an inherent conflict of interest, if they are in charge of the change process.) When someone is part of group that is the focus of community disgruntlement, it is easy to get defensive, to misinterpret what is said, and generally to entrench into a siege mentality. Please don't. The most notable thing about the Kobe "revolution" is how little was actually changed. We need to make changes now, but we need to make as few as possible. This is only possible if the effort to make change is pursued honestly, as well as constructively. Caricaturizing core concerns, ignoring core concerns, or trivializing the difficulties of the change effort will not achieve the results the community wants. The effort is not about nit-picking adherence to process details. It is about problems with productivity and utility. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue May 20 18:12: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 SAA03046 for ; Tue, 20 May 2003 18:12:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2B83E6233E; Wed, 21 May 2003 00:11:47 +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 0AAA16225B; Wed, 21 May 2003 00:11:39 +0200 (CEST) Received: from adsl-68-120-69-222.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4KMBJN20321; Tue, 20 May 2003 15:11:19 -0700 Date: Tue, 20 May 2003 15:13:49 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <16763365594.20030520151349@brandenburg.com> To: Harald Tveit Alvestrand In-Reply-To: <368714022.1053472818@localhost> References: <160610315.1053356338@p3.JCK.COM> <337667099.1053441771@localhost> <12857373889.20030520133358@brandenburg.com> <368714022.1053472818@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "problem-statement@alvestrand.no" Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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> Yes, and they are. But I follow it even more closely than the others. >> But it has nothing to do with the work of actually providing oversight. HTA> It has - oversight cannot be provided without following the work, and a HTA> significant portion of the work of oversight is to follow (in, ideally, HTA> near real time) discussions like this one. I started to write a "that's not my point" response to your note but suddenly realized that this exchange is frankly a distraction. This is not a company. The employees are not the final authority in a company. So we should not automatically apply corporate management style to these IETF efforts. As already noted, even with company change, independent change agents are often brought in. We have a disgruntled community. We have productivity problems. Some changes are underway, including finally getting better tracking software. All that is fine, but it has literally nothing at all to do with the core problems. The core problems are deep and long-standing. They have to do with transparency, accountability, responsiveness and conflicting responsibilities. With Kobe we had constructive change within a few months. Now we are 10 months after Kobe and simple, reasonable suggestions for independent management of the change effort are being resisted rather vigorously. It really is time to change this. John K. has made an extremely constructive proposal as a compromise between concerns over enjoying the safety of existing process, versus the need for independence in the change effort. Please note the word *compromise*. It needs to be present in far more of the postings. Having any sitting member of the IESG directly in charge of this effort is a good way to make sure the effort is not credible. It does not matter who that person is; it does not matter what the community thinks of them. Having any such person in charge is an inherent conflict of interest. The community has an institutional concern and it is not reasonable for anyone from that institution to manage the change effort. John's proposal places a *new* person into that same institution, with the sole mandate to pursue the necessary structural change. Placing them into the IESG creates some risk with credibility, but at the benefit of ensuring use of existing process and good access to current management. HTA> my point was that we either relax the requirement on "operative day before HTA> yesterday" or we (perhaps initially) load the hat on some existing IESG HTA> member. To repeat: We are already 10 months after Kobe, with no direct changes yet underway. The current effort is already a long way from "operative day before yesterday." d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue May 20 18:34: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 SAA03905 for ; Tue, 20 May 2003 18:34:44 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8E488623CD; Wed, 21 May 2003 00:34:13 +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 B8691622AC; Wed, 21 May 2003 00:34:11 +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 19IFgM-0006Wg-00; Tue, 20 May 2003 15:34:06 -0700 Date: Tue, 20 May 2003 18:33:04 -0400 From: Keith Moore To: Dave Crocker Message-Id: <20030520183304.107fe02f.moore@cs.utk.edu> In-Reply-To: <16763365594.20030520151349@brandenburg.com> References: <160610315.1053356338@p3.JCK.COM> <337667099.1053441771@localhost> <12857373889.20030520133358@brandenburg.com> <368714022.1053472818@localhost> <16763365594.20030520151349@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: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 have a disgruntled community. We have productivity problems. > > Some changes are underway, including finally getting better tracking > software. All that is fine, but it has literally nothing at all to do > with the core problems. The core problems are deep and long-standing. > They have to do with transparency, accountability, responsiveness and > conflicting responsibilities. IMHO the core problem is the inability of many working groups to produce technically sound output in a timely manner. Trying to blame this on IESG is counterproductive. From problem-statement-bounces@alvestrand.no Tue May 20 18:42: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 SAA04225 for ; Tue, 20 May 2003 18:42:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 327A96233E; Wed, 21 May 2003 00:41:46 +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 CD8A9622AC for ; Wed, 21 May 2003 00:41:40 +0200 (CEST) Received: from adsl-68-120-69-222.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4KMfLN21870; Tue, 20 May 2003 15:41:21 -0700 Date: Tue, 20 May 2003 15:43:49 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <4565165462.20030520154349@brandenburg.com> To: "Spencer Dawkins" In-Reply-To: <04c701c31ec8$1efb8b40$0300a8c0@DFNJGL21> References: <5.1.0.14.2.20030515114433.04767ac8@mail.windriver.com> <4517643810.20030516200534@brandenburg.com> <04c701c31ec8$1efb8b40$0300a8c0@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: WG Chair Selection 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 Spencer, SD> I believe that this thread was actually about the general SD> process of selecting a chair for any WG, not about the SD> mechanisms we're discussing for choosing leadership SD> for the Solutions WG (we seem to be converging on a oh. SD> "less change is better than more change" for the Solutions SD> AD and WG chair(s), not if it establishes an inherent conflict of interest we aren't. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue May 20 19:03: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 TAA04877 for ; Tue, 20 May 2003 19:03:14 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BD1A1623CD; Wed, 21 May 2003 01:02:44 +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 BAA0D6233E for ; Wed, 21 May 2003 01:02: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 QAA50484 for ; Tue, 20 May 2003 16:02: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 88D0eCJ2 Tue, 20 May 2003 16:02:40 -0700 (PDT) Message-ID: <06ae01c31f23$ecab1fa0$0300a8c0@DFNJGL21> From: "Spencer Dawkins" Cc: References: <5.1.0.14.2.20030515114433.04767ac8@mail.windriver.com> <4517643810.20030516200534@brandenburg.com> <04c701c31ec8$1efb8b40$0300a8c0@DFNJGL21> <4565165462.20030520154349@brandenburg.com> Date: Tue, 20 May 2003 18:02:44 -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: Solutions WG chair selection (was: Re: OPEN ISSUE: 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 Hi, Dave, My apologies for appearing to pronounce convergence, (at least I never used the word "consensus"). My attention was mostly focused on an "Open Issue" from process-00, and I was trying to say "... although some of us would like for the Solutions WG chair selection to be done differently". It wasn't my intention to try to steer the conversation on the Solutions WG chair selection. Poor choice of words. I now return you to the capable hands of Melinda and Avri! Dear All, I'd still like to hear comments on whether the way we select working group chairs IN GENERAL is a "problem". This was a question in section 4.5 of the current version of the process draft, and the editorial team was looking for input - hence Margaret's posting. I tweaked the subject line, so we can start trying to tell the two threads apart when we look back... Spencer ----- Original Message ----- From: "Dave Crocker" To: "Spencer Dawkins" Cc: Sent: Tuesday, May 20, 2003 5:43 PM Subject: Re: OPEN ISSUE: WG Chair Selection > Spencer, > > SD> I believe that this thread was actually about the general > SD> process of selecting a chair for any WG, not about the > SD> mechanisms we're discussing for choosing leadership > SD> for the Solutions WG (we seem to be converging on a > > oh. > > > SD> "less change is better than more change" for the Solutions > SD> AD and WG chair(s), > > not if it establishes an inherent conflict of interest we aren't. > > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > From problem-statement-bounces@alvestrand.no Tue May 20 19:11: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 TAA05176 for ; Tue, 20 May 2003 19:11:29 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0B77762594; Wed, 21 May 2003 01:10:59 +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 6A4046233E; Wed, 21 May 2003 01:10:56 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19IGFy-0007gz-00; Tue, 20 May 2003 18:10:54 -0500 Date: Tue, 20 May 2003 19:10:54 -0400 From: John C Klensin To: Keith Moore , Dave Crocker Message-ID: <262124304.1053457854@p3.JCK.COM> In-Reply-To: <20030520183304.107fe02f.moore@cs.utk.edu> References: <160610315.1053356338@p3.JCK.COM> <337667099.1053441771@localhost> <12857373889.20030520133358@brandenburg.com> <368714022.1053472818@localhost> <16763365594.20030520151349@brandenburg.com> <20030520183304.107fe02f.moore@cs.utk.edu> 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: "harald@alvestrand.no" Cc: "problem-statement@alvestrand.no" Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, 20 May, 2003 18:33 -0400 Keith Moore wrote: >> We have a disgruntled community. We have productivity >> problems. >> >> Some changes are underway, including finally getting better >> tracking software. All that is fine, but it has literally >> nothing at all to do with the core problems. The core >> problems are deep and long-standing. They have to do with >> transparency, accountability, responsiveness and conflicting >> responsibilities. > > IMHO the core problem is the inability of many working groups > to produce technically sound output in a timely manner. > Trying to blame this on IESG is counterproductive. Keith and Dave, Neither of you really need to be reminded of this, but the issue isn't placing blame (and I didn't read "blame the IESG" into Dave's note). Getting technically sound standards out the door in a reasonable amount of time is, under our current procedures and working models, a partnership and shared responsibility between the IESG, the individual ADs, WG leadership, and WG participants. If we aren't succeeding in the goal of getting technically sound documents through the system and out the door in a reasonable time, we need to be pursuing _all_ of the aspects of our way of doing things that might cure that problem -- or we need to adjust our expectations. Fortunately or unfortunately, it is a good deal easier to think about difficulties and ways in which the management and oversight structures might be tuned than it is to think about finding a mechanism, or the right variety of pixie dust, that would cause all WGs to require sufficient wisdom, insight, and resources to avoid the need for review and coordination. We should identify the problems and expectations, fix what we can, and figure out how to adjust our expectations to match what we cannot fix. "Blame the IESG" isn't a constructive part of the puzzle, IMO, although "blame some things that IESG does or some procedures that IESG has" or "blame some ways in which WGs are constituted and work" should both, again IMO, be fair game. john From problem-statement-bounces@alvestrand.no Tue May 20 19:26: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 TAA05572 for ; Tue, 20 May 2003 19:26:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BB4D8625A0; Wed, 21 May 2003 01:26:01 +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 84FE262598; Wed, 21 May 2003 01:25:59 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=cs.utk.edu) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19IGUT-0004IF-00; Tue, 20 May 2003 16:25:53 -0700 Date: Tue, 20 May 2003 19:26:00 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: John C Klensin From: Keith Moore In-Reply-To: <262124304.1053457854@p3.JCK.COM> Message-Id: <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: Dave Crocker Cc: "harald@alvestrand.no" Cc: Keith Moore Cc: "problem-statement@alvestrand.no" Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > Neither of you really need to be reminded of this, but the issue isn't > placing blame agreed. but we seem to be spending most of our energy concentrating on what's wrong with IESG and how to fix it, and very little energy trying to understand what is wrong with working groups and how to fix them. working groups that produce technically sound results rarely have problems with IESG. From problem-statement-bounces@alvestrand.no Tue May 20 19:28: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 TAA05651 for ; Tue, 20 May 2003 19:28:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4973C625A7; Wed, 21 May 2003 01:27:49 +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 B96CE625A3; Wed, 21 May 2003 01:27:06 +0200 (CEST) Message-ID: <048201c31f27$1c3e81f0$236015ac@DCLKEMPFTP> From: "James Kempf" To: "Dave Crocker" , "Harald Tveit Alvestrand" References: <160610315.1053356338@p3.JCK.COM> <337667099.1053441771@localhost> <12857373889.20030520133358@brandenburg.com> <368714022.1053472818@localhost> <16763365594.20030520151349@brandenburg.com> Date: Tue, 20 May 2003 16:25:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 think you hit this right on. The issue has to do with the community's perception's in and since Yokohama and the lack of progress since Yokohama (I read the 10 months below as Yokohama not Kobe). John K.'s proposal is a good compromise between the need for independence and the desire for something that fits the IETF community's process. Of course, we need an individual who can make this work, and getting the right person is always important, but I think we need to really decide on something that looks like it will work and get started on solutions. jak ----- Original Message ----- From: "Dave Crocker" To: "Harald Tveit Alvestrand" Cc: Sent: Tuesday, May 20, 2003 3:13 PM Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re > Harald, > > HTA> Yes, and they are. But I follow it even more closely than the others. > > >> But it has nothing to do with the work of actually providing oversight. > > HTA> It has - oversight cannot be provided without following the work, and a > HTA> significant portion of the work of oversight is to follow (in, ideally, > HTA> near real time) discussions like this one. > > > I started to write a "that's not my point" response to your note but > suddenly realized that this exchange is frankly a distraction. > > > This is not a company. The employees are not the final authority in a > company. So we should not automatically apply corporate management > style to these IETF efforts. As already noted, even with company change, > independent change agents are often brought in. > > > We have a disgruntled community. We have productivity problems. > > Some changes are underway, including finally getting better tracking > software. All that is fine, but it has literally nothing at all to do > with the core problems. The core problems are deep and long-standing. > They have to do with transparency, accountability, responsiveness and > conflicting responsibilities. > > With Kobe we had constructive change within a few months. Now we are 10 > months after Kobe and simple, reasonable suggestions for independent > management of the change effort are being resisted rather vigorously. > > It really is time to change this. > > John K. has made an extremely constructive proposal as a compromise > between concerns over enjoying the safety of existing process, versus > the need for independence in the change effort. > > Please note the word *compromise*. It needs to be present in far more > of the postings. > > Having any sitting member of the IESG directly in charge of this > effort is a good way to make sure the effort is not credible. > > It does not matter who that person is; it does not matter what the > community thinks of them. Having any such person in charge is an > inherent conflict of interest. > > The community has an institutional concern and it is not reasonable > for anyone from that institution to manage the change effort. > > John's proposal places a *new* person into that same institution, with > the sole mandate to pursue the necessary structural change. > > Placing them into the IESG creates some risk with credibility, but at > the benefit of ensuring use of existing process and good access to > current management. > > > HTA> my point was that we either relax the requirement on "operative day before > HTA> yesterday" or we (perhaps initially) load the hat on some existing IESG > HTA> member. > > To repeat: We are already 10 months after Kobe, with no direct changes > yet underway. > > The current effort is already a long way from "operative day before > yesterday." > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > > From problem-statement-bounces@alvestrand.no Tue May 20 19:34: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 TAA05827 for ; Tue, 20 May 2003 19:34:52 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E691362598; Wed, 21 May 2003 01:34:22 +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 AF0D562594 for ; Wed, 21 May 2003 01:34:19 +0200 (CEST) Received: from adsl-68-120-69-222.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4KNXwN24362; Tue, 20 May 2003 16:33:58 -0700 Date: Tue, 20 May 2003 16:36:24 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <3168320519.20030520163624@brandenburg.com> To: John C Klensin In-Reply-To: <262124304.1053457854@p3.JCK.COM> References: <160610315.1053356338@p3.JCK.COM> <12857373889.20030520133358@brandenburg.com> <16763365594.20030520151349@brandenburg.com> <262124304.1053457854@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: Charters, "normal process" versus ISOC, etc. (was: Re 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 JCK> We should identify the problems and expectations, fix what we JCK> can, and figure out how to adjust our expectations to match what JCK> we cannot fix. "Blame the IESG" isn't a constructive part of JCK> the puzzle, IMO, although "blame some things that IESG does or JCK> some procedures that IESG has" or "blame some ways in which WGs JCK> are constituted and work" should both, again IMO, be fair game. very nicely said. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue May 20 19:50: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 TAA06255 for ; Tue, 20 May 2003 19:50:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5536B62573; Wed, 21 May 2003 01:49: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 3DC2F61DEC; Wed, 21 May 2003 01:49:28 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19IGrG-0007t8-00; Tue, 20 May 2003 18:49:26 -0500 Date: Tue, 20 May 2003 19:49:26 -0400 From: John C Klensin To: Keith Moore Message-ID: <264436479.1053460166@p3.JCK.COM> In-Reply-To: <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> References: <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> 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: Dave Crocker Cc: "harald@alvestrand.no" Cc: "problem-statement@alvestrand.no" Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, Two brief observations... --On Tuesday, 20 May, 2003 19:26 -0400 Keith Moore wrote: >> Neither of you really need to be reminded of this, but the >> issue isn't placing blame > > agreed. but we seem to be spending most of our energy > concentrating on what's wrong with IESG and how to fix it, and > very little energy trying to understand what is wrong with > working groups and how to fix them. I agree, and agree that this is a problem. But many members of the set of non-pixie-dust possible fixes for WG problems come down to looking at how they are chartered, structured, and managed. To the extent to which we are looking at WG problems that involve those sorts of solution spaces, the remedies, if not the problems, lie again in the vicinity of the IESG... at least within our current overall structure. > working groups that produce technically sound results rarely > have problems with IESG. If "problems" includes delays in getting those results approved and published --delays that are longer than those WGs consider appropriate-- then I think several people have made comments on this list that disagree with you. Some have claimed that this is getting better and that the improvements are due to procedural changes that the IESG has made spontaneously. I don't have nearly enough first-hand information to support or deny either of those claims, although both would make me happy if they were true. Conversely, if there is a disconnect between the time-to-publish expectations of a WG that has produced a technically (and editorially) sound result and the length of time it takes the IESG and the RFC Editor to get a document out, then that would fall into the "adjusting expectations" category. And, in at least some cases, that category may turn out to be as important as "fixing things". But, with the understanding that this isn't what you said, there is clearly a perception that WGs that produce results that they consider technically sound (or at least "good enough") quite often see delays in the IESG that they consider unreasonable. john From problem-statement-bounces@alvestrand.no Tue May 20 20: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 UAA06749 for ; Tue, 20 May 2003 20:12:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A3BE162598; Wed, 21 May 2003 02:11:59 +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 E9B8162573; Wed, 21 May 2003 02:11:48 +0200 (CEST) Received: from ppp-67-126-241-118.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4L0BQN26121; Tue, 20 May 2003 17:11:26 -0700 Date: Tue, 20 May 2003 17:13:47 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1411052583.20030520171347@brandenburg.com> To: "James Kempf" In-Reply-To: <048201c31f27$1c3e81f0$236015ac@DCLKEMPFTP> References: <160610315.1053356338@p3.JCK.COM> <337667099.1053441771@localhost> <12857373889.20030520133358@brandenburg.com> <368714022.1053472818@localhost> <16763365594.20030520151349@brandenburg.com> <048201c31f27$1c3e81f0$236015ac@DCLKEMPFTP> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Harald Tveit Alvestrand Cc: problem-statement@alvestrand.no Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re 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> Yokohama and the lack of progress since Yokohama (I read the 10 months JK> below as Yokohama not Kobe). oh my. how Freudian of me. yes, I meant Yokohama, even though the beef isn't nearly as good. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue May 20 20:17: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 UAA06864 for ; Tue, 20 May 2003 20:17:27 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6AC3B62573; Wed, 21 May 2003 02:16:58 +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 3A6E061DEC for ; Wed, 21 May 2003 02:16:52 +0200 (CEST) Received: from ppp-67-126-241-118.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4L0GWN26281; Tue, 20 May 2003 17:16:32 -0700 Date: Tue, 20 May 2003 17:19:03 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <741367957.20030520171903@brandenburg.com> To: Keith Moore In-Reply-To: <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> References: <6AE98D44-8B1A-11D7-91A9-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: Charters, "normal process" versus ISOC, etc. (was: Re 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, KM> agreed. but we seem to be spending most of our energy concentrating on KM> what's wrong with IESG and how to fix it, and very little energy trying KM> to understand what is wrong with working groups and how to fix them. both of the I-Ds that have been produced discuss rather more than just the IESG. in fact we were rather pointed to make sure it discussed working group issues rather than just IESG issue. I believe what might seem like excessive online discussion about the IESG, right now, is coming from the fact that efforts to get independent management of the change process are being met with considerable resistance... notably from the IESG. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue May 20 20: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 UAA07326 for ; Tue, 20 May 2003 20:44:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 64E3562573; Wed, 21 May 2003 02:44: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 8F28462206 for ; Wed, 21 May 2003 02:43:51 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.2]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA09242; Tue, 20 May 2003 17:43:34 -0700 (PDT) Message-Id: <5.1.0.14.2.20030520202101.03c85b10@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 20 May 2003 20:35:27 -0400 To: Dave Crocker From: Margaret Wasserman In-Reply-To: <741367957.20030520171903@brandenburg.com> References: <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "problem-statement@alvestrand.no" Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 05:19 PM 5/20/2003 -0700, Dave Crocker wrote: >I believe what might seem like excessive online discussion about the >IESG, right now, is coming from the fact that efforts to get independent >management of the change process are being met with considerable >resistance... notably from the IESG. I don't believe that this fairly characterizes the discussion. I think that there is a big difference between raising concerns with a proposal and/or suggesting alternatives and resisting efforts to get independent management of the change process. I raised some concerns with John's proposal... John didn't claim that his proposal was the only possible compromise, or that he had perfected it, so I consider it reasonable to raise concerns. There seems to be some assumption that, if we open a new Process AD position, the nomcom will pick someone who has never served on the IAB or IESG (and is therefore "untainted"). [Of course, none of us can control the criteria that the Nomcom uses to select a Process AD, so they could choose a current sitting IESG or IAB member, and back-fill. Or, they could choose a recent IESG member. But, the assumption seems to be that they would choose, as Keith put it, a "neophyte".] I pointed out that this would also have the downside of having the process run by someone who is new to the IESG processes. I've been told that it takes 6+ months to come up-to-speed in the IESG, and I believe that. So, we have a situation where there may be a trade-off between the speed/efficiency of this process and the desire to have it run by a "neutral" party. I think that perfectly reasonable could associate different priorities with these two properties. In one of Harald's recent messages, he alluded to a different possible compromise... We could suggest that the IESG add another AD to the General area and keep the work there. If this was done so that it added a seat, instead of adding a new "hat" to an existing AD, we could have one experienced AD and one new appointee running the General area. This would also fix other concerns (under discussion on the poised list) with having a single-AD area run by the IETF chair. What do folks think of that idea? Margaret From problem-statement-bounces@alvestrand.no Tue May 20 22: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 WAA09119 for ; Tue, 20 May 2003 22:40:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3C40F6259C; Wed, 21 May 2003 04:38: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 ED30A62573 for ; Wed, 21 May 2003 04:38:22 +0200 (CEST) Received: from ppp-67-126-241-118.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4L2c0N32220; Tue, 20 May 2003 19:38:00 -0700 Date: Tue, 20 May 2003 19:40:32 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1609856713.20030520194032@brandenburg.com> To: Margaret Wasserman In-Reply-To: <5.1.0.14.2.20030520202101.03c85b10@mail.windriver.com> References: <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> <5.1.0.14.2.20030520202101.03c85b10@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: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: dcrocker@brandenburg.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 Margaret, >>I believe what might seem like excessive online discussion about the >>IESG, right now, is coming from the fact that efforts to get independent >>management of the change process are being met with considerable >>resistance... notably from the IESG. MW> I don't believe that this fairly characterizes the discussion. MW> I think that there is a big difference between raising MW> concerns with a proposal and/or suggesting alternatives and MW> resisting efforts to get independent management of the change MW> process. You might want to review the postings from IESG members. The direction of the concerns has been quite consistent. You may also want to re-read my posting. Yes, non-IESG people have also raised questions about John's proposal, and about the ISOC alternative. I said "notably". I did not say "xclusively". MW> There seems to be some assumption that, if we open a new MW> Process AD position, the nomcom will pick someone who has never MW> served on the IAB or IESG (and is therefore "untainted"). There are all sorts of "assumptions" being made. Oddly the assumptions all seem to presume that John's proposal is not viable. MW> I pointed out that this would also have the downside MW> of having the process run by someone who is new to the MW> IESG processes. I've been told that it takes 6+ months MW> to come up-to-speed in the IESG, and I believe that. And were this a normal AD slot, that might be important. It isn't, so it isn't. Then, of course, there is the minor likelihood that whoever is selected actually would be someone with quite a bit of IETF experience. Gosh. What a thought. MW> So, we have a situation where there may be a trade-off MW> between the speed/efficiency of this process and the desire MW> to have it run by a "neutral" party. Please forgive me for noting that raising an arbitrary concern will almost always create the appearance of a trade-off. You see, the nice thing about such carefully selected concerns is that they ignore other factors that are likely to be brought into the selection process. MW> We could suggest that the IESG add another AD to the General MW> area and keep the work there. The need is not for managing the "general area". The need is for managing a change process that is credible to the community. When you pursue alternative proposals, it would help for this concern about credibility and independence to be given as much credence as whether the bureaucratic niceties are comfortable to the IESG. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Tue May 20 23:36: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 XAA09956 for ; Tue, 20 May 2003 23:36:29 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3741C625A1; Wed, 21 May 2003 05:35: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 54BAB6259C for ; Wed, 21 May 2003 05:35:50 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19IKOL-0009IW-00; Tue, 20 May 2003 22:35:49 -0500 Date: Tue, 20 May 2003 23:35:49 -0400 From: John C Klensin To: Margaret Wasserman Message-ID: <278018759.1053473749@p3.JCK.COM> In-Reply-To: <5.1.0.14.2.20030520202101.03c85b10@mail.windriver.com> References: <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> <5.1.0.14.2.20030520202101.03c85b10@mail.windriver.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: IESG spin-up time (was: Re: Charters, "normal process" versus ISOC, etc. (was: Re) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, 20 May, 2003 20:35 -0400 Margaret Wasserman wrote: > I pointed out that this would also have the downside > of having the process run by someone who is new to the > IESG processes. I've been told that it takes 6+ months > to come up-to-speed in the IESG, and I believe that. Ok. This has now been said several times. Ignoring whether or not it applies to a possible "process" position or not, I think it represents a problem that belongs on the list and that isn't, as far as I can tell, there. ADs serve a 24 month [initial] term. Under our present system, we expect them to hit the ground running, regardless of their prior experience. If they really take six months to come up to speed, it implies, first, that any area in which an AD is replaced is going to be running at reduced capability for half a year, which is a huge hit. And the AD will be disfunctional, or at least below acceptable function levels, for fully one fourth of the initial term. I suggest that, if this is what is happening, it is inefficient to the point of silliness and that we should get it on the list as a problem and build a framework for considering alternatives. Examples: Should we expand the initial term to three years so that the spin-up time is 1/6 of the term, rather than 1/4? Should we try to alter the transition process from "atomic handover after the plenary of the first meeting of the year" to some flavor of "AD Elect" or "understudy" model that would permit most or all of that six months of acclimatization to before the new AD actually had any WG management responsibilities? If we see a six-month startup period as real and a problem, there are a number of low-disruption ways get around that and to meet him again. john From problem-statement-bounces@alvestrand.no Wed May 21 03: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 DAA11082 for ; Wed, 21 May 2003 03:35:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0FE29625A0; Wed, 21 May 2003 09:35:15 +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 2560562598 for ; Wed, 21 May 2003 09:35:11 +0200 (CEST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])h4L7Z8b01020 for ; Wed, 21 May 2003 02:35:08 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com ; Wed, 21 May 2003 02:35:08 -0500 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 21 May 2003 00:35:07 -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: Wed, 21 May 2003 00:35:06 -0700 Message-ID: <4D7B558499107545BB45044C63822DDEEBDCDC@mvebe001.americas.nokia.com> Thread-Topic: OPEN ISSUE: WG Chair Selection Thread-Index: AcMfBp8tw7ne4lN5SDGNLJ94M2qefAAY4ccA From: To: , , X-OriginalArrivalTime: 21 May 2003 07:35:07.0952 (UTC) FILETIME=[80CF0B00:01C31F6B] Subject: RE: OPEN ISSUE: 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA11082 Hi John, thanks for your clarification of this (I have to say) peculiar process. I started wondering a bit about a few things. You said that performance issues are fairly common - a few times per WG per year. That does sound awful lot to me. How is this performance actually measured? I mean, the milestones are generally totally off anyways. Does every AD have their own measures? Secondly, you say that a non-performing WG could be fired totally (closed?). Would that mean that the WG had already no meeting, and no participants on the mailing list, or how is it determined that the WG is performing so poorly that it can be closed down? I just wonder, if there such occurring performance problems maybe the WGs, or the chairs are not alone anymore to blame, but the responsibility goes already to the ADs that are managing the WG. If there needs to be a change very often, maybe the selection criteria of the WG chairs is wrong, or the management is inadequate. Cheers, Jonne. > -----Original Message----- > From: ext John C Klensin [mailto:john-ietf@jck.com] > Sent: Tuesday, May 20, 2003 12:32 PM > To: Spencer Dawkins; problem-statement@alvestrand.no > Subject: Re: OPEN ISSUE: WG Chair Selection > > > Spencer, > > For perhaps-obvious reasons, sitting IESG members may be a bit > reluctant to answer this explicitly. As a variation, let me > explain why you may not get an answer that is as clear as you > like. > > In this, or any similar volunteer organization, occasions in > which an AD becomes uncomfortable with WG, or WG Chair, > performance are fairly common. On average, I'd guess that > occurs at least a few times per WG per year, but the tails on > that distribution are very long. Normally, depending somewhat > on the personalities and style of the particular AD and Chair > involved, that discomfort is followed by some combination of > advice, encouragement, counselling, education, etc. If enough > of those occur enough times, much more direct conversations, > sometimes followed by threats, enter the equation. Now, for > some WG chair personalities, especially in combination with > particularly forceful ADs, there may be very little perceived > difference between a "firm and frank exchange of views", > especially if it occurs with a few accompanying threats, a > demand for a resignation, or an outright firing. In other > combinations of cases, the difference is very great indeed. > > Of course, ADs don't have infinite patience, and probably > shouldn't. Frequent instances of discomfort or annoyance are as > likely to lead to chair-removal (maybe more likely) as a few > seriously bad actions. > > To complicate things further, I've observed that most ADs try to > keep to keep the fact of forcing a Chair out fairly low profile > and to try to avoid disrupting WGs more than necessary. So, > e.g., what might appear to a WG as "adding a co-chair to help > with the load" might actually be a "get someone new in and up to > speed so that the disfunctional original chair can be dumped". > > There are also situations in which an AD concludes that the > correct action is to fire a WG, not a chair. But sometimes that > results from the conclusion that the chair isn't functioning but > that no replacement would be likely to function any better. > Again, you can't generally tell from the outside and that is > often a good thing (especially when the chair might be perfectly > appropriate for managing some other WG, under other > circumstances). > > The "WG isn't getting anything done anyway" point that you make > is important. It figures prominently in many of these > decisions, but certainly not all of them. To take an extreme > case as an example, suppose we had a WG that is working smoothly > and effectively and has co-chairs. One of them is function and > the other is not. Some ADs are going to be strongly inclined to > force the disfunctional Co-chair out as a matter of principle if > he or she can't be quickly persuaded to start pulling weight and > contributing usefully. Other ADs would be inclined to just let > this go, especially if the functional co-Chair isn't > complaining, on the "why stir up trouble" or "it isn't broken, > don't fix it" principles. I think there aren't any uniformly > correct answers and the differences mess up the statistics. > > Those aren't numbers, but maybe the explanation will help a bit. > > john > > > > --On Tuesday, 20 May, 2003 07:19 -0500 Spencer Dawkins > wrote: > > > I understand your distinction between WG chairs leaving and > > "leaving with assistance". > > > > I've got to ask - how common IS the case where a WG chair is > > > > (1) not performing to the point where s/he should be replaced, > > and (2) not willing to step down? > > > > If this happens once a year, I'd say "tough, let the AD > > announce the impending replacement publically and ask for > > input anyway". It's not like anything is getting done in the > > WG anyway, right? > >... > > From problem-statement-bounces@alvestrand.no Wed May 21 04:03: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 EAA11530 for ; Wed, 21 May 2003 04:03:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3F48D62598; Wed, 21 May 2003 10:03:19 +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 E357262593 for ; Wed, 21 May 2003 10:03:11 +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 11EBEAF7B; Wed, 21 May 2003 04:02:56 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 21 May 2003 04:02: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: Wed, 21 May 2003 04:02:56 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241288@tayexc13.americas.cpqcorp.net> Thread-Topic: OPEN ISSUE: WG Chair Selection Thread-Index: AcMfBp8tw7ne4lN5SDGNLJ94M2qefAAY4ccAAADjt6A= From: "Bound, Jim" To: , , , X-OriginalArrivalTime: 21 May 2003 08:02:56.0789 (UTC) FILETIME=[63835C50:01C31F6F] Subject: RE: OPEN ISSUE: 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA11530 I wonder too often but then at the end of the day the solution is to just feed losers and liars to pigs :--), but explanation and clarity must be provided to the community or else this is all irrelevant and discourse Aristotle made clear in Thomas Aquinas Summa Theologica accounting a false action of those who do not have the courage to defend that which they actually love and care about. The IETF is completely messed up and this list is depicting that clearly and we need to look past the bubble of illusion as Buddha suggested. This will probably make sense to John Lennon from the Beatles,but not others, and he is dead. Sorry but the IETF is very important and I think we are missing the most critical points (not to Jonne just responding to his email) regarding total open systems view point. /jim > -----Original Message----- > From: Jonne.Soininen@nokia.com [mailto:Jonne.Soininen@nokia.com] > Sent: Wednesday, May 21, 2003 3:35 AM > To: john-ietf@jck.com; spencer@mcsr-labs.org; > problem-statement@alvestrand.no > Subject: RE: OPEN ISSUE: WG Chair Selection > > > Hi John, > > thanks for your clarification of this (I have to say) > peculiar process. I started wondering a bit about a few things. > > You said that performance issues are fairly common - a few > times per WG per year. That does sound awful lot to me. How > is this performance actually measured? I mean, the milestones > are generally totally off anyways. Does every AD have their > own measures? > > Secondly, you say that a non-performing WG could be fired > totally (closed?). Would that mean that the WG had already no > meeting, and no participants on the mailing list, or how is > it determined that the WG is performing so poorly that it can > be closed down? > > I just wonder, if there such occurring performance problems > maybe the WGs, or the chairs are not alone anymore to blame, > but the responsibility goes already to the ADs that are > managing the WG. If there needs to be a change very often, > maybe the selection criteria of the WG chairs is wrong, or > the management is inadequate. > > Cheers, > > Jonne. > > > > -----Original Message----- > > From: ext John C Klensin [mailto:john-ietf@jck.com] > > Sent: Tuesday, May 20, 2003 12:32 PM > > To: Spencer Dawkins; problem-statement@alvestrand.no > > Subject: Re: OPEN ISSUE: WG Chair Selection > > > > > > Spencer, > > > > For perhaps-obvious reasons, sitting IESG members may be a bit > > reluctant to answer this explicitly. As a variation, let me > > explain why you may not get an answer that is as clear as you > > like. > > > > In this, or any similar volunteer organization, occasions in > > which an AD becomes uncomfortable with WG, or WG Chair, > > performance are fairly common. On average, I'd guess that > > occurs at least a few times per WG per year, but the tails on > > that distribution are very long. Normally, depending somewhat > > on the personalities and style of the particular AD and Chair > > involved, that discomfort is followed by some combination of > > advice, encouragement, counselling, education, etc. If enough > > of those occur enough times, much more direct conversations, > > sometimes followed by threats, enter the equation. Now, for > > some WG chair personalities, especially in combination with > > particularly forceful ADs, there may be very little perceived > > difference between a "firm and frank exchange of views", > > especially if it occurs with a few accompanying threats, a > > demand for a resignation, or an outright firing. In other > > combinations of cases, the difference is very great indeed. > > > > Of course, ADs don't have infinite patience, and probably > > shouldn't. Frequent instances of discomfort or annoyance are as > > likely to lead to chair-removal (maybe more likely) as a few > > seriously bad actions. > > > > To complicate things further, I've observed that most ADs try to > > keep to keep the fact of forcing a Chair out fairly low profile > > and to try to avoid disrupting WGs more than necessary. So, > > e.g., what might appear to a WG as "adding a co-chair to help > > with the load" might actually be a "get someone new in and up to > > speed so that the disfunctional original chair can be dumped". > > > > There are also situations in which an AD concludes that the > > correct action is to fire a WG, not a chair. But sometimes that > > results from the conclusion that the chair isn't functioning but > > that no replacement would be likely to function any better. > > Again, you can't generally tell from the outside and that is > > often a good thing (especially when the chair might be perfectly > > appropriate for managing some other WG, under other > > circumstances). > > > > The "WG isn't getting anything done anyway" point that you make > > is important. It figures prominently in many of these > > decisions, but certainly not all of them. To take an extreme > > case as an example, suppose we had a WG that is working smoothly > > and effectively and has co-chairs. One of them is function and > > the other is not. Some ADs are going to be strongly inclined to > > force the disfunctional Co-chair out as a matter of principle if > > he or she can't be quickly persuaded to start pulling weight and > > contributing usefully. Other ADs would be inclined to just let > > this go, especially if the functional co-Chair isn't > > complaining, on the "why stir up trouble" or "it isn't broken, > > don't fix it" principles. I think there aren't any uniformly > > correct answers and the differences mess up the statistics. > > > > Those aren't numbers, but maybe the explanation will help a bit. > > > > john > > > > > > > > --On Tuesday, 20 May, 2003 07:19 -0500 Spencer Dawkins > > wrote: > > > > > I understand your distinction between WG chairs leaving > and "leaving > > > with assistance". > > > > > > I've got to ask - how common IS the case where a WG chair is > > > > > > (1) not performing to the point where s/he should be > replaced, and > > > (2) not willing to step down? > > > > > > If this happens once a year, I'd say "tough, let the AD announce > > >the impending replacement publically and ask for input > anyway". It's > > >not like anything is getting done in the WG anyway, right? > > >... > > > > > From problem-statement-bounces@alvestrand.no Wed May 21 04:39: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 EAA12104 for ; Wed, 21 May 2003 04:39:42 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7F5D3625B5; Wed, 21 May 2003 10:39:11 +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 B965162593; Wed, 21 May 2003 10:39:01 +0200 (CEST) Date: Wed, 21 May 2003 10:33:41 +0200 From: Harald Tveit Alvestrand To: John C Klensin Message-ID: <409117549.1053513221@localhost> In-Reply-To: <278018759.1053473749@p3.JCK.COM> References: <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> <5.1.0.14.2.20030520202101.03c85b10@mail.windriver.com> <278018759.1053473749@p3.JCK.COM> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: "problem-statement@alvestrand.no" Subject: Re: IESG spin-up time (was: Re: Charters, "normal process" versus ISOC, etc. (was: Re) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit WRT "6 months": People's capabilities vary. Some are faster than others - and for routine matters, procedures and so on, I think the process goes much faster than 6 months. But the process of learning the personal, technological and organizational interactions in working groups you have not previously followed is a significant learning curve - it took me more than one IETF meeting after I became managing AD for the SNMPv3 group before I understood the interactions there well enough to be an effective AD, for instance (sometimes I'm not sure I ever got there in the 1 year I did that job). --On 20. mai 2003 23:35 -0400 John C Klensin wrote: > ADs serve a 24 month [initial] term. Under our present system, we expect > them to hit the ground running, regardless of their prior experience. If > they really take six months to come up to speed, it implies, first, that > any area in which an AD is replaced is going to be running at reduced > capability for half a year, which is a huge hit. And the AD will be > disfunctional, or at least below acceptable function levels, for fully > one fourth of the initial term. > > I suggest that, if this is what is happening, it is inefficient to the > point of silliness and that we should get it on the list as a problem and > build a framework for considering alternatives. Examples: Should we > expand the initial term to three years so that the spin-up time is 1/6 of > the term, rather than 1/4? Should we try to alter the transition process > from "atomic handover after the plenary of the first meeting of the year" > to some flavor of "AD Elect" or "understudy" model that would permit most > or all of that six months of acclimatization to before the new AD > actually had any WG management responsibilities? The IESG and IAB have tried to alleviate the hit as much as the current procedures permit - the new IESG and IAB members are routinely added to the mailing lists and invited to teleconferences soon after they have been confirmed. But at least in the IESG, the idea of knowing exactly who's responsible at any point in time seems attractive. But if we manage to get around to thinking about new organizational models for the leadership, this definitely bears thinking about. Harald From problem-statement-bounces@alvestrand.no Wed May 21 06: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 GAA14015 for ; Wed, 21 May 2003 06:29:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3086F622AC; Wed, 21 May 2003 12:29:07 +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 A884B61DEC; Wed, 21 May 2003 12:28:55 +0200 (CEST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) h4LASglr014232; Wed, 21 May 2003 12:28:44 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4LARLmS114360; Wed, 21 May 2003 12:27:22 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA23072 from ; Wed, 21 May 2003 12:27:19 +0200 Message-Id: <3ECB54A4.B0288C3C@hursley.ibm.com> Date: Wed, 21 May 2003 12:27:48 +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: Harald Tveit Alvestrand References: <160610315.1053356338@p3.JCK.COM> <337667099.1053441771@localhost> <368714022.1053472818@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "problem-statement@alvestrand.no" Subject: Please get it done X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 Tveit Alvestrand wrote: ... > > no - I was thinking about adding another AD to the General area - either > assigning the hat to an existing IESG member or asking Nomcom to fill a new > slot. Yes, there is no point whatever in artificially creating a new Area for this. A new AD, not an existing one, should resolve the perception of conflict of interest. Ask Nomcom. Let's get it done, rather the repeating the arguments yet again. Brian From problem-statement-bounces@alvestrand.no Wed May 21 06:52: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 GAA14461 for ; Wed, 21 May 2003 06:52:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A56E2622A1; Wed, 21 May 2003 12:51:55 +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 88AAC61DEC for ; Wed, 21 May 2003 12:51:53 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.16]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id DAA21612; Wed, 21 May 2003 03:51:38 -0700 (PDT) Message-Id: <5.1.0.14.2.20030521063914.03db25a0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 21 May 2003 06:47:44 -0400 To: Brian E Carpenter From: Margaret Wasserman In-Reply-To: <3ECB54A4.B0288C3C@hursley.ibm.com> References: <160610315.1053356338@p3.JCK.COM> <337667099.1053441771@localhost> <368714022.1053472818@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: Please get it done X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 12:27 PM 5/21/2003 +0200, Brian E Carpenter wrote: > > no - I was thinking about adding another AD to the General area - either > > assigning the hat to an existing IESG member or asking Nomcom to fill a new > > slot. > >Yes, there is no point whatever in artificially creating a new Area >for this. A new AD, not an existing one, should resolve the perception >of conflict of interest. Ask Nomcom. > >Let's get it done, rather the repeating the arguments yet again. I like this approach. Should we just trust the Nomcom to pick the right person, or should we offer some suggestions regarding the "independence" criteria and "neutrality" that some have suggested is important to maintaining the credibility of the process? Do we specifically want someone who has never served on the I*? Or at least not in the last 10 years, since everyone seems to agree that some of the problems have existed at least that long? And are there particular qualifications for this position, such as experience with process management and process improvement? Margaret From problem-statement-bounces@alvestrand.no Wed May 21 07:54: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 HAA15409 for ; Wed, 21 May 2003 07:54:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 042A1622B1; Wed, 21 May 2003 13:53:46 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from lawyers.ir.bbn.com (d14-69-204-117.clv.wideopenwest.com [69.14.117.204]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4F68C62206 for ; Wed, 21 May 2003 13:53:43 +0200 (CEST) Received: by lawyers.ir.bbn.com (Postfix, from userid 9076) id AAA6A6B2BA; Wed, 21 May 2003 07:52:23 -0400 (EDT) To: Margaret Wasserman From: Mark Allman In-Reply-To: <5.1.0.14.2.20030521063914.03db25a0@mail.windriver.com> Organization: BBN Technologies/NASA GRC Song-of-the-Day: If I Wanted To Date: Wed, 21 May 2003 07:52:22 -0400 Message-Id: <20030521115223.AAA6A6B2BA@lawyers.ir.bbn.com> Cc: problem-statement@alvestrand.no Cc: Brian E Carpenter Subject: Re: Please get it done X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mallman@grc.nasa.gov List-Id: Problem 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's get it done, rather the repeating the arguments yet again. > > I like this approach. me too > Should we just trust the Nomcom to pick the right person, or > should we offer some suggestions regarding the "independence" > criteria and "neutrality" that some have suggested is important to > maintaining the credibility of the process? > > Do we specifically want someone who has never served on the I*? > Or at least not in the last 10 years, since everyone seems to > agree that some of the problems have existed at least that long? > > And are there particular qualifications for this position, such > as experience with process management and process improvement? My hit is that we should leave it to nomcom. I generally give nomcom input on particular cnadidates, but also on particular skills/traits I am interested in. I'd say we can all funnel our own feelings to nomcom and we should not have a lengthy debate on what those should be. (The most advice I'd want to give nomcom would be: please solicit input on the skills/traits that are important, not just on candidates. But, I assume they know that already.) allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ From problem-statement-bounces@alvestrand.no Wed May 21 07:54: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 HAA15424 for ; Wed, 21 May 2003 07:54:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3CFFC62598; Wed, 21 May 2003 13:53:47 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from lawyers.ir.bbn.com (d14-69-204-117.clv.wideopenwest.com [69.14.117.204]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5D41B622A1 for ; Wed, 21 May 2003 13:53:43 +0200 (CEST) Received: by lawyers.ir.bbn.com (Postfix, from userid 9076) id D2E046B2B8; Wed, 21 May 2003 07:43:18 -0400 (EDT) To: John C Klensin From: Mark Allman In-Reply-To: <278018759.1053473749@p3.JCK.COM> Organization: BBN Technologies/NASA GRC Song-of-the-Day: If I Wanted To Date: Wed, 21 May 2003 07:43:18 -0400 Message-Id: <20030521114318.D2E046B2B8@lawyers.ir.bbn.com> Cc: Margaret Wasserman Cc: "problem-statement@alvestrand.no" Subject: Re: IESG spin-up time (was: Re: Charters, "normal process"versus ISOC, etc. (was: Re) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mallman@grc.nasa.gov List-Id: Problem 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 told that it takes 6+ months to come up-to-speed in > > the IESG, and I believe that. > > Ok. This has now been said several times. Ignoring whether or > not it applies to a possible "process" position or not, I think it > represents a problem that belongs on the list and that isn't, as > far as I can tell, there. Or, is this just symptomatic of a larger problem that is the job of "AD" is just too much? I.e., if it takes someone 6 months to spin-up then maybe that means breadth of the AD job is too wide. (Not that I dislike the data point. It's quite interesting. I just don't know that it represents the problem.) allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ From problem-statement-bounces@alvestrand.no Wed May 21 08:47: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 IAA17614 for ; Wed, 21 May 2003 08:47:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1F65B6259A; Wed, 21 May 2003 14:46:38 +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 D052F622B1; Wed, 21 May 2003 14:46:34 +0200 (CEST) Date: Wed, 21 May 2003 14:13:28 +0200 From: Harald Tveit Alvestrand To: Margaret Wasserman Message-ID: <422303971.1053526408@localhost> In-Reply-To: <5.1.0.14.2.20030519101737.041cbf50@mail.windriver.com> References: <6459658.1053158473@p3.JCK.COM> <200305161703.h4GH3ODi023565@newdev.harvard.edu> <6459658.1053158473@p3.JCK.COM> <5.1.0.14.2.20030519101737.041cbf50@mail.windriver.com> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: "problem-statement@alvestrand.no" Subject: Re: Document Blocking (Was: I-D X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 19. mai 2003 10:22 -0400 Margaret Wasserman wrote: > At 12:02 PM 5/19/2003 +0200, Harald Tveit Alvestrand wrote: >> (tangential..... I am sometimes frustrated that WGs seem to take a >> Discuss as "declaration from on high that a technical decision needs to >> be changed", rather than as a challenge asking them to explain their >> positions better; > > I agree with other comments that this could be made clearer in > how IESG DISCUSS comments are communicated to the WG. For > example, why doesnt' the IESG member with the DISCUSS send a > message directly to the WG raising the issue? Sometimes he will, sometimes there are reasons not to.... one reason is that he wants the sponsoring AD's feedback first... after all, he might be wrong, or it might not be important enough. Or someone else might be better placed to take it - a common call is "Steve, this looks like a security issue to me - I'll say no-ob if you say it's OK; otherwise, either you or I could take it". at times, too, the sponsoring AD has suggested that an issue would be better handled by the document editor or even with a note to the RFC Editor, rather than inviting the WG to reexamine an issue where the WG had a rough time coming to consensus, and the IESG only wants the result to be more clearly documented, not changed. The AD for the WG is the IESG member best placed to give advice about how the message should go back to the WG. and also - sending mail to a WG list is not always simple, unless you have interacted with that list before - just about all lists bounce mail from nonsubscribers, and not all of them have active moderators who will forward such mail, no matter what guidelines say. >> after all, what has happened is that the IESG has failed to understand >> that the WG position is reasonable; either the WG is wrong, or the >> documents have insufficient convincing power - increasing the convincing >> power SHOULD be the right answer in some cases. But that seems rare....) > > Why are there only two choices that "the WG is wrong, or the > documents have insufficient convincing power"? While I don't > think it happens very often, couldn't the IESG be wrong? of course the IESG could be wrong! But they failed to be convinced by the documents. So more discussion is needed.... > > Also, some AD review comments and DISCUSS comments are really > about matters of taste -- the belief that a section should be > removed from a document because it is redundant (not wrong, > just redundant), the opinion that some historical note should be > added explaining why something was done a particular way, etc. > In those cases, there may be no right or wrong. In general, > the IESG wins because they can block publication of the document. > Do you think that's reasonable? No. Those issues should be labelled COMMENT, not DISCUSS. From problem-statement-bounces@alvestrand.no Wed May 21 09:18: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 JAA20091 for ; Wed, 21 May 2003 09:18:37 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1E70562573; Wed, 21 May 2003 15:18:06 +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 EDC9A622B1 for ; Wed, 21 May 2003 15:18:03 +0200 (CEST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) h4LDHsCi049530 for ; Wed, 21 May 2003 15:18:00 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4LDGVJ4241730 for ; Wed, 21 May 2003 15:16:31 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA38300 from ; Wed, 21 May 2003 15:16:30 +0200 Message-Id: <3ECB7C4A.F38F3029@hursley.ibm.com> Date: Wed, 21 May 2003 15:16:58 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: problem-statement@alvestrand.no References: <20030521115223.AAA6A6B2BA@lawyers.ir.bbn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Please get it done X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Mark Allman wrote: > > > >Let's get it done, rather the repeating the arguments yet again. > > > > I like this approach. > > me too > > > Should we just trust the Nomcom to pick the right person, or > > should we offer some suggestions regarding the "independence" > > criteria and "neutrality" that some have suggested is important to > > maintaining the credibility of the process? > > > > Do we specifically want someone who has never served on the I*? > > Or at least not in the last 10 years, since everyone seems to > > agree that some of the problems have existed at least that long? > > > > And are there particular qualifications for this position, such > > as experience with process management and process improvement? > > My hit is that we should leave it to nomcom. I generally give > nomcom input on particular cnadidates, but also on particular > skills/traits I am interested in. I'd say we can all funnel our own > feelings to nomcom and we should not have a lengthy debate on what > those should be. (The most advice I'd want to give nomcom would be: > please solicit input on the skills/traits that are important, not > just on candidates. But, I assume they know that already.) > Yes, I assume Nomcom would make their usual open call for nominations, and that gives everybody the chance to provide input. Brian From problem-statement-bounces@alvestrand.no Wed May 21 11:04: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 LAA24541 for ; Wed, 21 May 2003 11:04:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7795B62206; Wed, 21 May 2003 17:03:45 +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 575DE621FB for ; Wed, 21 May 2003 17:03:37 +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 19IV7p-0005VX-00; Wed, 21 May 2003 08:03:29 -0700 Date: Wed, 21 May 2003 11:02:24 -0400 From: Keith Moore To: Margaret Wasserman Message-Id: <20030521110224.78c23b89.moore@cs.utk.edu> In-Reply-To: <5.1.0.14.2.20030521063914.03db25a0@mail.windriver.com> References: <160610315.1053356338@p3.JCK.COM> <337667099.1053441771@localhost> <368714022.1053472818@localhost> <5.1.0.14.2.20030521063914.03db25a0@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 Cc: brian@hursley.ibm.com Subject: Re: Please get it done X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > Should we just trust the Nomcom to pick the right person, Yes. > or should we offer some suggestions regarding the "independence" criteria > and "neutrality" that some have suggested is important to maintaining > the credibility of the process? individuals can, as always, make suggestions to nomcom. let's not try to do so as a group; that will just slow the whole process down. > Do we specifically want someone who has never served on the I*? since working group operation is an even larger problem, perhaps we should specifically request someone who has never participated in a working group? Keith From problem-statement-bounces@alvestrand.no Wed May 21 11:14: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 LAA24863 for ; Wed, 21 May 2003 11:14:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E223362571; Wed, 21 May 2003 17:14:14 +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 5A9CF622B1 for ; Wed, 21 May 2003 17:14:06 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19IVI3-000DaV-00; Wed, 21 May 2003 10:14:03 -0500 Date: Wed, 21 May 2003 11:14:03 -0400 From: John C Klensin To: "Jonne.Soininen@nokia.com" , "spencer@mcsr-labs.org" , "problem-statement@alvestrand.no" Message-ID: <319912499.1053515643@p3.JCK.COM> In-Reply-To: <4D7B558499107545BB45044C63822DDEEBDCDC@mvebe001.americas.nokia.com> References: <4D7B558499107545BB45044C63822DDEEBDCDC@mvebe001.amer icas.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 Subject: RE: OPEN ISSUE: 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 Wednesday, 21 May, 2003 00:35 -0700 "Jonne.Soininen@nokia.com" wrote: > Hi John, > > thanks for your clarification of this (I have to say) peculiar > process. I started wondering a bit about a few things. I don't think it is peculiar at all, given the circumstances and the way we organize ourselves. Perhaps my reflections on your comments below will explain better. > You said that performance issues are fairly common - a few > times per WG per year. That does sound awful lot to me. How is > this performance actually measured? I mean, the milestones are > generally totally off anyways. Does every AD have their own > measures? Please don't read too much into either what I said or how I said it. Unhappiness is part of the AD job. More important, worrying about WG performance is part of the job. And I used "performance" broadly: as an AD, I would worry when there were clear disagreements within the WG that seemed to be going in circles, without convergence, and I would worry when there appeared to be too _much_ consensus about areas I believed should be controversial. Does silence indicate that the WG membership isn't broad enough? That people with dissenting views have been driven out or shouted into silence? That no one is really reading the docouments? And so on. The benchmarks are just part of this: some ADs find them a very useful management tool, others don't. For those who don't, putting energy (of either the AD or the WG) into getting frequent updates and readjustments is a waste of time and effort. For those who do, concern/discomfort is always appropriate, but the question of whether to come down on the WG (or its Chair) for getting behind requires, IMO, some judgment, not a firm rule. For example, if a WG is overdue, but finally working swiftly toward what looks like a positive conclusion, telling them to stop, lose momentum, and start rewriting benchmarks would typically (but perhaps not always) be a dumb decision. Conversely, if a WG has lost direction, is wandering in the weeds, and is also overdue, focusing on benchmarks may be the wrong way to spend energy. Since I'm good at worrying and thinking about thing can could go wrong and what their early symptoms would look like, I'm even likely to get concerned or uncomfortable if a WG appears to be well ahead of benchmarks (not that this happens very often) -- e.g., I wonder whether they are missing or burying issues that ought to be taking up more time (similar to my comment about "too much consensus" above, but still a bit different). For some combinations of AD and WG personalities, and general styles, the AD might monitor these things actively and interact actively with the WG Chairs each time a concern came up. For others, the AD might look in every few months, depending on the Chair(s) to raise issues if they showed up in the interim. Does any of this lead automatically, or even frequently, to "shoot the Chair"? It had better not. Replacing Chairs is a difficult and disruptive process even when it is completely voluntary. A new person has to be found and brought up to speed, working relationships and styles with both the AD and the WG have to be rebuilt, etc. "The group is close enough to finished" can be an excellent reason to keep a chair on who is obviously disfunctional, or even to plead with one who has burned out to stay on a bit longer, just because of the effort and disruption associated with a change. (Of course, sometimes ADs make bad guesses about how close the group really is, which has other bad consequences, but we had better not start expecting perfect forecasting or prophecy.) If we ever have an AD would _likes_ firing and replacing Chairs, it will be time to ask whether that person had outlived his or her usefulness on the IESG. > Secondly, you say that a non-performing WG could be fired > totally (closed?). Would that mean that the WG had already no > meeting, and no participants on the mailing list, or how is it > determined that the WG is performing so poorly that it can be > closed down? We've actually discussed this quite a lot on this list, although in slightly different form. I hope we can avoid rehashing it. Under current procedures, the responsible AD for a WG can close that WG at any time, for any reason. In general, there is agreement that doing this without warning and prior discussion would be a terrible practice. But it is almost impossible to imagine how we could write more specific rules that would cover all possible situations without over-constraining the ability of ADs to manage or bogging down a process in which the potential for decisive action may sometimes be very important. So we rely on AD discretion, good sense, and the ability to appeal such decisions. > I just wonder, if there such occurring performance problems > maybe the WGs, or the chairs are not alone anymore to blame, > but the responsibility goes already to the ADs that are > managing the WG. If there needs to be a change very often, > maybe the selection criteria of the WG chairs is wrong, or the > management is inadequate. We do not change WG chairs very often, perhaps even not as often as we should. Some, perhaps many, of the changes that do occur are due to external reasons, e.g., a chair changing jobs and not having adequate time or resources to continue effectively. When we do make changes, the reasons are often hard to discern, and that is often for very good reasons, as I tried to point out in my note. If we ever had an AD who was routinely selecting chairs, removing and replacing them, and then repeating the cycle, that AD is probably ready for retirement... but, to my recollection, that has never happened. And I would add to your list/discussion: "maybe the charter was wrong and the WG is just hopeless" -- which is the reason I wanted to discuss "fire the WG" along with "fire the WG Chair". But, again, thinking about this in terms of blame is not often going to be helpful. Even in the "weak charter" case, ADs are sometimes under a lot of pressure to approve charters. Sometimes the right answer is not "try to tune this until everyone is happy", but "let them try this, but for a relatively short period of time -- if the WG turns out to be unsuccessful during that period, either replace the leadership, drastically revise the charter, or close or suspend the WG until a more realistic plan can be developed". If the second course is taken, the choise among those three options may depend more on AD style and circumstances than about any firm or public theory about who or what is to blame. regards, john From problem-statement-bounces@alvestrand.no Wed May 21 11:39: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 LAA25483 for ; Wed, 21 May 2003 11:39:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2BE2C6257F; Wed, 21 May 2003 17:38:36 +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 56E3262206; Wed, 21 May 2003 17:38:15 +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 19IVfP-0002Hs-00; Wed, 21 May 2003 08:38:11 -0700 Date: Wed, 21 May 2003 11:37:06 -0400 From: Keith Moore To: John C Klensin Message-Id: <20030521113706.705f6066.moore@cs.utk.edu> In-Reply-To: <264436479.1053460166@p3.JCK.COM> References: <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> <264436479.1053460166@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: dcrocker@brandenburg.com Cc: harald@alvestrand.no Cc: moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > >> Neither of you really need to be reminded of this, but the > >> issue isn't placing blame > > > > agreed. but we seem to be spending most of our energy > > concentrating on what's wrong with IESG and how to fix it, and > > very little energy trying to understand what is wrong with > > working groups and how to fix them. > > I agree, and agree that this is a problem. But many members of > the set of non-pixie-dust possible fixes for WG problems come > down to looking at how they are chartered, structured, and > managed. To the extent to which we are looking at WG problems > that involve those sorts of solution spaces, the remedies, if > not the problems, lie again in the vicinity of the IESG... Actually I disagree - I think they lie with our processes for operation of working groups, much of which is beyond IESG control. Even the part that is theoretically under control of ADs may be effectively out of reach due to community expectations and inertia. > > working groups that produce technically sound results rarely > > have problems with IESG. > > If "problems" includes delays in getting those results approved > and published --delays that are longer than those WGs consider > appropriate-- then I think several people have made comments on > this list that disagree with you. But did those groups produce technically sound results, or for instance did they fail to take into account the impact of the protocol on some other concern not represented in the WG? And were the delays really unreasaonble given the amount of review and comment that needs to take place, or did the group just feel that way? And were those actions sufficiently recent to be a fair representation of the current IESG processes? Maybe concrete examples would help. > But, with the understanding that this isn't what you said, there > is clearly a perception that WGs that produce results that they > consider technically sound (or at least "good enough") quite > often see delays in the IESG that they consider unreasonable. Perceptions are often wrong. IMHO we are in danger of biasing the process so that it favors the reinforcement of perceptions over producing sound results. From problem-statement-bounces@alvestrand.no Wed May 21 11:53: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 LAA26027 for ; Wed, 21 May 2003 11:53:42 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F3C22622A1; Wed, 21 May 2003 17:53:12 +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 107E761C73 for ; Wed, 21 May 2003 17:53:11 +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 h4LFr8BP000736 for ; Wed, 21 May 2003 08:53:09 -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 AHM49890; Wed, 21 May 2003 08:53:07 -0700 (PDT) Message-Id: <200305211553.AHM49890@mira-sjc5-c.cisco.com> To: problem-statement@alvestrand.no From: Melinda Shore Date: Wed, 21 May 2003 11:53:07 -0400 Subject: Update X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 notes on where we currently stand: 1) We're scheduled to have the problem description document through WG last call in May. Obviously that's not going to happen, but I think we can get it wrapped up pretty quickly if we hunker down a bit. There haven't been many comments on the new version other than a few "well done"s; it would be helpful if people who haven't read the new version could take a look at it and raise any issues they discover. Elwyn is going to be posting specific questions to the mailing list for resolution before bringing out the next revision, which we hope will be the one going into WG last call. 2) We're going to try to close some of the uncontentious open issues in process document. I'll be sending out specific queries 3) We're not ready to close the more contentious issues. I realize that we're trying to meet an aggressive schedule, but the discussion has been productive and there's been no consensus on at least one of them, and in those cases it would be premature to cut discussion off. 4) We do have an issue tracker (Bugzilla) that we haven't started using yet. To be honest, it's currently hosted on my home server and I've gotten cold feet about opening it up to the world. If someone has a server they'd like to volunteer, we'd be receptive. More to follow, Melinda From problem-statement-bounces@alvestrand.no Wed May 21 11:57: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 LAA26175 for ; Wed, 21 May 2003 11:57:06 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9671B622A1; Wed, 21 May 2003 17:56:36 +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 9AD6D61C73 for ; Wed, 21 May 2003 17:56:34 +0200 (CEST) Message-ID: <003801c31fb1$57eb80b0$236015ac@DCLKEMPFTP> From: "James Kempf" To: "Dave Crocker" , "Margaret Wasserman" References: <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> <5.1.0.14.2.20030520202101.03c85b10@mail.windriver.com> Date: Wed, 21 May 2003 08:55:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, > There seems to be some assumption that, if we open a new > Process AD position, the nomcom will pick someone who has never > served on the IAB or IESG (and is therefore "untainted"). [Of > course, none of us can control the criteria that the Nomcom > uses to select a Process AD, so they could choose a current > sitting IESG or IAB member, and back-fill. Or, they could > choose a recent IESG member. But, the assumption seems to > be that they would choose, as Keith put it, a "neophyte".] > I don't think this is a valid assumption. There are several people who have served on IAB or IESG in the far enough distant past that they would be credible candidates, and some who would be excellent based on other qualities. There are additionally a couple who have served in the recent past who I think would make excellent candidates, but who should probably not be considered due to perceptions about their more recent association. I feel very uncomfortable with this, because there is an implication about the current members of the I* which I feel is completely unfounded, but that perception does exist among some members of the community, expressed on this list, and I believe we must deal with it properly in order to have the process be credible. jak From problem-statement-bounces@alvestrand.no Wed May 21 12:06: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 MAA26450 for ; Wed, 21 May 2003 12:06:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E8B5661C73; Wed, 21 May 2003 18:06:07 +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 68ADF61C73 for ; Wed, 21 May 2003 18:06:05 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19IW6O-000DxB-00; Wed, 21 May 2003 11:06:04 -0500 Date: Wed, 21 May 2003 12:06:04 -0400 From: John C Klensin To: Melinda Shore Message-ID: <323033657.1053518764@p3.JCK.COM> In-Reply-To: <200305211553.AHM49890@mira-sjc5-c.cisco.com> References: <200305211553.AHM49890@mira-sjc5-c.cisco.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: Update X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, 21 May, 2003 11:53 -0400 Melinda Shore wrote: > A few notes on where we currently stand: > > 1) We're scheduled to have the problem description document > through WG last call in May. Obviously that's not going to > happen, but I think we can get it wrapped up pretty quickly > if we hunker down a bit. There haven't been many comments > on the new version other than a few "well done"s; it would > be helpful if people who haven't read the new version could > take a look at it and raise any issues they discover. >... Melinda, I think that a large fraction of the notes I've posted recently have contained comments of the nature of "this appears to be an important problem/issue and it appears to not be reflected in the current version of the problem description document". Sometimes, the comments have been even more specific than that, pointing out sections in which I would expect the issues to be reflected but that don't seem to reflect them. The most recent of those is the discussion of whether there really is a "6+ month spin-up time" on the IESG and whether that calls for some radical rethinking of terms of office, structure, transition mechanisms and timing, or AD responsibilities. I suppose I could have tried to write a list of omissions against the current document instead, but that just isn't how the flow of discussion on the list has been going. If you need that sort of presentation in order to count something as a "comment on the new version", it would be really helpful if you, as co-chairs, would post --or arrange for someone else to post-- reminders that people should explicitly relate discussions to the text of the document when those discussions appear to be about useful topics but their relationships can't be identified easily. thanks, john From problem-statement-bounces@alvestrand.no Wed May 21 12:12: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 MAA26630 for ; Wed, 21 May 2003 12:12:15 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 888AE622B1; Wed, 21 May 2003 18:11:45 +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 7F6D661C73 for ; Wed, 21 May 2003 18:11:40 +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 h4LGBWeS012142; Wed, 21 May 2003 09:11:32 -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 AHM52047; Wed, 21 May 2003 09:11:31 -0700 (PDT) Message-Id: <200305211611.AHM52047@mira-sjc5-c.cisco.com> To: John C Klensin From: Melinda Shore In-Reply-To: Message from john-ietf@jck.com of "Wed, 21 May 2003 12:06:04 EDT." <323033657.1053518764@p3.JCK.COM> Date: Wed, 21 May 2003 12:11:31 -0400 Cc: problem-statement@alvestrand.no Subject: Re: Update X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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, I think that a large fraction of the notes I've posted > recently have contained comments of the nature of "this appears > to be an important problem/issue and it appears to not be > reflected in the current version of the problem description > document". Sorry, should have been clearer. We're certainly tracking discussion of new problems as they crop up on the mailing list and those are being distilled into the new revision of the document. Those discussions are about what's not in the document. We haven't had much discussion of what *is* in the document, however, and in the interest of moving the document along towards WG last call we need to make sure that the it's getting that kind of review. Melinda From problem-statement-bounces@alvestrand.no Wed May 21 12:31: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 MAA27364 for ; Wed, 21 May 2003 12:31:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 099EE62572; Wed, 21 May 2003 18:30:42 +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 E23D8622B1 for ; Wed, 21 May 2003 18:30:30 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.40]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA10302; Wed, 21 May 2003 09:30:16 -0700 (PDT) Message-Id: <5.1.0.14.2.20030521122233.03f42338@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 21 May 2003 12:26:21 -0400 To: "James Kempf" From: Margaret Wasserman In-Reply-To: <003801c31fb1$57eb80b0$236015ac@DCLKEMPFTP> References: <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> <5.1.0.14.2.20030520202101.03c85b10@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 James, At 08:55 AM 5/21/2003 -0700, James Kempf wrote: >I don't think this is a valid assumption. There are several people who >have served on IAB or IESG in the far enough distant past that they >would be credible candidates, and some who would be excellent based on >other qualities. Given that people who were there at the time have indicated that most of these problems have existed in the IETF for at least 10 years, how could you reasonably claim that any IAB/IESG member who has served in the last ten years is any less culpable than current IAB/IESG members? Margaret From problem-statement-bounces@alvestrand.no Wed May 21 12:32: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 MAA27447 for ; Wed, 21 May 2003 12:32:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 36337622B1; Wed, 21 May 2003 18:32: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 B0AB8622A1 for ; Wed, 21 May 2003 18:32:15 +0200 (CEST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) h4LGWBXF026974 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 21 May 2003 09:32:12 -0700 (PDT) Received: from [10.30.2.233] (carbuncle.qualcomm.com [129.46.74.110]) h4LGW9ix029856; Wed, 21 May 2003 09:32:10 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <1609856713.20030520194032@brandenburg.com> References: <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> <5.1.0.14.2.20030520202101.03c85b10@mail.windriver.com> <1609856713.20030520194032@brandenburg.com> Date: Wed, 21 May 2003 09:32:09 -0700 To: dcrocker@brandenburg.com, Margaret Wasserman From: hardie@qualcomm.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "problem-statement@alvestrand.no" Cc: Dave Crocker Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 7:40 PM -0700 5/20/03, Dave Crocker wrote: > >You might want to review the postings from IESG members. The direction >of the concerns has been quite consistent. You also might want to drop the assumption that anyone speaking in this forum is doing so as a representative of a corporate body, internal or external to the IETF. Current and former members of various bodies have contributed their experience and concerns, but as far as I can tell they have done so as individuals. If at anytime I personally have been remiss in putting "just my opinion" on a note, forgive me; I may have assumed it and I invite you to do the same. Speaking personally, I have contributed to this working group draft documents, alternatives, and comments on others' text, and I have done so both before and after I took on the role of co-AD for Applications. Do not assume my maunderings represent the consensus opinion of any other body. They are my own statements, not a posting from "an IESG member". Please feel free to disagree, point out errors, and even think me an idiot, but do me the courtesy common to this body of thinking me an individual idiot, rather than a stooge. On another point, I was not asked during the NomCom process whether I was planning to shut up for the following two years; I was asked a great deal both about my desires for change and my willingness to participate actively in it. I expressed then a desire for change that borders on the radical, and I still hold that view. Attempting to push my view out because I am also trying to work with Chairs to get documents done doesn't seem very productive; in fact, it seems rude. On the larger point, let me make clear again my own opinion: adding a process-specific AD to the current IESG as way to achieve some form of neutrality in oversight seems to me to me the wrong approach. It creates an oversight position that replicates the current system, when we are engaged in an effort to re-imagine the system; it may be interpreted as a statement by this body that the community should not trust the IETF chair, when this body should be listening to the community on that point instead; and it forces us to find someone focused on this issue who can dedicate nearly full time to it when such a person might have other roles to play (someone trusted to be this AD is obviously also a good candidate to be the chair of one of the groups, for example). As I said above, just my opinion, regards, Ted Hardie > >You may also want to re-read my posting. > >Yes, non-IESG people have also raised questions about John's proposal, >and about the ISOC alternative. > >I said "notably". I did not say "xclusively". > > >MW> There seems to be some assumption that, if we open a new >MW> Process AD position, the nomcom will pick someone who has never >MW> served on the IAB or IESG (and is therefore "untainted"). > > >There are all sorts of "assumptions" being made. > >Oddly the assumptions all seem to presume that John's proposal is not >viable. > > > >MW> I pointed out that this would also have the downside >MW> of having the process run by someone who is new to the >MW> IESG processes. I've been told that it takes 6+ months >MW> to come up-to-speed in the IESG, and I believe that. > >And were this a normal AD slot, that might be important. It isn't, so >it isn't. > >Then, of course, there is the minor likelihood that whoever is selected >actually would be someone with quite a bit of IETF experience. > >Gosh. What a thought. > > >MW> So, we have a situation where there may be a trade-off >MW> between the speed/efficiency of this process and the desire >MW> to have it run by a "neutral" party. > >Please forgive me for noting that raising an arbitrary concern will >almost always create the appearance of a trade-off. > >You see, the nice thing about such carefully selected concerns is that >they ignore other factors that are likely to be brought into the >selection process. > > >MW> We could suggest that the IESG add another AD to the General >MW> area and keep the work there. > >The need is not for managing the "general area". > >The need is for managing a change process that is credible to the >community. > >When you pursue alternative proposals, it would help for this concern >about credibility and independence to be given as much credence as >whether the bureaucratic niceties are comfortable to the IESG. > > > >d/ >-- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Wed May 21 12:41: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 MAA27769 for ; Wed, 21 May 2003 12:41:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4C23C622A1; Wed, 21 May 2003 18:41: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 E2D2A61C73 for ; Wed, 21 May 2003 18:41:15 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19IWeR-000E9H-00; Wed, 21 May 2003 11:41:15 -0500 Date: Wed, 21 May 2003 12:41:14 -0400 From: John C Klensin To: Melinda Shore Message-ID: <325143962.1053520874@p3.JCK.COM> In-Reply-To: <200305211611.AHM52047@mira-sjc5-c.cisco.com> References: <200305211611.AHM52047@mira-sjc5-c.cisco.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: Update X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Ah. Thanks for the clarification. john --On Wednesday, 21 May, 2003 12:11 -0400 Melinda Shore wrote: >> Melinda, I think that a large fraction of the notes I've >> posted recently have contained comments of the nature of >> "this appears to be an important problem/issue and it >> appears to not be reflected in the current version of the >> problem description document". > > Sorry, should have been clearer. We're certainly tracking > discussion of new problems as they crop up on the mailing > list and those are being distilled into the new revision of > the document. Those discussions are about what's not in the > document. We haven't had much discussion of what *is* in > the document, however, and in the interest of moving the > document along towards WG last call we need to make sure > that the it's getting that kind of review. > > Melinda From problem-statement-bounces@alvestrand.no Wed May 21 12:43: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 MAA27820 for ; Wed, 21 May 2003 12:43:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D13A562593; Wed, 21 May 2003 18:42:43 +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 439CB62581 for ; Wed, 21 May 2003 18:42:13 +0200 (CEST) Message-ID: <015101c31fb7$b8480630$236015ac@DCLKEMPFTP> From: "James Kempf" To: "Brian E Carpenter" , "Margaret Wasserman" References: <160610315.1053356338@p3.JCK.COM> <337667099.1053441771@localhost> <368714022.1053472818@localhost> <5.1.0.14.2.20030521063914.03db25a0@mail.windriver.com> Date: Wed, 21 May 2003 09:40:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Please get it done X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 the approach as well. I think we ought to ask for nominations, and give Nomcom a list of critera. Hopefully, we can get such a list without a 6 month discussion. The important thing AFAIC is that there is a dedicated AD, that the individual is perceived by the community to be capable of doing an objective and fair job, and that she or he has enough working knowledge of the IETF, including how IESG and IAB function, that they are able to make informed judgements about suggestions which come from the Working Groups. Some proven management skill may also be useful, as is always the case with an AD. I don't think a new Area is really necessary, however. jak ----- Original Message ----- From: "Margaret Wasserman" To: "Brian E Carpenter" Cc: Sent: Wednesday, May 21, 2003 3:47 AM Subject: Re: Please get it done > > Hi Brian, > > At 12:27 PM 5/21/2003 +0200, Brian E Carpenter wrote: > > > no - I was thinking about adding another AD to the General area - either > > > assigning the hat to an existing IESG member or asking Nomcom to fill a new > > > slot. > > > >Yes, there is no point whatever in artificially creating a new Area > >for this. A new AD, not an existing one, should resolve the perception > >of conflict of interest. Ask Nomcom. > > > >Let's get it done, rather the repeating the arguments yet again. > > I like this approach. > > Should we just trust the Nomcom to pick the right person, or should > we offer some suggestions regarding the "independence" criteria and > "neutrality" that some have suggested is important to maintaining > the credibility of the process? > > Do we specifically want someone who has never served on the I*? > Or at least not in the last 10 years, since everyone seems to agree > that some of the problems have existed at least that long? > > And are there particular qualifications for this position, such > as experience with process management and process improvement? > > Margaret > > > > From problem-statement-bounces@alvestrand.no Wed May 21 13:04: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 NAA28347 for ; Wed, 21 May 2003 13:04:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D7D2562581; Wed, 21 May 2003 19:04:27 +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 574F86257F for ; Wed, 21 May 2003 19:04:24 +0200 (CEST) Message-ID: <01c601c31fba$d16e49f0$236015ac@DCLKEMPFTP> From: "James Kempf" To: "Margaret Wasserman" References: <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> <5.1.0.14.2.20030520202101.03c85b10@mail.windriver.com> <5.1.0.14.2.20030521122233.03f42338@mail.windriver.com> Date: Wed, 21 May 2003 10:02:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > Given that people who were there at the time have indicated that most > of these problems have existed in the IETF for at least 10 years, how > could you reasonably claim that any IAB/IESG member who has served in the > last ten years is any less culpable than current IAB/IESG members? > First off, I don't believe any of the current IAB/IESG members are in any sense "culpable". If the problems are a result of the current structure of the organization, then even highly talented people with the best of intentions can have their talents and intentions frustrated to the point where they give up and quit. I assume, in fact, that some of the IESG/IAB members who have served during the last 10 years did, in fact, not continue to serve for exactly that reason. Their knowledge and understanding could be helpful in guiding the reform process. And, as I mentioned, many people on this list and elsewhere continue to place blame on existing members, so to the extent that some people believe existing IESG members are "culpable" as you put it, that perception must be accounted for, which appointing an existing AD won't do. The only other alternative I can think of that might have good chance of success is to get someone who knows alot about process engineering in organizations but might not know much at all about IETF (because those kinds of people don't tend to hang around IETF). This would probaby mean someone with world class expertise in management. This is not unlike how we select ADs for technical areas: they are expected to be world class experts in their area (routing, security, etc.). But the downside is, not knowing anything about IETF or having any commitment to it, they might not understand all the subtilties of the IETF community and end up alienating people by making uninformed suggestions. jak From problem-statement-bounces@alvestrand.no Wed May 21 13:31: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 NAA29206 for ; Wed, 21 May 2003 13:31:34 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1D2CC62581; Wed, 21 May 2003 19:31:05 +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 26073622A1 for ; Wed, 21 May 2003 19:30:55 +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 h4LHUrNS015186 for ; Wed, 21 May 2003 10:30: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 AHM63354; Wed, 21 May 2003 10:30:52 -0700 (PDT) Message-Id: <200305211730.AHM63354@mira-sjc5-c.cisco.com> To: problem-statement@alvestrand.no From: Melinda Shore Date: Wed, 21 May 2003 13:30:52 -0400 Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 question was this: >There is also a more fundamental issue with the IETF's engineering >practices. Although our current standards track contains three >levels of maturity (Proposed Standard, Draft Standard and Full >Standard), we do not have sufficient differentiation regarding the >quality and completeness of documents required at each stage. The >bar is set very high for publication at Proposed Standard, and very >few documents advance beyond this stage. [OPEN ISSUE: Do we have >IETF consensus that this is a problem?] There appears to be clear consensus that we have a problem with standards maturity levels. However there isn't consensus beyond that about the extent to which internet draft categories (wg draft, etc.) are a part of that problem, and the possibility was raised that there may be some sloppiness in how we (the IETF) move documents along as protocols mature. Some of the discussion was implentation-y and nature and therefore out of scope. If people feel that something needs to be said beyond what Margaret included in the draft, please speak up. Melinda From problem-statement-bounces@alvestrand.no Wed May 21 13:37: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 NAA29363 for ; Wed, 21 May 2003 13:37:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2EA4862572; Wed, 21 May 2003 19:37:21 +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 3BAFE62572 for ; Wed, 21 May 2003 19:37:14 +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 h4LHbCed026126 for ; Wed, 21 May 2003 10:37:12 -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 AHM64481; Wed, 21 May 2003 10:37:11 -0700 (PDT) Message-Id: <200305211737.AHM64481@mira-sjc5-c.cisco.com> To: problem-statement@alvestrand.no From: Melinda Shore Date: Wed, 21 May 2003 13:37:11 -0400 Subject: Re: OPEN ISSUE: Nomcom 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 The issue identified was this: >We may also need to modify our Nomcom processes so that IETF >participants who are not part of the IETF leadership can have more >visibility into the Nomcom process and more proportional input into >leadership selection. [OPEN ISSUE: Do we have consensus that these >are real problems that need to be solved?] In the ensuing discussion there was no consensus that there is a problem there that cannot be handled through current processes. Melinda From problem-statement-bounces@alvestrand.no Wed May 21 13:42: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 NAA29480 for ; Wed, 21 May 2003 13:42:15 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 589A6625A2; Wed, 21 May 2003 19:41:41 +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 0EAF3622A1 for ; Wed, 21 May 2003 19:41:37 +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 h4LHfZed002808 for ; Wed, 21 May 2003 10:41:35 -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 AHM65240; Wed, 21 May 2003 10:41:33 -0700 (PDT) Message-Id: <200305211741.AHM65240@mira-sjc5-c.cisco.com> To: problem-statement@alvestrand.no From: Melinda Shore Date: Wed, 21 May 2003 13:41:33 -0400 Subject: Re: OPEN ISSUE: Appeals Path X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 issue raised was this: >- [The ISOC-driven] approach does not require an explicit appeals > process, because an IETF Plenary is used as the basis for approval, > and it is that body from which the IETF draws its authority. > [OPEN ISSUE: Do we have consensus that a defined appeals > process is not required for this option?] We were unable to reach consensus on this (yet), but since the ISOC-driven approach has been rejected by the WG, this question is academic. Melinda From problem-statement-bounces@alvestrand.no Wed May 21 14:08: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 OAA00148 for ; Wed, 21 May 2003 14:08:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3910062573; Wed, 21 May 2003 20:08:28 +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 993B262572 for ; Wed, 21 May 2003 20:08:25 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 19IY0m-000J0W-10 for problem-statement@alvestrand.no; Wed, 21 May 2003 11:08:24 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 21 May 2003 11:08:23 -0700 To: problem-statement@alvestrand.no Message-Id: Subject: what are the real 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 a tiny error in an initial trajectory adds up to large errors at the target. errors in the statement(s) of our problems will therefore produce irrelevant, or worse damaging, solutions. hence, it is critical that we get the set of statements of problems very very correct, and very clear. what are problems anyway? i propose they are conditions which hamper our ability to reach our goals. but what are our goals? for the moment, i will put forth the following goals which were stated (far too quietly) in london and then a couple of times afterwards (again, far too quietly): the ietf's goal is to produce high quality, relevant, and timely standards for internet technology. so, for any statement of a problem, i would suggest that it be made very clear how it is a root, or close to root, cause of damage to achieving our goals. i submit that, by doing so, we would have much more confidence in a good problems statement, and have an excellent foundation on which to build the next level, the changes we need to make to better meet our goals by solving those problems. if a problem can not be shown to pretty directly affect our goals, then perhaps it is the result of other more root problems, people's personal issue, ... randy From problem-statement-bounces@alvestrand.no Wed May 21 15:27: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 PAA04991 for ; Wed, 21 May 2003 15:27:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 241FA6259A; Wed, 21 May 2003 21:27:24 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9653F62598 for ; Wed, 21 May 2003 21:27:21 +0200 (CEST) Received: from new.isi.edu (new.isi.edu [128.9.160.38]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h4LJRJ129241; Wed, 21 May 2003 12:27:19 -0700 (PDT) Date: Wed, 21 May 2003 12:27:23 -0700 From: Aaron Falk To: Randy Bush , problem-statement@alvestrand.no Message-ID: <96848300.1053520043@new.isi.edu> 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: what are the real 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 Thanks for your thoughts, Randy. On a related note, I think the perception in IETF that we (the IETF community) are stewards of the Internet has weakened. This may be the reason for the somewhat conservative nature of the IESG. Perhaps it's because corporate interests have become stronger. This concerns me because it is our common purpose. --aaron --On Wednesday, May 21, 2003 11:08 AM -0700 Randy Bush wrote: > > > a tiny error in an initial trajectory adds up to large errors at > the target. errors in the statement(s) of our problems will > therefore produce irrelevant, or worse damaging, solutions. hence, > it is critical that we get the set of statements of problems very > very correct, and very clear. > > what are problems anyway? i propose they are conditions which > hamper our ability to reach our goals. > > but what are our goals? for the moment, i will put forth the > following goals which were stated (far too quietly) in london and > then a couple of times afterwards (again, far too quietly): > > the ietf's goal is to produce high quality, relevant, and timely > standards for internet technology. > > so, for any statement of a problem, i would suggest that it be made > very clear how it is a root, or close to root, cause of damage to > achieving our goals. i submit that, by doing so, we would have > much more confidence in a good problems statement, and have an > excellent foundation on which to build the next level, the changes > we need to make to better meet our goals by solving those problems. > > if a problem can not be shown to pretty directly affect our goals, > then perhaps it is the result of other more root problems, people's > personal issue, ... > > randy From problem-statement-bounces@alvestrand.no Wed May 21 16:02: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 QAA06865 for ; Wed, 21 May 2003 16:02:06 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6D0F962598; Wed, 21 May 2003 22:01: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 C64B6622A1 for ; Wed, 21 May 2003 22:01: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 NAA52646 for ; Wed, 21 May 2003 13:01:27 -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 pgD0LlJ2 Wed, 21 May 2003 13:01:26 -0700 (PDT) Message-ID: <094d01c31fd3$c42b04e0$0300a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <200305211741.AHM65240@mira-sjc5-c.cisco.com> Date: Wed, 21 May 2003 15:01: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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: OPEN ISSUE: Appeals Path 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 had the (mis?)understanding that the current version of the draft did not recognize that ISOC reviewed process changes anyway, as part of providing liability insurance coverage for process leadership. Brian posted this as his last comment in http://www.alvestrand.no/pipermail/problem-statement/2003-May/001591.html. So I think the issue is still a no-op, just for slightly different reasons. Spencer ----- Original Message ----- From: "Melinda Shore" To: Sent: Wednesday, May 21, 2003 12:41 PM Subject: Re: OPEN ISSUE: Appeals Path > The issue raised was this: > > >- [The ISOC-driven] approach does not require an explicit appeals > > process, because an IETF Plenary is used as the basis for approval, > > and it is that body from which the IETF draws its authority. > > [OPEN ISSUE: Do we have consensus that a defined appeals > > process is not required for this option?] > > We were unable to reach consensus on this (yet), but since > the ISOC-driven approach has been rejected by the WG, this > question is academic. > > Melinda From problem-statement-bounces@alvestrand.no Wed May 21 16:13: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 QAA07197 for ; Wed, 21 May 2003 16:13:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 899CF62598; Wed, 21 May 2003 22:13:08 +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 5637C622A1 for ; Wed, 21 May 2003 22:13:02 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 19IZxK-000KnU-8r; Wed, 21 May 2003 13:12:58 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 21 May 2003 13:12:57 -0700 To: Aaron Falk References: <96848300.1053520043@new.isi.edu> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: what are the real 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 > Thanks for your thoughts, Randy. On a related note, I think the > perception in IETF that we (the IETF community) are stewards of > the Internet has weakened. This may be the reason for the > somewhat conservative nature of the IESG. at least among some iesg members, there is the feeling that o while the ietf is supposed to be the steward of the (technical part of the) internet o we perceive that we get massive pushback when we act in a conservative fashion, as it is perceived as inhibiting vendors, who are a bit desperate these days. o yet we think that the purpose of an sdo is to provide to the *users* inter-vendor choice through compatibility. so we wonder how pandering to featuritis of the vendors is serving the users no easy answers. randy From problem-statement-bounces@alvestrand.no Wed May 21 16:18: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 QAA07419 for ; Wed, 21 May 2003 16:18:34 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 42B8A625A9; Wed, 21 May 2003 22:18:01 +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 EBD06622A1 for ; Wed, 21 May 2003 22:17:58 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.40]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA25708; Wed, 21 May 2003 13:17:45 -0700 (PDT) Message-Id: <5.1.0.14.2.20030521160652.03db25a0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 21 May 2003 16:12:04 -0400 To: Spencer Dawkins From: Margaret Wasserman In-Reply-To: <094d01c31fd3$c42b04e0$0300a8c0@DFNJGL21> References: <200305211741.AHM65240@mira-sjc5-c.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Appeals Path X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 Spencer, At 03:01 PM 5/21/2003 -0500, Spencer Dawkins wrote: >I had the (mis?)understanding that the current version of the draft >did not recognize that ISOC reviewed process changes anyway, >as part of providing liability insurance coverage for process leadership. Yes. I received the following description of this process from Scott Bradner (who should know better than anyone :-)): "After the IETF finishes its normal process on a process document the document is brought before the ISOC BoT by an ISOC board member and the board is asked to accept the document as a description of the IETF process." And, I will include this step in the next version of the document. Margaret From problem-statement-bounces@alvestrand.no Wed May 21 17:34: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 RAA09752 for ; Wed, 21 May 2003 17:34:34 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AB6E2625A0; Wed, 21 May 2003 23:34:04 +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 932E162598; Wed, 21 May 2003 23:33:57 +0200 (CEST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])h4LLXub12602; Wed, 21 May 2003 16:33:56 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com ; Wed, 21 May 2003 16:33:55 -0500 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 21 May 2003 14:32:53 -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: Wed, 21 May 2003 14:32:52 -0700 Message-ID: <4D7B558499107545BB45044C63822DDEEBDCDE@mvebe001.americas.nokia.com> Thread-Topic: OPEN ISSUE: Standards Track Thread-Index: AcMeXW5ozytEFMOzRHy4lQuo8Hm2AgBgfWNw From: To: , X-OriginalArrivalTime: 21 May 2003 21:32:53.0479 (UTC) FILETIME=[8965C770:01C31FE0] Cc: problem-statement@alvestrand.no Subject: RE: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 RAA09752 Hi everybody, > -----Original Message----- > From: ext Keith Moore [mailto:moore@cs.utk.edu] > Sent: Friday, May 16, 2003 9:02 AM > > *what sort of bugs, if detected, would make a protocol > unsuitable for > > Proposed Standard?* > > the way Proposed is treated by industry now, anything that would cause > problems in wide deployment should make a protocol unsuitable for > Proposed. > > certainly failure to interoperate would be in this list, > but so would failure to scale, lack of robustness, failure to provide > adequate security, and a lot of other problems. I do not really think it is just the industry that is considering Proposed ready for wide development, but how we are going around in the IETF about the proposed standard actually makes it feel like it should be ready for wide scale implementation. When I first started coming to the IETF back in '99, I first read all the training material on the IETF web page. To my it was quite clear that proposed standard is no way stable, but either draft or full standard would be then really stable. Sadly, I had to be rehabilitated in the IETF to understand that proposed standard is mostly the last stage a protocol ever takes. And now for something a bit different: I think we should have a new stability stage (proposed standard?) to the documentation process, where the specification is relatively stable. That would mean that the bugs can be fixed, and the the work has by no means stopped. However, the technical concept would already be quite stable. At the moment, the specifications can change quite a bit in the last stages before going to proposed. The relatively-stable-stage could help the vendors to standart to implement the protocol and find out the bugs, and not to have to change the implementation completely when the next version of the protocol is out. For instance, it could be considered that the specs are "functionally frozen", but the last bugs are to be taken out. BTW, yes, I think too this is a real issue. Cheers, Jonne. From problem-statement-bounces@alvestrand.no Wed May 21 17:45: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 RAA09926 for ; Wed, 21 May 2003 17:45:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CD029625A0; Wed, 21 May 2003 23:44:29 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mgw-dax1.ext.nokia.com (unknown [63.78.179.216]) by eikenes.alvestrand.no (Postfix) with ESMTP id 62E386259A for ; Wed, 21 May 2003 23:44:27 +0200 (CEST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])h4LLiN108344 for ; Wed, 21 May 2003 16:44:23 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com ; Wed, 21 May 2003 16:44:23 -0500 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 21 May 2003 14:44:14 -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: Wed, 21 May 2003 14:44:13 -0700 Message-ID: <4D7B558499107545BB45044C63822DDE0175E0C7@mvebe001.americas.nokia.com> Thread-Topic: OPEN ISSUE: Nomcom Process Thread-Index: AcMa+qL9lL8ppEE9SlSzRZrOvU2I7ABB0oZgAPfqcaA= From: To: , , X-OriginalArrivalTime: 21 May 2003 21:44:14.0890 (UTC) FILETIME=[1F8CD8A0:01C31FE2] Subject: RE: OPEN ISSUE: Nomcom 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA09926 Hi everybody, > -----Original Message----- > From: ext Bound, Jim [mailto:Jim.Bound@hp.com] > Sent: Friday, May 16, 2003 4:29 PM > > I do not believe we should take this discussion to the NOMCOM that > process needs fixing too. Our job is to document the problem and the > NOMCOM has problems. I do believe sending mail to the nomcom with > specifics is fine but the problems there should be aired here too as > they affect the very fabric of the only open process we have for the > community to be able to add or remove IESG members. I think as well that the NOMCOM process (as any other process) should be discussed here in this WG. I would say that we have much more information in our hands than we did when the NOMCOM WG started. It may end up doing bit of the work again, and if we come to the same conclusion then fine. However, I believe its worth the trouble. I also thought that the NOMCOM work started with the notion that there is not much to change, and I believe that assumption is not as valid as it was at that time. Cheers, Jonne. > > Now if someone would like me to send my issue to NOMCOM please send me > what mail list to send to I have not the desire or time to get into > another WG debate. My issue is I want the IESG out of the room at > nomcom meetings unless called in for clarifications. They > should NOT be > present during the deliberations it is wrong and as I said it is like > having the government in the voting booth with me. It is > philosophically and morally wrong for the IESG to be in that room. > Period. Also the statements around existing IESG members > should receive > special treatment during deliberations is completely bogus they should > be judged on their results, their action, and their ability > to guide an > Area to success. If they did a bad job they should be removed (in > multiple areas) if they did a good job they should be kept > given that a > more qualified candidate does not show up. The above two issues are a > problem because they smell of academic tenure viewpoint and > the IETF is > not an academic exercise or institution but a standards body that is > suppose to produce results and work. If that is not done the IETF has > failed. > > /jim > > > -----Original Message----- > > From: Margaret Wasserman [mailto:mrw@windriver.com] > > Sent: Thursday, May 15, 2003 11:44 AM > > To: problem-statement@alvestrand.no > > Subject: OPEN ISSUE: Nomcom Process > > > > > > > > The process document currently says: > > > > >We may also need to modify our Nomcom processes so that IETF > > >participants who are not part of the IETF leadership can have more > > >visibility into the Nomcom process and more proportional > input into > > >leadership selection. [OPEN ISSUE: Do we have consensus > > that these are > > >real problems that need to be solved?] > > > > I believe that this is a real problem, and that we should > > modify our Nomcom processes to do two (related) things: > > > > - Give the community more visibility into the > > process. > > - Get more feedback on potential candidates from > > the community. Currently, some candidates > > are discussed with the leaders (IESG/IAB > > members and WG chairs), but the greater > > community doesn't even know who is being > > considered. > > > > Margaret > > > > > > > > > From problem-statement-bounces@alvestrand.no Wed May 21 17:52: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 RAA10010 for ; Wed, 21 May 2003 17:52:11 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C285E62598; Wed, 21 May 2003 23:51:40 +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 25273621FB for ; Wed, 21 May 2003 23:51:32 +0200 (CEST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])h4LLpTb14696 for ; Wed, 21 May 2003 16:51:30 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com ; Wed, 21 May 2003 16:51:29 -0500 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 21 May 2003 14:50:36 -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: Wed, 21 May 2003 14:50:35 -0700 Message-ID: <4D7B558499107545BB45044C63822DDEEBDCDF@mvebe001.americas.nokia.com> Thread-Topic: OPEN ISSUE: Nomcom Process Thread-Index: AcMbAlOhIU1vO8qMRfOzPqr9fke+JwE3849g From: To: , , , X-OriginalArrivalTime: 21 May 2003 21:50:36.0517 (UTC) FILETIME=[03048150:01C31FE3] Subject: RE: OPEN ISSUE: Nomcom 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA10010 James, > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, May 15, 2003 9:50 AM > > John, > > Making the names of nominated candidates public has been discussed in > the past and has been rejected for a variety of reasons. Here are > some: > > 1) It would make the process more overtly political, so candidates > would be tempted to lobby for election. It would also tend to attract > candidates who like that kind of process, to the detriment of those > who might be better qualified on technical grounds but are not > comfortable with a more politicized selection process. I think the process is rather political already. Especially something that I am worried about is that it overly based on rumors. I have heard tons of rumors during this NomCom of who is running on which area, and what their chances are. To be honest, I think this is a bit contradictory to the openess of the IETF. > 2) For those candidates who are not selected, there could be the > feeling of having been "defeated". This is especially a problem for > cultures where loss of face is a big issue, and so would serve to > discourage their participation. This must be a cultural issue. I do not think that people _should_ feel defeated if an obviously more competent person wins. I think we are all here for the best of the IETF and not the best of ourselves personally. Running for IESG or IAB should not be of personal prestige, but the will to make thinks work better. If someone feels defeated in the end, I guess that person was not into this for the right reasons. > > Nocomm this year was very proactive about soliciting input on > candidates. Those solicited were asked to keep the names confidential, > and most people agree that this request was followed this year, though > it hasn't been as closely followed in past years. Since IAB and IESG > members standing for re-election are already known, and their record > should be an issue in whether or not they are re-elected, I agree that > making public who is up for re-election would be appropriate, however, > to avoid 1) above, it might make sense to just put out the names of > those I* who are up for re-election, regardless of whether they are > interested in serving again or not. I don't think that would be very helpful. I think people are really interested on the information who is really willing to serve as it may affect their interest to give input to NomCom. Cheers, Jonne. > > jak > > ----- Original Message ----- > From: > To: ; > Sent: Thursday, May 15, 2003 8:59 AM > Subject: RE: OPEN ISSUE: Nomcom Process > > > > Hi Margaret, > > > > I know this has been done in the past, but people nominated (and > accepting the > > nomination) for IESG/IAB positions should be identified. I think, > at a minimum, > > at least current IAB & IESG members who are interested in continuing > should > > be announced. > > > > John > > > > > -----Original Message----- > > > From: ext Margaret Wasserman [mailto:mrw@windriver.com] > > > Sent: 15 May, 2003 18:44 > > > To: problem-statement@alvestrand.no > > > Subject: OPEN ISSUE: Nomcom Process > > > > > > > > > > > > The process document currently says: > > > > > > >We may also need to modify our Nomcom processes so that IETF > > > >participants who are not part of the IETF leadership can have > more > > > >visibility into the Nomcom process and more proportional input > into > > > >leadership selection. [OPEN ISSUE: Do we have consensus that > these > > > >are real problems that need to be solved?] > > > > > > I believe that this is a real problem, and that we should > > > modify our Nomcom processes to do two (related) things: > > > > > > - Give the community more visibility into the > > > process. > > > - Get more feedback on potential candidates from > > > the community. Currently, some candidates > > > are discussed with the leaders (IESG/IAB > > > members and WG chairs), but the greater > > > community doesn't even know who is being > > > considered. > > > > > > Margaret > > > > > > > > > > > > > > > > > > From problem-statement-bounces@alvestrand.no Wed May 21 18: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 SAA11677 for ; Wed, 21 May 2003 18:19:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 75C2B6259A; Thu, 22 May 2003 00:19: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 8B19C62598 for ; Thu, 22 May 2003 00:19: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 h4LMJ2k03552; Wed, 21 May 2003 18:19:03 -0400 (EDT) Date: Wed, 21 May 2003 18:19:02 -0400 From: Keith Moore To: Message-Id: <20030521181902.66676393.moore@cs.utk.edu> In-Reply-To: <4D7B558499107545BB45044C63822DDEEBDCDF@mvebe001.americas.nokia.com> References: <4D7B558499107545BB45044C63822DDEEBDCDF@mvebe001.americas.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: mrw@windriver.com Cc: kempf@docomolabs-usa.com Cc: moore@cs.utk.edu Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Nomcom 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 > > 2) For those candidates who are not selected, there could be the > > feeling of having been "defeated". This is especially a problem for > > cultures where loss of face is a big issue, and so would serve to > > discourage their participation. > > This must be a cultural issue. I do not think that people _should_ > feel defeated if an obviously more competent person wins. what people should feel and what they do feel are probably different. and selection probably shouldn't be based entirely on competence anyway, but also on other factors like "fit" between that individual's skill set and the skills that the nomcom thinks are lacking or would complement other ADs' skills, support from the candidate's employer. > If someone feels > defeated in the end, I guess that person was not into this for the > right reasons. how the candidate feels might not be as important as the way other people mis-interpret the nomcom's action. at any rate, the "losing" candidate already knows he "lost" out to someone else, so he's going to feel "defeated" anyway - the reason we want to keep it private (relatively) is to avoid having the action (mis)interpreted by others. (I write "losing" and "lost" and "defeated" in quotes because the traditional way for someone who has been there to acknowledge someone who has "won" a spot on the IESG is to offer condolences, and it's not unusual to acknowledge someone who has been "defeated" by offering congratulations.) From problem-statement-bounces@alvestrand.no Wed May 21 18:22: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 SAA11742 for ; Wed, 21 May 2003 18:22:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DB7B46259A; Thu, 22 May 2003 00:22:23 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mgw-dax1.ext.nokia.com (unknown [63.78.179.216]) by eikenes.alvestrand.no (Postfix) with ESMTP id 46AC0622A1 for ; Thu, 22 May 2003 00:22:21 +0200 (CEST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])h4LMMJ111845 for ; Wed, 21 May 2003 17:22:20 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com ; Wed, 21 May 2003 17:22:18 -0500 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 21 May 2003 15:21:10 -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: Wed, 21 May 2003 15:21:09 -0700 Message-ID: <4D7B558499107545BB45044C63822DDE0175E0CD@mvebe001.americas.nokia.com> Thread-Topic: OPEN ISSUE: Nomcom Process Thread-Index: AcMf5wPMGRtxVo+uSu2BXBbZJWJp7QAAAbYQ From: To: X-OriginalArrivalTime: 21 May 2003 22:21:10.0310 (UTC) FILETIME=[480B1C60:01C31FE7] Cc: john.loughney@nokia.com Cc: mrw@windriver.com Cc: kempf@docomolabs-usa.com Cc: problem-statement@alvestrand.no Subject: RE: OPEN ISSUE: Nomcom 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA11742 OK, I'm going to fix something without yet reading your mail: > -----Original Message----- > From: ext Keith Moore [mailto:moore@cs.utk.edu] > Sent: Wednesday, May 21, 2003 3:19 PM > To: Soininen Jonne (NET/MtView) > Cc: moore@cs.utk.edu; kempf@docomolabs-usa.com; Loughney John > (NRC/Helsinki); mrw@windriver.com; problem-statement@alvestrand.no > Subject: Re: OPEN ISSUE: Nomcom Process > > > > > 2) For those candidates who are not selected, there could be the > > > feeling of having been "defeated". This is especially a > problem for > > > cultures where loss of face is a big issue, and so would serve to > > > discourage their participation. > > > > This must be a cultural issue. I do not think that people _should_ > > feel defeated if an obviously more competent person wins. _should not_, I meant should not. Sorry about very stupid error in the sentence that totally destroys the message! (*shame*) Sorry about the confusion, Jonne. From problem-statement-bounces@alvestrand.no Wed May 21 18:34: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 SAA12084 for ; Wed, 21 May 2003 18:34:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5C8536259A; Thu, 22 May 2003 00:33:46 +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 68436622A1 for ; Thu, 22 May 2003 00:33:34 +0200 (CEST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])h4LMXW726940 for ; Thu, 22 May 2003 01:33:33 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com ; Thu, 22 May 2003 01:33:32 +0300 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 22 May 2003 01:33:32 +0300 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 21 May 2003 15:32:06 -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: Wed, 21 May 2003 15:32:05 -0700 Message-ID: <4D7B558499107545BB45044C63822DDE0175E0CE@mvebe001.americas.nokia.com> Thread-Topic: OPEN ISSUE: Nomcom Process Thread-Index: AcMf5wPMGRtxVo+uSu2BXBbZJWJp7QAAIWTQ From: To: X-OriginalArrivalTime: 21 May 2003 22:32:06.0362 (UTC) FILETIME=[CF14B3A0:01C31FE8] Cc: john.loughney@nokia.com Cc: mrw@windriver.com Cc: kempf@docomolabs-usa.com Cc: problem-statement@alvestrand.no Subject: RE: OPEN ISSUE: Nomcom 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA12084 Keith, > -----Original Message----- > From: ext Keith Moore [mailto:moore@cs.utk.edu] > Sent: Wednesday, May 21, 2003 3:19 PM > > > 2) For those candidates who are not selected, there could be the > > > feeling of having been "defeated". This is especially a > problem for > > > cultures where loss of face is a big issue, and so would serve to > > > discourage their participation. > > > > This must be a cultural issue. I do not think that people _should_ > > feel defeated if an obviously more competent person wins. Once again I correct that I meant _should not_! (This is when you get careless while writing mails...) > > what people should feel and what they do feel are probably different. > and selection probably shouldn't be based entirely on > competence anyway, > but also on other factors like "fit" between that > individual's skill set > and the skills that the nomcom thinks are lacking or would > complement other ADs' skills, support from the candidate's employer. Agreed, people react differently to different situations. And, of course, there should be no public embarrassment to the person who has been "defeated", which I would say there would not be. I am not implicating that the people that weren't chosen should be publicly fed to pigs... ;) (Why is it that only Jim and I find this amusing. Maybe it tells something about our characters...) > > > If someone feels > > defeated in the end, I guess that person was not into this for the > > right reasons. > > how the candidate feels might not be as important as the way other > people mis-interpret the nomcom's action. at any rate, the "losing" > candidate already knows he "lost" out to someone else, so > he's going to > feel "defeated" anyway - the reason we want to keep it private > (relatively) is to avoid having the action (mis)interpreted by others. I think this should be made clear: Even if you didn't "get" in this time, it may just be that the time was not right, yet and there is nothing wrong with you. However, I would also say that if people are afraid of having their names public during the NomCom just wait when you are the AD. I think it should be (or made) clear to everybody that there are usually multiple people running, and it can be only one of them. Not getting in is definitely no shame! One reason could be, for instance, that the person is an extraordinary WG chair it has been seen more valuable to keep the person in that position than to put her/him to a more 'political' position. > > (I write "losing" and "lost" and "defeated" in quotes because the > traditional way for someone who has been there to acknowledge someone > who has "won" a spot on the IESG is to offer condolences, and it's not > unusual to acknowledge someone who has been "defeated" by offering > congratulations.) I still believe that there are no winners or losers in this game. Except maybe the people who got selected have lost quite a bit of their free time... ;) Cheers, Jonne. From problem-statement-bounces@alvestrand.no Wed May 21 19:08: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 TAA12650 for ; Wed, 21 May 2003 19:08:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 415EA62598; Thu, 22 May 2003 01:08:03 +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 4E5F4622A1 for ; Thu, 22 May 2003 01:08:00 +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 h4LN7vNS019525; Wed, 21 May 2003 16:07:58 -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 AHN13390; Wed, 21 May 2003 16:07:56 -0700 (PDT) Message-Id: <200305212307.AHN13390@mira-sjc5-c.cisco.com> To: Jonne.Soininen@nokia.com From: Melinda Shore In-Reply-To: Message from Jonne.Soininen@nokia.com <4D7B558499107545BB45044C63822DDE0175E0CD@mvebe001.americas.nokia.com> Date: Wed, 21 May 2003 19:07:55 -0400 Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Nomcom 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 This discussion really does belong in nomcom rather than here. Thanks, Melinda From problem-statement-bounces@alvestrand.no Wed May 21 19:29: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 TAA12922 for ; Wed, 21 May 2003 19:29:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DAF856259A; Thu, 22 May 2003 01:28:57 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from nit.isi.edu (nit.isi.edu [128.9.160.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 305A7622A1 for ; Thu, 22 May 2003 01:28:55 +0200 (CEST) Received: (from falk@localhost) by nit.isi.edu (8.11.6/8.11.6) id h4LNSru27956; Wed, 21 May 2003 16:28:53 -0700 Date: Wed, 21 May 2003 16:28:53 -0700 From: Aaron Falk To: Randy Bush Message-ID: <20030521232852.GB27849@isi.edu> Mail-Followup-To: Randy Bush , problem-statement@alvestrand.no References: <96848300.1053520043@new.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Cc: problem-statement@alvestrand.no Subject: Re: what are the real 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 Randy Bush wrote: > > Thanks for your thoughts, Randy. On a related note, I think the > > perception in IETF that we (the IETF community) are stewards of > > the Internet has weakened. This may be the reason for the > > somewhat conservative nature of the IESG. > > > > at least among some iesg members, there is the feeling that > > o while the ietf is supposed to be the steward of the (technical > part of the) internet > > o we perceive that we get massive pushback when we act in a > conservative fashion, as it is perceived as inhibiting vendors, > who are a bit desperate these days. > > o yet we think that the purpose of an sdo is to provide to the > *users* inter-vendor choice through compatibility. so we > wonder how pandering to featuritis of the vendors is serving > the users > > no easy answers. indeed. Randy- You've been around the IETF much longer than I. Do you sense that the level of conservatism in the IESG has increased over time? My perception is that, as more non-computer scientists get on the Internet, it has been viewed as more of a utility, i.e., "it just works." It wouldn't surprise me if there is a reduced tolerance of risk by the IESG to protect these users. In other words, the interpretation of stewardship of the Internet has changed from "let's grow something neat" (or "let 1000 flowers bloom") to "let's keep this cool thing from breaking" (or "let's not confuse the marketplace"). Do you concur? --aaron (PS. If this is too off-topic or omphaloskepsical, hit me with the clue-stick and I'll shut up.) From problem-statement-bounces@alvestrand.no Thu May 22 00:38: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 AAA18381 for ; Thu, 22 May 2003 00:38:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E5F6F62590; Thu, 22 May 2003 06:37:45 +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 B015061C73 for ; Thu, 22 May 2003 06:37:44 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 19Ihpn-000FGt-BI; Wed, 21 May 2003 21:37:43 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 21 May 2003 21:37:42 -0700 To: Aaron Falk References: <96848300.1053520043@new.isi.edu> <20030521232852.GB27849@isi.edu> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: what are the real 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 > You've been around the IETF much longer than I. Do you sense that the > level of conservatism in the IESG has increased over time? it's gone both ways. there are fans of 'let 1000 flowers bloom' and there are 'this is now a service' folk. and, there are folk who are trying to find seriously innovative change. It's perfectly appropriate to be upset. I thought of it in a slightly different way--like a space that we were exploring and, in the early days, we figured out this consistent path through the space: IP, TCP, and so on. What's been happening over the last few years is that the IETF is filling the rest of the space with every alternative approach, not necessarily any better. Every possible alternative is now being written down. And it's not useful. -- Jon Postel randy From problem-statement-bounces@alvestrand.no Thu May 22 03: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 DAA03388 for ; Thu, 22 May 2003 03:29:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 900C262278; Thu, 22 May 2003 09:28:33 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from agitator.ibr.cs.tu-bs.de (ns.ibr.cs.tu-bs.de [134.169.34.18]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2DB2562207 for ; Thu, 22 May 2003 09:28:31 +0200 (CEST) Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) h4M7RwXK018352 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 22 May 2003 09:27:59 +0200 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) h4M7RwZY027194; Thu, 22 May 2003 09:27:58 +0200 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) id h4M7Rwgl027191; Thu, 22 May 2003 09:27:58 +0200 Date: Thu, 22 May 2003 09:27:58 +0200 Message-Id: <200305220727.h4M7Rwgl027191@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: problem-statement@alvestrand.no In-reply-to: <20030514010117.60be2009.moore@cs.utk.edu> (message from Keith Moore on Wed, 14 May 2003 01:01:17 -0400) References: <20030514010117.60be2009.moore@cs.utk.edu> X-IBRFilter-SpamReport: -9.9 () IN_REP_TO,REFERENCES X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Subject: Re: draft-ietf-problem-issue-statement-01.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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: Keith> Wow! This a tremendous improvement. At least on first Keith> reading, I have no serious issues with this version. And it Keith> also seems fairly comprehensive. FYI: I have read this document this morning and I like it. /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 Thu May 22 05:09: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 FAA05228 for ; Thu, 22 May 2003 05:09:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BB2D6625A7; Thu, 22 May 2003 11:07: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 DD2E56259A for ; Thu, 22 May 2003 11:07:35 +0200 (CEST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) h4M97GDI085896 for ; Thu, 22 May 2003 11:07:20 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4M91xrQ276756 for ; Thu, 22 May 2003 11:02:15 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA49752 from ; Thu, 22 May 2003 11:01:57 +0200 Message-Id: <3ECC9222.F0100CBD@hursley.ibm.com> Date: Thu, 22 May 2003 11:02:26 +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: <4D7B558499107545BB45044C63822DDE0175E0C7@mvebe001.americas.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: OPEN ISSUE: Nomcom 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 Jonne.Soininen@nokia.com wrote: > > Hi everybody, > > > -----Original Message----- > > From: ext Bound, Jim [mailto:Jim.Bound@hp.com] > > Sent: Friday, May 16, 2003 4:29 PM > > > > I do not believe we should take this discussion to the NOMCOM that > > process needs fixing too. Our job is to document the problem and the > > NOMCOM has problems. I do believe sending mail to the nomcom with > > specifics is fine but the problems there should be aired here too as > > they affect the very fabric of the only open process we have for the > > community to be able to add or remove IESG members. > > I think as well that the NOMCOM process (as any other process) should be discussed here in this WG. I would say that we have much more information in our hands than we did when the NOMCOM WG started. It may end up doing bit of the work again, and if we come to the same conclusion then fine. However, I believe its worth the trouble. I also thought that the NOMCOM work started with the notion that there is not much to change, and I believe that assumption is not as valid as it was at that time. Jonne, this really puzzles me. I haven't seen any nomcom issue raised on this list that hasn't been debated and decided on the ietf-nomcom list. As Melinda says, if you think there are *new* issues that the nomcom WG has not discussed, the ietf-nomcom list is the place to raise them (urgently, given the status of their draft). Obviously, if we changed the underlying constitution of the IETF, we would have to adapt the nomcom process accordingly, but we aren't anywhere near that point today. Brian From problem-statement-bounces@alvestrand.no Thu May 22 05:16: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 FAA05369 for ; Thu, 22 May 2003 05:16:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D41D76259A; Thu, 22 May 2003 11:15:36 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from d06lmsgate-3.uk.ibm.com (d06lmsgate-3.uk.ibm.com [195.212.29.3]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2B696622AF for ; Thu, 22 May 2003 11:15:34 +0200 (CEST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) h4M9F6uc020576 for ; Thu, 22 May 2003 10:15:09 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4M96xrQ267198 for ; Thu, 22 May 2003 11:06:59 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA66106 from ; Thu, 22 May 2003 11:06:58 +0200 Message-Id: <3ECC934E.2E3C2988@hursley.ibm.com> Date: Thu, 22 May 2003 11:07:26 +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: <4D7B558499107545BB45044C63822DDEEBDCDE@mvebe001.americas.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Jonne.Soininen@nokia.com wrote: > > Hi everybody, > > > -----Original Message----- > > From: ext Keith Moore [mailto:moore@cs.utk.edu] > > Sent: Friday, May 16, 2003 9:02 AM > > > *what sort of bugs, if detected, would make a protocol > > unsuitable for > > > Proposed Standard?* > > > > the way Proposed is treated by industry now, anything that would cause > > problems in wide deployment should make a protocol unsuitable for > > Proposed. > > > > certainly failure to interoperate would be in this list, > > but so would failure to scale, lack of robustness, failure to provide > > adequate security, and a lot of other problems. > > I do not really think it is just the industry that is considering Proposed ready for wide development, but how we are going around in the IETF about the proposed standard actually makes it feel like it should be ready for wide scale implementation. When I first started coming to the IETF back in '99, I first read all the training material on the IETF web page. To my it was quite clear that proposed standard is no way stable, but either draft or full standard would be then really stable. Sadly, I had to be rehabilitated in the IETF to understand that proposed standard is mostly the last stage a protocol ever takes. > > And now for something a bit different: I think we should have a new stability stage (proposed standard?) to the documentation process, where the specification is relatively stable. That would mean that the bugs can be fixed, and the the work has by no means stopped. However, the technical concept would already be quite stable. At the moment, the specifications can change quite a bit in the last stages before going to proposed. The relatively-stable-stage could help the vendors to standart to implement the protocol and find out the bugs, and not to have to change the implementation completely when the next version of the protocol is out. For instance, it could be considered that the specs are "functionally frozen", but the last bugs are to be taken out. > > BTW, yes, I think too this is a real issue. The answer to this is to recycle at Proposed. The last thing we need to do is to add a step to the process. It would be entirely recursive in effect - after a few years, someone would be be asking "shall I implement draft-jonnes-protocol-17.txt, or should I wait for the relatively-stable draft?" We need to remove steps, not add them. Brian From problem-statement-bounces@alvestrand.no Thu May 22 05:50: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 FAA06505 for ; Thu, 22 May 2003 05:50:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2A8D9625A9; Thu, 22 May 2003 11:50:28 +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 763D5622AF for ; Thu, 22 May 2003 11:50:19 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4M9oH924532; Thu, 22 May 2003 12:50:18 +0300 Date: Thu, 22 May 2003 12:50:17 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter In-Reply-To: <3ECC934E.2E3C2988@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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, 22 May 2003, Brian E Carpenter wrote: > > > -----Original Message----- > > > From: ext Keith Moore [mailto:moore@cs.utk.edu] > > > Sent: Friday, May 16, 2003 9:02 AM > > > > *what sort of bugs, if detected, would make a protocol > > > unsuitable for > > > > Proposed Standard?* > > > > > > the way Proposed is treated by industry now, anything that would cause > > > problems in wide deployment should make a protocol unsuitable for > > > Proposed. > > > > > > certainly failure to interoperate would be in this list, > > > but so would failure to scale, lack of robustness, failure to provide > > > adequate security, and a lot of other problems. > > > > I do not really think it is just the industry that is considering Proposed ready for wide development, but how we are going around in the IETF about the proposed standard actually makes it feel like it should be ready for wide scale implementation. When I first started coming to the IETF back in '99, I first read all the training material on the IETF web page. To my it was quite clear that proposed standard is no way stable, but either draft or full standard would be then really stable. Sadly, I had to be rehabilitated in the IETF to understand that proposed standard is mostly the last stage a protocol ever takes. > > > > And now for something a bit different: I think we should have a new stability stage (proposed standard?) to the documentation process, where the specification is relatively stable. That would mean that the bugs can be fixed, and the the work has by no means stopped. However, the technical concept would already be quite stable. At the moment, the specifications can change quite a bit in the last stages before going to proposed. The relatively-stable-stage could help the vendors to standart to implement the protocol and find out the bugs, and not to have to change the implementation completely when the next version of the protocol is out. For instance, it could be considered that the specs are "functionally frozen", but the last bugs are to be taken out. > > > > BTW, yes, I think too this is a real issue. > > The answer to this is to recycle at Proposed. The last thing we need to do > is to add a step to the process. It would be entirely recursive in effect - > after a few years, someone would be be asking "shall I implement > draft-jonnes-protocol-17.txt, or should I wait for the relatively-stable > draft?" > > We need to remove steps, not add them. It cuts both ways. We may either have many smaller steps or only few big ones. If we add a step which should be easy to get to ("Experimental") and actually try to make it so, we might still leave the folks enough incentive to finish it and hone it to get it to the next level ("Proposed Standard") -- or kill it completely as a bad idea. I'm not sure whether that's really a good idea, but neither is the alternative.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From problem-statement-bounces@alvestrand.no Thu May 22 05:59: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 FAA06752 for ; Thu, 22 May 2003 05:59:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E3BFF625BC; Thu, 22 May 2003 11:57:53 +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 D06F5622AF for ; Thu, 22 May 2003 11:57:48 +0200 (CEST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])ESMTP id h4M9vj119392 for ; Thu, 22 May 2003 05:57:46 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10HT60>; Thu, 22 May 2003 11:57:44 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501A9F5E7@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Aaron Falk , Randy Bush Date: Thu, 22 May 2003 11:57:34 +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: what are the real 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 Aaron responds to Randy: > You've been around the IETF much longer than I. Do you sense that the > level of conservatism in the IESG has increased over time? My > perception is that, as more non-computer scientists get on the > Internet, it has been viewed as more of a utility, i.e., "it just > works." It wouldn't surprise me if there is a reduced tolerance of > risk by the IESG to protect these users. In other words, the > interpretation of stewardship of the Internet has changed from "let's > grow something neat" (or "let 1000 flowers bloom") to "let's keep this > cool thing from breaking" (or "let's not confuse the marketplace"). > I don't think that "let's grow a neat thing" and "let a 1000 flowers bloom" are the same thing, are they? Bert From problem-statement-bounces@alvestrand.no Thu May 22 06:58: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 GAA07923 for ; Thu, 22 May 2003 06:58:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2A2EE6256B; Thu, 22 May 2003 12:58:26 +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 4790C622AF for ; Thu, 22 May 2003 12:58:22 +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 DAA33934 for ; Thu, 22 May 2003 03:58:21 -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 Gp80mtE2 Thu, 22 May 2003 03:58:20 -0700 (PDT) Message-ID: <003701c32051$0f230920$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <7D5D48D2CAA3D84C813F5B154F43B15501A9F5E7@nl0006exch001u.nl.lucent.com> Date: Thu, 22 May 2003 05:58:20 -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: what are the real problems 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 Bert and Randy, I was assuming that Aaron's "1000 flowers" reference was to the "Hundred Flowers" campaign in the People's Republic of China - if so, I note that we could kill ninety percent of the ideas and STILL "let 100 flowers blossom"... http://www.megastories.com/china/unueco/flowers.htm Not that letting "100 flowers bloom" was a great idea either, but maybe a 90% fallout rate would be a start? Spencer ----- Original Message ----- From: "Wijnen, Bert (Bert)" To: "Aaron Falk" ; "Randy Bush" Cc: Sent: Thursday, May 22, 2003 4:57 AM Subject: RE: what are the real problems > Aaron responds to Randy: > > > You've been around the IETF much longer than I. Do you sense that the > > level of conservatism in the IESG has increased over time? My > > perception is that, as more non-computer scientists get on the > > Internet, it has been viewed as more of a utility, i.e., "it just > > works." It wouldn't surprise me if there is a reduced tolerance of > > risk by the IESG to protect these users. In other words, the > > interpretation of stewardship of the Internet has changed from "let's > > grow something neat" (or "let 1000 flowers bloom") to "let's keep this > > cool thing from breaking" (or "let's not confuse the marketplace"). > > > > I don't think that "let's grow a neat thing" and "let a 1000 flowers bloom" > are the same thing, are they? > > Bert From problem-statement-bounces@alvestrand.no Thu May 22 07:19: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 HAA08832 for ; Thu, 22 May 2003 07:19:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DAD8C622AF; Thu, 22 May 2003 13:18:30 +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 06487621FB for ; Thu, 22 May 2003 13:18:20 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.4]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id EAA00490; Thu, 22 May 2003 04:18:05 -0700 (PDT) Message-Id: <5.1.0.14.2.20030522070508.04123c60@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 22 May 2003 07:11:33 -0400 To: "Wijnen, Bert (Bert)" From: Margaret Wasserman In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501A9F5E7@nl0006exch001u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: RE: what are the real 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 At 11:57 AM 5/22/2003 +0200, Wijnen, Bert (Bert) wrote: >I don't think that "let's grow a neat thing" and "let a 1000 flowers bloom" >are the same thing, are they? IMO, these aren't the same thing at all... The Postel quote that Randy sent talks about figuring out a "consistent path through the space" vs. "filling the rest of the space with every alternative approach". This resonates with me. We shouldn't be hesitant to undertake new work in new spaces. In those cases, we should try, as a community, to find a consistent path through the new space. There may be no single true path, but we should try to find a consistent path that meets the requirements of practicality and simplicity. In some cases, this may require exploring more than one path, and eventually choosing the one that works. But, we should try to avoid activity that could be considered "filling the rest of the space". Of course, it isn't always easy to tell these things apart, which is why we pay the IESG the big bucks. :-) Margaret It's not al From problem-statement-bounces@alvestrand.no Thu May 22 07: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 HAA08906 for ; Thu, 22 May 2003 07:22:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8BFC0625B9; Thu, 22 May 2003 13:21:49 +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 2F837621FB for ; Thu, 22 May 2003 13:21:47 +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 h4MBLWH3015703 for ; Thu, 22 May 2003 07:21:32 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h4MBLWLw015702 for problem-statement@alvestrand.no; Thu, 22 May 2003 07:21:32 -0400 (EDT) Date: Thu, 22 May 2003 07:21:32 -0400 (EDT) From: Scott Bradner Message-Id: <200305221121.h4MBLWLw015702@newdev.harvard.edu> To: problem-statement@alvestrand.no Subject: RE: what are the real 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 mrw sez: > In some cases, this may require exploring > more than one path, and eventually choosing the one that works or maybe, just maybe, let the people who wnat to use the technology do the choosing not a 1,000 flowers but sometimes 2 or 3 Scott From problem-statement-bounces@alvestrand.no Thu May 22 07:23: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 HAA08932 for ; Thu, 22 May 2003 07:23:14 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 85E5E6257C; Thu, 22 May 2003 13:22:44 +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 BF11F621FB for ; Thu, 22 May 2003 13:22:33 +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 EAA37101 for ; Thu, 22 May 2003 04:22:33 -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 Le90riF2 Thu, 22 May 2003 04:22:32 -0700 (PDT) Message-ID: <004801c32054$70b6dd80$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: Date: Thu, 22 May 2003 06:22: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: OPEN ISSUE: Standards Track 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 We're into specific solutions here, but to return to the drafts... The process document current says: >There is also a more fundamental issue with the IETF's engineering >practices. Although our current standards track contains three >levels of maturity (Proposed Standard, Draft Standard and Full >Standard), we do not have sufficient differentiation regarding the >quality and completeness of documents required at each stage. The >bar is set very high for publication at Proposed Standard, and very >few documents advance beyond this stage. [OPEN ISSUE: Do we have >IETF consensus that this is a problem?] We're hearing proposed solutions to this problem, so it looks like there are folks who agree that it's a problem. Are there folks who DON'T agree that this is a problem? Spencer ----- Original Message ----- From: "Pekka Savola" To: "Brian E Carpenter" Cc: Sent: Thursday, May 22, 2003 4:50 AM Subject: Re: OPEN ISSUE: Standards Track > On Thu, 22 May 2003, Brian E Carpenter wrote: > > > > The answer to this is to recycle at Proposed. The last thing we need to do > > is to add a step to the process. It would be entirely recursive in effect - > > after a few years, someone would be be asking "shall I implement > > draft-jonnes-protocol-17.txt, or should I wait for the relatively-stable > > draft?" > > > > We need to remove steps, not add them. > > It cuts both ways. > > We may either have many smaller steps or only few big ones. > > If we add a step which should be easy to get to ("Experimental") and > actually try to make it so, we might still leave the folks enough > incentive to finish it and hone it to get it to the next level ("Proposed > Standard") -- or kill it completely as a bad idea. > > I'm not sure whether that's really a good idea, but neither is the > alternative.. From problem-statement-bounces@alvestrand.no Thu May 22 08:01: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 IAA10194 for ; Thu, 22 May 2003 08:01:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 52860625C5; Thu, 22 May 2003 14:00:40 +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 CDC47625C3 for ; Thu, 22 May 2003 14:00:37 +0200 (CEST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])h4MC0a713434 for ; Thu, 22 May 2003 15:00:36 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com ; Thu, 22 May 2003 15:00:36 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 22 May 2003 15:00:35 +0300 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 22 May 2003 15:00:35 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 22 May 2003 15:00: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: Thu, 22 May 2003 15:00:34 +0300 Message-ID: Thread-Topic: OPEN ISSUE: Standards Track Thread-Index: AcMgVIVb5E4/1lX2QUOqsHp93krWOQABDTdQ From: To: , X-OriginalArrivalTime: 22 May 2003 12:00:34.0694 (UTC) FILETIME=[C04CC260:01C32059] Subject: RE: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 IAA10194 Hi Spencer, > >There is also a more fundamental issue with the IETF's engineering > >practices. Although our current standards track contains three > >levels of maturity (Proposed Standard, Draft Standard and Full > >Standard), we do not have sufficient differentiation regarding the > >quality and completeness of documents required at each stage. The > >bar is set very high for publication at Proposed Standard, and very > >few documents advance beyond this stage. [OPEN ISSUE: Do we have > >IETF consensus that this is a problem?] > > We're hearing proposed solutions to this problem, so it looks like there > are folks who agree that it's a problem. > > Are there folks who DON'T agree that this is a problem? OK, I'll bite. This may be a problem, but I don't see this problem as being on the critical path of problems we should solve. I am not sure how changing the above will help us produce useful & timely standards. The reason I say this is because other organizations, companies & marketers are already quite happy to take IETF drafts into use, even if these have no permanent status. I would not be opposed to cleaning up our standards track process, because I think it would be useful - but I see this a smaller problem as compared to some others ... John PS - on a related note, does anyone think it could be useful to try to make Experimental RFCs less of a second-class citizen? My feeling is that there is some work we may not want to completely embrace with a standards designation, but something that lets folks go out & trial things and come back with their findings (note - this comment implies that there are those who think the label 'Experimental' is almost as bad as sending something to the IRTF!) From problem-statement-bounces@alvestrand.no Thu May 22 08:03: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 IAA10308 for ; Thu, 22 May 2003 08:03:30 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8BE9D625BE; Thu, 22 May 2003 14:02:57 +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 B3F4D625B8 for ; Thu, 22 May 2003 14:02:53 +0200 (CEST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])h4MC2r716296 for ; Thu, 22 May 2003 15:02:53 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com ; Thu, 22 May 2003 15:02:52 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 22 May 2003 15:02:52 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 22 May 2003 15:02:52 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 22 May 2003 15:02: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: Thu, 22 May 2003 15:02:51 +0300 Message-ID: Thread-Topic: what are the real problems Thread-Index: AcMgWWkjOmRW4uOHQHeg9H9fl/AekAAAFoAg From: To: , X-OriginalArrivalTime: 22 May 2003 12:02:51.0845 (UTC) FILETIME=[120C5750:01C3205A] Subject: RE: what are the real 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA10308 Hi Scott, > > In some cases, this may require exploring > > more than one path, and eventually choosing the one that works > > or maybe, just maybe, let the people who wnat to use the technology > do the choosing > > not a 1,000 flowers but sometimes 2 or 3 I agree - I'm not a rabid free-market person, but I do think it is appropriate to allow users of the technology to have some say in this; and that may require allowing 2 or 3 protocols that do similar things. John From problem-statement-bounces@alvestrand.no Thu May 22 08:34: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 IAA11305 for ; Thu, 22 May 2003 08:34:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E40EE625B8; Thu, 22 May 2003 14:34:22 +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 9E8F2621FB for ; Thu, 22 May 2003 14:34:17 +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 19IpGu-0004p2-00; Thu, 22 May 2003 05:34:12 -0700 Date: Thu, 22 May 2003 08:33:04 -0400 From: Keith Moore To: Scott Bradner Message-Id: <20030522083304.5399ba76.moore@cs.utk.edu> In-Reply-To: <200305221121.h4MBLWLw015702@newdev.harvard.edu> References: <200305221121.h4MBLWLw015702@newdev.harvard.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 Subject: Re: what are the real 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 > > In some cases, this may require exploring > > more than one path, and eventually choosing the one that works > > or maybe, just maybe, let the people who wnat to use the technology > do the choosing > > not a 1,000 flowers but sometimes 2 or 3 not saying it's always a bad idea, but I can think of cases where it's worked poorly. cell phone service in the US is one example; instant messaging is another. questions which might be relevant in a particular case: - will the choices actually be made by the users based on how well a protocol suits their needs, or for some other reason which forces the protocol choice? - will competition in the marketplace between multiple protocols result in feature refinement? - will competition in the marketplace between multiple protocols result in eventual de facto standardization? - will it be easy for users to migrate from one protocol to another as the market decides which ones are better, or will such migration be too onerous for some reason? when a vendor tries to push its own protocol or protocol variant often it seems to me that the goal is to limit consumer choice. From problem-statement-bounces@alvestrand.no Thu May 22 08:39: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 IAA11396 for ; Thu, 22 May 2003 08:39:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 64109625C9; Thu, 22 May 2003 14:38:41 +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 8D739621FB for ; Thu, 22 May 2003 14:38:28 +0200 (CEST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])ESMTP id h4MCcQ128549 for ; Thu, 22 May 2003 08:38:26 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10HYDJ>; Thu, 22 May 2003 14:38:25 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501A9F647@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: john.loughney@nokia.com, sob@harvard.edu, problem-statement@alvestrand.no Date: Thu, 22 May 2003 14:38:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: what are the real 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 > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: donderdag 22 mei 2003 14:03 > To: sob@harvard.edu; problem-statement@alvestrand.no > Subject: RE: what are the real problems > > > Hi Scott, > > > > In some cases, this may require exploring > > > more than one path, and eventually choosing the one that works > > > > or maybe, just maybe, let the people who wnat to use the technology > > do the choosing > > > > not a 1,000 flowers but sometimes 2 or 3 > > I agree - I'm not a rabid free-market person, but I do think it is > appropriate to allow users of the technology to have some say in this; > and that may require allowing 2 or 3 protocols that do similar things. > I suspect we're starting to diverge. My last comment on this is: If we can absolutely not agree on the single best solution, then probably gaining some experience with 2 (or 3 ??) solutions may make sense. To do so... I would say, let us put them in Experimental stage, cause apparently we know not ebough to make up our mind on what should be the standard. Bert From problem-statement-bounces@alvestrand.no Thu May 22 08:39: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 IAA11411 for ; Thu, 22 May 2003 08:39:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 77B5D625CF; Thu, 22 May 2003 14:39:26 +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 BF11E621FB for ; Thu, 22 May 2003 14:39:23 +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 19IpLn-0006a4-00; Thu, 22 May 2003 05:39:15 -0700 Date: Thu, 22 May 2003 08:38:07 -0400 From: Keith Moore To: Brian E Carpenter Message-Id: <20030522083807.5a36ac33.moore@cs.utk.edu> In-Reply-To: <3ECC934E.2E3C2988@hursley.ibm.com> References: <4D7B558499107545BB45044C63822DDEEBDCDE@mvebe001.americas.nokia.com> <3ECC934E.2E3C2988@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: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 need to remove steps, not add them. actually I also think that we need one or two baby steps, prior to what we now think of as proposed, to ensure that certain considerations get dealt with early in the design phase, and also to ensure that proposals get wide review long before the Last Call for proposed. From problem-statement-bounces@alvestrand.no Thu May 22 09:44: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 JAA13694 for ; Thu, 22 May 2003 09:44:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4DAF1625D4; Thu, 22 May 2003 15:44:01 +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 AB414625C6 for ; Thu, 22 May 2003 15:43:59 +0200 (CEST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) h4MDhjlr040234 for ; Thu, 22 May 2003 15:43:47 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4MDgOrQ170488 for ; Thu, 22 May 2003 15:42:24 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA36696 from ; Thu, 22 May 2003 15:42:22 +0200 Message-Id: <3ECCD3DA.35505B60@hursley.ibm.com> Date: Thu, 22 May 2003 15:42: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: problem-statement@alvestrand.no References: <4D7B558499107545BB45044C63822DDEEBDCDE@mvebe001.americas.nokia.com> <20030522083807.5a36ac33.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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: > > > We need to remove steps, not add them. > > actually I also think that we need one or two baby steps, prior to what > we now think of as proposed, to ensure that certain considerations > get dealt with early in the design phase, and also to ensure that > proposals get wide review long before the Last Call for proposed. Agreed. But these problems are clearly identified in the problem statement draft (and clearly targetted by at least one extant proposed solution). Brian From problem-statement-bounces@alvestrand.no Thu May 22 09:49: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 JAA13920 for ; Thu, 22 May 2003 09:49:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED243625D8; Thu, 22 May 2003 15:49:09 +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 A238E625C6 for ; Thu, 22 May 2003 15:49:02 +0200 (CEST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) h4MDmklr083030 for ; Thu, 22 May 2003 15:48:48 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4MDm2rQ246690 for ; Thu, 22 May 2003 15:48:02 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA61674 from ; Thu, 22 May 2003 15:48:01 +0200 Message-Id: <3ECCD52D.7E62A303@hursley.ibm.com> Date: Thu, 22 May 2003 15:48:29 +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: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, you're correct, but the fact is that viewed from the outside, the set of RFCs looks like a shambles, and in terms of maintaining our position as *the* Internet standards body, we'd better clear that up. I think it is a serious problem, in terms of persuading the industry as a whole that the IETF is doing a good enough job to recieve the support we need. So it needs to be on the list, if not at the top of the list. Brian john.loughney@nokia.com wrote: > > Hi Spencer, > > > >There is also a more fundamental issue with the IETF's engineering > > >practices. Although our current standards track contains three > > >levels of maturity (Proposed Standard, Draft Standard and Full > > >Standard), we do not have sufficient differentiation regarding the > > >quality and completeness of documents required at each stage. The > > >bar is set very high for publication at Proposed Standard, and very > > >few documents advance beyond this stage. [OPEN ISSUE: Do we have > > >IETF consensus that this is a problem?] > > > > We're hearing proposed solutions to this problem, so it looks like there > > are folks who agree that it's a problem. > > > > Are there folks who DON'T agree that this is a problem? > > OK, I'll bite. This may be a problem, but I don't see this problem > as being on the critical path of problems we should solve. I am not sure > how changing the above will help us produce useful & timely standards. > > The reason I say this is because other organizations, companies & marketers > are already quite happy to take IETF drafts into use, even if these have > no permanent status. > > I would not be opposed to cleaning up our standards track process, because > I think it would be useful - but I see this a smaller problem as compared > to some others ... > > John > > PS - on a related note, does anyone think it could be useful to try to make > Experimental RFCs less of a second-class citizen? My feeling is that > there is some work we may not want to completely embrace with a standards > designation, but something that lets folks go out & trial things and > come back with their findings (note - this comment implies that there > are those who think the label 'Experimental' is almost as bad as sending > something to the IRTF!) From problem-statement-bounces@alvestrand.no Thu May 22 10:01: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 KAA14334 for ; Thu, 22 May 2003 10:01:44 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 51998625C6; Thu, 22 May 2003 16:01:14 +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 250CA62579 for ; Thu, 22 May 2003 16:01:12 +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 h4ME17OO009168; Thu, 22 May 2003 10:01:07 -0400 (EDT) Message-Id: <200305221401.h4ME17OO009168@rtp-core-1.cisco.com> To: Randy Bush In-reply-to: Your message of Wed, 21 May 2003 21:37:42 -0700. 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: Thu, 22 May 2003 10:01:09 -0400 From: Eric Rosen Cc: problem-statement@alvestrand.no Cc: Aaron Falk Subject: Re: what are the real problems 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 It would certainly be interesting to know exactly which of the IESG members think that they are on a mission to protect the users against exploitation by the vendors. Naturally, anyone who is on such a mission will think it very important to replace the operation of the marketplace by his personal vision of the future, and will do whatever he can to purge the IETF of other views. But let's not pretend that such an overtly political agenda has anything to do with technical quality. And people still wonder why the IESG is not trusted! From problem-statement-bounces@alvestrand.no Thu May 22 10:14: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 KAA15705 for ; Thu, 22 May 2003 10:14:44 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B7274625DF; Thu, 22 May 2003 16:14:14 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by eikenes.alvestrand.no (Postfix) with ESMTP id 56E53625DE for ; Thu, 22 May 2003 16:14:11 +0200 (CEST) Received: by smtp1.arin.net (Postfix, from userid 5003) id ECFFF36C; Thu, 22 May 2003 10:13:58 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 863AF320; Thu, 22 May 2003 10:13:58 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 268628; Thu, 22 May 2003 10:12:49 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Thu, 22 May 2003 10:14:04 -0400 To: Randy Bush From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_00_01 version=2.43-arin1 Cc: problem-statement@alvestrand.no Subject: Re: what are the real 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 At 11:08 -0700 5/21/03, Randy Bush wrote: > > the ietf's goal is to produce high quality, relevant, and timely > standards for internet technology. With limited time, I've off and on tracked this mail list. From this thread I can see two different states in which the IETF can wind up, both meeting the above goal, yet the problems in achieving one state are different from one achieving the other state. (These two states do not necessarily constitute an exhaustive list.) One state is being a strongly authoritative SDO, being a leader to the vendor and operator community through quality and timely documents describing protocols and practices. Getting there from here means solving the perceived-by-some latency, hidden criterion, and opaque decision making process. (Note "perceived-by-some.") The other state is a being an engineering collective that fosters goodness in individual contributions via a strong mentoring program, letting the market decide from there on. The problem to solve before reaching this state is the reversal of the IETF's long standing tendency to downgrade education as part of its mission. (This state is much lighter weight than the first, which is why it might be a viable alternative.) Both states can achieve the goal as stated above, but the different approaches to doing so require different problems to be solved. Perhaps the state in which we wind up will depend on which problems are easier to solve. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Your office is *not* a reality-based sit-com TV show. From problem-statement-bounces@alvestrand.no Thu May 22 10:44: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 KAA16772 for ; Thu, 22 May 2003 10:44:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9369F625C0; Thu, 22 May 2003 16:44:06 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from nit.isi.edu (nit.isi.edu [128.9.160.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id 90983621FB for ; Thu, 22 May 2003 16:43:56 +0200 (CEST) Received: (from falk@localhost) by nit.isi.edu (8.11.6/8.11.6) id h4MEhqw31786; Thu, 22 May 2003 07:43:52 -0700 Date: Thu, 22 May 2003 07:43:52 -0700 From: Aaron Falk To: "Wijnen, Bert (Bert)" Message-ID: <20030522144352.GC29088@isi.edu> Mail-Followup-To: "Wijnen, Bert (Bert)" , Randy Bush , problem-statement@alvestrand.no References: <7D5D48D2CAA3D84C813F5B154F43B15501A9F5E7@nl0006exch001u.nl.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501A9F5E7@nl0006exch001u.nl.lucent.com> User-Agent: Mutt/1.4i Cc: Randy Bush Cc: problem-statement@alvestrand.no Subject: Re: what are the real 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 Wijnen, Bert (Bert) wrote: > Aaron responds to Randy: > > > In other words, the interpretation of stewardship of the Internet > > has changed from "let's grow something neat" (or "let 1000 flowers > > bloom") to "let's keep this cool thing from breaking" (or "let's > > not confuse the marketplace"). > > > > I don't think that "let's grow a neat thing" and "let a 1000 flowers bloom" > are the same thing, are they? > Bert- My suggestion, of which I was seeking confirmation, was that both statements represented the attitude held in former days not that they were synonymous. Using "and" rather than "or" would have been clearer. (I can be a lousy editor) --aaron (gratefully not speaking for the RFC Editor :) From problem-statement-bounces@alvestrand.no Thu May 22 11:16: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 LAA18153 for ; Thu, 22 May 2003 11:16:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AE382625A2; Thu, 22 May 2003 17:16:13 +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 35321625A2 for ; Thu, 22 May 2003 17:16:04 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 19IrnV-0005yb-W2; Thu, 22 May 2003 08:16:02 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 22 May 2003 08:16:01 -0700 To: Scott Bradner References: <200305221121.h4MBLWLw015702@newdev.harvard.edu> Message-Id: Cc: problem-statement@alvestrand.no Subject: RE: what are the real 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 >> In some cases, this may require exploring more than one path, >> and eventually choosing the one that works > or maybe, just maybe, let the people who wnat to use the technology > do the choosing which is precisely why we have standards organizations randy From problem-statement-bounces@alvestrand.no Thu May 22 11:18: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 LAA18203 for ; Thu, 22 May 2003 11:18:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 43F22625DE; Thu, 22 May 2003 17:17:47 +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 886CB625DB for ; Thu, 22 May 2003 17:17:44 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 19Irp8-00061N-WA; Thu, 22 May 2003 08:17:43 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 22 May 2003 08:17:42 -0700 To: "Spencer Dawkins" References: <004801c32054$70b6dd80$0200a8c0@DFNJGL21> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 process document current says: > >> There is also a more fundamental issue with the IETF's engineering >> practices. Although our current standards track contains three >> levels of maturity (Proposed Standard, Draft Standard and Full >> Standard), we do not have sufficient differentiation regarding the >> quality and completeness of documents required at each stage. The >> bar is set very high for publication at Proposed Standard, and very >> few documents advance beyond this stage. [OPEN ISSUE: Do we have >> IETF consensus that this is a problem?] > > We're hearing proposed solutions to this problem, so it looks like there > are folks who agree that it's a problem. > > Are there folks who DON'T agree that this is a problem? how does this 'problem' do damage to the ietf's goal is to produce high quality, relevant, and timely standards for internet technology. randy From problem-statement-bounces@alvestrand.no Thu May 22 11:22: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 LAA18270 for ; Thu, 22 May 2003 11:22:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D551A625E6; Thu, 22 May 2003 17:22:15 +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 B9C9D625DB for ; Thu, 22 May 2003 17:22:13 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 19IrtU-00068s-Ju; Thu, 22 May 2003 08:22:12 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 22 May 2003 08:22:11 -0700 To: Keith Moore References: <200305221121.h4MBLWLw015702@newdev.harvard.edu> <20030522083304.5399ba76.moore@cs.utk.edu> Message-Id: Cc: problem-statement@alvestrand.no Cc: Scott Bradner Subject: Re: what are the real 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 > - will competition in the marketplace between multiple protocols > result in feature refinement? more to the point, will competition in the marketplace between *companies' marketing departments* obscure and over-ride the differences in technical quality and longevity of the protocols? > when a vendor tries to push its own protocol or protocol variant > often it seems to me that the goal is to limit consumer choice. bingo! randy From problem-statement-bounces@alvestrand.no Thu May 22 11:40: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 LAA18646 for ; Thu, 22 May 2003 11:40:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 570DA62579; Thu, 22 May 2003 17:40:06 +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 21BF862573 for ; Thu, 22 May 2003 17:39:57 +0200 (CEST) Received: from medea.wz-berlin.de ([193.174.6.5]) by athene.wz-berlin.de with esmtp (Exim 4.20) id 19IsAe-0004Ap-R9; Thu, 22 May 2003 17:39:56 +0200 Received: from ERDE/SpoolDir by medea.wz-berlin.de (Mercury 1.48); 22 May 03 17:39:57 +0200 Received: from SpoolDir by ERDE (Mercury 1.48); 22 May 03 17:39:33 +0200 From: "Jeanette Hofmann" Organization: Wissenschaftszentrum Berlin To: Margaret Wasserman Date: Thu, 22 May 2003 17:39:32 +0200 MIME-Version: 1.0 Message-ID: <3ECD0B56.21106.E8807D@localhost> Priority: normal In-reply-to: <5.1.0.14.2.20030522070508.04123c60@mail.windriver.com> References: <7D5D48D2CAA3D84C813F5B154F43B15501A9F5E7@nl0006exch001u.nl .lucent.com> X-mailer: Pegasus Mail for Windows (v4.11) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Cc: problem-statement@alvestrand.no Subject: RE: what are the real 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 On 22 May 2003 at 7:11, Margaret Wasserman wrote: > > At 11:57 AM 5/22/2003 +0200, Wijnen, Bert (Bert) wrote: > >I don't think that "let's grow a neat thing" and "let a 1000 flowers bloom" > >are the same thing, are they? > > IMO, these aren't the same thing at all... > > The Postel quote that Randy sent talks about figuring out a > "consistent path through the space" vs. "filling the rest of > the space with every alternative approach". This resonates > with me. The problem with consistency is that it depends so much on context. Whether step 2 is really consistent with step 1 only shows once step 3 is implemented. Consistency can be judged best in retrospect. If used to decide on future directions, consistency turns easily into a rhetoric weapon to exclude other valid options. It is probably a myth to assume that the development of TCP/IP followed principles of consistency. It just looks that way in hindsight. There is no inherent logic in further development of network architecture. What is needed as guideline is a mission that defines core values and principles, as outlined in the process document by Margaret. Jeanette > > We shouldn't be hesitant to undertake new work in new > spaces. In those cases, we should try, as a community, > to find a consistent path through the new space. There > may be no single true path, but we should try to find a > consistent path that meets the requirements of practicality > and simplicity. In some cases, this may require exploring > more than one path, and eventually choosing the one that > works. > > But, we should try to avoid activity that could be considered > "filling the rest of the space". > > Of course, it isn't always easy to tell these things apart, > which is why we pay the IESG the big bucks. :-) > > Margaret > > > > It's not al > > > > From problem-statement-bounces@alvestrand.no Thu May 22 11:42: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 LAA18686 for ; Thu, 22 May 2003 11:42:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 374BF625DD; Thu, 22 May 2003 17:41:34 +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 52E3762573 for ; Thu, 22 May 2003 17:41: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 h4MFeBk26715; Thu, 22 May 2003 11:40:11 -0400 (EDT) Date: Thu, 22 May 2003 11:40:11 -0400 From: Keith Moore To: Randy Bush Message-Id: <20030522114011.6eeeaa28.moore@cs.utk.edu> In-Reply-To: References: <004801c32054$70b6dd80$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: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 is also a more fundamental issue with the IETF's engineering > >> practices. Although our current standards track contains three > >> levels of maturity (Proposed Standard, Draft Standard and Full > >> Standard), we do not have sufficient differentiation regarding the > >> quality and completeness of documents required at each stage. The > >> bar is set very high for publication at Proposed Standard, and very > >> few documents advance beyond this stage. [OPEN ISSUE: Do we have > >> IETF consensus that this is a problem?] > > > > We're hearing proposed solutions to this problem, so it looks like > > there are folks who agree that it's a problem. > > > > Are there folks who DON'T agree that this is a problem? > > how does this 'problem' do damage to > > the ietf's goal is to produce high quality, relevant, and timely > standards for internet technology. well, what we currently have is for most purposes a single stage of review. perhaps we'd produce higher quality and more relevant documents if we imposed some earlier review, and perhaps we'd get those documents done in a more timely fashion if the early reviews identified problems that are expensive (or time consuming) to fix if not discovered until later. From problem-statement-bounces@alvestrand.no Thu May 22 11:59: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 LAA19241 for ; Thu, 22 May 2003 11:59:29 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7E67D625E7; Thu, 22 May 2003 17:58:56 +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 CB68A625E9 for ; Thu, 22 May 2003 17:58:52 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 19IsSw-00079o-GQ; Thu, 22 May 2003 08:58:50 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 22 May 2003 08:58:49 -0700 To: Keith Moore References: <004801c32054$70b6dd80$0200a8c0@DFNJGL21> <20030522114011.6eeeaa28.moore@cs.utk.edu> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 is also a more fundamental issue with the IETF's engineering >>>> practices. Although our current standards track contains three >>>> levels of maturity (Proposed Standard, Draft Standard and Full >>>> Standard), we do not have sufficient differentiation regarding the >>>> quality and completeness of documents required at each stage. The >>>> bar is set very high for publication at Proposed Standard, and very >>>> few documents advance beyond this stage. [OPEN ISSUE: Do we have >>>> IETF consensus that this is a problem?] >>> >>> We're hearing proposed solutions to this problem, so it looks like >>> there are folks who agree that it's a problem. >>> >>> Are there folks who DON'T agree that this is a problem? >> >> how does this 'problem' do damage to >> >> the ietf's goal is to produce high quality, relevant, and timely >> standards for internet technology. > > well, what we currently have is for most purposes a single stage of > review. perhaps we'd produce higher quality and more relevant documents > if we imposed some earlier review, and perhaps we'd get those documents > done in a more timely fashion if the early reviews identified problems > that are expensive (or time consuming) to fix if not discovered until > later. i do not disagree with you. but that is not at all what the problem statement above says to me it seems to say that o the bar is too high o there is insufficient differentiation between ps, ds, and fs with which i disagree randy From problem-statement-bounces@alvestrand.no Thu May 22 12:02: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 MAA19369 for ; Thu, 22 May 2003 12:02:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9E075625E5; Thu, 22 May 2003 18:01: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 2620F625D6 for ; Thu, 22 May 2003 18:01:52 +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 JAA05783; Thu, 22 May 2003 09:01:50 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4MG1nk12096; Thu, 22 May 2003 09:01:49 -0700 X-mProtect: <200305221601> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqb4vJx; Thu, 22 May 2003 09:01:48 PDT Message-ID: <3ECCF46D.E09436DE@iprg.nokia.com> Date: Thu, 22 May 2003 09:01:49 -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: Randy Bush References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, I think it is a serious problem. Lengthy gestation periods for Proposed Standards means that we don't get experience with using the technology except in limited deployments and labs. With faster publication of a Proposed Standard that would be subject to further refinement, we would get better operational experience sooner, and overall faster progress. As it is, even with the too-long process, we see that hasty decisions are taken at the end to satisfy all possible stakeholders, even those who have not done any work on the protocol. Since it takes so long to do the process, at the end the hardest working people are burned out and just want to get it over with, so compromise is shunned because that takes too much discussion, so the specification just gets axed in order to avoid debate. This leads to some unwise elimination of tested, interoperable, known-good features only in the name of getting the damned process finished. I'd prefer more interoperability assurance than longer processing time. If dozens of teams can build it and get good results, I think that says something more relevant about the readiness of the specification, than whether anyone in any corner of the IESG can think of something that might possibly go wrong under some hypothetical set of circumstances. Of course I do not mean that this is all black and white, and that interoperability trumps all architectural considerations. I just think it's tilted much too far in the "what if" direction than the "what is" direction. As an example, I think it was a terrible mistake to delay Mobile IPv6 for so long pending the completion of the world's most sophisticated and super robost security solution (slight exaggeration, but ...). I guess I don't have to describe the effect this can have in a world moving at what used to be called "Internet speed". Regards, Charlie P. Randy Bush wrote: > > > The process document current says: > > > >> There is also a more fundamental issue with the IETF's engineering > >> practices. Although our current standards track contains three > >> levels of maturity (Proposed Standard, Draft Standard and Full > >> Standard), we do not have sufficient differentiation regarding the > >> quality and completeness of documents required at each stage. The > >> bar is set very high for publication at Proposed Standard, and very > >> few documents advance beyond this stage. [OPEN ISSUE: Do we have > >> IETF consensus that this is a problem?] > > > > We're hearing proposed solutions to this problem, so it looks like there > > are folks who agree that it's a problem. > > > > Are there folks who DON'T agree that this is a problem? > > how does this 'problem' do damage to > > the ietf's goal is to produce high quality, relevant, and timely > standards for internet technology. > > randy From problem-statement-bounces@alvestrand.no Thu May 22 12: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 MAA19500 for ; Thu, 22 May 2003 12:07:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 996B5625D6; Thu, 22 May 2003 18:07:21 +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 EBA1E62573 for ; Thu, 22 May 2003 18:07:14 +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 h4MG5vk27191; Thu, 22 May 2003 12:05:57 -0400 (EDT) Date: Thu, 22 May 2003 12:05:57 -0400 From: Keith Moore To: Randy Bush Message-Id: <20030522120557.46459fd2.moore@cs.utk.edu> In-Reply-To: References: <004801c32054$70b6dd80$0200a8c0@DFNJGL21> <20030522114011.6eeeaa28.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 Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, what we currently have is for most purposes a single stage of > > review. perhaps we'd produce higher quality and more relevant > > documents if we imposed some earlier review, and perhaps we'd get > > those documents done in a more timely fashion if the early reviews > > identified problems that are expensive (or time consuming) to fix if > > not discovered until later. > > i do not disagree with you. > > but that is not at all what the problem statement above says to me > it seems to say that > o the bar is too high > o there is insufficient differentiation between ps, ds, and fs > with which i disagree yes, I think that bit of the problem statement needs some refinement. Keith From problem-statement-bounces@alvestrand.no Thu May 22 12:09: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 MAA19548 for ; Thu, 22 May 2003 12:09:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 51D5A625C3; Thu, 22 May 2003 18:08:57 +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 6BFD4625E9 for ; Thu, 22 May 2003 18:08:47 +0200 (CEST) Received: from [129.46.77.29] (129.46.77.29) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.1b1); Thu, 22 May 2003 11:09:12 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 6.0a15] Date: Thu, 22 May 2003 09:08:43 -0700 To: Randy Bush From: Pete Resnick Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: problem-statement@alvestrand.no Cc: Keith Moore Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 5/22/03 at 8:58 AM -0700, Randy Bush wrote: >>perhaps we'd produce higher quality and more relevant documents if >>we imposed some earlier review, and perhaps we'd get those >>documents done in a more timely fashion if the early reviews... > >i do not disagree with you. >[...] > o the bar is too high >[...] >with which i disagree How about "the first bar is too high" or "we need a new lower initial bar"? -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From problem-statement-bounces@alvestrand.no Thu May 22 12:11: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 MAA19656 for ; Thu, 22 May 2003 12:11:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C9E9262573; Thu, 22 May 2003 18:11: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 677F762206 for ; Thu, 22 May 2003 18:11: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 h4MG9lk27206; Thu, 22 May 2003 12:09:48 -0400 (EDT) Date: Thu, 22 May 2003 12:09:47 -0400 From: Keith Moore To: "Charles E. Perkins" Message-Id: <20030522120947.3d484944.moore@cs.utk.edu> In-Reply-To: <3ECCF46D.E09436DE@iprg.nokia.com> References: <3ECCF46D.E09436DE@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: randy@psg.com Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 an example, I think it was a terrible mistake to delay > Mobile IPv6 for so long pending the completion of the world's > most sophisticated and super robost security solution (slight > exaggeration, but ...). I guess I don't have to describe the > effect this can have in a world moving at what used to be > called "Internet speed". then again, we have plenty of experience that - security holes *will* be exploited, and - vendors will avoid implementation of security if allowed to do so, even if it subjects their customers to greatly increased risk (ask yourself: why is it so easy for viruses to propagate by email?) From problem-statement-bounces@alvestrand.no Thu May 22 12: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 MAA19688 for ; Thu, 22 May 2003 12:12:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AAAE7625EF; Thu, 22 May 2003 18:11:48 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9A71462206 for ; Thu, 22 May 2003 18:11:46 +0200 (CEST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id CFAAC1B203C; Thu, 22 May 2003 10:09:08 -0500 (CDT) Date: Thu, 22 May 2003 11:11:44 -0500 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Pekka Savola From: Ted Lemon In-Reply-To: Message-Id: <14EE7C92-8C70-11D7-BBB3-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Cc: Brian E Carpenter Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 we add a step which should be easy to get to ("Experimental") and > actually try to make it so, we might still leave the folks enough > incentive to finish it and hone it to get it to the next level > ("Proposed > Standard") -- or kill it completely as a bad idea. Right now I think most people think of "Experimental" as "never going to be a standard." I know that's not what it was originally intended to mean, but in practice that seems to be how people think of it. I'm reluctant to provide a specific example here because the one I can think of is so controversial, but a lot of you probably remember the conversation anyway. From problem-statement-bounces@alvestrand.no Thu May 22 12:14: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 MAA19753 for ; Thu, 22 May 2003 12:14:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A883D625EA; Thu, 22 May 2003 18:14: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 9D33362206 for ; Thu, 22 May 2003 18:14:22 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 19Ishn-0007b4-9n; Thu, 22 May 2003 09:14:11 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 22 May 2003 09:14:10 -0700 To: Pete Resnick References: <004801c32054$70b6dd80$0200a8c0@DFNJGL21> <20030522114011.6eeeaa28.moore@cs.utk.edu> Message-Id: Cc: problem-statement@alvestrand.no Cc: Keith Moore Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > How about "the first bar is too high" or "we need a new lower > initial bar"? [ i *really* don't like to post too much to the list. but i guess it's my day in the barrel. so apologies. ] i think the real issue may be the difference between what is drafted and what is passed as PS. that is perceived as "it is very hard to get a document to PS." i suspect this difference may be as much or more caused by the input quality and relevance as it is by the level of the bar. if so, this is a core problem that clearly affects the ietf's goals. randy From problem-statement-bounces@alvestrand.no Thu May 22 12:24: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 MAA20085 for ; Thu, 22 May 2003 12:24:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4BDFC625ED; Thu, 22 May 2003 18:23:56 +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 D1FA262206 for ; Thu, 22 May 2003 18:23: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 JAA07265; Thu, 22 May 2003 09:23:50 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4MGNnu01664; Thu, 22 May 2003 09:23:49 -0700 X-mProtect: <200305221623> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQEoPze; Thu, 22 May 2003 09:23:48 PDT Message-ID: <3ECCF994.48A310B8@iprg.nokia.com> Date: Thu, 22 May 2003 09:23:48 -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: <20030522120947.3d484944.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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: > then again, we have plenty of experience that > > - security holes *will* be exploited, and > - vendors will avoid implementation of security if allowed to do so, > even if it subjects their customers to greatly increased risk These considerations do NOT apply to the situation in Mobile IPv6. This list is NOT the place for me to explain why. Plus, your counterpoint has no relevance to anything I tried to say, thus I view it purely as setting up a strawman. > (ask yourself: why is it so easy for viruses to propagate by email?) Because of certain operating systems features, mainly. There is no point to a specification that says viruses MUST NOT be included in e-mail attachments. And, yes, I understand that further e-mail specification _might_ prevent _some_ viral infections. Regards, Charlie P. From problem-statement-bounces@alvestrand.no Thu May 22 12:42: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 MAA20690 for ; Thu, 22 May 2003 12:42:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 439D7625D9; Thu, 22 May 2003 18:41:33 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by eikenes.alvestrand.no (Postfix) with ESMTP id 49A7562206 for ; Thu, 22 May 2003 18:41:31 +0200 (CEST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 0B8381B2148 for ; Thu, 22 May 2003 10:38:54 -0500 (CDT) Date: Thu, 22 May 2003 11:41:30 -0500 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Ted Lemon To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit In-Reply-To: <20030522120947.3d484944.moore@cs.utk.edu> Message-Id: <3D4EDCCA-8C74-11D7-BBB3-00039367340A@nominum.com> X-Mailer: Apple Mail (2.552) Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > (ask yourself: why is it so easy for viruses to propagate by email?) Because of buggy programs that execute code in email messages, which has exactly zero to do with SMTP, POP or IMAP. :'/ BTW, implementations of POP and SMTP security features in both open-source and vendor-supplied mailers seem to be getting pretty advanced at this stage, although there is still more work to do. From problem-statement-bounces@alvestrand.no Thu May 22 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 MAA21260 for ; Thu, 22 May 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 E968062206; Thu, 22 May 2003 18:57:06 +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 69D16621FB for ; Thu, 22 May 2003 18:57:03 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 19ItNE-0009rB-2F; Thu, 22 May 2003 09:57:00 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 22 May 2003 09:56:59 -0700 To: "Charles E. Perkins" References: <004801c32054$70b6dd80$0200a8c0@DFNJGL21> <3ECCF46D.E09436DE@iprg.nokia.com> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, i think there are at least two major factors in increased delay, and you pointed out one, security. we used not to even think about it. it was rude to run a unix host without a password-less account named 'guest'. but the world has changed. and the ing security folk have not given us magic pixie dust to secure our stuff, but instead we have a serious ramp-up to achieve even reasonable security (for some value of reasonable). this can be a significant part of the work of producing a new protocol or piece thereof. but one we seem to miss is that the total protocol space is now much larger than we were kids. and the interactions have gone up super-linearly with the number of features. this has serious impact in the intra-area and cross-wg and cross-area analysis and operational evaluation of a proposal for a new protocol or feature. and this only gets worse in time, and not linearly. i think that mip, being so basic, also hits this one seriously. i think that these may be core problems. sorry, but i am not sure i have solutions. the second may be somewhat ameliorated by the restraint for which brian continually excoriates me. randy From problem-statement-bounces@alvestrand.no Thu May 22 13:33: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 NAA22142 for ; Thu, 22 May 2003 13:33:21 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C5A93625CE; Thu, 22 May 2003 19:32:52 +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 2735B625CC for ; Thu, 22 May 2003 19:32:43 +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 h4MHWfk27488; Thu, 22 May 2003 13:32:41 -0400 (EDT) Date: Thu, 22 May 2003 13:32:40 -0400 From: Keith Moore To: "Charles E. Perkins" Message-Id: <20030522133240.60c4f9c0.moore@cs.utk.edu> In-Reply-To: <3ECCF994.48A310B8@iprg.nokia.com> References: <3ECCF46D.E09436DE@iprg.nokia.com> <20030522120947.3d484944.moore@cs.utk.edu> <3ECCF994.48A310B8@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: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, yes, I understand that further e-mail specification > _might_ prevent _some_ viral infections. As a start, it might help if the existing ones were followed. Keith From problem-statement-bounces@alvestrand.no Thu May 22 13:49: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 NAA22562 for ; Thu, 22 May 2003 13:49:15 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 76613625D0; Thu, 22 May 2003 19:48: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 4B80F625CC for ; Thu, 22 May 2003 19:48:42 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4MHmZS28802; Thu, 22 May 2003 20:48:39 +0300 Date: Thu, 22 May 2003 20:48:35 +0300 (EEST) From: Pekka Savola To: Ted Lemon In-Reply-To: <14EE7C92-8C70-11D7-BBB3-00039367340A@nominum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: problem-statement@alvestrand.no Cc: Brian E Carpenter Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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, 22 May 2003, Ted Lemon wrote: > > If we add a step which should be easy to get to ("Experimental") and > > actually try to make it so, we might still leave the folks enough > > incentive to finish it and hone it to get it to the next level > > ("Proposed > > Standard") -- or kill it completely as a bad idea. > > Right now I think most people think of "Experimental" as "never going > to be a standard." I know that's not what it was originally intended > to mean, but in practice that seems to be how people think of it. I'm > reluctant to provide a specific example here because the one I can > think of is so controversial, but a lot of you probably remember the > conversation anyway. Right.. which is why "Experimental" would be a good one. What we want is a stable specification to get some limited testing and deployment, *NOT* widespread use. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From problem-statement-bounces@alvestrand.no Thu May 22 13:54: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 NAA22691 for ; Thu, 22 May 2003 13:54:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1B1A1625F8; Thu, 22 May 2003 19:53:45 +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 6B941625CC for ; Thu, 22 May 2003 19:53:41 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4MHrZx28863; Thu, 22 May 2003 20:53:35 +0300 Date: Thu, 22 May 2003 20:53:35 +0300 (EEST) From: Pekka Savola To: Pete Resnick In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Randy Bush Cc: problem-statement@alvestrand.no Cc: Keith Moore Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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, 22 May 2003, Pete Resnick wrote: > On 5/22/03 at 8:58 AM -0700, Randy Bush wrote: > > >>perhaps we'd produce higher quality and more relevant documents if > >>we imposed some earlier review, and perhaps we'd get those > >>documents done in a more timely fashion if the early reviews... > > > >i do not disagree with you. > >[...] > > o the bar is too high > >[...] > >with which i disagree > > How about "the first bar is too high" or "we need a new lower initial bar"? Completely disagree. We need to be able to kill the bad ideas early so that we don't get to the typical case: "2 years has passed, people have spent a lot of work on this, so it wouldn't be fair to kill it now.. so let's pass it through even if we shouldn't." .. of course, the alternative to killing bad ideas is correcting them early on.. but it's fallacy to believe that all the bad ideas can be corrected. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From problem-statement-bounces@alvestrand.no Thu May 22 13:59: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 NAA22839 for ; Thu, 22 May 2003 13:59:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 91FBD625FD; Thu, 22 May 2003 19:59:27 +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 B0A6C625FC for ; Thu, 22 May 2003 19:59:24 +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 KAA11773; Thu, 22 May 2003 10:59:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4MHxM901044; Thu, 22 May 2003 10:59:22 -0700 X-mProtect: <200305221759> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdjRSy5S; Thu, 22 May 2003 10:59:20 PDT Message-ID: <3ECD0FF9.78A14550@iprg.nokia.com> Date: Thu, 22 May 2003 10:59:21 -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: Randy Bush References: <004801c32054$70b6dd80$0200a8c0@DFNJGL21> <3ECCF46D.E09436DE@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, Randy Bush wrote: > i think there are at least two major factors in increased delay, > and you pointed out one, security. Someone reading your note might get the incorrect notion that we didn't pay attention to Mobile IPv6 security. That would be very much wrong. To put it as briefly as possible, the ADs demanded a key distribution mechanism _in addition_ to the basic authentication scheme. This is in marked contrast to the situation with AH and ESP, But _nobody_ claims that AH and ESP were insecure because they were standardized without key distribution. I get steamed when people perpetuate this serious misperception about "the security problem". I do NOT claim that insecure standards should be promulgated. I _do_ claim that as we get more experience with protocols, we can provide more ways to enable key distribution for authorizing the use of those protocols. <... discussion deleted about how nice it used to be ...> > but one we seem to miss is that the total protocol space is now > much larger than we were kids. and the interactions have gone up > super-linearly with the number of features. this has serious > impact in the intra-area and cross-wg and cross-area analysis and > operational evaluation of a proposal for a new protocol or feature. > and this only gets worse in time, and not linearly. i think that > mip, being so basic, also hits this one seriously. This was not the reason for delay of Mobile IPv6. Besides the demand for a key distribution mechanism (a bad reason for delay, in my opinion), we did not exhibit any serious interaction problems with other protocols. There are some serious considerations here, but discussion of them does not fit on this list. It has to do with how use of existing protocol specifications (you would think this is a good thing) leads into some of the worst problems I can remember. Bottom line: at this point in time, I am convinced that trying to use IPsec was my own worst mistake in the initial designs of Mobile IPv6, and recent decisions have made the use of RFC 2461 to be very, very questionable indeed. Using someone else's specification, with even the most microscopic refinements, gives them carte blanche to destroy your protocol design in the future. > i think that these may be core problems. sorry, but i am not sure > i have solutions. the second may be somewhat ameliorated by the > restraint for which brian continually excoriates me. There are no easy answers, and any solution we pick will have problems that need further attention. Rigidity and inability to make change is only one of the worst answers, not the least likely answer. Regards, Charlie P. From problem-statement-bounces@alvestrand.no Thu May 22 14:01: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 OAA22885 for ; Thu, 22 May 2003 14:01:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 199E362606; Thu, 22 May 2003 20:01:04 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by eikenes.alvestrand.no (Postfix) with ESMTP id D7D5462603 for ; Thu, 22 May 2003 20:00:45 +0200 (CEST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 096091B203C for ; Thu, 22 May 2003 11:58:08 -0500 (CDT) Date: Thu, 22 May 2003 13:00:45 -0500 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Ted Lemon To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <4F58D0B6-8C7F-11D7-BBB3-00039367340A@nominum.com> X-Mailer: Apple Mail (2.552) Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > Right.. which is why "Experimental" would be a good one. What we want > is > a stable specification to get some limited testing and deployment, > *NOT* > widespread use. One slightly draconian way to fix this problem would be to *require* that a spec go through experimental on the way to proposed. Then there can't be a stigma, because every spec does it. This would be a small inconvenience for trivial specifications, but probably a big win for the bigger specifications. I don't think it would make sense to put all the specs that are nearly at proposed through this extra step now, but it might be a good thing to do for new drafts. From problem-statement-bounces@alvestrand.no Thu May 22 14:11: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 OAA23150 for ; Thu, 22 May 2003 14:11:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B742562605; Thu, 22 May 2003 20:10:42 +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 F2D8362603 for ; Thu, 22 May 2003 20:10: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 h4MI9Nk29889; Thu, 22 May 2003 14:09:23 -0400 (EDT) Date: Thu, 22 May 2003 14:09:23 -0400 From: Keith Moore To: "Charles E. Perkins" Message-Id: <20030522140923.1686e0be.moore@cs.utk.edu> In-Reply-To: <3ECD0FF9.78A14550@iprg.nokia.com> References: <004801c32054$70b6dd80$0200a8c0@DFNJGL21> <3ECCF46D.E09436DE@iprg.nokia.com> <3ECD0FF9.78A14550@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: randy@psg.com Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > _nobody_ claims that AH and ESP were insecure because they > were standardized without key distribution. not insecure, just useless. and the fallback to bare IP _is_ insecure. I'd also claim that IPsec implementation in hosts is useless without an API that allows apps to determine the validity of their peers' credentials... maybe this is another illustration that we don't really try to understand the full scope of the problem until it gets to IESG. and it's hardly surprising if IESG does a poor job of fixing that. From problem-statement-bounces@alvestrand.no Thu May 22 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 OAA23222 for ; Thu, 22 May 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 708C96260B; Thu, 22 May 2003 20:11: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 E96EF625FC for ; Thu, 22 May 2003 20:11:35 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4MIBP429089; Thu, 22 May 2003 21:11:25 +0300 Date: Thu, 22 May 2003 21:11:24 +0300 (EEST) From: Pekka Savola To: "Charles E. Perkins" In-Reply-To: <3ECD0FF9.78A14550@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Randy Bush Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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, 22 May 2003, Charles E. Perkins wrote: [...] > It has to > do with how use of existing protocol specifications (you would think > this is a good thing) leads into some of the worst problems I can > remember. Bottom line: at this point in time, I am convinced > that trying to use IPsec was my own worst mistake in the initial > designs of Mobile IPv6, and recent decisions have made the use > of RFC 2461 to be very, very questionable indeed. Using someone > else's specification, with even the most microscopic refinements, > gives them carte blanche to destroy your protocol design in the future. Perhaps the problem here was trying to apply an apparent solution to an apparent problem without considering the applicability of the protocol for such a purpose.. or fleshing out the details. Of course, I'm not sure how well the applicability of IPsec has/had been documented... Early review from IPsec folks might have been useful; I'm not sure how much of that did indeed happen before the IESG noticed the issue. IMO the problem was very real, and the action being the only responsible thing to do. Looking back, maybe MIPv6 could have been published as Experimental (or the like) as is, but definitely not PS. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From problem-statement-bounces@alvestrand.no Thu May 22 14:14: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 OAA23311 for ; Thu, 22 May 2003 14:14:30 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9B1686260D; Thu, 22 May 2003 20:13:58 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from agitator.ibr.cs.tu-bs.de (ns.ibr.cs.tu-bs.de [134.169.34.18]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7580D62603 for ; Thu, 22 May 2003 20:13:56 +0200 (CEST) Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) h4MIDNXK024960 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 22 May 2003 20:13:23 +0200 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) h4MIDNZY003423; Thu, 22 May 2003 20:13:23 +0200 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) id h4MIDMmt003420; Thu, 22 May 2003 20:13:22 +0200 Date: Thu, 22 May 2003 20:13:22 +0200 Message-Id: <200305221813.h4MIDMmt003420@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: mellon@nominum.com In-reply-to: <4F58D0B6-8C7F-11D7-BBB3-00039367340A@nominum.com> (message from Ted Lemon on Thu, 22 May 2003 13:00:45 -0500) References: <4F58D0B6-8C7F-11D7-BBB3-00039367340A@nominum.com> X-IBRFilter-SpamReport: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no >>>>> Ted Lemon writes: >> Right.. which is why "Experimental" would be a good one. What we >> want is a stable specification to get some limited testing and >> deployment, *NOT* widespread use. Ted> One slightly draconian way to fix this problem would be to Ted> *require* that a spec go through experimental on the way to Ted> proposed. Then there can't be a stigma, because every spec does Ted> it. This would be a small inconvenience for trivial Ted> specifications, but probably a big win for the bigger Ted> specifications. I don't think it would make sense to put all the Ted> specs that are nearly at proposed through this extra step now, Ted> but it might be a good thing to do for new drafts. And then we kick out Draft (because Proposed is already pretty good and few documents make two additional steps) and we end up with the same three step process but just the steps have been renamed to match today's common understanding. Since public perception is important, this might actually not be such a bad idea and it is relatively cheap to implement... Of course, in a few years we will have raised the bar for Experimental. So we need to introduce another new name. But luckily, since Draft has then not been used for a while, we can simply introduce a new model which has Draft->Proposed->Standard. :-) /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 Thu May 22 14:38: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 OAA24023 for ; Thu, 22 May 2003 14:38:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2D8D5625EC; Thu, 22 May 2003 20:37:55 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6042F625CC for ; Thu, 22 May 2003 20:37:52 +0200 (CEST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 77CCF1B203C; Thu, 22 May 2003 12:35:13 -0500 (CDT) Date: Thu, 22 May 2003 13:37:50 -0500 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Juergen Schoenwaelder From: Ted Lemon In-Reply-To: <200305221813.h4MIDMmt003420@hansa.ibr.cs.tu-bs.de> Message-Id: <7DF6FD17-8C84-11D7-BBB3-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Cc: problem-statement@alvestrand.no Cc: Ted.Lemon@nominum.com Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > Of course, in a few years we will have raised the bar for Experimental. > So we need to introduce another new name. But luckily, since Draft has > then not been used for a while, we can simply introduce a new model > which has Draft->Proposed->Standard. :-) Don't experimental RFCs have warnings all over them about not deploying them widely? Anyway, that brings up another point, which I think is the real problem - it is not "Experimental" or "Proposed" or "Draft" or "Standard" that makes something a standard in the eyes of the wider Internet developer community. Unfortunately, it is "RFC," despite the fact that "RFC" stands for Request For Comments. What about using a different TLA for experimental than for other RFCs? Like "XCR" - Experimental, Comments Requested. XCRs would have the same degree of permanence in the IETF's RFC distribution as RFCs, but wouldn't have the much-coveted "RFC" TLA applied to them, and thus wouldn't be considered standards in the same way that something that has the RFC TLA is. I-Ds could be IPD (Informational Protocol Description) instead of RFC, and so on. From problem-statement-bounces@alvestrand.no Thu May 22 14:56: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 OAA24707 for ; Thu, 22 May 2003 14:56:21 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 30EE9625FB; Thu, 22 May 2003 20:55:51 +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 E725C625F9 for ; Thu, 22 May 2003 20:55:48 +0200 (CEST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])h4MItkb13886 for ; Thu, 22 May 2003 13:55:47 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com ; Thu, 22 May 2003 13:55:47 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 22 May 2003 11:55:41 -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: Thu, 22 May 2003 13:55:40 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44017535AB@daebe007.americas.nokia.com> Thread-Topic: OPEN ISSUE: Standards Track Thread-Index: AcMgjZ/1gmXxv0oPTm2v8oa/byQn0gABSbYw From: To: , X-OriginalArrivalTime: 22 May 2003 18:55:41.0378 (UTC) FILETIME=[BDD72220:01C32093] Cc: randy@psg.com Cc: problem-statement@alvestrand.no Subject: RE: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 OAA24707 > Early review from IPsec folks might have been useful; I'm not > sure how much of that did indeed happen before the IESG noticed the issue. This is the key issue. If there had been a review by some of the IPsec experts or cross-exchange of views between the Mobile IP and IPsec WGs, we may not have ended up in the sticky situation of being rejected by the IESG after WG LCs etc. and a few years in the development of the protocol. The problem that resulted in resetting the clock on Mobile IPv6 is the fact that a detailed review by the security folks was only done at the very end by the IESG (far too late in the game). The issue related to early reviews and feedback to WGs from other areas has been captured by the PS WG docs. > > IMO the problem was very real, and the action being the only > responsible thing to do. Looking back, maybe MIPv6 could have been > published as Experimental (or the like) as is, but definitely not PS. > Maybe. But the key lesson to be learn here is that the Mobile IP WG spent about 3 years or more before the IESG said that the security solution based on IPsec was broken. The timeline to arrive at such a conclusion is a serious problem for any standards work. -Basavaraj > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > From problem-statement-bounces@alvestrand.no Thu May 22 15:21: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 PAA26813 for ; Thu, 22 May 2003 15:21:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A87E3625FF; Thu, 22 May 2003 21:21:26 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mailman.research.att.com (H-135-207-24-32.research.att.com [135.207.24.32]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3B0E9625FC for ; Thu, 22 May 2003 21:21:23 +0200 (CEST) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101])h4MJHL3j025954; Thu, 22 May 2003 15:17:21 -0400 Received: from berkshire.research.att.com (raptor.research.att.com [135.207.23.32])h4MJLKV10820; Thu, 22 May 2003 15:21:20 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 367ED7B4D; Thu, 22 May 2003 15:21:20 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: "Charles E. Perkins" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 May 2003 15:21:20 -0400 From: "Steven M. Bellovin" Message-Id: <20030522192120.367ED7B4D@berkshire.research.att.com> Cc: Randy Bush Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 message <3ECCF46D.E09436DE@iprg.nokia.com>, "Charles E. Perkins" writes: > > >As an example, I think it was a terrible mistake to delay >Mobile IPv6 for so long pending the completion of the world's >most sophisticated and super robost security solution (slight >exaggeration, but ...). I guess I don't have to describe the >effect this can have in a world moving at what used to be >called "Internet speed". > It wasn't a matter of a "sophisticated and super robost security solution"; it was a matter of one that would *ever* work outside a company. > To put it as briefly as >possible, the ADs demanded a key distribution mechanism >_in addition_ to the basic authentication scheme. This is >in marked contrast to the situation with AH and ESP, But >_nobody_ claims that AH and ESP were insecure because they >were standardized without key distribution. You can't do AH or ESP without keys; the difference is that we had a story about where those keys could come from even before we had a key distribution mechanism. The story was simple: pre-arranged keys. That only works for MobileIP if you can pre-arrange keys with every possible spot you'd ever roam to, which is quite at variance with the plans I'd heard for MobileIP. The only path forward we heard was, in effect, the One True PKI; that's something that will not, can not, and should not exist ("should not" because it would be horribly destructive towards any form of Internet privacy). >Bottom line: at this point in time, I am convinced >that trying to use IPsec was my own worst mistake in the initial >designs of Mobile IPv6 I won't argue that point; however, any form of cryptographic authentication would run into the same key distribution problem. Very little of the issue had to do with the syntax or semantics of IPsec. You were running afoul of a basic architectural issue. Let me expand a bit more on why IPsec can work (on a small scale) without key distribution, and on why the models are fundamentally different. If I want to talk "securely" to someone, I have to have some out-of-band way of knowing who they are. Put in concrete terms, if Alice wants to talk to Bob, she needs to know that it's Bob she wants to reach and not, say, Carol. If you don't know out-of-band the difference between Bob and Carol, there's no difference in whom you're talking to... If you do know it's Bob, you have to have some way to verify that the party to whom you're talking really is Bob. That can be via pre-arranged keys or by a key distribution mechanism *rooted in a common trust anchor*. In other words, it's not the key distribution mechanism that's at issue, it's the out-of-band trust mechanism, and that's relatively easy for most uses of IPsec. With MobileIP, the mobile node and the home agent are trying to persuade random parts of the Internet infrastructure of assorted ownership and trust relationships. But where's the trust anchor? --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) From problem-statement-bounces@alvestrand.no Thu May 22 16:07: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 QAA27755 for ; Thu, 22 May 2003 16:07:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 59563625F5; Thu, 22 May 2003 22:07:00 +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 88F4D625F1 for ; Thu, 22 May 2003 22:06:57 +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 NAA18071; Thu, 22 May 2003 13:06:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4MK6ua26208; Thu, 22 May 2003 13:06:56 -0700 X-mProtect: <200305222006> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdAHhO37; Thu, 22 May 2003 13:06:54 PDT Message-ID: <3ECD2DDE.982C8297@iprg.nokia.com> Date: Thu, 22 May 2003 13:06:54 -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: "Steven M. Bellovin" References: <20030522192120.367ED7B4D@berkshire.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 Steven, "Steven M. Bellovin" wrote: > It wasn't a matter of a "sophisticated and super robost security solution"; > it was a matter of one that would *ever* work outside a company. This isn't true. A mobile node could roam outside a company, and still get data from its home agent. I'm worried about going over technical details on the problem statement list, so I'll stop there. > You can't do AH or ESP without keys; the difference is that we had a > story about where those keys could come from even before we had a key > distribution mechanism. The story was simple: pre-arranged keys. Exactly. > That only works for MobileIP if you can pre-arrange keys with every > possible spot you'd ever roam to, which is quite at variance with the > plans I'd heard for MobileIP. No, you could do it with prearranged keys with the home agent (as I hope you would agree), and prearranged keys with some selected correspondent nodes. > The only path forward we heard was, in > effect, the One True PKI; that's something that will not, can not, and > should not exist ("should not" because it would be horribly destructive > towards any form of Internet privacy). The other path, which _was_ articulated, was doing prearranged keys first, and better key distribution later. Which is what happened anyway, but we just couldn't publish the Proposed Standard. > I won't argue that point; however, any form of cryptographic > authentication would run into the same key distribution problem. > Very little of the issue had to do with the syntax or semantics of > IPsec. You were running afoul of a basic architectural issue. Actually, the situation was _far_ more complicated than that, and IPsec produces serious constraints on what can be actually run in a protocol. Again, this is far afield from the problem statement list material. > Let me expand a bit more on why IPsec can work (on a small scale) > without key distribution, and on why the models are fundamentally > different. The scale for initial deployment with correspondent nodes would be limited by the lack of key distribution. That was never at issue. > With MobileIP, the mobile node and the home agent are trying to > persuade random parts of the Internet infrastructure of assorted > ownership and trust relationships. But where's the trust anchor? What a lot of people wanted was the ability to run Mobile IP with home agents and a few correspondent nodes. What the ADs demanded was assurance that we could run Mobile IPv6 with an entire IPv6-universe full of mobile nodes. It was and is a great goal. I think we achieved it, but it shouldn't have stood in the way of Proposed Standard. Regards, Charlie P. From problem-statement-bounces@alvestrand.no Thu May 22 16:19: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 QAA27961 for ; Thu, 22 May 2003 16:19:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0205262600; Thu, 22 May 2003 22:18:48 +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 1E435625F2 for ; Thu, 22 May 2003 22:18:41 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.4]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA26432; Thu, 22 May 2003 13:18:14 -0700 (PDT) Message-Id: <5.1.0.14.2.20030522155752.0416b6f0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 22 May 2003 16:05:28 -0400 To: From: Margaret Wasserman In-Reply-To: <697DAA22C5004B4596E033803A7CEF44017535AB@daebe007.americas .nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: randy@psg.com Cc: problem-statement@alvestrand.no Cc: pekkas@netcore.fi Subject: Quality of WG Output (Was: RE: OPEN ISSUE: Standards Track) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 Basavaraj, At 01:55 PM 5/22/2003 -0500, Basavaraj.Patil@nokia.com wrote: >Maybe. But the key lesson to be learn here is that the Mobile IP WG >spent about 3 years or more before the IESG said that the security >solution based on IPsec was broken. The timeline to arrive at such >a conclusion is a serious problem for any standards work. I agree that it is a serious problem that there was no adequate security review of this proposal for three years while it was being processed by the WG. But, I don't think that this is a problem with: - The IESG, or - The IETF standards track. Instead, I consider this a problem with the quality processes (or lack thereof) used by our WGs. We need to find ways to make sure that documents are adequately reviewed during different phases of WG development, so that these "late surprises" don't occur. In other words, we need to determine ways to increase the quality and integrity of WG output. This is dealt with in the problem statement and the process document in the discussion of WG engineering practices. Margaret From problem-statement-bounces@alvestrand.no Thu May 22 16:39: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 QAA28367 for ; Thu, 22 May 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 803D562602; Thu, 22 May 2003 22:39:12 +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 A2F5C625F2 for ; Thu, 22 May 2003 22:39:09 +0200 (CEST) Message-ID: <008f01c320a1$fc06e680$236015ac@DCLKEMPFTP> From: "James Kempf" To: , "Margaret Wasserman" References: <5.1.0.14.2.20030522155752.0416b6f0@mail.windriver.com> Date: Thu, 22 May 2003 13:37:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: randy@psg.com Cc: problem-statement@alvestrand.no Cc: pekkas@netcore.fi Subject: Re: Quality of WG Output (Was: RE: OPEN ISSUE: Standards Track) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, Well stated. Introduction of more structured, formal reviews at a selected, very fiew points in the development process could help to reduce the late suprise factor. Of course, it is possible to go overboard and slow down the development with too much process, so care is needed. jak ----- Original Message ----- From: "Margaret Wasserman" To: Cc: ; ; Sent: Thursday, May 22, 2003 1:05 PM Subject: Quality of WG Output (Was: RE: OPEN ISSUE: Standards Track) > > Hi Basavaraj, > > At 01:55 PM 5/22/2003 -0500, Basavaraj.Patil@nokia.com wrote: > >Maybe. But the key lesson to be learn here is that the Mobile IP WG > >spent about 3 years or more before the IESG said that the security > >solution based on IPsec was broken. The timeline to arrive at such > >a conclusion is a serious problem for any standards work. > > I agree that it is a serious problem that there was no > adequate security review of this proposal for three > years while it was being processed by the WG. > > But, I don't think that this is a problem with: > > - The IESG, or > - The IETF standards track. > > Instead, I consider this a problem with the quality > processes (or lack thereof) used by our WGs. We > need to find ways to make sure that documents are > adequately reviewed during different phases of > WG development, so that these "late surprises" don't > occur. In other words, we need to determine ways > to increase the quality and integrity of WG output. > > This is dealt with in the problem statement > and the process document in the discussion of WG > engineering practices. > > Margaret > > > > From problem-statement-bounces@alvestrand.no Thu May 22 17:34: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 RAA29622 for ; Thu, 22 May 2003 17:34:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 99BBE625F2; Thu, 22 May 2003 23:33: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 6B565625F1 for ; Thu, 22 May 2003 23:33: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 OAA22601; Thu, 22 May 2003 14:33:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4MLXSb03901; Thu, 22 May 2003 14:33:28 -0700 X-mProtect: <200305222133> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNZAdKm; Thu, 22 May 2003 14:33:26 PDT Message-ID: <3ECD4226.9C99E51D@iprg.nokia.com> Date: Thu, 22 May 2003 14:33:26 -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: <004801c32054$70b6dd80$0200a8c0@DFNJGL21> <3ECCF46D.E09436DE@iprg.nokia.com> <20030522140923.1686e0be.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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: > > _nobody_ claims that AH and ESP were insecure because they > > were standardized without key distribution. > > not insecure, just useless. and the fallback to bare IP _is_ insecure. They weren't useless, because as Steve B. said, you could use preconfigured keys. Do you really claim that's useless? > I'd also claim that IPsec implementation in hosts is useless without an > API that allows apps to determine the validity of their peers' > credentials... We can't boil the ocean all the time. First the basic headers. Then the key distribution. Then the APIs. If the basic headers were never published in a stable document, I'll bet the whole process would stall and _nothing_ would have gotten done. > maybe this is another illustration that we don't really try to > understand the full scope of the problem until it gets to IESG. > and it's hardly surprising if IESG does a poor job of fixing that. It's equally well an illustration that we can't boil the ocean over and over again -- especially with new people every time. We need to boil a few gallons first, and then a few truckloads. Failure to publish is a distinct impediment in the process, and I think that timely publication of a stable Proposed Standard should be a good initial step. Regards, Charlie P. From problem-statement-bounces@alvestrand.no Thu May 22 17:59: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 RAA00488 for ; Thu, 22 May 2003 17:59:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4749F625F6; Thu, 22 May 2003 23:59:14 +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 37EB9625F1 for ; Thu, 22 May 2003 23:59:12 +0200 (CEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id E0E386A901; Fri, 23 May 2003 00:59:10 +0300 (EEST) Message-ID: <3ECD47D5.8050504@piuha.net> Date: Fri, 23 May 2003 00:57:41 +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: "Steven M. Bellovin" References: <20030522192120.367ED7B4D@berkshire.research.att.com> In-Reply-To: <20030522192120.367ED7B4D@berkshire.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Standards Track 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 I will just say first that I agree with Steven's explanation of the reasons why AH/ESP were inappropriate for securing binding updates to random nodes in the Internet. For those that haven't followed MIPv6 development I'll add that AH/ESP were eventually replaced by an application specific security design which deals with the specific dangers resulting from binding updates, but does not require pre-arranged security associations or global authentication infrastructure. Original MIPv6 didn't actually have a security problem, IMHO; it was more of a deployment problem. Yes, we have wasted two years but on the other hand the amount of nodes you can run it against has increased from one or few to the size of the Internet. Not bad? Now all we need is for IPv6 to take off ... and IESG to approve the documents this time. I'm trying to figure out which one is more likely ;-) But then back to the issues relevant for the problem statement WG. Raj said that earlier review from the security folks would have helped. Perhaps, and such help is often very useful and the IETF needs more cross-area expertise. I'm all for it. However, I'd like to present a slightly different opinion about the way that security design in the IETF could work better. Reviews may be a necesary but certainly not a sufficient condition. The way I see it, there appears to be a number of problems that we are facing: - developed protocol specifications fail to take in account security in some manner, leading to security/ approval/delay issues - security mechanisms developed for various things don't get used in the field for various reasons, perhaps a key issue being once again deployment and configuration - there are some hard problems that even the security experts are learning to deal with - slow publication schedule for at least some of security features that the community would need. - differing opinions about where we should be in the low "cost" vs. high security question. So how could the IETF do better? I think a key element for this is not (only) more frequent review from the few security experts, but rather a better understanding of the security issues by the other protocol designers. Or making the security design more of an integral part of the rest of the design for whatever we are working on. This should include an understanding of the possible security problems resulting from the planned feature. Among other things, this understanding would help in choosing security solutions that prevent the problems, and don't do additional things that would require, for instance, a global PKI. A number of documents by Steven, Eric, and others exist to educate protocol designers and we should use those documents, and write more. So: we need more training. As a result of better understanding of the security issues in a feature, I suspect that we'd see less "just authenticate everyone" approaches, and more intelligence tied to the specific application, such as cross-checking TLS-derived information with something else at the application layer. Secondly, we've talked about early architecture design in this list. The security architecture for protocol X would be a prime candidate for inclusion in the architecture design section, and should be reviewed early. Not when the bits have been designed! No mandatory architecture design early on, no early review possible... Thirdly, it is really, really crucial to think about deployment issues and how easy to use people find the security mechanisms. All of us could use secure e-mail but almost no one does. Why? And do the current secure e-mail protocols deal with the real problems people are having with e-mail? Why can't I think of more success stories in security beyond one-sided TLS authentication, SSH, and cellphone smart cards? IMHO we as a community do not understand these issues well enough at the moment, let alone have documented them somewhere. Yet this seems a much more important issue for the world than getting some documents approved by the IESG at t1 or t2. Here's where I think the security area should probably move a bit of its focus on. Less "policy" from admins, less extra work for users, less reliance on non-existent other stuff in the network. My fourth point is that we need to be more honest about the limitations of our security mechanisms, and faster to get them updated when new algorithms come around etc. Again some educational documents are needed for the first part. (In some cases I suspect the educational aspects would apply even to the folks developing the particular mechanism...) Finally, any problem in the process is amplified when we try to do too large chunks of functionality in one document. Unfortunately, this appears quite common in today's IETF. Why? In addition to making the wrong decision, there maybe a few other reasons behind this. We appear not so good in incremental design. Reviewers want to see the whole thing, to ensure that all aspects have been taken care of. I agree with Charlie that we shouldn't try to boil the ocean (though I may have a different idea about the right way to split and phase protocols). In general, the IETF tries to arrive at a pretty perfect protocol for PS. We need security and maybe even scalable security when a document becomes a PS RFC, but we may not need all functions. Lets start producing basic protocols with a series of enhancements following them. And since someone will worry about the "big picture" and how these pieces fit together, we probably need again the architecture design document, we need more detailed roadmaps than the current charters are, and so on. And WGs need to realize that documenting functions in separate specifications does not mean that their pet features have been "left out". --Jari From problem-statement-bounces@alvestrand.no Thu May 22 18:24: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 SAA02656 for ; Thu, 22 May 2003 18:24:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C57A9625F7; Fri, 23 May 2003 00:24:07 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by eikenes.alvestrand.no (Postfix) with ESMTP id AFD02625F1 for ; Fri, 23 May 2003 00:24:05 +0200 (CEST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id DAEA11B203C for ; Thu, 22 May 2003 16:21:25 -0500 (CDT) Date: Thu, 22 May 2003 17:24:05 -0500 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Ted Lemon To: problem-statement@alvestrand.no Content-Transfer-Encoding: 7bit In-Reply-To: <3ECD4226.9C99E51D@iprg.nokia.com> Message-Id: <18FB8C94-8CA4-11D7-BBB3-00039367340A@nominum.com> X-Mailer: Apple Mail (2.552) Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 equally well an illustration that we can't boil > the ocean over and over again -- especially with new > people every time. We need to boil a few gallons first, > and then a few truckloads. This is a _really_ good point. One of the things that I've seen cause major hassle and pain for people who've been working on a draft for a while is that someone new comes along (it's been me! :') and asks the same damned questions that got answered *last* year. And then someone else comes along a week later and does the same thing. :'} Incremental steps would really help with this (although of course in my case the questions I was asking were extremely pertinent. :') From problem-statement-bounces@alvestrand.no Thu May 22 18:33: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 SAA02993 for ; Thu, 22 May 2003 18:33:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0CA48625F1; Fri, 23 May 2003 00:32:34 +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 4F192625EB for ; Fri, 23 May 2003 00:32:27 +0200 (CEST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])h4MMWQb16430 for ; Thu, 22 May 2003 17:32:26 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com ; Thu, 22 May 2003 17:32:28 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 22 May 2003 15:31:49 -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: Thu, 22 May 2003 17:31:48 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44017535B8@daebe007.americas.nokia.com> Thread-Topic: OPEN ISSUE: Standards Track Thread-Index: AcMgsOqV7uDKCmrnQN2NpJvIDazhSAAABYQg From: To: , X-OriginalArrivalTime: 22 May 2003 22:31:49.0164 (UTC) FILETIME=[EF3E3EC0:01C320B1] Subject: RE: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 SAA02993 > > > It's equally well an illustration that we can't boil > > the ocean over and over again -- especially with new > > people every time. We need to boil a few gallons first, > > and then a few truckloads. > > This is a _really_ good point. One of the things that I've > seen cause major hassle and pain for people who've been working on a draft for a > while is that someone new comes along (it's been me! :') and asks the > same damned questions that got answered *last* year. And > then someone else comes along a week later and does the same thing. :'} > > Incremental steps would really help with this (although of > course in my case the questions I was asking were extremely pertinent. :') > This is bound to happen when you have documents that take a couple of years or more and umpteen revisions. Obviously churn among WG members participating is also a fact. The only effective way is to track issues and maintain that. Asking the newbies to go and read the archives is not the most effective (especially when you have extemely active MLs). But a list of issues that have been dealt with by the WG during the course of n revisions over time will alleviate the pain ;) of revisiting the issue(s). -Basavaraj From problem-statement-bounces@alvestrand.no Thu May 22 20:05: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 UAA05665 for ; Thu, 22 May 2003 20:05:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6EEE9625EE; Fri, 23 May 2003 02:05:05 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from kahuna.telstra.net (kahuna.telstra.net [203.50.0.6]) by eikenes.alvestrand.no (Postfix) with ESMTP id 869CC625A4 for ; Fri, 23 May 2003 02:05:01 +0200 (CEST) Received: from gih505.telstra.net (rsdhcp13.telstra.net [203.50.0.207]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h4N04vMK021321; Fri, 23 May 2003 10:04:58 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 23 May 2003 10:04:50 +1000 To: erosen@cisco.com, Randy Bush From: Geoff Huston In-Reply-To: <200305221401.h4ME17OO009168@rtp-core-1.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: what are the real 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 At 10:01 AM 22/05/2003 -0400, Eric Rosen wrote: >It would certainly be interesting to know exactly which of the IESG members >think that they are on a mission to protect the users against exploitation >by the vendors. Naturally, anyone who is on such a mission will think it >very important to replace the operation of the marketplace by his personal >vision of the future, and will do whatever he can to purge the IETF of other >views. But let's not pretend that such an overtly political agenda has >anything to do with technical quality. > >And people still wonder why the IESG is not trusted! On the other hand the IETF still manages to undertake a certain amount of Bad Idea filtering, and the criteria for a Bad Idea has some reference to a generic engineering model of the Internet as we know it. Markets are not usually seen as discriminators of quality, and invoking the market as some discriminator of technical quality for this work is not a view that I can agree with. If the only role of the IETF is to bless the offerings from certain vendors who hold significant market share and to soundly rubbish offerings from those vendors to whom the Market has shown displeasure, then we are all wasting our time. From that perspective I find I simply cannot accept Eric's perspective that the operation of the marketplace Knows Best, for in that world there is no credible role for interoperable standards, no opportunity for customers being able to make independent choices of technology and vendor, and, as far as I can tell, we are then pretty much back to the bleak mainframe years of the 70s where vendor abuse of customers through lock-in with proprietary technology was a common mode of operation. i.e. the role here (among others) is to balance the various perspectives of vendors and consumers, and in such a role one cannot ignore the legitimate interests of either sector. I would be very reluctant to characterize this important role as being "a mission to protect the users from exploitation by the vendors", but I do see that part of the rationale of the existence of the IETF is to provide a means of balancing the various interests of consumers and competing vendors when defining rational, useful and, hopefully, high quality, technology standards. regards, Geoff From problem-statement-bounces@alvestrand.no Thu May 22 23:05: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 XAA09678 for ; Thu, 22 May 2003 23:05:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 35AAC62601; Fri, 23 May 2003 05:04:50 +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 8E6A262589 for ; Fri, 23 May 2003 05:04:47 +0200 (CEST) Received: from adsl-67-126-140-17.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4N34RN32157 for ; Thu, 22 May 2003 20:04:28 -0700 Date: Thu, 22 May 2003 20:04:44 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <4318516885.20030522200444@brandenburg.com> To: problem-statement@alvestrand.no In-Reply-To: <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> References: <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: what are the real problems 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 Geoff, GH> On the other hand the IETF still manages to undertake a certain amount of GH> Bad Idea filtering, and the criteria for a Bad Idea has some reference to GH> a generic engineering model of the Internet as we know it. Markets are not GH> usually seen as discriminators of quality, ... GH> If the only role of the IETF is to bless the offerings from certain vendors GH> who hold significant market share and to soundly rubbish offerings from GH> those vendors to whom the Market has shown displeasure, then GH> we are all wasting our time. This is an absolutely key point. There is a difference between 'let a thousand flowers bloom' and 'let a thousand weeds bloom'. The IETF process is intended to exert quite a bit of quality control. The difficulty is in thinking that quality control necessarily means permitting only one solution to be issued. Or that letting multiple solution be issued means that we exert no quality control. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Thu May 22 23:31: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 XAA10166 for ; Thu, 22 May 2003 23:31:48 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DA2696260F; Fri, 23 May 2003 05:31:18 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by eikenes.alvestrand.no (Postfix) with ESMTP id B307A625D1 for ; Fri, 23 May 2003 05:31:10 +0200 (CEST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 85B8D1B2097 for ; Thu, 22 May 2003 21:28:28 -0500 (CDT) Date: Thu, 22 May 2003 22:30:43 -0500 Content-Type: text/plain; charset=US-ASCII; format=flowed Resent-Date: Thu, 22 May 2003 22:31:10 -0500 Content-Transfer-Encoding: 7bit Resent-Message-Id: Resent-To: problem-statement@alvestrand.no Mime-Version: 1.0 (Apple Message framework v552) From: Ted Lemon To: Geoff Huston Message-Id: Resent-From: Ted Lemon X-Mailer: Apple Mail (2.552) Subject: Re: what are the real 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 > On the other hand the IETF still manages to undertake a certain amount > of > Bad Idea filtering, and the criteria for a Bad Idea has some reference > to > a generic engineering model of the Internet as we know it. > If the only role of the IETF is to bless the offerings from certain > vendors > who hold significant market share and to soundly rubbish offerings from > those vendors to whom the Market has shown displeasure, then > we are all wasting our time. I think there's a middle ground between the extreme of preventing anything from happening that might change anything, and the extreme of blessing everything. My experience has been that we tend to err more towards the former than the latter (indeed, I think there's no danger of us erring towards the latter), and I've seen some very good ideas shot down as a result. From problem-statement-bounces@alvestrand.no Thu May 22 23:43: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 XAA10424 for ; Thu, 22 May 2003 23:43:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 328D562617; Fri, 23 May 2003 05:42:57 +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 958E5625D1 for ; Fri, 23 May 2003 05:42:54 +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 19J3SE-0006yi-00; Thu, 22 May 2003 20:42:51 -0700 Date: Thu, 22 May 2003 23:41:40 -0400 From: Keith Moore To: Dave Crocker Message-Id: <20030522234140.3387e2e0.moore@cs.utk.edu> In-Reply-To: <4318516885.20030522200444@brandenburg.com> References: <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> <4318516885.20030522200444@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: what are the real 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 > The IETF process is intended to exert quite a bit of quality control. > > The difficulty is in thinking that quality control necessarily means > permitting only one solution to be issued. has this really been a problem in practice? do we have any reason to believe that issuing multiple solutions will improve the quality of life on the Internet? seems like in most cases we have a difficult enough time producing a single solution of appropriate quality, and when we're reluctant to issue multiple solutions it is not usually out of concern for quality of those solutions but for the interactions and lack of interoperability between them. From problem-statement-bounces@alvestrand.no Fri May 23 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 BAA12110 for ; Fri, 23 May 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 D12C0625EB; Fri, 23 May 2003 07:04:03 +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 7130E625A1 for ; Fri, 23 May 2003 07:04:00 +0200 (CEST) Received: from ppp-68-120-82-43.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4N53eN05491; Thu, 22 May 2003 22:03:40 -0700 Date: Thu, 22 May 2003 22:03:56 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1815027409.20030522220356@brandenburg.com> To: Keith Moore In-Reply-To: <20030522234140.3387e2e0.moore@cs.utk.edu> References: <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> <4318516885.20030522200444@brandenburg.com> <20030522234140.3387e2e0.moore@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Cc: dhc@dcrocker.net Subject: Re: what are the real problems 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 difficulty is in thinking that quality control necessarily means >> permitting only one solution to be issued. KM> has this really been a problem in practice? do we have any reason to believe KM> that issuing multiple solutions will improve the quality of life on the KM> Internet? esmtp and mime were competitive efforts, initially. dominant forces probably would have opted for CMIP. and ISIS. etc. terminating credible efforts prematurely is silly. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Fri May 23 01: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 BAA12251 for ; Fri, 23 May 2003 01:14:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8D557625F0; Fri, 23 May 2003 07:13:55 +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 0066A625A1 for ; Fri, 23 May 2003 07:13:52 +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 19J4sE-0002v8-00; Thu, 22 May 2003 22:13:46 -0700 Date: Fri, 23 May 2003 01:12:35 -0400 From: Keith Moore To: Dave Crocker Message-Id: <20030523011235.7478d87f.moore@cs.utk.edu> In-Reply-To: <1815027409.20030522220356@brandenburg.com> References: <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> <4318516885.20030522200444@brandenburg.com> <20030522234140.3387e2e0.moore@cs.utk.edu> <1815027409.20030522220356@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: what are the real 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 > terminating credible efforts prematurely is silly. so is spreading ourselves too thin. From problem-statement-bounces@alvestrand.no Fri May 23 01:18: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 BAA12316 for ; Fri, 23 May 2003 01:18:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9D05C6260A; Fri, 23 May 2003 07:17:51 +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 B2379625A1 for ; Fri, 23 May 2003 07:17:48 +0200 (CEST) Received: from ppp-68-120-82-43.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4N5HRN06041; Thu, 22 May 2003 22:17:27 -0700 Date: Thu, 22 May 2003 22:17:44 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1005854969.20030522221744@dcrocker.net> To: Keith Moore In-Reply-To: <20030523011235.7478d87f.moore@cs.utk.edu> References: <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> <4318516885.20030522200444@brandenburg.com> <20030522234140.3387e2e0.moore@cs.utk.edu> <1815027409.20030522220356@brandenburg.com> <20030523011235.7478d87f.moore@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Cc: dhc@dcrocker.net Subject: Re: what are the real problems 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, >> terminating credible efforts prematurely is silly. KM> so is spreading ourselves too thin. ahh, right. that was the argument for not doing xmpp. better to worry about multiple efforts, each of which has serious support, than it is to worry about unproductive efforts that drag on for years. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Fri May 23 01:28: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 BAA12486 for ; Fri, 23 May 2003 01:28:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 44326625D1; Fri, 23 May 2003 07:27:42 +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 BE429625A1 for ; Fri, 23 May 2003 07:27:35 +0200 (CEST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])h4N5RY708321 for ; Fri, 23 May 2003 08:27:34 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com ; Fri, 23 May 2003 08:27:34 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 23 May 2003 08:27:33 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 23 May 2003 08:27: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: Fri, 23 May 2003 08:27:31 +0300 Message-ID: Thread-Topic: OPEN ISSUE: Standards Track Thread-Index: AcMgrWz+czzb+MgTQBya5T5A/w8OKAAPjjBg From: To: , X-OriginalArrivalTime: 23 May 2003 05:27:32.0456 (UTC) FILETIME=[029A8E80:01C320EC] Cc: problem-statement@alvestrand.no Subject: RE: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 BAA12486 Jari, > Secondly, we've talked about early architecture > design in this list. The security architecture > for protocol X would be a prime candidate for > inclusion in the architecture design section, > and should be reviewed early. Not when the bits > have been designed! No mandatory architecture > design early on, no early review possible... > > Thirdly, it is really, really crucial to think about > deployment issues and how easy to use people find the > security mechanisms. All of us could use secure e-mail > but almost no one does. Why? And do the current secure > e-mail protocols deal with the real problems people are > having with e-mail? Why can't I think of more success > stories in security beyond one-sided TLS authentication, > SSH, and cellphone smart cards? IMHO we as a community > do not understand these issues well enough at the moment, > let alone have documented them somewhere. Yet this > seems a much more important issue for the world than > getting some documents approved by the IESG at t1 or t2. > Here's where I think the security area should probably > move a bit of its focus on. Less "policy" from admins, > less extra work for users, less reliance on non-existent > other stuff in the network. Adding on to this, perhaps it would be prudent for most new working groups should do a threats analysis and perhaps even an analysis or review of existing security solutions, before protocol design. John From problem-statement-bounces@alvestrand.no Fri May 23 01:42: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 BAA12857 for ; Fri, 23 May 2003 01:42:33 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5D74A62608; Fri, 23 May 2003 07:42:02 +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 0CBE6625A1 for ; Fri, 23 May 2003 07:42:00 +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 WAA13219 for ; Thu, 22 May 2003 22:41:59 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4N5fu307953; Thu, 22 May 2003 22:41:56 -0700 X-mProtect: <200305230541> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdHWKVfq; Thu, 22 May 2003 22:41:54 PDT Message-ID: <3ECDB4B7.2030407@iprg.nokia.com> Date: Thu, 22 May 2003 22:42:15 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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'm afraid this may be getting away from the original point, which is that there needs to be a way to boil a truckload of water before we boil the ocean. The idea of requiring a threat analysis and deployment scenarios analysis is a pretty good way to raise the bar way up into the stratosphere so that no work gets done. Presumably you meant that this would come _after_ the problem statement and definition, followed by the requirements analysis, all of which should (???) occur before anyone is allowed to mention a solution. Or did you mean that we could mention a solution without having any protocol in mind, and then somehow do a threat analysis on the solution without seeing any protocol that might embody that solution? I really don't think engineers work that way. I think iterative and parallel development is best, and testing interoperability all along the way. Regards, Charlie P. john.loughney@nokia.com wrote: >Jari, > > > >>Secondly, we've talked about early architecture >>design in this list. The security architecture >>for protocol X would be a prime candidate for >>inclusion in the architecture design section, >>and should be reviewed early. Not when the bits >>have been designed! No mandatory architecture >>design early on, no early review possible... >> >>Thirdly, it is really, really crucial to think about >>deployment issues and how easy to use people find the >>security mechanisms. All of us could use secure e-mail >>but almost no one does. Why? And do the current secure >>e-mail protocols deal with the real problems people are >>having with e-mail? Why can't I think of more success >>stories in security beyond one-sided TLS authentication, >>SSH, and cellphone smart cards? IMHO we as a community >>do not understand these issues well enough at the moment, >>let alone have documented them somewhere. Yet this >>seems a much more important issue for the world than >>getting some documents approved by the IESG at t1 or t2. >>Here's where I think the security area should probably >>move a bit of its focus on. Less "policy" from admins, >>less extra work for users, less reliance on non-existent >>other stuff in the network. >> >> > >Adding on to this, perhaps it would be prudent for >most new working groups should do a threats analysis >and perhaps even an analysis or review of existing >security solutions, before protocol design. > >John > > From problem-statement-bounces@alvestrand.no Fri May 23 02:32: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 CAA25640 for ; Fri, 23 May 2003 02:32:14 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 956DA62613; Fri, 23 May 2003 08:31: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 910436260C for ; Fri, 23 May 2003 08:31:40 +0200 (CEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id EFED16A901; Fri, 23 May 2003 09:31:39 +0300 (EEST) Message-ID: <3ECDBFF2.1070909@piuha.net> Date: Fri, 23 May 2003 09:30:10 +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: Charlie Perkins References: <3ECDB4B7.2030407@iprg.nokia.com> In-Reply-To: <3ECDB4B7.2030407@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: john.loughney@nokia.com Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Standards Track 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 Perkins wrote: > I'm afraid this may be getting away from the original point, > which is that there needs to be a way to boil a truckload > of water before we boil the ocean. > > The idea of requiring a threat analysis and deployment > scenarios analysis is a pretty good way to raise the bar > way up into the stratosphere so that no work gets done. > Presumably you meant that this would come _after_ > the problem statement and definition, followed by the > requirements analysis, all of which should (???) occur > before anyone is allowed to mention a solution. (This is starting to sound a lot like the operation of the problem WG...) I very much agree with you about boiling the ocean. And about including interoperability and implementation experience along the way. The current IETF mindset resembles the waterfall software engineering model: lengthy release cycle, a lot of new features in releases, emphasis on planning, review, and quality control. I agree that adding at least some amount of iterative process thinking would be good. I view this mainly as starting with a smaller set of functionality than improving scalability of solutions at a later stage, however. In short: we need to have scalable, secure, and otherwise quality protocols. But we may not need them to have all features. Looking at the planned future work in the charters of the MIPv4/MIPv6/MIPSHOP WGs, it looks like we are now using an iterative and parallel approach. Very good! --Jari P.S. Here's an exercise for the day: calculate an estimated completion date for the problem WG when it starts with the following: (a) full enumeration of all problems of the IETF, (b) banning discussion of "running code" i.e. solutions, (c) enumeration of all core values that may not be broken as a result of modifications, (d) lengthy discussion about the process-changing process. This will have to be followed by a discussion which picks the problems and solutions that will be solved, the development of the detailed solutions, and getting them approved and deployed. From problem-statement-bounces@alvestrand.no Fri May 23 02:41: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 CAA25940 for ; Fri, 23 May 2003 02:41:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3AC6B62619; Fri, 23 May 2003 08:40:47 +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 7261B6260C for ; Fri, 23 May 2003 08:40:35 +0200 (CEST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])h4N6eY723958 for ; Fri, 23 May 2003 09:40:34 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com for ; Fri, 23 May 2003 09:40:34 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 23 May 2003 09:40:33 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 23 May 2003 09:40: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: Fri, 23 May 2003 09:40:31 +0300 Message-ID: Thread-Topic: OPEN ISSUE: Standards Track Thread-Index: AcMg7ge8DqqcOOpBRYaAsCeqFb7PGQABzjoQ From: To: X-OriginalArrivalTime: 23 May 2003 06:40:32.0881 (UTC) FILETIME=[358A5E10:01C320F6] Cc: problem-statement@alvestrand.no Subject: RE: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 CAA25940 Charlie, First off, a disclaimer. I am not talking about Mobile IP. > I'm afraid this may be getting away from the original point, > which is that there needs to be a way to boil a truckload > of water before we boil the ocean. No, I agree with your point about tackling the problem in measured steps. > The idea of requiring a threat analysis and deployment > scenarios analysis is a pretty good way to raise the bar > way up into the stratosphere so that no work gets done. > Presumably you meant that this would come _after_ > the problem statement and definition, followed by the > requirements analysis, all of which should (???) occur > before anyone is allowed to mention a solution. Not at all. Deployment analysis was not even something I suggested. What I actually meant is that when working on a clean sheet of paper, it doesn't hurt to think about what are the possible threat models which can aid in working on a solution - rather than trying to retrofit solutions during IESG review. If you are not working with a clean-sheet of paper, then taking some time to look at what exists, in terms of security, is not a bad thing. I think most of this can be done in parallel, or nearly parallel. I hope that problem statements, problem definition, requirements, ad-nauseum don't become the standard WG deliverables for all WGs. Actually, I think the the problem statement & definition should be a feature of the charter, not a seperate document. > I think iterative and parallel development is best, > and testing interoperability all along the way. I agree - and I was just suggesting that putting some thoughts about security upfront could actually make things work smoother & perhaps even speed things up (to save from last minute security gotchas). John From problem-statement-bounces@alvestrand.no Fri May 23 02:52: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 CAA26247 for ; Fri, 23 May 2003 02:52:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 48DF36260C; Fri, 23 May 2003 08:52:20 +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 0FC5361BA7 for ; Fri, 23 May 2003 08:52:18 +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 XAA15890 for ; Thu, 22 May 2003 23:52:16 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4N6qEp17813; Thu, 22 May 2003 23:52:14 -0700 X-mProtect: <200305230652> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdvKJFHf; Thu, 22 May 2003 23:52:12 PDT Message-ID: <3ECDC532.4030100@iprg.nokia.com> Date: Thu, 22 May 2003 23:52:34 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, john.loughney@nokia.com wrote: >I agree - and I was just suggesting that putting some >thoughts about security upfront could actually make >things work smoother & perhaps even speed things up >(to save from last minute security gotchas). > On this, I think we can all agree. In fact, it's required, otherwise one cannot write a sensible Security Considerations. Regards, Charlie P. > > From problem-statement-bounces@alvestrand.no Fri May 23 05: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 FAA29573 for ; Fri, 23 May 2003 05:21:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED2926261F; Fri, 23 May 2003 11:20:49 +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 37AE86261A; Fri, 23 May 2003 11:20:48 +0200 (CEST) Date: Fri, 23 May 2003 10:41:13 +0200 From: Harald Tveit Alvestrand To: erosen@cisco.com Message-ID: <582367169.1053686473@localhost> In-Reply-To: <200305221401.h4ME17OO009168@rtp-core-1.cisco.com> References: <200305221401.h4ME17OO009168@rtp-core-1.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 Cc: problem-statement@alvestrand.no Subject: Useless demagoguery (Re: what are the real 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 Eric, if, somehow, we came to the point where we split the IETF between "those who are on a mission to protect the users against exploitation by the vendors" and "those who are on a mission to help the vendors exploit the users", I'd reluctantly have to join the first camp. Reluctantly, because I believe the dichtonomy to be entirely false and unproductive. If we're going to have an useful IETF, it has to be based on some shared metric of what "good" is - and "exploitation by the vendors" (less demagogically - maximizing vendors' short-term profits at the expense of making the Internet a tool that is useful to the users) is certainly not a goal that I think we can get wide buy-in on. [I happen to think that maximimzing users' benefits is critical to maintaining vendors' *long*-term profits, though - and that the marketplace is one, but not the only, critical part of the picture] Now, can we stop this useless sniping about secret personal agendas and get back to talking frankly and honestly about what core values we want the IETF to be based on? Harald --On 22. mai 2003 10:01 -0400 Eric Rosen wrote: > > It would certainly be interesting to know exactly which of the IESG > members think that they are on a mission to protect the users against > exploitation by the vendors. Naturally, anyone who is on such a > mission will think it very important to replace the operation of the > marketplace by his personal vision of the future, and will do whatever he > can to purge the IETF of other views. But let's not pretend that such > an overtly political agenda has anything to do with technical quality. > > And people still wonder why the IESG is not trusted! From problem-statement-bounces@alvestrand.no Fri May 23 07: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 HAA02545 for ; Fri, 23 May 2003 07:42:06 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 63E656261B; Fri, 23 May 2003 13:41:34 +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 AC0F962615 for ; Fri, 23 May 2003 13:41:31 +0200 (CEST) Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4650085 for problem-statement@alvestrand.no; Fri, 23 May 2003 07:41:30 -0400 Message-Id: <5.1.0.14.0.20030523073210.0274ff30@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 23 May 2003 07:38:21 -0400 To: problem-statement@alvestrand.no From: "Joel M. Halpern" In-Reply-To: <1005854969.20030522221744@dcrocker.net> References: <20030523011235.7478d87f.moore@cs.utk.edu> <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> <4318516885.20030522200444@brandenburg.com> <20030522234140.3387e2e0.moore@cs.utk.edu> <1815027409.20030522220356@brandenburg.com> <20030523011235.7478d87f.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: what are the real 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 As long as we understand this as a tension, we are probably fine. Treating this as simple produces bad results. For example, as worded Dave's note suggests that there is no drawback from having too many efforts. I don't think anyone believes that there are no drawbacks. Just in case, let me suggest one of the many drawbacks. I believe that no matter what organizational structure we craft for ourselves, there will always be a leadership load based on the number of "things to be lead" (working groups, activities, ...) As such, taking a view that we should allow more competing efforts (which at least some of the time is indeed what we should do) puts more load on our leadership. I would be very surprised if we could find a structure in which such loading was not warning for care to prevent system failure. Another major issue with allowing competing efforts is that the results do not interoperate. If there is any technical mantra that has driven our work and our success, I think that a focus on interoperability (rather than, for example, conformance) has been critical. It is why we try very hard to have as few options in protocols as possible,, for example (although we seem to fail about as often as we succeed on that particular goal.) Yours, Joel At 10:17 PM 5/22/2003 -0700, Dave Crocker wrote: >Keith, > > >> terminating credible efforts prematurely is silly. >KM> so is spreading ourselves too thin. > >ahh, right. > >that was the argument for not doing xmpp. > >better to worry about multiple efforts, each of which has serious >support, than it is to worry about unproductive efforts that drag on for >years. > >d/ >-- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Fri May 23 07:43: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 HAA02643 for ; Fri, 23 May 2003 07:43:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D4F1C62623; Fri, 23 May 2003 13:43:06 +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 AAD8C62622 for ; Fri, 23 May 2003 13:43:04 +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 h4NBh1FV014058; Fri, 23 May 2003 07:43:02 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn4-69.cisco.com [10.21.80.69]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id HAA17537; Fri, 23 May 2003 07:42:55 -0400 (EDT) Message-Id: <4.3.2.7.2.20030523072412.042d4de0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 23 May 2003 07:42:46 -0400 To: Keith Moore From: Ralph Droms In-Reply-To: <20030522083807.5a36ac33.moore@cs.utk.edu> References: <3ECC934E.2E3C2988@hursley.ibm.com> <4D7B558499107545BB45044C63822DDEEBDCDE@mvebe001.americas.nokia.com> <3ECC934E.2E3C2988@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: problem-statement@alvestrand.no Cc: Brian E Carpenter Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 Keith about a need for baby steps. We stumbled across a sequence of baby steps entirely through serendipity that seems to have worked well for the DHCPv6 specification (I say "seems to" because the spec has only recently been completed so we don't have a lot of history with the results). The extra baby step we took was to perform two rounds of interoperability testing between the acceptance of the DHCPv6 spec as a Proposed Standard and the publication of the RFC. This interoperability testing allowed us to identify a dozen or so places in the text that could be improved prior to publication of the RFC: a couple of typos, some text that required clarification, etc. We published an I-D (and ran a WG last call) summarizing the results of that interoperability testing and the spec has been edited based on the report in the I-D. The result will be (I believe; we'll see how the spec fares in practice) a better Proposed Standard spec. The analogy with the current usual path for a spec is, I think, that draft-ietf-dhc-dhcpv6-28.txt (the I-D that was accepted as the basis for the Proposed Standard) was roughly equivalent to the definition (if not the practice) of a "Proposed Standard". The version of the spec that will be published as an RFC is roughly equivalent to a "Draft Standard". What was different about the DHCPv6 spec process is that draft-ietf-dhc-dhcpv6-28.txt had no acceptance and deployment (which would have happened had it been published as Proposed). I don't claim that this experience points out a specific problem (and attendant solution) with the current process. I think the experience points out that there may be improvements we could make to the current process that better achieves the goal of "experience to prove correctness of a stable specification" prior to widespread acceptance and deployment. - Ralph At 08:38 AM 5/22/2003 -0400, Keith Moore wrote: >> We need to remove steps, not add them. > >actually I also think that we need one or two baby steps, prior to what >we now think of as proposed, to ensure that certain considerations >get dealt with early in the design phase, and also to ensure that >proposals get wide review long before the Last Call for proposed. From problem-statement-bounces@alvestrand.no Fri May 23 08:26: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 IAA03406 for ; Fri, 23 May 2003 08:26:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0034962622; Fri, 23 May 2003 14:26:03 +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 062156261D for ; Fri, 23 May 2003 14:26:01 +0200 (CEST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])ESMTP id h4NCPwW00314 for ; Fri, 23 May 2003 08:25:58 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10235X>; Fri, 23 May 2003 14:25:57 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501A9F889@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: James Kempf Date: Fri, 23 May 2003 14:25:52 +0200 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: Quality of WG Output (Was: RE: OPEN ISSUE: Standards Track) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Mmmm... maybe this is just me... But what is wrong with WG members and WG chairs to seek early help from the Security Area Advisors and ADs or from some specific WG in the security area? I.e. WG chairs should feel free to try and find help in other places in the IETF. Thanks, Bert > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: donderdag 22 mei 2003 22:38 > To: Basavaraj.Patil@nokia.com; Margaret Wasserman > Cc: randy@psg.com; problem-statement@alvestrand.no; pekkas@netcore.fi > Subject: Re: Quality of WG Output (Was: RE: OPEN ISSUE: > Standards Track) > > > Margaret, > > Well stated. Introduction of more structured, formal reviews at a > selected, very fiew points in the development process could help to > reduce the late suprise factor. Of course, it is possible to go > overboard and slow down the development with too much process, so care > is needed. > > jak > > ----- Original Message ----- > From: "Margaret Wasserman" > To: > Cc: ; ; > > Sent: Thursday, May 22, 2003 1:05 PM > Subject: Quality of WG Output (Was: RE: OPEN ISSUE: Standards Track) > > > > > > Hi Basavaraj, > > > > At 01:55 PM 5/22/2003 -0500, Basavaraj.Patil@nokia.com wrote: > > >Maybe. But the key lesson to be learn here is that the Mobile IP WG > > >spent about 3 years or more before the IESG said that the security > > >solution based on IPsec was broken. The timeline to arrive at such > > >a conclusion is a serious problem for any standards work. > > > > I agree that it is a serious problem that there was no > > adequate security review of this proposal for three > > years while it was being processed by the WG. > > > > But, I don't think that this is a problem with: > > > > - The IESG, or > > - The IETF standards track. > > > > Instead, I consider this a problem with the quality > > processes (or lack thereof) used by our WGs. We > > need to find ways to make sure that documents are > > adequately reviewed during different phases of > > WG development, so that these "late surprises" don't > > occur. In other words, we need to determine ways > > to increase the quality and integrity of WG output. > > > > This is dealt with in the problem statement > > and the process document in the discussion of WG > > engineering practices. > > > > Margaret > > > > > > > > > From problem-statement-bounces@alvestrand.no Fri May 23 08:43: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 IAA03734 for ; Fri, 23 May 2003 08:43:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 92CDD62620; Fri, 23 May 2003 14:42: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 B49576261D for ; Fri, 23 May 2003 14:42:43 +0200 (CEST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) h4NCgClr080562 for ; Fri, 23 May 2003 14:42:34 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4NCeoNh058012 for ; Fri, 23 May 2003 14:40:51 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA55108 from ; Fri, 23 May 2003 14:40:49 +0200 Message-Id: <3ECE16ED.28B36B65@hursley.ibm.com> Date: Fri, 23 May 2003 14:41:17 +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: <200305211611.AHM52047@mira-sjc5-c.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Update X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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: > > > Melinda, I think that a large fraction of the notes I've posted > > recently have contained comments of the nature of "this appears > > to be an important problem/issue and it appears to not be > > reflected in the current version of the problem description > > document". > > Sorry, should have been clearer. We're certainly tracking > discussion of new problems as they crop up on the mailing > list and those are being distilled into the new revision of > the document. Those discussions are about what's not in the > document. We haven't had much discussion of what *is* in > the document, however, and in the interest of moving the > document along towards WG last call we need to make sure > that the it's getting that kind of review. Related to that, I'm a little sad to see the former Appendix (i.e. the long list of specific problems) consigned to the archive. There may be a case for a second document that is in fact the long list, including any new ones that don't make it into the root causes document. Brian From problem-statement-bounces@alvestrand.no Fri May 23 08: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 IAA03863 for ; Fri, 23 May 2003 08:56:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E378562628; Fri, 23 May 2003 14:56:08 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by eikenes.alvestrand.no (Postfix) with ESMTP id 201096261D for ; Fri, 23 May 2003 14:56:06 +0200 (CEST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4NCu4kc272604; Fri, 23 May 2003 08:56:04 -0400 Received: from rotala.raleigh.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) h4NCu3Ku059228; Fri, 23 May 2003 06:56:03 -0600 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) h4NCqYGZ021234; Fri, 23 May 2003 08:52:34 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) h4NCqXYd021229; Fri, 23 May 2003 08:52:34 -0400 Message-Id: <200305231252.h4NCqXYd021229@rotala.raleigh.ibm.com> To: Aaron Falk In-Reply-To: Message from falk@isi.edu of "Wed, 21 May 2003 16:28:53 PDT." <20030521232852.GB27849@isi.edu> Date: Fri, 23 May 2003 08:52:33 -0400 From: Thomas Narten Cc: problem-statement@alvestrand.no Subject: Re: what are the real 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 Aaron Falk writes: > You've been around the IETF much longer than I. Do you sense that the > level of conservatism in the IESG has increased over time? My > perception is that, as more non-computer scientists get on the > Internet, it has been viewed as more of a utility, i.e., "it just > works." It wouldn't surprise me if there is a reduced tolerance of > risk by the IESG to protect these users. In other words, the > interpretation of stewardship of the Internet has changed from "let's > grow something neat" (or "let 1000 flowers bloom") to "let's keep this > cool thing from breaking" (or "let's not confuse the marketplace"). It probably has. Speaking personally, the longer I've participated in the IETF, the more I can look at past decisions and conclude "we shouldn't have done that", or "if only we had pushed back a bit more". Ten years ago, the Internet wasn't being viewed as something that had to be 7x24 and part of the basic infrastructure of our economy and society. But times have changed. Protocols that might easily be considered "90% finished" (as in "Good Enough" for PS) ten years ago don't get the same deference today. In many cases, one just can't assume that we can fix the serious bugs after we get experience. In today's world, where a PS can be implemented/shipped via a Windows OS release or cell phones to tens-hundreds of millions of devices, stuff that gets deployed has to be dealt with as part of the infrastructure for years afterwards. Security is the obvious example where if we screw up in what gets deployed, the potential for damage is huge. This goes back to a thread earlier (Brian?) about how the industry has matured and expectations have changed as well. Thomas From problem-statement-bounces@alvestrand.no Fri May 23 09:09: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 JAA04027 for ; Fri, 23 May 2003 09:09:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CEDE56262B; Fri, 23 May 2003 15:09:06 +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 4558C6261D for ; Fri, 23 May 2003 15:09:05 +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 19JCI9-0004fg-00; Fri, 23 May 2003 06:09:02 -0700 Date: Fri, 23 May 2003 09:07:50 -0400 From: Keith Moore To: Dave Crocker Message-Id: <20030523090750.77b899d3.moore@cs.utk.edu> In-Reply-To: <1005854969.20030522221744@dcrocker.net> References: <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> <4318516885.20030522200444@brandenburg.com> <20030522234140.3387e2e0.moore@cs.utk.edu> <1815027409.20030522220356@brandenburg.com> <20030523011235.7478d87f.moore@cs.utk.edu> <1005854969.20030522221744@dcrocker.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: what are the real 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 > >> terminating credible efforts prematurely is silly. > KM> so is spreading ourselves too thin. > > ahh, right. > > that was the argument for not doing xmpp. > > better to worry about multiple efforts, each of which has serious > support, than it is to worry about unproductive efforts that drag on for > years. I think I'd agree that if you have fundamental differences that you cannot resolve, sometimes it's better to have multiple competing efforts than to either give up entirely or try to force everyone to work together -- especially if the efforts are trying to solve different (though overlapping) problems. And there might be some potential for merging at a later time as the problems become better understood. But if the groups aren't really trying to solve different problems, would IETF really be serving the Internet community by promoting non-interoperable solutions? From problem-statement-bounces@alvestrand.no Fri May 23 09:17: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 JAA04138 for ; Fri, 23 May 2003 09:17:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DCE1B6262E; Fri, 23 May 2003 15:16:48 +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 EF6006261D for ; Fri, 23 May 2003 15:16:46 +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 19JCPW-0002SW-00; Fri, 23 May 2003 06:16:39 -0700 Date: Fri, 23 May 2003 09:15:27 -0400 From: Keith Moore To: Charlie Perkins Message-Id: <20030523091527.583d3022.moore@cs.utk.edu> In-Reply-To: <3ECDB4B7.2030407@iprg.nokia.com> References: <3ECDB4B7.2030407@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: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 idea of requiring a threat analysis and deployment > scenarios analysis is a pretty good way to raise the bar > way up into the stratosphere so that no work gets done. > Presumably you meant that this would come _after_ > the problem statement and definition, followed by the > requirements analysis, all of which should (???) occur > before anyone is allowed to mention a solution. ... > I really don't think engineers work that way. > I think iterative and parallel development is best, > and testing interoperability all along the way. I don't know of any other field of engineering that doesn't try to comprehensively understand and define the problem before declaring something a solution. That's not to say that potential solutions are never sketched out, but they're not treated as anything other than rough ideas. If we're going to call ourselves an Engineering organization maybe we should actually do Engineering rather than guesswork. And I realize that many participants in IETF have problems thinking like engineers. Maybe we should find a way to either teach IETF participants to think like engineers or to recruit participants who do understand the discipline of engineering. From problem-statement-bounces@alvestrand.no Fri May 23 09:19: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 JAA04195 for ; Fri, 23 May 2003 09:19:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 88E6B62633; Fri, 23 May 2003 15:18:39 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6D1846261D for ; Fri, 23 May 2003 15:18:37 +0200 (CEST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4NDIZsZ156080; Fri, 23 May 2003 09:18:35 -0400 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) h4NDIWfD153284; Fri, 23 May 2003 09:18:33 -0400 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) h4NDF5GZ021330; Fri, 23 May 2003 09:15:05 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) h4NDF4wF021325; Fri, 23 May 2003 09:15:04 -0400 Message-Id: <200305231315.h4NDF4wF021325@rotala.raleigh.ibm.com> To: john.loughney@nokia.com In-Reply-To: Message from john.loughney@nokia.com Date: Fri, 23 May 2003 09:15:04 -0400 From: Thomas Narten Cc: problem-statement@alvestrand.no Cc: sob@harvard.edu Subject: Re: what are the real 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 writes: > I agree - I'm not a rabid free-market person, but I do think it is > appropriate to allow users of the technology to have some say in this; > and that may require allowing 2 or 3 protocols that do similar things. There are pros and cons to having 2-3 protocols doing the same thing. Not always a simple answer. In some (or even most?) cases, having multiple protocols doesn't mean (say) the market (or users) will pick one (and even then the best one). Sometimes/often, the market forces vendors to implement *all* the protocols. This results from a combination of checkmarks on RFPs, or just fear of being at a disadvantage with competitors in the marketplace. Sometimes/often, you need a way for the 2-3 protocols to interoperate with each other, as they will co-exist in the same enviornment (this also gets back to the previous point -- if Big Vendor X ships protocol 1, others may be forced to implement it simply because not implementing it means no workable solution in some deployments, where there is a mixture of vendor's products). Having 3 ways of doing essentially the same thing complicates implementations (raising their cost, increasing bugs, increasing the number of interoperability issues, etc.) Ditto for operational considerations. Is the community well-served by this? In most cases, I think not. Also, how *quickly* can the market sort these things out? Not always very quickly. If end hosts are involved, we're often looking 1-3 year cycles before a protocol gets implemented and shipped in a mainstream release. There are some cases where a site/environment can really pick one approach, and it doesn't matter that other sites do it differently, because they don't need to interoperate. This tends to be more true (I suspect) when the set of devices that need to run protocol X is more constrained (e.g., only routers in my AS). But where end hosts are involved, it's a lot harder to ensure that a sys admin really has the choice to (only) use protocol X when there are multple protocols on the market. If only one vendor doesn't support the protocol (or doesn't yet in the current release because they opted to implement Y first, since they can't implement everything at once), the sys admin/end user really doesn't have a choice, in which case the argument that "the market can decide" doesn't really hold. This has led the IESG (from my view) to (as a general rule) prefer a single solution/protocol for a problem. If there are multiple protocols, there needs to be good justifications for why this is necessary and desirable. I.e., an applicability statement that explains why one might use one vs. the other. Not an absolute rule, but certainly a preference. And just saying "some vendors prefer X, others prefer Y" isn't a technical argument that can be scrutinized or evaluated. Thomas From problem-statement-bounces@alvestrand.no Fri May 23 09:20: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 JAA04249 for ; Fri, 23 May 2003 09:20:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A336062637; Fri, 23 May 2003 15:19:55 +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 80C5562636 for ; Fri, 23 May 2003 15:19:53 +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 h4NDJnH3025884 for ; Fri, 23 May 2003 09:19:49 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h4NDJnUQ025883 for problem-statement@alvestrand.no; Fri, 23 May 2003 09:19:49 -0400 (EDT) Date: Fri, 23 May 2003 09:19:49 -0400 (EDT) From: Scott Bradner Message-Id: <200305231319.h4NDJnUQ025883@newdev.harvard.edu> To: problem-statement@alvestrand.no Subject: Re: what are the real 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 keith sed: > seems like in most cases we have a difficult enough time producing a single > solution of appropriate quality and sometimes trying to resolve two conflicting approaches in order to get that single solution means that nothing gets done - see, for example, the attempt to come up with the one true multicast routing protocol - progress was made when the requirement for a working group to agree on just one solution was removed we should not produce multiple solutions for the sake of multiple solutions but we should be open to doing so when there are two or so different enough approaches that trying to force a single solution will not likly be successful in any rational period of time the IM area is another case where forcing a one true solution route would have been counter productive Scott From problem-statement-bounces@alvestrand.no Fri May 23 09:30: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 JAA04476 for ; Fri, 23 May 2003 09:30:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 42B7D62635; Fri, 23 May 2003 15:30:02 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from znsgs01r.nortelnetworks.com (h21s128a211n47.user.nortelnetworks.com [47.211.128.21]) by eikenes.alvestrand.no (Postfix) with ESMTP id 95F666261D for ; Fri, 23 May 2003 15:29:59 +0200 (CEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124])id h4NDTnG06328; Fri, 23 May 2003 14:29:50 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 May 2003 14:29:35 +0100 Message-ID: <4103264BC8D3D51180B7002048400C4501623489@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "'Brian E Carpenter'" Date: Fri, 23 May 2003 14:29:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3212F.569207FA" Cc: "'problem-statement@alvestrand.no'" Subject: RE: Update X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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_01C3212F.569207FA Content-Type: text/plain; charset="iso-8859-1" Hi. Moving the long list to a separate document has been actively considered, and the view was that we didn't have time to filter the mailing list again at this moment but if there was sufficient interest to publish the long list extended with the problems since -00 as an RFC then we would do this (more specifically I would do this). [There was text suggesting this way of proceeding in the main body originally but it is now mentioned in the Changes List]. Sending a copy to the mailing list was seen as a handy way of getting it archived. Regards, Elwyn > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: 23 May 2003 13:41 > To: problem-statement@alvestrand.no > Subject: Re: Update > > > Melinda Shore wrote: > > > > > Melinda, I think that a large fraction of the notes I've posted > > > recently have contained comments of the nature of "this appears > > > to be an important problem/issue and it appears to not be > > > reflected in the current version of the problem description > > > document". > > > > Sorry, should have been clearer. We're certainly tracking > > discussion of new problems as they crop up on the mailing > > list and those are being distilled into the new revision of > > the document. Those discussions are about what's not in the > > document. We haven't had much discussion of what *is* in > > the document, however, and in the interest of moving the > > document along towards WG last call we need to make sure > > that the it's getting that kind of review. > > Related to that, I'm a little sad to see the former Appendix > (i.e. the long list of specific problems) consigned to the > archive. There may be a case for a second document that is in > fact the long list, including any new ones that don't make it > into the root causes document. > > Brian > ------_=_NextPart_001_01C3212F.569207FA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Update

Hi.

Moving the long list to a separate document has been = actively considered, and the view was that we didn't have time to = filter the mailing list again at this moment but if there was = sufficient interest to publish the long list extended with the problems = since -00 as an RFC then we would do this (more specifically I would do = this).  [There was text suggesting this way of proceeding in the = main body originally but it is now mentioned in the Changes = List].  Sending a copy to the mailing list was seen as a handy way = of getting it archived.

Regards,
Elwyn

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com]<= /FONT>
> Sent: 23 May 2003 13:41
> To: problem-statement@alvestrand.no
> Subject: Re: Update
>
>
> Melinda Shore wrote:
> >
> > > Melinda, I think that a large = fraction of the notes I've posted
> > > recently have contained comments of = the nature of "this appears
> > > to be an important problem/issue and = it appears to not be
> > > reflected in the current version of = the problem description
> > > document".
> >
> > Sorry, should have been clearer.  = We're certainly tracking
> > discussion of new problems as they crop up = on the mailing
> > list and those are being distilled into = the new revision of
> > the document.  Those discussions are = about what's not in the
> > document.  We haven't had much = discussion of what *is* in
> > the document, however, and in the interest = of moving the
> > document along towards WG last call we = need to make sure
> > that the it's getting that kind of = review.
>
> Related to that, I'm a little sad to see the = former Appendix
> (i.e. the long list of specific problems) = consigned to the
> archive. There may be a case for a second = document that is in
> fact the long list, including any new ones that = don't make it
> into the root causes document.
>
>     Brian
>

------_=_NextPart_001_01C3212F.569207FA-- From problem-statement-bounces@alvestrand.no Fri May 23 09: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 JAA04531 for ; Fri, 23 May 2003 09:32:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 55BA06263D; Fri, 23 May 2003 15:31:40 +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 199F462626 for ; Fri, 23 May 2003 15:31:38 +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 h4NDVbH3025975 for ; Fri, 23 May 2003 09:31:37 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h4NDVb1O025974 for problem-statement@alvestrand.no; Fri, 23 May 2003 09:31:37 -0400 (EDT) Date: Fri, 23 May 2003 09:31:37 -0400 (EDT) From: Scott Bradner Message-Id: <200305231331.h4NDVb1O025974@newdev.harvard.edu> To: problem-statement@alvestrand.no Subject: Re: what are the real 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 thomas sed: > This has led the IESG (from my view) to (as a general rule) prefer a > single solution/protocol for a problem. I also *prefer* a single solution but I'd rather not block all solutions trying to force one solution when a WG is not likly to agree to a single solution Scott From problem-statement-bounces@alvestrand.no Fri May 23 09:35: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 JAA04579 for ; Fri, 23 May 2003 09:35:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D4DB862626; Fri, 23 May 2003 15:35:05 +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 2F3E76261D for ; Fri, 23 May 2003 15:35:04 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19JChK-000E6C-Ls; Fri, 23 May 2003 06:35:02 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 23 May 2003 06:35:02 -0700 To: Scott Bradner References: <200305231331.h4NDVb1O025974@newdev.harvard.edu> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: what are the real 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 > I also *prefer* a single solution > > but I'd rather not block all solutions trying to force one > solution when a WG is not likly to agree to a single solution yup. trade-offs are often a large part of this community's task. which is why this is the Engineering task force, not the Political task force, despite some recent efforts. randy From problem-statement-bounces@alvestrand.no Fri May 23 09:49: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 JAA05022 for ; Fri, 23 May 2003 09:49:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2D9256261D; Fri, 23 May 2003 15:48:56 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6121B62589 for ; Fri, 23 May 2003 15:48:51 +0200 (CEST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4NDmnsZ040470; Fri, 23 May 2003 09:48:49 -0400 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) h4NDmkfD109764; Fri, 23 May 2003 09:48:47 -0400 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) h4NDjIGZ021465; Fri, 23 May 2003 09:45:18 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) h4NDjDJ6021460; Fri, 23 May 2003 09:45:18 -0400 Message-Id: <200305231345.h4NDjDJ6021460@rotala.raleigh.ibm.com> To: Keith Moore In-Reply-To: Message from moore@cs.utk.edu <20030516144814.24774f62.moore@cs.utk.edu> Date: Fri, 23 May 2003 09:45:13 -0400 From: Thomas Narten Cc: problem-statement@alvestrand.no Subject: Re: Document Blocking (Was: I-D ACTION:draft-ietf-problem-process-00.txt) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Going back through this thread to understand better... Keith Moore writes: > > >But if one or both Security ADs are deeply convinced that a draft > > >constitutes a major security risk, or one or both Routing ADs are > > >convinced that a draft will lead to routing loops, isn't it quite > > >appropriate for them to block the document? > > > > Absolutely not, but *not* because the document shouldn't be stopped. > > The ADs who think that there is a serious problem with a document > > should convince the rest of the IESG that the document is a bad idea. > > Then, the IESG can come to consensus (or unanimity) to reject a > > document (or at least stop it until the problem is fixed). > > > > The problem with the current process (as I understand it) is that it > > allows documents to be blocked by one or two IESG members without the > > consensus of the group. > I don't see this as a problem at all. I see a problem with Keith's statement here. It can be read to imply that Keith thinks it's fine for an AD to block a document without there being any other support for the action by the rest of the IESG. I disagree with this view, and I doubt anyone else on the IESG would agree with this view. I hope that I'm misreading Keith's intent here. What is the case is that there is an assumption that when an AD raises a discuss, there is validity behind it. Whenever there is a discuss on a document, the issue needs to be articulated so that the rest of the IESG and the IETF community as a whole can be made to understand what the issue is. If that can't be done, we have a fairly basic problem. Our internal processes call for all discuss's to be written up. Once one has words, one can discuss them and agree/disagree, claim lack of understanding, etc. But the notion that an AD can (or does) just put in a vague/bogus discuss and no one ever objects to it is broken shouldn't be happenning. If it is happening, that's broken, and needs to be fixed. Again, here, having specific examples to point to would help. (I'll grant some people are saying there is an appearance of this happening, and our process rules don't prevent it from being possible, and therefore this aspect of our processes needs to be changed.) Now, you can read my words above differently depending on whether you think the cup is half empty or half full. I.e., maybe the IESG just defers to others and doesn't even check whether a particular discuss has any validity. Or, that all IESG members review *every* discuss in detail and agree with it. The reality is somewhere in between. For example, when the security ADs raise an issue, I do review them, and I have found that in most cases I agree with them. So I don't feel like I need to explicitely check every thing they say -- they have a track record and I have found them to be reasonable. > Many of the issues that hold up document publication are not easily > understood without expertise in that particular area. But it is also an absolute requirement that a real issue must be explainable to the community. So suggesting that "the issue is too hard to understand by mere mortals and therefore an AD must have blocking power" is unnacceptable. IMO, the "one discuss blocks" rule isn't designed to allow the above, but is intended to allow any AD to raise an issue that can't simply be dismissed, say, because only one AD voted that way. > Also, IESG does not "block" documents, it explains what is wrong > with them and sends them back to the working group. It's simply > infeasible to expect all of IESG to reach consensus on every issue > that requires a change to a document. For a deep technical issue, > there *might* be four people on IESG who really have enough > appreciation for that issue to express an informed opinion - and two > of those might have to stretch to understand it. I would couch this differently. Every AD must be capable of being able to understand an issue being raised. This is part of our need for breadth. But it may take time -- or even a significant amount of time -- to do that in cases where the issue is subtle, etc. Requiring that all ADs understand everything to this level is simply not scalable. But the other extreme of one AD "understanding" an issue, but no one else (either in the WG or on the IESG) is also broken. Thomas From problem-statement-bounces@alvestrand.no Fri May 23 09:54: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 JAA05150 for ; Fri, 23 May 2003 09:54:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 252F662644; Fri, 23 May 2003 15:53: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 3A47562644 for ; Fri, 23 May 2003 15:53:34 +0200 (CEST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) h4NDrMDI084314 for ; Fri, 23 May 2003 15:53:27 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4NDogNh049056 for ; Fri, 23 May 2003 15:50:47 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA42318 from ; Fri, 23 May 2003 15:50:40 +0200 Message-Id: <3ECE274D.9142C378@hursley.ibm.com> Date: Fri, 23 May 2003 15:51:09 +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: <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> <5.1.0.14.2.20030520202101.03c85b10@mail.windriver.com> <01c601c31fba$d16e49f0$236015ac@DCLKEMPFTP> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Charters, "normal process" versus ISOC, etc. (was: Re X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 Kempf wrote: > > > Given that people who were there at the time have indicated that > most > > of these problems have existed in the IETF for at least 10 years, > how > > could you reasonably claim that any IAB/IESG member who has served > in the > > last ten years is any less culpable than current IAB/IESG members? > > > > First off, I don't believe any of the current IAB/IESG members are in > any sense "culpable". Anyway, even if the old-timers are (and feel) culpable, why does that disqualify them? Repairing one's past mistakes is supposed to be a virtue. I find this whole line of discussion worrying. If applied recursively, it contaminates everyone on this mailing list; if we weren't part of the problem, we wouldn't be here. Brian From problem-statement-bounces@alvestrand.no Fri May 23 10:05: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 KAA05616 for ; Fri, 23 May 2003 10:05:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 56C5462630; Fri, 23 May 2003 16:04:53 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from alpha.jnpr.net (natint.juniper.net [207.17.136.129]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5A3CF62627 for ; Fri, 23 May 2003 16:04:51 +0200 (CEST) Received: from pi-smtp.jnpr.net ([10.10.2.36]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 23 May 2003 07:04:49 -0700 Received: from ophelia.jnpr.net ([10.10.2.95]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.5329); Fri, 23 May 2003 10:04:48 -0400 Received: from fkastenholzpc1.juniper.net ([10.10.132.71]) by ophelia.jnpr.net with Microsoft SMTPSVC(5.0.2195.5329); Fri, 23 May 2003 10:04:48 -0400 Message-Id: <5.1.1.5.2.20030523094108.04481e90@pi> X-Sender: fkastenholz@pi X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 23 May 2003 10:04:39 -0400 To: problem-statement@alvestrand.no From: Frank Kastenholz Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 23 May 2003 14:04:48.0278 (UTC) FILETIME=[45652B60:01C32134] Subject: The One True Path To Nirvana X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Folks, I hate to inject a bit of reality into this but whether the IETF decides to bless one-and-only-one way to do FOO with the high-honor of "Standards Track RFC" or allows multiple ways is only marginally important. Vendors, being interested in making money, try to differentiate their products. The Offical IETF Mantra in this regard is that vendor differentiation arises out of things like quality. While true, it is not the complete truth. Vendors will also have with their own protocols as alternative ways to do FOO. The vendor's marketing people will then tout their proprietary FOO Protocol as "better" than the standard in various ways. The proprietary FOO Protocol might even be what the vendor tried to get made a standard but failed (and now there might be an installed base...) Second, customers (bless their checkbooks and capex budgets) sometimes what something that's not the standard. It could have been something that was a candidate for standardizing but didn't make it. It could be something that the customer came up with. It could be some set of requirements that the customer has (or thinks they have) that are not met with the standard, requiring some non-standard-FOO. Having multiple levels of standard really doesn't have any effect on what vendors do or what customers want. If the deltas from one level to the next are "just bugfixes" then that's how they are treated by vendors. If there are substantive changes in function (function-x is available in proposed std, but not in draft, or vice versa) then the implementation becomes the union of all standard-levels, with config switches and the like. In other words, the propose/draft/full hierarchy is little more than feel-good self-gratification on the part of The Process Experts. Btw, before I get roasted for heresy a) There are always exceptions where things happen differently. When the right things happen, it's like winning the lottery. Enjoy it, but don't count on it b) This is not a state of affairs that I find particularly desireable. It is a state of affairs that does exist, however, and pretending that it does not exist is foolish. So, the short answer is that multiple-competing-FOOs is a fact of life. We live with it. We deal with it. Whatever the IETF does, it will not go away. That said, what the IETF _can_ do is to make the problem easier to deal with by - getting the technical quality of things as high as we can as early as we can. That means -00 of the draft, if possible (yes, I know it won't happen, but the sooner, the better) - getting drafts and changes and RFCs through the system faster (without sacrificing quality). Ideally, -00 of the ID comes out 1 week after the first BOF and there are no changes made to it, ever. Frank Kastenholz This is all my personal opinion and does not have anything to do with what my employer says, thinks, does, etc. From problem-statement-bounces@alvestrand.no Fri May 23 10:06: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 KAA05685 for ; Fri, 23 May 2003 10:06:06 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2C45A62643; Fri, 23 May 2003 16:05:37 +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 9A23462627 for ; Fri, 23 May 2003 16:05:35 +0200 (CEST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) h4NE5LUm104948 for ; Fri, 23 May 2003 16:05:27 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4NE4wYI095068 for ; Fri, 23 May 2003 16:04:59 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA21428 from ; Fri, 23 May 2003 16:04:51 +0200 Message-Id: <3ECE2A9F.E826DFD4@hursley.ibm.com> Date: Fri, 23 May 2003 16:05:19 +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: <004801c32054$70b6dd80$0200a8c0@DFNJGL21> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Now, getting back from Mobile IP to the subject field... Randy Bush wrote: > > >>>> There is also a more fundamental issue with the IETF's engineering > >>>> practices. Although our current standards track contains three > >>>> levels of maturity (Proposed Standard, Draft Standard and Full > >>>> Standard), we do not have sufficient differentiation regarding the > >>>> quality and completeness of documents required at each stage. The > >>>> bar is set very high for publication at Proposed Standard, and very > >>>> few documents advance beyond this stage. [OPEN ISSUE: Do we have > >>>> IETF consensus that this is a problem?] > >>> > >>> We're hearing proposed solutions to this problem, so it looks like > >>> there are folks who agree that it's a problem. > >>> > >>> Are there folks who DON'T agree that this is a problem? > >> > >> how does this 'problem' do damage to > >> > >> the ietf's goal is to produce high quality, relevant, and timely > >> standards for internet technology. > > > > well, what we currently have is for most purposes a single stage of > > review. perhaps we'd produce higher quality and more relevant documents > > if we imposed some earlier review, and perhaps we'd get those documents > > done in a more timely fashion if the early reviews identified problems > > that are expensive (or time consuming) to fix if not discovered until > > later. > > i do not disagree with you. > > but that is not at all what the problem statement above says to me > it seems to say that > o the bar is too high Which I simply don't agree to, after my experience as a WG Chair shepherding documents to PS. We should *not* be applying rubber stamps more easily. There are enough bugs in PS documents to satisfy anybody. > o there is insufficient differentiation between ps, ds, and fs > with which i disagree I agree there is enough differentiation - the problem is that fs is too strongly differentiated, so nobody bothers. That's why I propose to munge ds and fs into a single grade. Make it simpler. Never make it more complicated. Brian From problem-statement-bounces@alvestrand.no Fri May 23 10:31: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 KAA07347 for ; Fri, 23 May 2003 10:31:27 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A2B1462647; Fri, 23 May 2003 16:30:57 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7B42F62639 for ; Fri, 23 May 2003 16:30:55 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19JDZF-0002pa-00; Fri, 23 May 2003 07:30:46 -0700 Date: Fri, 23 May 2003 10:29:33 -0400 From: Keith Moore To: Thomas Narten Message-Id: <20030523102933.3d208710.moore@cs.utk.edu> In-Reply-To: <200305231345.h4NDjDJ6021460@rotala.raleigh.ibm.com> References: <20030516144814.24774f62.moore@cs.utk.edu> <200305231345.h4NDjDJ6021460@rotala.raleigh.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 Blocking (Was: I-D ACTION:draft-ietf-problem-process-00.txt) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 the current process (as I understand it) is that it > > > allows documents to be blocked by one or two IESG members without the > > > consensus of the group. > > > I don't see this as a problem at all. > > I see a problem with Keith's statement here. It can be read to imply > that Keith thinks it's fine for an AD to block a document without > there being any other support for the action by the rest of the > IESG. Not quite - but I should clarify that part of the reason I don't see this as a problem is that I don't view a Discuss as "blocking a document". IMHO IESG does not have enough power to block documents that are truly bad - the presumption is that IESG must tell the WG how to fix the document, and sometimes that is simply infeasible. And IESG wastes a lot of its energy trying to reconcile problems with documents that should simply be discarded. But if IESG were given the power to actually block documents, I agree it should take a significant plurality of IESG to do so. Note that even under our current processes and procedures if an AD were to repeatedly vote Discuss for no good reason in order to block a document, there are several avenues available to fix the problem. The IESG has a procedure that would require at least one other AD's support in order to continue blocking - which seems unlikely if there's no good reason. Failing that, there is always the ability to appeal to IAB and/or recall the AD. But I don't really think this is a problem in reality, as opposed to perception. Generally, as Thomas says, when an AD votes Discuss there is enough understanding of the issue among IESG for other ADs to support and/or clarify the objection that is being raised. But even if only one AD supports the Discuss, I think it's reasonable to allow a single AD to raise the issue, and send the document back to the WG, with the WG expected to respond in good faith - either to fix the problem or refute the problem. And if they can't resolve their differences, I'd probably suggest that the AD write up a "dissenting opinion" RFC - doing his best job to explain the problem - and publish that simultaneously with the WG's RFC. I've seen more recalcitrant WGs than stubbornly incorrect ADs, so I don't presume that the WG is more right than the AD - actually I think the AD is more likely to be correct about the objections he/she is raising even when he/she has a hard time explaining them to others. But perhaps more importantly, I've seen each of ADs and WG charirs and document authors refuse to cooperate or compromise or even try to understand each other when they thought they could get their way by exploiting the rules. So I think we should try to avoid rules that automatically permit either an AD or a WG to force his/her/its preferred outcome. From problem-statement-bounces@alvestrand.no Fri May 23 10: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 KAA07486 for ; Fri, 23 May 2003 10:37:49 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6382F6263F; Fri, 23 May 2003 16:37:19 +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 C547662639 for ; Fri, 23 May 2003 16:37:16 +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 19JDfS-0007mo-00; Fri, 23 May 2003 07:37:11 -0700 Date: Fri, 23 May 2003 10:35:58 -0400 From: Keith Moore To: Scott Bradner Message-Id: <20030523103558.3bf96d7e.moore@cs.utk.edu> In-Reply-To: <200305231319.h4NDJnUQ025883@newdev.harvard.edu> References: <200305231319.h4NDJnUQ025883@newdev.harvard.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 Subject: Re: what are the real 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 > and sometimes trying to resolve two conflicting approaches in order to > get that single solution means that nothing gets done - see, for example, > the attempt to come up with the one true multicast routing protocol - > progress was made when the requirement for a working group to agree > on just one solution was removed > the IM area is another case where forcing a one true solution route would > have been counter productive as I understand it these are very different situations - weren't the multicast routing protocol differences a result of wanting to solve different problems (or at least the same problem in different environments)? whereas the differences in the IM area seemed to lack technical justification. From problem-statement-bounces@alvestrand.no Fri May 23 11:02: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 LAA08722 for ; Fri, 23 May 2003 11:02:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 538066264C; Fri, 23 May 2003 17:01:31 +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 B212F6262F; Fri, 23 May 2003 17:01:28 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19JE2y-00069w-00; Fri, 23 May 2003 10:01:28 -0500 Date: Fri, 23 May 2003 11:01:27 -0400 From: John C Klensin To: Harald Tveit Alvestrand Message-ID: <101078583.1053687687@p3.JCK.COM> In-Reply-To: <409117549.1053513221@localhost> References: <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> <5.1.0.14.2.20030520202101.03c85b10@mail.windriver.com> <278018759.1053473749@p3.JCK.COM> <409117549.1053513221@localhost> 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: IESG spin-up time (was: Re: Charters, "normal process" versus ISOC, etc. (was: Re) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, 21 May, 2003 10:33 +0200 Harald Tveit Alvestrand wrote: > WRT "6 months": > > People's capabilities vary. Some are faster than others - and > for routine matters, procedures and so on, I think the process > goes much faster than 6 months. But the process of learning > the personal, technological and organizational interactions in > working groups you have not previously followed is a > significant learning curve - it took me more than one IETF > meeting after I became managing AD for the SNMPv3 group before > I understood the interactions there well enough to be an > effective AD, for instance (sometimes I'm not sure I ever got > there in the 1 year I did that job). But it took you less than one IETF meeting to come up to speed and be reasonably effective when you got your first AD job, so the equation is more complicated than that. One thing I'm pretty sure about is that your co-AD in applications didn't do anything superhuman to help -- he pretty much assumed that you would hit the ground running and ask questions if needed, and you more than satified that expectation. So, in one case, you came, new, onto the IESG and came up to speed very rapidly, both with regard to IESG procedures and with regard to the WGs involved. In the other, you already knew the IESG procedures and had a working relationship with most of the rest of the IESG, which should have made things a lot faster, and still found taking over a new area a slow process. Absent other data, I suggest this points toward an hypothesis of "some areas are harder to take over as AD than others, especially if the area is already problematic and/or the new AD hasn't worked extensively in it (regardless of his or her background in the field of that area)" rather than an issue in coming up to speed on the IESG itself. regards, john From problem-statement-bounces@alvestrand.no Fri May 23 11:10: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 LAA08935 for ; Fri, 23 May 2003 11:10:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D99626262F; Fri, 23 May 2003 17:09: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 695AB62589 for ; Fri, 23 May 2003 17:09:51 +0200 (CEST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) h4NF9bCi073552 for ; Fri, 23 May 2003 17:09:40 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4NF9KNh071830 for ; Fri, 23 May 2003 17:09:21 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA52612 from ; Fri, 23 May 2003 17:09:19 +0200 Message-Id: <3ECE39BB.8DB4A72A@hursley.ibm.com> Date: Fri, 23 May 2003 17:09:47 +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: <7D5D48D2CAA3D84C813F5B154F43B15501A9F889@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Quality of WG Output (Was: RE: OPEN ISSUE: Standards Track) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Bert, they are free to do it today, but the problem is the ones who don't. However, I would rather fix this problem with a carrot than with a stick (hence the SIRs draft). Brian "Wijnen, Bert (Bert)" wrote: > > Mmmm... maybe this is just me... > > But what is wrong with WG members and WG chairs to seek > early help from the Security Area Advisors and ADs or > from some specific WG in the security area? > > I.e. WG chairs should feel free to try and find help in > other places in the IETF. > > Thanks, > Bert > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: donderdag 22 mei 2003 22:38 > > To: Basavaraj.Patil@nokia.com; Margaret Wasserman > > Cc: randy@psg.com; problem-statement@alvestrand.no; pekkas@netcore.fi > > Subject: Re: Quality of WG Output (Was: RE: OPEN ISSUE: > > Standards Track) > > > > > > Margaret, > > > > Well stated. Introduction of more structured, formal reviews at a > > selected, very fiew points in the development process could help to > > reduce the late suprise factor. Of course, it is possible to go > > overboard and slow down the development with too much process, so care > > is needed. > > > > jak > > > > ----- Original Message ----- > > From: "Margaret Wasserman" > > To: > > Cc: ; ; > > > > Sent: Thursday, May 22, 2003 1:05 PM > > Subject: Quality of WG Output (Was: RE: OPEN ISSUE: Standards Track) > > > > > > > > > > Hi Basavaraj, > > > > > > At 01:55 PM 5/22/2003 -0500, Basavaraj.Patil@nokia.com wrote: > > > >Maybe. But the key lesson to be learn here is that the Mobile IP WG > > > >spent about 3 years or more before the IESG said that the security > > > >solution based on IPsec was broken. The timeline to arrive at such > > > >a conclusion is a serious problem for any standards work. > > > > > > I agree that it is a serious problem that there was no > > > adequate security review of this proposal for three > > > years while it was being processed by the WG. > > > > > > But, I don't think that this is a problem with: > > > > > > - The IESG, or > > > - The IETF standards track. > > > > > > Instead, I consider this a problem with the quality > > > processes (or lack thereof) used by our WGs. We > > > need to find ways to make sure that documents are > > > adequately reviewed during different phases of > > > WG development, so that these "late surprises" don't > > > occur. In other words, we need to determine ways > > > to increase the quality and integrity of WG output. > > > > > > This is dealt with in the problem statement > > > and the process document in the discussion of WG > > > engineering practices. > > > > > > Margaret > > > From problem-statement-bounces@alvestrand.no Fri May 23 11:16: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 LAA09375 for ; Fri, 23 May 2003 11:16:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1DF2E6264F; Fri, 23 May 2003 17:15:35 +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 B37BE62646; Fri, 23 May 2003 17:15:32 +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 h4NFFSFV004520; Fri, 23 May 2003 11:15:29 -0400 (EDT) Message-Id: <200305231515.h4NFFSFV004520@rtp-core-1.cisco.com> To: Geoff Huston , Harald Tveit Alvestrand In-reply-to: Your message of Fri, 23 May 2003 10:04:50 +1000. <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> 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, 23 May 2003 11:15:28 -0400 From: Eric Rosen Cc: problem-statement@alvestrand.no Subject: Re: what are the real problems 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 Geoff> I do see that part of the rationale of the existence of the IETF is Geoff> to provide a means of balancing the various interests of consumers Geoff> and competing vendors The "balancing of interests" is a political matter that is orthogonal to the issue of technical quality. People will have different opinions about how well the marketplace balances the various interests, of course. There have been many cases in which small groups of people use closed processes to "balance interests" according to their own view of the proper balance. Rarely does this work out well. I'd remind you that the spread of TCP/IP is due to the market demand for interoperable standards, NOT due to any attempt on the part of the IETF to manipulate the market. Harald> if, somehow, we came to the point where we split the IETF between Harald> "those who are on a mission to protect the users against Harald> exploitation by the vendors" and "those who are on a mission to help Harald> the vendors exploit the users", I'd reluctantly have to join the Harald> first camp. Any suggestion that if you're not in one of these camps you must be in the other would indeed be useless demagoguery. As long as the IESG asserts the right to make decisions that go beyond issues of technical quality and correctness, we have a problem. From problem-statement-bounces@alvestrand.no Fri May 23 11:17: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 LAA09480 for ; Fri, 23 May 2003 11:17:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 508A06264E; Fri, 23 May 2003 17:16:53 +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 BF8B862646 for ; Fri, 23 May 2003 17:16:50 +0200 (CEST) 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 h4NFGl9x017770 for ; Fri, 23 May 2003 08:16:48 -0700 (PDT) Received: from cisco.com (sjc-vpn2-500.cisco.com [10.21.113.244]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AGL29927; Fri, 23 May 2003 08:10:42 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Fri, 23 May 2003 11:16:45 -0400 Date: Fri, 23 May 2003 11:16:45 -0400 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030523151645.GX2128@sbrim-w2k> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: <7D5D48D2CAA3D84C813F5B154F43B15501A9F889@nl0006exch001u.nl.lucent.com> <3ECE39BB.8DB4A72A@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ECE39BB.8DB4A72A@hursley.ibm.com> User-Agent: Mutt/1.4i Subject: Re: Quality of WG Output (Was: RE: OPEN ISSUE: Standards Track) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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, May 23, 2003 05:09:47PM +0200, Brian E Carpenter allegedly wrote: > Bert, they are free to do it today, but the problem is > the ones who don't. > > However, I would rather fix this problem with a carrot > than with a stick (hence the SIRs draft). which technically includes a stick, since documents MUST be reviewed before publication. From problem-statement-bounces@alvestrand.no Fri May 23 11:31: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 LAA09748 for ; Fri, 23 May 2003 11:31:29 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3A3A562655; Fri, 23 May 2003 17:31:00 +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 675EB62639; Fri, 23 May 2003 17:30:58 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19JEVU-000HCl-O1; Fri, 23 May 2003 08:30:56 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 23 May 2003 08:30:56 -0700 To: Eric Rosen References: <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> <200305231515.h4NFFSFV004520@rtp-core-1.cisco.com> Message-Id: Cc: Harald Tveit Alvestrand Cc: Geoff Huston Cc: problem-statement@alvestrand.no Subject: Re: what are the real 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 > The "balancing of interests" is a political matter that is orthogonal to > the issue of technical quality. People will have different opinions about > how well the marketplace balances the various interests, of course. There > have been many cases in which small groups of people use closed processes > to "balance interests" according to their own view of the proper balance. > Rarely does this work out well. i agree. i can specifically remember whan a large vendor whose employees caucused internally and tried to apply *corporate* pressure at all sorts of points in the ietf, including the chair, to achieve their marketing goal. and you're right, it didn't work out well. but frank is right, thinking we can change this is naive. learning to deal with it is not. randy From problem-statement-bounces@alvestrand.no Fri May 23 12:00: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 MAA10560 for ; Fri, 23 May 2003 12:00:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 686C76262A; Fri, 23 May 2003 18:00:19 +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 0895F62205 for ; Fri, 23 May 2003 18:00:18 +0200 (CEST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) h4NG0Glr068424 for ; Fri, 23 May 2003 18:00:16 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4NG0FYI221222 for ; Fri, 23 May 2003 18:00:15 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA35220 from ; Fri, 23 May 2003 18:00:14 +0200 Message-Id: <3ECE45AA.E4F547FC@hursley.ibm.com> Date: Fri, 23 May 2003 18:00: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: <7D5D48D2CAA3D84C813F5B154F43B15501A9F889@nl0006exch001u.nl.lucent.com> <20030523151645.GX2128@sbrim-w2k> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Quality of WG Output (Was: RE: OPEN ISSUE: Standards Track) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 W Brim wrote: > > On Fri, May 23, 2003 05:09:47PM +0200, Brian E Carpenter allegedly wrote: > > Bert, they are free to do it today, but the problem is > > the ones who don't. > > > > However, I would rather fix this problem with a carrot > > than with a stick (hence the SIRs draft). > > which technically includes a stick, since documents MUST be reviewed > before publication. Actually, wait for the -01 version. We've had comments on that point. Brian From problem-statement-bounces@alvestrand.no Fri May 23 12:38: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 MAA12113 for ; Fri, 23 May 2003 12:38:41 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D9DA962624; Fri, 23 May 2003 18:38:11 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mta3.wss.scd.yahoo.com (mta3.wss.scd.yahoo.com [66.218.85.34]) by eikenes.alvestrand.no (Postfix) with ESMTP id EB81462621 for ; Fri, 23 May 2003 18:38:00 +0200 (CEST) Received: from AwducheHPlapt (129.174.54.58) by mta3.wss.scd.yahoo.com (7.0.015.1) (authenticated as awduche@awduche.com) id 3ECD1614000617C6 for problem-statement@alvestrand.no; Fri, 23 May 2003 09:37:59 -0700 From: "Daniel O. Awduche" To: Date: Fri, 23 May 2003 12:37:44 -0400 Message-ID: <001301c32149$a334c6a0$3a36ae81@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 In-Reply-To: <20030523090750.77b899d3.moore@cs.utk.edu> Importance: Normal Subject: Problem: Multiple Incompatible Specifications 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 Advancing multiple incompatible specifications addressing the same requirements is a disservice to the industry. Such actions diminish the wider impacts of "standardization," induce an unnecessary and avoidable partition in the market, increase the *real* cost of business, and diminish end user choice (rather than enhance it). If requirements differ, but overlap, then it is realistic to advance incompatible specifications. In that case, however, reasonable best effort should be made to reuse commonalities if at all possible. This does not preclude the need, as occasion warrants, for experimental specifications, and informational documents highlighting proprietary solutions. Cheers, /Dan From problem-statement-bounces@alvestrand.no Fri May 23 13: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 NAA16471 for ; Fri, 23 May 2003 13:45:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D4E856262C; Fri, 23 May 2003 19:45:23 +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 268F362621; Fri, 23 May 2003 19:45:18 +0200 (CEST) Date: Fri, 23 May 2003 18:29:52 +0200 From: Harald Tveit Alvestrand To: Spencer Dawkins , problem-statement@alvestrand.no Message-ID: <610486322.1053714592@localhost> In-Reply-To: <04c701c31ec8$1efb8b40$0300a8c0@DFNJGL21> References: <5.1.0.14.2.20030515114433.04767ac8@mail.windriver.com> <4517643810.20030516200534@brandenburg.com> <04c701c31ec8$1efb8b40$0300a8c0@DFNJGL21> 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 ISSUE: WG Chair Selection (in general) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 20. mai 2003 07:05 -0500 Spencer Dawkins wrote: > I found Harald's process for choosing co-chairs for the > Problem Statement working group to be encouraging, > and would like to see something like this become > more common in the IETF. > > Subject to the "ADs and WG chairs must have a > good relationship" caveat that Margaret mentioned... I liked that process, because it gave me candidates I wouldn't have thought of, and gave me the opportunity to solicit input on them in a far more open fashion than I could have done otherwise. It was also special, in that I was looking for people capable of operating with much less direct involvement than the usual AD-Chair relationship, so having independent views of their qualifications was even more important to me than usual. And it did not require any change to the rules to allow me to do it..... One thing I'm afraid of, though, is the degree to which the WG chair selection can be a tool of "corporate gameplaying". When an AD is the sole judge of which candidate is best for a position, he/she can (and has been!) accused of picking the person based on personal or company bias; this is hard to defend against, and the accusation, if made, can be quite harmful to the cooperation climate of a working group - one risks the AD going into "reverse discrimination mode" and seeking candidates that are obviously unaffiliated, even if they are not the best people available. Making a public call for input can mean getting more input - but also makes it easier to make objective-sounding complaints: "My company has offered seven chair candidates and had none selected - are you discriminating us?", "since company A got WG X, and company B got WG Y, we should get WG Z, even though our chair candidate is less qualified than company A's". And in the end, I still think the AD will be stuck with making the decision. Thoughts? Harald From problem-statement-bounces@alvestrand.no Fri May 23 14:26: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 OAA18794 for ; Fri, 23 May 2003 14:26:27 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 68D7662629; Fri, 23 May 2003 20:25:56 +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 34E4E62589 for ; Fri, 23 May 2003 20:25:53 +0200 (CEST) Received: from adsl-67-126-140-113.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4NIPXN17866; Fri, 23 May 2003 11:25:33 -0700 Date: Fri, 23 May 2003 11:25:49 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1423612053.20030523112549@dcrocker.net> To: Keith Moore In-Reply-To: <20030523011235.7478d87f.moore@cs.utk.edu> References: <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> <4318516885.20030522200444@brandenburg.com> <20030522234140.3387e2e0.moore@cs.utk.edu> <1815027409.20030522220356@brandenburg.com> <20030523011235.7478d87f.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: Re: what are the real problems X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: dcrocker@brandenburg.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 Keith, >> terminating credible efforts prematurely is silly. KM> so is spreading ourselves too thin. If the IETF ever gets serious about the question of spreading things too thin, it will need to worry far more about 1) the scope of what is legitimate to charter within the ietf, 2) the clarity, precision and utility of working group charters, and 3) the timely progress of working groups. Competing efforts have a natural filter, called critical mass. If they can't develop a critical mass of serious effort, they die of their own accord. If they *can* develop competent effort, then it is essentially hubris for IETF management to arbitrarily choose between competing proposals. For all of the times we have efforts to create competing proposals, most die of their own lack of credible technical support. They do not need arbitrary management 'help'. For the few that are serious, we do not need to worry about the "drain" on IETF management. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Fri May 23 14:36: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 OAA19282 for ; Fri, 23 May 2003 14:36:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D5E2C62632; Fri, 23 May 2003 20:35:39 +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 7788D62589 for ; Fri, 23 May 2003 20:35:36 +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 h4NIZZH3027253 for ; Fri, 23 May 2003 14:35:35 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h4NIZZvM027252 for problem-statement@alvestrand.no; Fri, 23 May 2003 14:35:35 -0400 (EDT) Date: Fri, 23 May 2003 14:35:35 -0400 (EDT) From: Scott Bradner Message-Id: <200305231835.h4NIZZvM027252@newdev.harvard.edu> To: problem-statement@alvestrand.no Subject: Re: Problem: Multiple Incompatible 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 note that in saying that there are times when more than one solution may need to be worked on I do not mean to imply that we should progress multiple standards track documents - in the cases I can think of it is a better idea to publish the competing ideas as experimental RFCs to see what the market thinks and then, if a clear message can be seen at some later date, focus attention on one solution which can then be brought to the standards track there are exceptions (SNMP vs CMOT is one and OSPF & ISIS is another) but I do not think that it is the general case that there should be multiple stds track technologies addressing the same problem. Scott From problem-statement-bounces@alvestrand.no Fri May 23 15:33: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 PAA22267 for ; Fri, 23 May 2003 15:33:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A478062639; Fri, 23 May 2003 21:33:08 +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 D397162638 for ; Fri, 23 May 2003 21:33:06 +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 h4NJWxk06735; Fri, 23 May 2003 15:32:59 -0400 (EDT) Date: Fri, 23 May 2003 15:32:59 -0400 From: Keith Moore To: dcrocker@brandenburg.com Message-Id: <20030523153259.4e97c29e.moore@cs.utk.edu> In-Reply-To: <1423612053.20030523112549@dcrocker.net> References: <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> <4318516885.20030522200444@brandenburg.com> <20030522234140.3387e2e0.moore@cs.utk.edu> <1815027409.20030522220356@brandenburg.com> <20030523011235.7478d87f.moore@cs.utk.edu> <1423612053.20030523112549@dcrocker.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: dhc@dcrocker.net Cc: moore@cs.utk.edu Subject: Re: what are the real 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 > >> terminating credible efforts prematurely is silly. > > KM> so is spreading ourselves too thin. > > If the IETF ever gets serious about the question of spreading things > too thin, it will need to worry far more about 1) the scope of what is > legitimate to charter within the ietf, 2) the clarity, precision and > utility of working group charters, and 3) the timely progress of > working groups. At least when I was on IESG, we *did* worry about such things. > For all of the times we have efforts to create competing proposals, > most die of their own lack of credible technical support. They do not > need arbitrary management 'help'. For the few that are serious, we do > not need to worry about the "drain" on IETF management. My experience indicates otherwise. Keith From problem-statement-bounces@alvestrand.no Fri May 23 15: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 PAA22913 for ; Fri, 23 May 2003 15:54:15 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A7DC062636; Fri, 23 May 2003 21:53:45 +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 9D33F62631 for ; Fri, 23 May 2003 21:53:43 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19JIbm-0007dV-00; Fri, 23 May 2003 14:53:42 -0500 Date: Fri, 23 May 2003 15:53:41 -0400 From: John C Klensin To: "dcrocker@brandenburg.com" Message-ID: <118612545.1053705221@p3.JCK.COM> In-Reply-To: <1423612053.20030523112549@dcrocker.net> References: <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> <4318516885.20030522200444@brandenburg.com> <20030522234140.3387e2e0.moore@cs.utk.edu> <1815027409.20030522220356@brandenburg.com> <20030523011235.7478d87f.moore@cs.utk.edu> <1423612053.20030523112549@dcrocker.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 Cc: "problem-statement@alvestrand.no" Subject: Re: what are the real 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 --On Friday, 23 May, 2003 11:25 -0700 Dave Crocker wrote: > Competing efforts have a natural filter, called critical mass. > If they can't develop a critical mass of serious effort, they > die of their own accord. If they *can* develop competent > effort, then it is essentially hubris for IETF management to > arbitrarily choose between competing proposals. Dave, While I think I agree in general, I think we need to be a bit careful here. It can sometimes be exceptionally difficult to tell a mob from "critical mass" and even more difficult to distinguish between a pack of wolves in full chase and "strong consensus". Both mobs and wolf packs typically have some organizing leadership, although often, when the leaders are good at their work, the only clear symptom is that everyone is headed in the same direction, or baying more or less in unison, rather than running off in all directions at random. If something dies from lack of critical mass, fine: we generally should wish the effort well and speed it on its way to a happy rest. I'm really pleased about the number of WGs the IESG has succeeded in closing in the last several months --both the "closed/sucessful" and "closed/wasn't doing much" ones-- I think it is a great trend that should be applauded and continued. But the combination of "they have critical mass" and "there is competent effort" are wildly subjective and both are subject to gaming. And what is, and is not, "arbitrary" is even worse: I don't think any of us would argue for, or encourage, the "IETF management" to make arbitrary choices between competing proposals (or any other arbitrary choice unless a choice is important and the particular choice really makes no difference). But that doesn't imply that some work with WG consensus behind it shouldn't be killed, or that choices should not be made on the grounds that one is better for the Internet than the other, and so on, even if the WG doesn't agree with the reasoning. I'm not opposed to competing standards, although I'd hate to see us make a habit of it (and, in most cases, would prefer competing Experimental protocols with a clear plan about review and real decision-making). I think that there are some circumstances in which we really should say "nice try, but no sale and no standard" to WGs -- again, I would be very upset if it became a habit and extremely concerned if it emerges as a "late surprise", but I think it is dangerous when the IESG doesn't believe it has that power and, indeed, responsibility to make those decisions when the WG has been getting, and resisting, push-back for some time without any real effort to engage in a dialogue on the issues the AD is raising. We have both seen situations in which a relatively well-organized, but very narrowly-focused, group comes to the IETF wanting either ratification, or an umbrella organization for, standards it wants to produce. These groups have critical mass by any objective measure we could apply. What they often lack is a strong sense of responsibility to and for the Internet as a whole as distinct from their narrow efforts and focus. Sometimes they can be educated, sometimes they can't. But they routinely argue "critical mass" (often in the form of how many people they can get to hum loudly at a BOF) as evidence for their entitlement to have a WG. If they get such a WG, it often requires superhuman efforts on the part of the relevant AD to get and keep their work on-track with basic functionality and interoperability goals on the public Internet, and the ADs are often damned for those efforts when we, as a community, should be thanking them. The same situation applies late in the process: if there is a controversial issue, and dollars are at stake, it is rarely difficult for someone who is good at whipping up crowds to get a number of folks to yell loudly in unison either for or against a proposal or some push-back about it. Ultimately, someone needs to make a judgment about whether a particular size group, or a particular volume of comments --favorable or unfavorable-- represent true "critical mass" or "rough consensus", and whether the result is competent, or whether they represent a possibly-well-organized effort to push a special interest or insufficiently-thought-out protocol through the IETF. Even from my perspective as someone who has had more than the usual quota of disagreements with the IESG as a whole and with how individual IESG members have handled particular situations, I think our best hope is to let --and expect-- the IESG to do its job in these areas. That means avoiding getting into the kind of second-guessing in which "John (or Dave) thinks there is critical mass" or "everyone who spoke more than twice at the last plenary agreed" are presumed to take precedence over IESG deliberation and decision-making. Does "let the IESG do it" have a potential for abuse? Sure. Do I, personally, think it has been abused occasionally? Yes. Do I believe they have made the wrong decisions, or have been much too slow to make a decision, sometimes? Yes, more certainly than I think there has been intentional abuse in getting there. But, for those issues, I think we need to concentrate on having the basis on which decisions are made be much more public and transparent. I think we also need to look at improving the efficiency and effectiveness of the checks and balances --including the appeals and recall procedures-- if we conclude that they aren't usable enough. But I think that blanket statements about criteria that, themselves, are subject to abuse and require subjective interpretation just take us around in circles. > For all of the times we have efforts to create competing > proposals, most die of their own lack of credible technical > support. They do not need arbitrary management 'help'. For the > few that are serious, we do not need to worry about the > "drain" on IETF management. In general, yes. But, perhaps because I seem to like worrying, I don't want to do anything that would say to the IESG "even if you think this is important and should be encouraged, if they don't have critical mass on their own, you are not to go try to nurture them or figure out ways to move the effort along". And I do think it is important to examine, or help the IESG examine, their workload so that, if something _is_ serious, the cycles are available to deal with it without setting off crises about how other things are getting delayed or "blocked". regards, john From problem-statement-bounces@alvestrand.no Fri May 23 17:34: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 RAA26833 for ; Fri, 23 May 2003 17:34:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 208AD62631; Fri, 23 May 2003 23:34:05 +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 67CDA62621 for ; Fri, 23 May 2003 23:34:02 +0200 (CEST) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) h4NLXu6I000584; Fri, 23 May 2003 14:33:57 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) h4NLXsix005865; Fri, 23 May 2003 14:33:55 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <118612545.1053705221@p3.JCK.COM> References: <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> <4318516885.20030522200444@brandenburg.com> <20030522234140.3387e2e0.moore@cs.utk.edu> <1815027409.20030522220356@brandenburg.com> <20030523011235.7478d87f.moore@cs.utk.edu> <1423612053.20030523112549@dcrocker.net> <118612545.1053705221@p3.JCK.COM> Date: Fri, 23 May 2003 14:33:53 -0700 To: John C Klensin From: hardie@qualcomm.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "problem-statement@alvestrand.no" Subject: Problem: Resolution mechanisms for when working group consensus and IETF consensus or principles are not the same (was Re: what are the real 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 I think John has made a very important point here, and want to pull it up to the named problem level (though I'm not sure I've written the right name above). Here's the critical text for me: > >We have both seen situations in which a relatively well-organized, >but very narrowly-focused, group comes to the IETF wanting either >ratification, or an umbrella organization for, standards it wants to >produce. These groups have critical mass by any objective measure >we could apply. What they often lack is a strong sense of >responsibility to and for the Internet as a whole as distinct from >their narrow efforts and focus. Sometimes they can be educated, >sometimes they can't. But they routinely argue "critical mass" >(often in the form of how many people they can get to hum loudly at >a BOF) as evidence for their entitlement to have a WG. If they get >such a WG, it often requires superhuman efforts on the part of the >relevant AD to get and keep their work on-track with basic >functionality and interoperability goals on the public Internet, and >the ADs are often damned for those efforts when we, as a community, >should be thanking them. Another way to put this is that what is a rational decision for a working group may not be the right decision for the IETF as a whole. From some perspectives, it may be rational to resist change to deployed clients, even though they contribute to congestion or lack security. It may be rational to avoid interoperability with competing systems, so that a larger scope for the current effort may be planned. It may even be rational for the working group to replicate at one layer a suite of services developed or being developed at another, so as to avoid dependencies. Looked at from a broader perspectives, these are rarely the right choices, but we have to acknowledge the tension between the needs of a single effort and the needs of the network as a whole. At the moment, we have poor mechanisms to deal with those tensions, even though I believe most IETF participants would agree that congestion control, security, interoperability, and the reuse of a common core set of services are all laudable design goals. The community reviews charters and constrains them such that efforts are expected to meet certain design goals. There can be pushback during IETF Last Call or during the IESG's review. Fundamentally, though, we lack a clear way of handling this tension as working groups go through the process. We trust that participants have internalized the issues and that they, therefore, will handle the tension themselves. That can and does work, but we need other mechanisms to reinforce it: some of those may be training, some may be structural reviews at periodic intervals, and some may be creating methods to ensure that cross-speciality expertise is more consistently available. But I believe this is one of the key issues at stake in our reform efforts: keeping in balance the global and local. Just my opinion, regards, Ted Hardie From problem-statement-bounces@alvestrand.no Fri May 23 18:31: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 SAA28994 for ; Fri, 23 May 2003 18:31:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CE9A562621; Sat, 24 May 2003 00:30: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 0DE5162616 for ; Sat, 24 May 2003 00:30:36 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19JL3b-0008PK-00; Fri, 23 May 2003 17:30:35 -0500 Date: Fri, 23 May 2003 18:30:34 -0400 From: John C Klensin To: "hardie@qualcomm.com" Message-ID: <128024980.1053714634@p3.JCK.COM> In-Reply-To: References: <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> <4318516885.20030522200444@brandenburg.com> <20030522234140.3387e2e0.moore@cs.utk.edu> <1815027409.20030522220356@brandenburg.com> <20030523011235.7478d87f.moore@cs.utk.edu> <1423612053.20030523112549@dcrocker.net> <118612545.1053705221@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 Cc: "problem-statement@alvestrand.no" Subject: Re: Problem: Resolution mechanisms for when working group consensus and IETF consensus or principles are not the same (was Re: what are the real 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 --On Friday, 23 May, 2003 14:33 -0700 "hardie@qualcomm.com" wrote: > I think John has made a very important point here, and want to > pull it up to the named problem level (though I'm not sure > I've written the right name above). Here's the critical text > for me: > >> We have both seen situations in which a relatively >> well-organized, but very narrowly-focused, group comes to >> the IETF wanting either ratification, or an umbrella >> organization for, standards it wants to produce. These >... > Another way to put this is that what is a rational decision > for a working group may not be the right decision for the IETF > as a whole. From some perspectives, it may be rational to > resist change to deployed clients, even though they contribute > to congestion or lack security. It may be rational to avoid >... Ted, I agree with everything you say and, if my note helped you formulate it, I'm pleased. But I am equally concerned about the startup- and mid-process versions of the problem. I see that problem as one of the community claiming the "right" to have particular things happen if some vague, but important-sounding condition is claimed to be met. You may have missed that; it may be a separate problem. Let me take the part you have addressed as a given (i.e., if people want to argue about it, I'm happy to have them argue with you :-)). But I want to give an extended, if made-up (or at least deliberately disguised) example, of that other part. I think it represents one of our key problems, and one that generates many opportunities for heaping abuse on IESG for doing things we _want_ them to do. -------------- Suppose that we have a large handful of people who have gotten very interested in frobitzes. How they got together isn't important -- perhaps they are part of the Frobitz Consortium, perhaps they had a discussion in a bar bof and got excited about it. To make the example a bit more interesting, suppose they write, and post, draft-bozo-frobitz-requirements-00 and draft-fudd-frobitz-implementation-scenarios-00 (we routinely kill bad ideas that don't have supporting documents). Now they ask for a BOF. "Ask" may not be quite the right word: they go to a relevant AD and _demand_ a BOF, based on their having interest, critical mass, and documents on the table. If the AD says "this isn't interesting, it isn't relevant to the IETF, and no one cares about frobitzes anyway", they say "we care, we are part of the IETF, we think it is relevant, and we have critical mass". Then they start looking for over-ripe fruit with which to decorate the AD. At this point, all but the most hard-nosed of ADs gets tired of the abuse and need to wear a raincoat around the IETF, and gives them the BOF on the theory that it is worth finding out what they have to say (and, sometimes, in the hope that they will self-destruct). At the BOF, the AD and a handful of others question whether anyone really cares about frobitzes. A few members of the community, possibly including the overworked AD, have read the documents and point out that, even if people cared about frobitzes, the proposed solution scenarios --and every other solution scenario that they can imagine-- will work only on LANs containing fewer than 30 hosts and will pose grave security risks if that LAN has any connection at all to the public network. The discussion rapidly deteriorates into "you are wrong" / "no, you are wrong" and continues until the BOF is nearly out of time. Then the BOF chair asks for a hum about who wants to form a WG and the usual suspects, along with a handful of other people (a few of them known to scare off any clues which see them coming) all hum ...really loudly. Now approximately the same process repeats itself. The advocates of a frobitz effort point out that they have critical mass and that they held a BOF and got a really loud hum. They claim that the scaling and security issues are really irrelevant to anyone who would want to use a frobitz. They note that they have documents on the table (maybe at version -01 or -02 by then) and are anxious to move forward. And they tell the AD that they are _entitled_ to a WG and that the AD is being unresponsive and arrogant by not having set up the WG already. I suggest that almost everyone who has served as an AD for more than a few months has encountered some more or less clear version of this story, at least up to that point. As you nicely put it, we have poor mechanisms to deal with these tensions. Most IETF participants would agree that the frobitz crew should be encouraged to go away and stop wasting AD and IESG time -- unless they are _members_ of the frobitz crew. The pushback process works poorly: the AD often gets tired of the noise and goes into a charter review process, hoping that the effort will disappear --or get constrained into reality-- during that process. Sometimes that works. It always takes a lot of time, with the would-be WG members claiming (often with some justification) that the AD is foot-dragging and nit-picking -- after all, they have critical mass, documents, and all that other stuff. Often the pattern continues: The noise level may reach the point where the AD --and the IESG as a whole-- get worn down enough to just approve the WG in the hope that it will self-destruct or acquire wisdom... Well, it wastes a lot more time on education, guidance, attempts to inject clues that are not happily accepted, etc. That time has to come from somewhere, and other, more relevant, WGs may suffer. If the AD gets worn down enough to be unwilling to close this misguided effort, and they produce a document, it either gets Last Called or the AD, who concludes that he or she would be too embarrassed to Last Call the thing, sits on it (and gets more abuse). No one responds to the Last Call because no one reads it. And no one reads it because no one outside the core of the WG cares enough about frobitzes to justify putting in the time... note that we can't, in general, even get people to read documents that are obviously critical to the infrastructure. The AD, or the IESG as a whole, contemplate just saying "no", but the frobitz team argues that their charter was approved, they put in months (or years) of effort, the document conforms (more or less) to the charter, they, the real frobitz experts in the IETF, have consensus, and they are therefore entitled to have their document adopted as a proposed standard. The IESG either gives in and approves it, or tries to kill it through the death of a thousand cuts. Either way, we all lose. I suggest that is a problem. john From problem-statement-bounces@alvestrand.no Fri May 23 19:49: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 TAA00621 for ; Fri, 23 May 2003 19:49:47 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7CF64625A7; Sat, 24 May 2003 01:49:18 +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 D9D6462589 for ; Sat, 24 May 2003 01:49:15 +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 h4NNmrk17496; Fri, 23 May 2003 19:48:56 -0400 (EDT) Date: Fri, 23 May 2003 19:48:53 -0400 From: Keith Moore To: John C Klensin Message-Id: <20030523194853.23a7d0c5.moore@cs.utk.edu> In-Reply-To: <128024980.1053714634@p3.JCK.COM> References: <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> <4318516885.20030522200444@brandenburg.com> <20030522234140.3387e2e0.moore@cs.utk.edu> <1815027409.20030522220356@brandenburg.com> <20030523011235.7478d87f.moore@cs.utk.edu> <1423612053.20030523112549@dcrocker.net> <118612545.1053705221@p3.JCK.COM> <128024980.1053714634@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: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: Problem: Resolution mechanisms for when working group consensus and IETF consensus or principles are not the same (was Re: what are the real 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 > But I want to give > an extended, if made-up (or at least deliberately disguised) > example, of that other part. I think it represents one of our > key problems, and one that generates many opportunities for > heaping abuse on IESG for doing things we _want_ them to do. yup. seen it happen several times. and on a significant subset of those occasions we made the mistake of giving them a WG (in the hope that they'd somehow get a clue along the way) and then regretting it later. and in at least one case such a WG has demanded a PS even though it failed to meet technical concerns that were repeatedly raised at multiple (as in three, IIRC) BOFs before the WG was ever formed. it's things like this that occasionally make me wish that we had public executions of WGs as part of the Thursday night plenary. From problem-statement-bounces@alvestrand.no Fri May 23 20:17: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 UAA01232 for ; Fri, 23 May 2003 20:17:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4F442625A7; Sat, 24 May 2003 02:16: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 DC3C162572 for ; Sat, 24 May 2003 02:16:45 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19JMiL-00090H-00; Fri, 23 May 2003 19:16:45 -0500 Date: Fri, 23 May 2003 20:16:44 -0400 From: John C Klensin To: Keith Moore Message-ID: <134395019.1053721004@p3.JCK.COM> In-Reply-To: <20030523194853.23a7d0c5.moore@cs.utk.edu> References: <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> <4318516885.20030522200444@brandenburg.com> <20030522234140.3387e2e0.moore@cs.utk.edu> <1815027409.20030522220356@brandenburg.com> <20030523011235.7478d87f.moore@cs.utk.edu> <1423612053.20030523112549@dcrocker.net> <118612545.1053705221@p3.JCK.COM> <128024980.1053714634@p3.JCK.COM> <20030523194853.23a7d0c5.moore@cs.utk.edu> 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: Problem: Resolution mechanisms for when working group consensus and IETF consensus or principles are not the same (was Re: what are the real 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 --On Friday, 23 May, 2003 19:48 -0400 Keith Moore wrote: >> But I want to give >> an extended, if made-up (or at least deliberately disguised) >> example, of that other part. I think it represents one of >> our key problems, and one that generates many opportunities >> for heaping abuse on IESG for doing things we _want_ them to >> do. > > yup. seen it happen several times. and on a significant > subset of those occasions we made the mistake of giving them a > WG (in the hope that they'd somehow get a clue along the way) > and then regretting it later. and in at least one case such a > WG has demanded a PS even though it failed to meet technical > concerns that were repeatedly raised at multiple (as in > three, IIRC) BOFs before the WG was ever formed. > > it's things like this that occasionally make me wish that we > had public executions of WGs as part of the Thursday night > plenary. I don't know that I've mentioned it on this list (probably haven't, and it intrudes into the "solution" space a bit anyway), but I've had periodic thoughts that it would be a good idea to have ADs "invite" particularly interesting and/or problematic WGs to present their problem definition, work in progress, ideas, and plans at a plenary, and then take questions, etc. This would act as a way to bring the whole community in on questions of relevance and relationship to the overall architecture and operation of the Internet. Both the audience and the WG participants might learn a lot. And while "contemplate process changes", "whine at the IESG" and "whine at the IAB" have an important place, injecting some community-wide _technical_ review and discussion back into the environment might be really helpful and interesting. I would hope the process would rarely resemble a public execution, or even a public flogging. But, in the rare cases where that is appropriate and necessary, it might not be a bad outcome. :-) john From problem-statement-bounces@alvestrand.no Sat May 24 20:16: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 UAA08988 for ; Sat, 24 May 2003 20:15:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1150462590; Sun, 25 May 2003 02:15: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 33EA3623F9; Sun, 25 May 2003 02:15:24 +0200 (CEST) Date: Sun, 25 May 2003 02:15:24 +0200 From: Harald Tveit Alvestrand To: erosen@cisco.com Message-ID: <22170000.1053821724@askvoll.hjemme.alvestrand.no> In-Reply-To: <200305231515.h4NFFSFV004520@rtp-core-1.cisco.com> References: <200305231515.h4NFFSFV004520@rtp-core-1.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: what are the real 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 --On fredag, mai 23, 2003 11:15:28 -0400 Eric Rosen wrote: > Harald> if, somehow, we came to the point where we split the IETF >> between "those who are on a mission to protect the >> users against exploitation by the vendors" and "those who are on >> a mission to help the vendors exploit the users", I'd >> reluctantly have to join the first camp. > > Any suggestion that if you're not in one of these camps you must be in > the other would indeed be useless demagoguery. thanks - we have a consensus on that point at least! > As long as the IESG asserts the right to make decisions that go > beyond issues of technical quality and correctness, we have a problem. unfortunately I don't believe we can separate the world that neatly into "technical" and "non-technical" issues. I believe that the *IETF* has a duty to speak to issues that concern the impact of our standards on the real world - RFC 1984, the "crypto is good, bad crypto is bad" document, has very little to do directly with either technical quality or correctness. Quoting from draft-ietf-problem-process-00 (ok, it's quoting me :-) on IETF core values: "Cares for the Internet" As its name implies, the Internet Engineering Task Force (IETF) focuses on Internet-related activities. We care about the Internet, and our standards work and operational activities are intended to improve the utility, scalability and availability of the Internet. The Internet isn't value-neutral, and neither is the IETF. We want the Internet to be useful for communities that share our commitment to openness and fairness. We embrace technical concepts such as decentralized control, edge-user empowerment and sharing of resources, because those concepts resonate with the core values of the IETF community. These concepts have little to do with the technology that's possible, and much to do with the technology that we choose to create. The IETF community also cares about making the Internet model a viable business proposition. People who choose to offer Internet products and services that fit with our core values should be able to do so with maximum benefit and minimum amount of fuss. The IETF community wants the Internet to succeed because we believe that the existence of the Internet, and its influence on economics, communication and education, will help us to build a better human society. The IESG has absolutely no business going beyond the IETF community's consensus on these issues. I believe consensus on these issues has a very clear core, but gets very fuzzy when trying to apply it to specific instances; the rambunctious debate that led to the publication of RFC 2804 (the "Raven" RFC on wiretapping) is only a recent example. I believe the IESG has tried to find the best way forward within the mandate given it by the IETF community as well as it has been able to see it. It may very well have misjudged (it would be a miracle if it never did). But I do believe it has tried faithfully. Harald From problem-statement-bounces@alvestrand.no Sat May 24 21: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 VAA09617 for ; Sat, 24 May 2003 21:03:20 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 72EE062579; Sun, 25 May 2003 03:02:50 +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 9B90F6230E for ; Sun, 25 May 2003 03:02:43 +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 192207F4F for ; Sat, 24 May 2003 21:02:42 -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, 24 May 2003 21:02: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: Sat, 24 May 2003 21:02:40 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B032412AD@tayexc13.americas.cpqcorp.net> Thread-Topic: Example of the One Liners out of context Thread-Index: AcMiWVpttS0PjJYbQ76uj1bxO8jK9w== From: "Bound, Jim" To: X-OriginalArrivalTime: 25 May 2003 01:02:41.0965 (UTC) FILETIME=[57F58DD0:01C32259] Subject: Example of the One Liners out of context X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 VAA09617 We were asked to show examples of one liners from mail that create confusion or is not constructive. Here is a mail where Dave requests to Randy more context, seems reasonable to me. It was not a disagreement but clarifying a statement. See for yourself. Please don't tell me this is not a problem :--) Regards, /jim -----Original Message----- From: Dave Crocker [mailto:dhc@dcrocker.net] Sent: Saturday, May 24, 2003 5:03 PM To: Randy Bush Cc: ietf-nomcom@lists.elistx.com Subject: Re: Liaisons interoperation with NOMCOM members Randy, RB> as i think even charlie agreed, security is indeed an important RB> issue for today's internet. Yet another, wonderfully clever unresponsive response. Gosh you're good at them. However, since your original posting was in fact *not* a forgery, it means that an area director has made a public statement that a couple of contributors are having a destructive effect. Your position carries an obligation to do more than simply make such pronouncements. You have an obligation to explain them. On the natural assumption that you, yourself, have constructive intent, then please engage in forthcoming dialogue, rather than just launching such public criticisms and then trying to dodge the consequences. d/ >> alas, from the received headers, this means that your system, >> psg.com, has been compromised. >> >> i guess that would explain a number of different postings purporting >> to be from you, recently, that did indeed have a more even-handed >> tone than usual. >> >> d/ >> >> RB> it should be obvious by the kind tone of the message that it was >> RB> a forgery. >> >> >> on the offchance that I am the 'dave' you are referring to, I >> >> tried to figure out what your posting referred to. It certainly >> >> did not refer to the thread it occurred in, since no dave or john >> >> had yet posted. >> >> >> >> so, Randy, please clarify. >> >> >> >> d/ >> >> >> >> RB> btw, i think both dave and john think they are being >> >> RB> constructive and are acting with good intent. i just don't >> >> RB> think that is the result. >> >> >> >> RB> randy >> >> >> >> >> >> RB> >> ---------------------------------------------------------------- >> >> RB> To subscribe or unsubscribe from this elist use the >> >> RB> subscription >> >> RB> manager: >> >> >> >> >> >> >> >> d/ >> >> -- >> >> Dave Crocker Brandenburg >> >> InternetWorking Sunnyvale, CA USA >> >> , >> >> >> >> >> RB> ---------------------------------------------------------------- >> RB> To subscribe or unsubscribe from this elist use the subscription >> RB> manager: >> >> >> >> d/ >> -- >> Dave Crocker >> Brandenburg InternetWorking Sunnyvale, >> CA USA , >> RB> ---------------------------------------------------------------- RB> To subscribe or unsubscribe from this elist use the subscription RB> manager: d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: From problem-statement-bounces@alvestrand.no Sat May 24 22:33: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 WAA10472 for ; Sat, 24 May 2003 22:33:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B6C6A622BB; Sun, 25 May 2003 04:31:32 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by eikenes.alvestrand.no (Postfix) with ESMTP id 12E45625A0 for ; Thu, 22 May 2003 09:34:17 +0200 (CEST) Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4M7YG4Z000716; Thu, 22 May 2003 00:34:16 -0700 (PDT) Received: from field (field.Germany.Sun.COM [129.157.142.146]) h4M7YDsY260376; Thu, 22 May 2003 00:34:14 -0700 (PDT) Date: Thu, 22 May 2003 09:34:10 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: Randy Bush In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Sun, 25 May 2003 04:31:11 +0200 Cc: problem-statement@alvestrand.no Cc: Aaron Falk Subject: Re: what are the real 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 On Wed, 21 May 2003, Randy Bush wrote: > > You've been around the IETF much longer than I. Do you sense that the > > level of conservatism in the IESG has increased over time? > > it's gone both ways. there are fans of 'let 1000 flowers bloom' > and there are 'this is now a service' folk. and, there are folk > who are trying to find seriously innovative change. > > It's perfectly appropriate to be upset. I thought of it in a slightly > different way--like a space that we were exploring and, in the early > days, we figured out this consistent path through the space: IP, TCP, > and so on. What's been happening over the last few years is that the > IETF is filling the rest of the space with every alternative approach, > not necessarily any better. Every possible alternative is now being > written down. And it's not useful. -- Jon Postel A shared commitment to conservatism is essential, if only to common values that we won't compromise. Validity is by no means the only standard by which a scientific proposition is accepted or rejected. ... These three: validity, profundity, and intrinsic human interest underlie jointly the valuation of scientific results. Suppose now that no limitations of value were imposed on the publication of scientific contributions in journals. The selection - which is indispensible in view of the limited space - would then have to be done by some neutral method - say drawing lots. Immediately the journalswould be flooded with rubbish an valuable work would be crowded out and banished to obscurity. Cranks are always abounding who will send in spates of nonsense. Immature, confused, fantastic, or else plodding, pedestrian, irrelevant material would be pouring in. Swindlers and bunglers combining all variants of deception and self-deception would seek publicity. Buried among so much that is specious or slipshod, the few remaining valuable publications could hardly have a chance of being recognized. The swift and reliable contacts by which scientists to-day keep each other informed would be broken; they would be isolated and their mutual reliance and co-operation would be paralysed. ...Self-governing institutions of science are effective in safeguarding the organized practice of science which embodies and transmits their premises. But their functions are mainly protective and regulative and are themselves based... on the preexistence of a general harmony of views among scientists. Michael Polyani, Science, Faith and Society, 1946 Erik From problem-statement-bounces@alvestrand.no Sat May 24 22:33: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 WAA10504 for ; Sat, 24 May 2003 22:33:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 90B886259F; Sun, 25 May 2003 04:31:49 +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 9703D62603 for ; Thu, 22 May 2003 20:02:01 +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 h4MI1uk29862; Thu, 22 May 2003 14:01:59 -0400 (EDT) Date: Thu, 22 May 2003 14:01:56 -0400 From: Keith Moore To: Ted Lemon Message-Id: <20030522140156.16551810.moore@cs.utk.edu> In-Reply-To: <3D4EDCCA-8C74-11D7-BBB3-00039367340A@nominum.com> References: <20030522120947.3d484944.moore@cs.utk.edu> <3D4EDCCA-8C74-11D7-BBB3-00039367340A@nominum.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 X-Mailman-Approved-At: Sun, 25 May 2003 04:31:11 +0200 Cc: moore@cs.utk.edu Subject: Re: OPEN ISSUE: Standards Track X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit [list bcc'ed to encourage the thread to terminate.] > > (ask yourself: why is it so easy for viruses to propagate by email?) > > Because of buggy programs that execute code in email messages, which > has exactly zero to do with SMTP, POP or IMAP. It has a lot to do with the way MIME is implemented. Hint: there's a reason we didn't use filename suffixes as content-types and expect operating systems to use the same dispatch tables as they would do for local files. There's also a reason we required a security considerations section for content-type registration. From problem-statement-bounces@alvestrand.no Sun May 25 00: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 AAA11976 for ; Sun, 25 May 2003 00:42:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B0C87621FB; Sun, 25 May 2003 06:42:21 +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 EBEB1621FA for ; Sun, 25 May 2003 06:42:15 +0200 (CEST) Received: from adsl-67-126-141-57.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4P4fsN12808; Sat, 24 May 2003 21:41:54 -0700 Date: Sat, 24 May 2003 21:41:55 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1926966205.20030524214155@brandenburg.com> To: "Joel M. Halpern" In-Reply-To: <5.1.0.14.0.20030523073210.0274ff30@mail.stevecrocker.com> References: <20030523011235.7478d87f.moore@cs.utk.edu> <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> <4318516885.20030522200444@brandenburg.com> <20030522234140.3387e2e0.moore@cs.utk.edu> <1815027409.20030522220356@brandenburg.com> <20030523011235.7478d87f.moore@cs.utk.edu> <5.1.0.14.0.20030523073210.0274ff30@mail.stevecrocker.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: what are the real problems 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 Joel, JJMH> For example, as worded Dave's note suggests that there is no drawback from JMH> having too many efforts. I don't think anyone believes that there are no JMH> drawbacks. Including Dave. He certainly did not mean to imply that having multiple efforts is without its downside. However he is frankly far more concerned with the downsides of prematurely terminating valid (parallel) efforts. I have a simple model of IETF work: 1. There must be a clear technical need/goal 2. There must be a core technical competence that can reasonably be expected to achieve that goal 3. There must be a core, committed constituency for developing and another for using the result. Satisfy all 3 and and it is a legitimate IETF effort. Where the modern IETF gets into trouble is when we try to get clever and pretend that it can dictate among competing, legitimate efforts. I claim that all we can or should do is to keep the pressure on to ensure high technical quality. Terminate an otherwise-legitimate technical effort early and we are pretending to have a far better understanding market preferences than we actually have. We also will preclude serendipity. If we had made THE choice of the right way to do international characters for email, we probably would not have gotten ESMTP. There is a good chance we would not have gotten SNMP. And so on. Lest someone feel certain that these various opportunities for shutting off parallel efforts would have been certain to come out the "right" way, I'll simply ask why? JMH> Just in case, let me suggest one of the many drawbacks. I believe that no JMH> matter what organizational structure we craft for ourselves, there will JMH> always be a leadership load based on the number of "things to be lead" JMH> (working groups, activities, ...) And I'll repeat that I thoroughly agree that paying attention to leadership load is an important -- nay, an essential -- concern. But let's apply that concern diligently, rather than opportunistically. As a community, we are so grossly inefficiently about this topic, it is actually hypocritical for us to to apply it in this way. And, no, that does not mean we should ignore the question of load. Again: it means we should look at the topic seriously and thoroughly. JMH> Another major issue with allowing competing efforts is that the results do JMH> not interoperate. TCP and UDP do not "interoperate". IS-IS and OSPF do not interoperate. And so on. Yes, competing efforts usually do not interoperate. That is what makes the phrase "let the market decide" highly non-trivial. It means that we do, in fact, let the market choose based on criteria beyond simple technical evaluation. The alternative is parental and premature. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Sun May 25 00: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 AAA12020 for ; Sun, 25 May 2003 00:50:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AEC426256F; Sun, 25 May 2003 06:49:38 +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 396C26223F for ; Sun, 25 May 2003 06:49:36 +0200 (CEST) Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4670603; Sun, 25 May 2003 00:49:34 -0400 Message-Id: <5.1.0.14.0.20030525004750.027f1300@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 25 May 2003 00:49:15 -0400 To: Dave Crocker From: "Joel M. Halpern" In-Reply-To: <1926966205.20030524214155@brandenburg.com> References: <5.1.0.14.0.20030523073210.0274ff30@mail.stevecrocker.com> <20030523011235.7478d87f.moore@cs.utk.edu> <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> <4318516885.20030522200444@brandenburg.com> <20030522234140.3387e2e0.moore@cs.utk.edu> <1815027409.20030522220356@brandenburg.com> <20030523011235.7478d87f.moore@cs.utk.edu> <5.1.0.14.0.20030523073210.0274ff30@mail.stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: what are the real 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 Actually, these examples illustrate two very different cases. TCP and UDP do different things. They both exist for good reasons. OSPF and IS-IS are so similar it is frankly a shame and a disservice that they both exist. Yours, Joel M. Halpern At 09:41 PM 5/24/2003 -0700, Dave Crocker wrote: >JMH> Another major issue with allowing competing efforts is that the >results do >JMH> not interoperate. > >TCP and UDP do not "interoperate". IS-IS and OSPF do not interoperate. >And so on. > >Yes, competing efforts usually do not interoperate. That is what makes >the phrase "let the market decide" highly non-trivial. It means that we >do, in fact, let the market choose based on criteria beyond simple >technical evaluation. The alternative is parental and premature. From problem-statement-bounces@alvestrand.no Sun May 25 10:25: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 KAA02680 for ; Sun, 25 May 2003 10:25:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 069D6621FA; Sun, 25 May 2003 16:25: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 CC56A621B8 for ; Sun, 25 May 2003 16:25:27 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19JwR9-000Bza-1d; Sun, 25 May 2003 07:25:23 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 25 May 2003 07:25:22 -0700 To: "Bound, Jim" References: <9C422444DE99BC46B3AD3C6EAFC9711B032412AD@tayexc13.americas.cpqcorp.net> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: Example of the One Liners out of context X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit i do not think that adding a process director to the iesg is constructive, and would be in fact destructive. we don't need to politicize the wgs, iesg, secretariat as we already have this wg. we should leave some parts of the organization to do actual ietf work. and all this seems like so much red herring, without even sour cream, but plenty of confrontationalism, polarization, etc. no real substance, all politics, at which we engnineers are so expert (not). so we destroy our organization and our culture with it. omplalo-sepsis. dunno about you, but i spent years in the iso, ieee, ansi, ... i came here to get engineering work done, not play amateur power politics, voting blocks, .... the focus on real work has been the ietf's strength and the root of its success. i suggest we play to our strengths, not divisiveness, mud-slinging, and demagoguery. randy From problem-statement-bounces@alvestrand.no Sun May 25 19:00: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 TAA14985 for ; Sun, 25 May 2003 19:00:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 16E9162573; Mon, 26 May 2003 01:00:27 +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 80563621FA for ; Mon, 26 May 2003 01:00:24 +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 QAA97040 for ; Sun, 25 May 2003 16:00:23 -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 3FP0ZJV2 Sun, 25 May 2003 16:00:20 -0700 (PDT) Message-ID: <005f01c32311$6dec1330$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: "Problem Statement Mailing List" Date: Sun, 25 May 2003 18:00:23 -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: NOT "inciting to riot" (was: Last Call: IP over MIME to Proposed Standard) 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 know some of our frequent contributors are already aware of the "Last Call: IP over MIME to Proposed Standard" thread on the main IETF list. We already have "mission statement" on our dance card for the solutions work. That's good. I don't have an opinion on the topic itself, but a number of people do, focused on whether "IP over MIME" is a suitable technology for Proposed Standard (the only other comment I've seen is that the document has normative references that are not standards-track). And the relevant point for this group is that I haven't seen anyone pointing to something written down as a filter for whether "IP over MIME" is something the IETF should standardize. The comments have been based on opinions and precedents. I would hope that our mission statement would help us to have (shorter) conversations like this AT LAST CALL TIME! Best wishes, Spencer Dawkins From problem-statement-bounces@alvestrand.no Sun May 25 21: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 VAA17572 for ; Sun, 25 May 2003 21:56:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 821F962581; Mon, 26 May 2003 03:56:04 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46]) by eikenes.alvestrand.no (Postfix) with ESMTP id 455B962573 for ; Mon, 26 May 2003 03:56:02 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19K7DS-0002dZ-00; Sun, 25 May 2003 18:55:59 -0700 Date: Sun, 25 May 2003 21:54:37 -0400 From: Keith Moore To: Spencer Dawkins Message-Id: <20030525215437.5136170d.moore@cs.utk.edu> In-Reply-To: <005f01c32311$6dec1330$0200a8c0@DFNJGL21> References: <005f01c32311$6dec1330$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: NOT "inciting to riot" (was: Last Call: IP over MIME to Proposed Standard) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 the relevant point for this group is that I haven't seen anyone > pointing to something written down as a filter for whether "IP > over MIME" is something the IETF should standardize. you mean besides RFC 2026? specifically the bits about A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. and A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it. ? but yes, I do think that the "IP over MIME" discussion is probably a good example of why we need a better defined scope for IETF standardization activities. Keith From problem-statement-bounces@alvestrand.no Sun May 25 23:35: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 XAA19282 for ; Sun, 25 May 2003 23:35:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DE29362573; Mon, 26 May 2003 05:35: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 E16E6622BB for ; Mon, 26 May 2003 05:35:07 +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 UAA27363 for ; Sun, 25 May 2003 20:35:07 -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 D770jBD2 Sun, 25 May 2003 20:35:06 -0700 (PDT) Message-ID: <00a701c32337$ce92da90$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <005f01c32311$6dec1330$0200a8c0@DFNJGL21> <20030525215437.5136170d.moore@cs.utk.edu> Date: Sun, 25 May 2003 22:35: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: NOT "inciting to riot" (was: Last Call: IP over MIME to Proposed Standard) 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. Yes, precisely - there were two subthreads, one subthread that I would expect during Last Call ("you have normative references that aren't standards-track") and one that I would have hoped would NOT be taking place during Last Call ("this is dumb, not useful, ..."). It was not at all clear to me what language we would point to (2026 or otherwise) to support a decision not to standardize "IP over MIME", so we're left with jawing back and forth to see whether we really standarize it or not, and when Aaron Falk and I finally submit our long-threatened "IP over Hand Percussion" ID as a Proposed Standard, there's no clear answer from "IP over MIME", so we'll get to have the same discussion with a slightly-different subject line then, too... Spencer ----- Original Message ----- From: "Keith Moore" To: "Spencer Dawkins" Cc: ; Sent: Sunday, May 25, 2003 8:54 PM Subject: Re: NOT "inciting to riot" (was: Last Call: IP over MIME to Proposed Standard) > > And the relevant point for this group is that I haven't seen anyone > > pointing to something written down as a filter for whether "IP > > over MIME" is something the IETF should standardize. > > you mean besides RFC 2026? > > specifically the bits about > > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has received > significant community review, and appears to enjoy enough community > interest to be considered valuable. > > and > > A Proposed Standard should have no known technical omissions with > respect to the requirements placed upon it. > > ? > > but yes, I do think that the "IP over MIME" discussion is probably a good > example of why we need a better defined scope for IETF standardization > activities. > > Keith From problem-statement-bounces@alvestrand.no Mon May 26 00:05: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 AAA19895 for ; Mon, 26 May 2003 00:05:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8016262590; Mon, 26 May 2003 06:05:00 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46]) by eikenes.alvestrand.no (Postfix) with ESMTP id 048CB62589 for ; Mon, 26 May 2003 06:04:55 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19K9ED-0003QW-00; Sun, 25 May 2003 21:04:53 -0700 Date: Mon, 26 May 2003 00:03:31 -0400 From: Keith Moore To: Spencer Dawkins Message-Id: <20030526000331.42985348.moore@cs.utk.edu> In-Reply-To: <00a701c32337$ce92da90$0200a8c0@DFNJGL21> References: <005f01c32311$6dec1330$0200a8c0@DFNJGL21> <20030525215437.5136170d.moore@cs.utk.edu> <00a701c32337$ce92da90$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: NOT "inciting to riot" (was: Last Call: IP over MIME to Proposed Standard) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, precisely - there were two subthreads, one subthread that I would > expect during Last Call ("you have normative references that aren't > standards-track") and one that I would have hoped would NOT be > taking place during Last Call ("this is dumb, not useful, ..."). If it were a WG document presumably the WG would have done that level of vetting. But this seems to be an individual submission. > It was not at all clear to me what language we would point to (2026 or > otherwise) to support a decision not to standardize "IP over MIME" I think there's plenty of leverage in 2026 to justify not standardizing this. But it's probably also the case that there's a lot of thinking regarding scope/applicability of IETF standards that isn't currently written down. Note that this is really isn't a question of whether "IP over X" is within IETF's scope to standardize (it certainly is), but rather, a question of whether IETF has an obligation to standardize every reasonably complete "IETF over X" proposal, no matter how limited its applicability. From problem-statement-bounces@alvestrand.no Mon May 26 00:21: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 AAA20127 for ; Mon, 26 May 2003 00:21:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 77D5262590; Mon, 26 May 2003 06:20:47 +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 A8C7D62589 for ; Mon, 26 May 2003 06:20:45 +0200 (CEST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])h4Q4KiD23984 for ; Mon, 26 May 2003 07:20:44 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com ; Mon, 26 May 2003 07:20:43 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 26 May 2003 07:20:41 +0300 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 26 May 2003 07:20:41 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 26 May 2003 07:20:40 +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, 26 May 2003 07:20:39 +0300 Message-ID: Thread-Topic: NOT "inciting to riot" (was: Last Call: IP over MIME toProposed Standard) Thread-Index: AcMjN9O0yWj49c5kSFCkl9IQsHkv5QABe9kA From: To: , X-OriginalArrivalTime: 26 May 2003 04:20:40.0972 (UTC) FILETIME=[2ACFECC0:01C3233E] Subject: RE: NOT "inciting to riot" (was: Last Call: IP over MIME toProposed Standard) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 AAA20127 Hi Spencer, > Yes, precisely - there were two subthreads, one subthread that I would > expect during Last Call ("you have normative references that aren't > standards-track") and one that I would have hoped would NOT be > taking place during Last Call ("this is dumb, not useful, ..."). It was > not at all clear to me what language we would point to (2026 or otherwise) > to support a decision not to standardize "IP over MIME", so we're > left with jawing back and forth to see whether we really standarize it or > not, This points to a thought I have had recently. What we need to do is come up with clear rules how things progress (and perhaps what is & is not appropriate for IETF standardization); a simple and straightforward way to resolve disputes; transparent leadership selection process and transparent decision making. If we had all of these, we probably would be about 80% done (in my opinion). John From problem-statement-bounces@alvestrand.no Mon May 26 00:31: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 AAA20277 for ; Mon, 26 May 2003 00:31:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 30F6162594; Mon, 26 May 2003 06:31:00 +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 24AB962590 for ; Mon, 26 May 2003 06:30: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 19K9dM-0007Hb-00; Sun, 25 May 2003 21:30:52 -0700 Date: Mon, 26 May 2003 00:29:30 -0400 From: Keith Moore To: Message-Id: <20030526002930.4ed21766.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: NOT "inciting to riot" (was: Last Call: IP over MIME toProposed Standard) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 come > up with clear rules how things progress (and perhaps what is & is not > appropriate for IETF standardization); a simple and straightforward > way to resolve disputes; transparent leadership selection process and > transparent decision making. If we had all of these, we probably would > be about 80% done (in my opinion). I think it's more like 30%. The thing that we really need to do most is to fix how working groups operate. From problem-statement-bounces@alvestrand.no Mon May 26 02:54: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 CAA03972 for ; Mon, 26 May 2003 02:54:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 106A7625AB; Mon, 26 May 2003 08:53:31 +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 8CF0D625A0; Mon, 26 May 2003 08:53:25 +0200 (CEST) Date: Mon, 26 May 2003 08:53:25 +0200 From: Harald Tveit Alvestrand To: John C Klensin Message-ID: <69120000.1053932005@askvoll.hjemme.alvestrand.no> In-Reply-To: <101078583.1053687687@p3.JCK.COM> References: <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> <6AE98D44-8B1A-11D7-91A9-000393DB5366@cs.utk.edu> <5.1.0.14.2.20030520202101.03c85b10@mail.windriver.com> <278018759.1053473749@p3.JCK.COM><409117549.1053513221@localhost> <101078583.1053687687@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: IESG spin-up time (was: Re: Charters, "normal process" versus ISOC, etc. (was: Re) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, mai 23, 2003 11:01:27 -0400 John C Klensin wrote: > --On Wednesday, 21 May, 2003 10:33 +0200 Harald Tveit Alvestrand > wrote: > >> WRT "6 months": >> >> People's capabilities vary. Some are faster than others - and >> for routine matters, procedures and so on, I think the process >> goes much faster than 6 months. But the process of learning >> the personal, technological and organizational interactions in >> working groups you have not previously followed is a >> significant learning curve - it took me more than one IETF >> meeting after I became managing AD for the SNMPv3 group before >> I understood the interactions there well enough to be an >> effective AD, for instance (sometimes I'm not sure I ever got >> there in the 1 year I did that job). > > But it took you less than one IETF meeting to come up to speed and be > reasonably effective when you got your first AD job, so the equation is > more complicated than that. One thing I'm pretty sure about is that > your co-AD in applications didn't do anything superhuman to help -- he > pretty much assumed that you would hit the ground running and ask > questions if needed, and you more than satified that expectation. thank you! (that would have to be Stockholm - the meeting where I came back to Norway and wondered why I had a severe case of jetlag without any timezone shift :-) > So, in one case, you came, new, onto the IESG and came up to speed very > rapidly, both with regard to IESG procedures and with regard to the WGs > involved. In the other, you already knew the IESG procedures and had a > working relationship with most of the rest of the IESG, which should have > made things a lot faster, and still found taking over a new area a slow > process. Absent other data, I suggest this points toward an hypothesis > of "some areas are harder to take over as AD than others, especially if > the area is already problematic and/or the new AD hasn't worked > extensively in it (regardless of his or her background in the field of > that area)" rather than an issue in coming up to speed on the IESG itself. another possible interpretation of the data is that there's a significant time gap between the time of "other people see you performing adequately" and the time of "you yourself see yourself performing adequately". or - that an AD can be harder on him/herself than other people are! Harald From problem-statement-bounces@alvestrand.no Mon May 26 03:44: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 DAA05353 for ; Mon, 26 May 2003 03:44:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A6499625B6; Mon, 26 May 2003 09:44:22 +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 4B0DB625A3 for ; Mon, 26 May 2003 09:44:19 +0200 (CEST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4Q7i4u9069402 for ; Mon, 26 May 2003 09:44:10 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4Q7i0Hk217040 for ; Mon, 26 May 2003 09:44:01 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA41662 from ; Mon, 26 May 2003 09:43:59 +0200 Message-Id: <3ED1C5DA.583A53A5@hursley.ibm.com> Date: Mon, 26 May 2003 09:44:26 +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: <200305231835.h4NIZZvM027252@newdev.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Problem: Multiple Incompatible 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 Scott Bradner wrote: > > note that in saying that there are times when more than one solution > may need to be worked on I do not mean to imply that we should > progress multiple standards track documents - in the cases I can think of > it is a better idea to publish the competing ideas as > experimental RFCs to see what the market thinks and then, if a clear > message can be seen at some later date, focus attention on one solution > which can then be brought to the standards track > > there are exceptions (SNMP vs CMOT is one and OSPF & ISIS is another) but I > do not think that it is the general case that there should be multiple stds > track technologies addressing the same problem. Exactly. While the general principle of avoiding duplicate solutions is clearly correct, there will be exceptions, but I don't see this as an active problem in the IETF. You can find occasional errors of judgement perhaps -- but where's the evidence of a systematic problem? By the way, this principle is documented in RFC 1958: 3.2 If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements. Brian From problem-statement-bounces@alvestrand.no Mon May 26 04: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 EAA05895 for ; Mon, 26 May 2003 04:32:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CC4816257C; Mon, 26 May 2003 10:31: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 1E325623CD; Mon, 26 May 2003 10:31:45 +0200 (CEST) Date: Mon, 26 May 2003 10:31:45 +0200 From: Harald Tveit Alvestrand To: john.loughney@nokia.com, spencer@mcsr-labs.org, problem-statement@alvestrand.no Message-ID: <88540000.1053937905@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: NOT "inciting to riot" (was: Last Call: IP over MIME toProposed Standard) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, mai 26, 2003 07:20:39 +0300 john.loughney@nokia.com wrote: > Hi Spencer, > John, trying to recast your "need to do" in terms of "problems"..... apologizing for reformatting your mail so much.... am I understanding you correctly? > This points to a thought I have had recently. What we need to do is come > up with > - clear rules how things progress one or more of: problem: RFC 2026 is not clear enough to say how things should progress problem: RFC 2026 is not followed, and it's not clear what is problem: RFC 2026 does not specify the procedures it should have (here I think I have to ask you what you think, since the meaning of "clear rules" changes according to which alternative(s) you pick) > - (and perhaps what is & is not appropriate for IETF standardization) problem: the IETF does not know its core mission. That's on the list :-) > - a simple and straightforward way to resolve disputes problem: we don't have (and I agree - consensus is neither simple nor straightforward in polarized situations) > - transparent leadership selection process and I take it this is one or both of: problem: the nomcom process is not transparent problem: the WG selection process (general) is not transparent > - transparent decision making. one or both of: problem: the community does not understand how/why a WG makes decisions problem: the community does not understand how/why the IESG makes decisions am I misunderstanding you? > If we had all of these, we probably would > be about 80% done (in my opinion). Maybe.... or we might have an easier time figuring out what the rest of the problem is.... From problem-statement-bounces@alvestrand.no Mon May 26 04:55: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 EAA06091 for ; Mon, 26 May 2003 04:55:01 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 04C64625AB; Mon, 26 May 2003 10:54: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 698D3623CD; Mon, 26 May 2003 10:54:24 +0200 (CEST) Date: Mon, 26 May 2003 10:54:24 +0200 From: Harald Tveit Alvestrand To: Dave Crocker Message-ID: <89860000.1053939264@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 Cc: problem-statement@alvestrand.no Subject: Can we learn something from IETF history? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 suddenly realized..... you were AD of Standards Management from 1990 to 1993, if I interpret the list of past IESG members correctly (and somewhat creatively - you are listed as "Network management" some of the time). That would, I would think, include being responsible AD of the POISED working group, which had its initial hyperactive phase from August 1992 to March 1993. Granted, this was an extremely tense time in the IETF's history (RFC 1396 claims that the POISED list produced 20 Mbytes of mail from August to mid-November; this list has only produced 4.3 Mbytes of mail from November to May....), and Steve Crocker was obviously not the same kind of WG chair as Melinda and Avri, nor was the charter even closely related to the current charter. But still, that's the past situation that most closely resembles the current one..... how would you say that the AD, IESG and IAB of that time positioned its management role in relation to the POISED WG? Harald From problem-statement-bounces@alvestrand.no Mon May 26 08:17: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 IAA09928 for ; Mon, 26 May 2003 08:17:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1105E6257C; Mon, 26 May 2003 14:17:19 +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 8386E6257C; Mon, 26 May 2003 14:17:07 +0200 (CEST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])h4QCH6L28059; Mon, 26 May 2003 15:17:06 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com ; Mon, 26 May 2003 15:17:05 +0300 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 26 May 2003 15:17:05 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 26 May 2003 15:08: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: Mon, 26 May 2003 15:08:05 +0300 Message-ID: Thread-Topic: NOT "inciting to riot" (was: Last Call: IP over MIME toProposed Standard) Thread-Index: AcMjYUIFT+P1tv+SROqLi0ctFTg94AAG/z4w From: To: , X-OriginalArrivalTime: 26 May 2003 12:08:05.0609 (UTC) FILETIME=[76B7ED90:01C3237F] Subject: RE: NOT "inciting to riot" (was: Last Call: IP over MIME toProposed Standard) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 IAA09928 Hi Harald. > trying to recast your "need to do" in terms of "problems"..... apologizing > for reformatting your mail so much.... am I understanding you correctly? Reformating is fine with me. As a meta-comment - I have been growing a little more frustrated by this mailing list. I'm wondering if it is more useful to spend my time getting real work done instead, but anyhow, responses in line: > one or more of: > problem: RFC 2026 is not clear enough to say how things should progress > problem: RFC 2026 is not followed, and it's not clear what is > problem: RFC 2026 does not specify the procedures it should have > (here I think I have to ask you what you think, since the meaning of "clear > rules" changes according to which alternative(s) you pick) Rewriting the above, in terms of what I was thinking, I get: problem: RFC 2026 has some ambiguity. problem: RFC 2026 is not always followed, and it's not when it is not followed (possibly pointing to more training needed by WG chairs, IESG, etc.) problem: The areas of ambiguity in RFC 2026 are sometimes interpreted differently, creating confusion. As evidence, I point to the "Last Call: IP over MIME to Proposed Standard" thread. It seems that people don't like it, but are raising 'boogey-man' fears. It is much easier & better (IMO) to simply say, it violates section A of RFC xyz. > problem: the IETF does not know its core mission. That's on > the list :-) Actually, I don't worry about this problem. I generally work recursively. I think no matter what, the core mission of the IETF has changed in the last 10 years and probably will continue changing. If we document how the IETF SHOULD (in a 2119 sense of the word) work, that's a good thing. When there are corner cases not covered, then we update our docs. > > - a simple and straightforward way to resolve disputes > > problem: we don't have (and I agree - consensus is neither simple nor > straightforward in polarized situations) > > > - transparent leadership selection process and > > I take it this is one or both of: > problem: the nomcom process is not transparent > problem: the WG selection process (general) is not transparent Probably both, but maybe a third: Problem: Design team membership; document editorship selection is not always transparent. > > - transparent decision making. > > one or both of: > problem: the community does not understand how/why a WG makes decisions > problem: the community does not understand how/why the IESG makes decisions > > am I misunderstanding you? I think you captured it well. > > If we had all of these, we probably would > > be about 80% done (in my opinion). > > Maybe.... or we might have an easier time figuring out what > the rest of the problem is.... Perhaps ... John From problem-statement-bounces@alvestrand.no Mon May 26 12:21: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 MAA17294 for ; Mon, 26 May 2003 12:21:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F401E625A0; Mon, 26 May 2003 18:20:37 +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 900466230A; Mon, 26 May 2003 18:20:35 +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 h4QGNHO18259; Mon, 26 May 2003 09:23:17 -0700 Date: Mon, 26 May 2003 07:58:23 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1861252390.20030526075823@brandenburg.com> To: Harald Tveit Alvestrand In-Reply-To: <89860000.1053939264@askvoll.hjemme.alvestrand.no> References: <89860000.1053939264@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: Dave Crocker Subject: Re: Can we learn something from IETF history? 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> you were AD of Standards Management from 1990 to 1993, if I interpret the HTA> list of past IESG members correctly HTA> (and somewhat creatively - you are listed as "Network management" some of I did net management for the first year of the 'modern' IETF (1989); standards process for the next 2 years; and "middleware" (including DNS) for the year after that. HTA> That would, I would think, include being responsible AD of the POISED HTA> working group, Nope. It did not report to me. I don't remember the reporting structure for it. I d HTA> But still, that's the past situation that most closely resembles the HTA> current one..... how would you say that the AD, IESG and IAB of that time HTA> positioned its management role in relation to the POISED WG? The original changes to the IETF were not formulated by POISED. Poised was a follow-on effort. The original work was done far less formally, with hallway conversations as the means for floating ideas and exploring reactions, and the IETF Plenary as the means of approving the changes. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Mon May 26 13:24: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 NAA18704 for ; Mon, 26 May 2003 13:24:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 26E78622AC; Mon, 26 May 2003 19:24:24 +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 2E49C621B3 for ; Mon, 26 May 2003 19:24:21 +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 h4QHR4O20735 for ; Mon, 26 May 2003 10:27:04 -0700 Date: Mon, 26 May 2003 10:24:18 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <510007089.20030526102418@brandenburg.com> To: problem-statement@alvestrand.no MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Subject: Controlling the IETF -- Engineers vs. Marketeers and Politeers 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, The discussion about standards track status highlights a basic source of disparity in quite a few of our discussions about changing the IETF. I'm finding myself labeling this disparity "Who is in charge of the IETF?" Historically, the IETF has done exceptionally well when it focuses on the "E". When we act like engineers who are concerned with engineering quality and core utility, we do great. When we wander into the territories of sociology, marketing or politics, we do very badly. Input from those three areas can be useful. But there is a difference between treating those considerations as "input" and treating them as "critical concerns that must determine strategic decisions". There is always someone, somewhere who will abuse our work in some fashion. They will tout an I-D as being under IETF consideration; they will tout an Informational RFC as an IETF standard, they will pressure the IETF to use small key sizes; etc., etc. We must not let these people control the IETF. We need to make sure that the meaning of I-D status is clear and is applied correctly. The same for Informational. We need to make sure that we choose key sizes that ensure the ability to provide the level of protection that is needed. Etc. Etc. These are engineering factors and they are what we have historically done well. When we make strategic decisions because someone, somewhere has distorted things, we cease to be engineers. We pretend to be politicians, marketeers and sociologists. Let's keep control of our work WITHIN the group doing the work, namely the iEtf. Let's discuss changes to the IETF that pertain to doing better engineering. That means focusing on engineering design quality and the utility of our specifications. It means focusing on deployment and use. It does not mean trying to react to "social" abuses and it does not mean trying to anticipate them. We have management and quality problems. Let's fix them. But let's not be distracted by the folks outside the world of IETF development and implementation. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Mon May 26 13:41: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 NAA19175 for ; Mon, 26 May 2003 13:41:30 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8597E6256F; Mon, 26 May 2003 19:40:56 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from pretender.boolean.net (router.boolean.net [198.144.206.49]) by eikenes.alvestrand.no (Postfix) with ESMTP id 35366622AC for ; Mon, 26 May 2003 19:40:54 +0200 (CEST) Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h4QHepc6008870; Mon, 26 May 2003 17:40:51 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20030526102607.029a8be0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 26 May 2003 10:38:01 -0700 To: Keith Moore From: "Kurt D. Zeilenga" In-Reply-To: <20030526002930.4ed21766.moore@cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: john.loughney@nokia.com Cc: problem-statement@alvestrand.no Subject: Re: NOT "inciting to riot" (was: Last Call: IP over MIME toProposed Standard) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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:29 PM 5/25/2003, Keith Moore wrote: >> What we need to do is come >> up with clear rules how things progress (and perhaps what is & is not >> appropriate for IETF standardization); a simple and straightforward >> way to resolve disputes; transparent leadership selection process and >> transparent decision making. If we had all of these, we probably would >> be about 80% done (in my opinion). > >I think it's more like 30%. The thing that we really need to do most is >to fix how working groups operate. I would have to agree 100% with this. I see two major problems with working group operations. Well, the first, I guess is the mis-conception held by some that you need a WG to develop a standard track document. Some of the most successful standard track documents we have were developed on an individual basis. SASL is a good example here (we're now revising it within a WG, but the original work was done individually). The second is the tendency of WG not to thoroughly consider alternatives offered to them, especially alternatives which are fundamentally different in design. This, I think, is due to WG not addressing discussing fundamentals (what's the problem, what are possible solutions, what applications do we serve, what are their requirements, etc.) early on. We often like to jump right into solutions. That's fine if there is implicit agreement on fundamentals but its bad if there isn't. Note that I am not a fan of requirement documents... but I do think it is wise for working groups to have some list discussions on fundamentals early on. (Guess that's a third). Kurt From problem-statement-bounces@alvestrand.no Mon May 26 13:55: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 NAA19654 for ; Mon, 26 May 2003 13:55:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D14AF622AC; Mon, 26 May 2003 19:55:25 +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 6FF24621B3 for ; Mon, 26 May 2003 19:55:20 +0200 (CEST) Received: from vkompella ([64.47.48.10] RDNS failed) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 26 May 2003 10:55:18 -0700 From: "Vach Kompella" To: "Dave Crocker" , Date: Mon, 26 May 2003 10:55:45 -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 Importance: Normal In-Reply-To: <510007089.20030526102418@brandenburg.com> X-OriginalArrivalTime: 26 May 2003 17:55:18.0305 (UTC) FILETIME=[F7F91110:01C323AF] Subject: RE: Controlling the IETF -- Engineers vs. Marketeers and Politeers 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 Dave, If we could exclude the marketeers and the politeers from the IETF and from society... More comments below. -Vach > > The discussion about standards track status highlights a basic source of > disparity in quite a few of our discussions about changing the IETF. When does the world outside the IETF decide that documents are making adequate progress that they may talk about them? Typically, when they hit certain milestones - WG accepts the draft, draft goes to IESG, various RFC labels attached to document... These _are_ important for an organization to judge whether something is worth implementing/deploying/marketing. > > I'm finding myself labeling this disparity "Who is in charge of the > IETF?" If we let them, then the marketing arms of organizations are. They are a far more powerful lobby than engineers have been. > > Historically, the IETF has done exceptionally well when it focuses on > the "E". When we act like engineers who are concerned with engineering > quality and core utility, we do great. The best we can do is to ignore the stuff outside the IETF, and prevent marketing/politics from influencing the IETF. > > When we wander into the territories of sociology, marketing or politics, > we do very badly. > > Input from those three areas can be useful. But there is a difference > between treating those considerations as "input" and treating them as > "critical concerns that must determine strategic decisions". Harald posted an email about "fixing" WG chairs and the counterpoint of "accusations of fixing". How we deal with those situations is critical to the independence of IETF decisions from the World Outside the IETF. Likewise, ballot stuffing, denial of service. > > There is always someone, somewhere who will abuse our work in some > fashion. They will tout an I-D as being under IETF consideration; they > will tout an Informational RFC as an IETF standard, they will pressure > the IETF to use small key sizes; etc., etc. Abuse is one thing. Affecting the integrity of the IETF is another. > > We must not let these people control the IETF. > > We need to make sure that the meaning of I-D status is clear and is > applied correctly. The same for Informational. We need to make sure > that we choose key sizes that ensure the ability to provide the level of > protection that is needed. Etc. Etc. I agree. Clear definitions allow us to correct impressions created by "marketeers" and "politeers". > > These are engineering factors and they are what we have historically > done well. > > When we make strategic decisions because someone, somewhere has > distorted things, we cease to be engineers. We pretend to be > politicians, marketeers and sociologists. I disagree. We don't pretend. We are surely influenced by the organizations we work for. I think that our only hope is to define clear processes so we can create enough organizational influence to prevent ourselves from shooting ourselves in the foot. Basically create a set of checks and balances that ensures that one group doesn't push the IETF the wrong direction. > > Let's keep control of our work WITHIN the group doing the work, namely > the iEtf. It's the Ietf to most people, i.e., there's a lot more riding on the Internet today than engineering. > > Let's discuss changes to the IETF that pertain to doing better > engineering. That means focusing on engineering design quality and the > utility of our specifications. It means focusing on deployment and use. > > It does not mean trying to react to "social" abuses and it does not mean > trying to anticipate them. > > We have management and quality problems. Let's fix them. > > But let's not be distracted by the folks outside the world of IETF > development and implementation. > It does mean reacting to abuses. It means limiting the impact of those abuses to outlying instances rather than letting them be the norm. It means not putting our heads in the sand about them actually occurring. It means defending the IETF against them. > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > > From problem-statement-bounces@alvestrand.no Mon May 26 14: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 OAA21271 for ; Mon, 26 May 2003 14:58:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1FECF6256F; Mon, 26 May 2003 20:57:38 +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 7182A6230A for ; Mon, 26 May 2003 20:57:35 +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 h4QIvWFW010072; Mon, 26 May 2003 11:57:33 -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 AHQ38542; Mon, 26 May 2003 11:57:31 -0700 (PDT) Message-Id: <200305261857.AHQ38542@mira-sjc5-c.cisco.com> To: Dave Crocker From: Melinda Shore In-Reply-To: Message from dhc@dcrocker.net <510007089.20030526102418@brandenburg.com> Date: Mon, 26 May 2003 14:57:30 -0400 Cc: problem-statement@alvestrand.no Subject: Re: Controlling the IETF -- Engineers vs. Marketeers and Politeers X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Speaking not as chair but as some other sort of entity, it seems to me that marketroids, etc., are actually less of a problem in practice than are people with narrow agendas, a lack of consensus on what the IETF's job is, etc. There are people who have legitimate disagreements about what's "bad for the internet," but there are also people who don't have a clue about what's bad for the internet or, conversely, do have a clue but don't care, or, for that matter, don't have a clue and don't care. I'd argue that these are the tensions that are more likely to cause functional problems and affect the overall quality of the organization's work. I liked the description of that problem that John Klensin posted several days ago. Melinda From problem-statement-bounces@alvestrand.no Mon May 26 15:28: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 PAA23376 for ; Mon, 26 May 2003 15:28:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8CF9E6256F; Mon, 26 May 2003 21:28:19 +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 0775C6230A for ; Mon, 26 May 2003 21:28:16 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19KNdk-0003F3-6F; Mon, 26 May 2003 12:28:12 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 26 May 2003 12:28:11 -0700 To: Dave Crocker References: <89860000.1053939264@askvoll.hjemme.alvestrand.no> <1861252390.20030526075823@brandenburg.com> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: Can we learn something from IETF history? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 original work was done far less formally, with hallway conversations > as the means for floating ideas and exploring reactions isn't this what some seem to call a closed conspiracy today? randy From problem-statement-bounces@alvestrand.no Mon May 26 15: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 PAA23456 for ; Mon, 26 May 2003 15:30:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8DAAD6256F; Mon, 26 May 2003 21:29: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 885CF6230A for ; Mon, 26 May 2003 21:29:25 +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 h4QJW6O24898; Mon, 26 May 2003 12:32:06 -0700 Date: Mon, 26 May 2003 12:29:20 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <7017509216.20030526122920@brandenburg.com> To: Randy Bush In-Reply-To: References: <89860000.1053939264@askvoll.hjemme.alvestrand.no> <1861252390.20030526075823@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: Can we learn something from IETF history? 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 >> The original work was done far less formally, with hallway conversations >> as the means for floating ideas and exploring reactions RB> isn't this what some seem to call a closed conspiracy today? or a Design Team. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Mon May 26 15:34: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 PAA23655 for ; Mon, 26 May 2003 15:34:15 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2BDB06230A; Mon, 26 May 2003 21:33:45 +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 27BF761DEC for ; Mon, 26 May 2003 21:33:43 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19KNj3-0003Nt-W7; Mon, 26 May 2003 12:33:42 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 26 May 2003 12:33:41 -0700 To: Dave Crocker References: <510007089.20030526102418@brandenburg.com> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: Controlling the IETF -- Engineers vs. Marketeers and Politeers X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 discussion about standards track status highlights a basic source of > disparity in quite a few of our discussions about changing the IETF. > ... > But let's not be distracted by the folks outside the world of IETF > development and implementation. i missed the part where marketeers et al. we pushing the ip over mime document? who outside is trying to distract us? or is it that we need more feeling of "us vs. them" to make us feel good about ourselves? randy From problem-statement-bounces@alvestrand.no Mon May 26 15:45: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 PAA23879 for ; Mon, 26 May 2003 15:45:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A3596625A0; Mon, 26 May 2003 21:44:28 +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 C53036256F; Mon, 26 May 2003 21:44:25 +0200 (CEST) Date: Mon, 26 May 2003 21:44:25 +0200 From: Harald Tveit Alvestrand To: Randy Bush Message-ID: <14880000.1053978265@askvoll.hjemme.alvestrand.no> In-Reply-To: References: <9C422444DE99BC46B3AD3C6EAFC9711B032412AD@tayexc13.americas.cpqco rp.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 Cc: problem-statement@alvestrand.no Subject: IESG restructuring (Re: Example of the One Liners out of context) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 PAA23879 what do other people think here? --On søndag, mai 25, 2003 07:25:22 -0700 Randy Bush wrote: > i do not think that adding a process director to the iesg is > constructive, and would be in fact destructive. we don't need to > politicize the wgs, iesg, secretariat as we already have this wg. > we should leave some parts of the organization to do actual ietf > work. > > and all this seems like so much red herring, without even sour > cream, but plenty of confrontationalism, polarization, etc. no > real substance, all politics, at which we engnineers are so expert > (not). so we destroy our organization and our culture with it. > omplalo-sepsis. > > dunno about you, but i spent years in the iso, ieee, ansi, ... i > came here to get engineering work done, not play amateur power > politics, voting blocks, .... the focus on real work has been the > ietf's strength and the root of its success. i suggest we play to > our strengths, not divisiveness, mud-slinging, and demagoguery. > > randy > > From problem-statement-bounces@alvestrand.no Mon May 26 16:30: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 QAA25843 for ; Mon, 26 May 2003 16:30:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EDC0C62590; Mon, 26 May 2003 22:30:03 +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 1BA0061DEC; Mon, 26 May 2003 22:30:01 +0200 (CEST) Received: by romeo.rtfm.com (Postfix, from userid 556) id 2AAB6ABA6; Mon, 26 May 2003 13:35:47 -0700 (PDT) To: Harald Tveit Alvestrand References: <9C422444DE99BC46B3AD3C6EAFC9711B032412AD@tayexc13.americas.cpqco rp.net> <14880000.1053978265@askvoll.hjemme.alvestrand.no> From: Eric Rescorla Date: 26 May 2003 13:35:46 -0700 In-Reply-To: <14880000.1053978265@askvoll.hjemme.alvestrand.no> Message-ID: Lines: 41 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Randy Bush Cc: problem-statement@alvestrand.no Subject: Re: IESG restructuring (Re: Example of the One Liners out of context) 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 Content-Transfer-Encoding: 8bit Harald Tveit Alvestrand writes: > what do other people think here? Maybe I've misunderstood Randy, but "real work vs. politics" strikes me as a false opposition. Getting real work done in organizations with more than a few people who have divergent goals is an inherently political activity. Sure, that sort of politics can be conducted in a more or less civilized manner, but I don't think it's really avoidable. -Ekr > --On søndag, mai 25, 2003 07:25:22 -0700 Randy Bush wrote: > > > i do not think that adding a process director to the iesg is > > constructive, and would be in fact destructive. we don't need to > > politicize the wgs, iesg, secretariat as we already have this wg. > > we should leave some parts of the organization to do actual ietf > > work. > > > > and all this seems like so much red herring, without even sour > > cream, but plenty of confrontationalism, polarization, etc. no > > real substance, all politics, at which we engnineers are so expert > > (not). so we destroy our organization and our culture with it. > > omplalo-sepsis. > > > > dunno about you, but i spent years in the iso, ieee, ansi, ... i > > came here to get engineering work done, not play amateur power > > politics, voting blocks, .... the focus on real work has been the > > ietf's strength and the root of its success. i suggest we play to > > our strengths, not divisiveness, mud-slinging, and demagoguery. > > > > randy > > > > > > -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From problem-statement-bounces@alvestrand.no Mon May 26 16:37: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 QAA25949 for ; Mon, 26 May 2003 16:37:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 73ADD622AC; Mon, 26 May 2003 22:36:35 +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 ACFBC61DEC for ; Mon, 26 May 2003 22:36:26 +0200 (CEST) Message-ID: <00ae01c323c6$42073050$4a6015ac@DCLKEMPFTP> From: "James Kempf" To: "Wijnen, Bert (Bert)" References: <7D5D48D2CAA3D84C813F5B154F43B15501A9F889@nl0006exch001u.nl.lucent.com> Date: Mon, 26 May 2003 13:34:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Quality of WG Output (Was: RE: OPEN ISSUE: Standards Track) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Bert, Sure. Putting on my WG chair hat, I do this informally all the time. But my milage does vary, depending on how busy the people are who I contact. I still think it makes a certain amount of sense to have some more formal design reviews earlier in the process, to avoid the "late suprise" problem. After a WG has been running for a while (where "a while" needs some definition), I think they are obligated to show some results. Making the design review formal assures that the relevent IETF people (Security ADs, SAAG, etc.) can commit time, gives the shepherding AD leverage if the WG is not performing for some judicious early pruning, or, less drastically, for some midcourse corrections. jak ----- Original Message ----- From: "Wijnen, Bert (Bert)" To: "James Kempf" Cc: Sent: Friday, May 23, 2003 5:25 AM Subject: RE: Quality of WG Output (Was: RE: OPEN ISSUE: Standards Track) > Mmmm... maybe this is just me... > > But what is wrong with WG members and WG chairs to seek > early help from the Security Area Advisors and ADs or > from some specific WG in the security area? > > I.e. WG chairs should feel free to try and find help in > other places in the IETF. > > Thanks, > Bert > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: donderdag 22 mei 2003 22:38 > > To: Basavaraj.Patil@nokia.com; Margaret Wasserman > > Cc: randy@psg.com; problem-statement@alvestrand.no; pekkas@netcore.fi > > Subject: Re: Quality of WG Output (Was: RE: OPEN ISSUE: > > Standards Track) > > > > > > Margaret, > > > > Well stated. Introduction of more structured, formal reviews at a > > selected, very fiew points in the development process could help to > > reduce the late suprise factor. Of course, it is possible to go > > overboard and slow down the development with too much process, so care > > is needed. > > > > jak > > > > ----- Original Message ----- > > From: "Margaret Wasserman" > > To: > > Cc: ; ; > > > > Sent: Thursday, May 22, 2003 1:05 PM > > Subject: Quality of WG Output (Was: RE: OPEN ISSUE: Standards Track) > > > > > > > > > > Hi Basavaraj, > > > > > > At 01:55 PM 5/22/2003 -0500, Basavaraj.Patil@nokia.com wrote: > > > >Maybe. But the key lesson to be learn here is that the Mobile IP WG > > > >spent about 3 years or more before the IESG said that the security > > > >solution based on IPsec was broken. The timeline to arrive at such > > > >a conclusion is a serious problem for any standards work. > > > > > > I agree that it is a serious problem that there was no > > > adequate security review of this proposal for three > > > years while it was being processed by the WG. > > > > > > But, I don't think that this is a problem with: > > > > > > - The IESG, or > > > - The IETF standards track. > > > > > > Instead, I consider this a problem with the quality > > > processes (or lack thereof) used by our WGs. We > > > need to find ways to make sure that documents are > > > adequately reviewed during different phases of > > > WG development, so that these "late surprises" don't > > > occur. In other words, we need to determine ways > > > to increase the quality and integrity of WG output. > > > > > > This is dealt with in the problem statement > > > and the process document in the discussion of WG > > > engineering practices. > > > > > > Margaret > > > > > > > > > > > > > > > From problem-statement-bounces@alvestrand.no Mon May 26 16:42: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 QAA26144 for ; Mon, 26 May 2003 16:42:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4F91C625BB; Mon, 26 May 2003 22:41:59 +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 70F03625AB for ; Mon, 26 May 2003 22:41:53 +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 h4QKfiAV019801 for ; Mon, 26 May 2003 13:41:44 -0700 (PDT) Received: from cisco.com (sjc-vpn2-500.cisco.com [10.21.113.244]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AGM36961; Mon, 26 May 2003 13:34:50 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Mon, 26 May 2003 16:41:42 -0400 Date: Mon, 26 May 2003 16:41:42 -0400 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030526204142.GS2424@sbrim-w2k> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: <9C422444DE99BC46B3AD3C6EAFC9711B032412AD@tayexc13.americas.cpqcorp.net> <14880000.1053978265@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: <14880000.1053978265@askvoll.hjemme.alvestrand.no> User-Agent: Mutt/1.4i Subject: Re: IESG restructuring (Re: Example of the One Liners out of context) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 Mon, May 26, 2003 09:44:25PM +0200, Harald Tveit Alvestrand allegedly wrote: > what do other people think here? > > --On søndag, mai 25, 2003 07:25:22 -0700 Randy Bush wrote: > > >i do not think that adding a process director to the iesg is > >constructive, and would be in fact destructive. we don't need to > >politicize the wgs, iesg, secretariat as we already have this wg. > >we should leave some parts of the organization to do actual ietf > >work. I would not have a process director per se -- that feels like too much permanent infrastructure -- but we do have plenty to do on process. How about something like NomCom -- let's not have 3000 people arguing endlessly about process, but let's do have a periodically refreshed small design team looking at problems, consulting with experienced IETFers, proposing designs and determining rough consensus. From problem-statement-bounces@alvestrand.no Mon May 26 17:00: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 RAA26990 for ; Mon, 26 May 2003 17:00:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5471B625A0; Mon, 26 May 2003 22:59:35 +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 316826230A; Mon, 26 May 2003 22:59:32 +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 19KP3z-0003b5-00; Mon, 26 May 2003 13:59:23 -0700 Date: Mon, 26 May 2003 16:57:58 -0400 From: Keith Moore To: Harald Tveit Alvestrand Message-Id: <20030526165758.1cceff7b.moore@cs.utk.edu> In-Reply-To: <14880000.1053978265@askvoll.hjemme.alvestrand.no> References: <9C422444DE99BC46B3AD3C6EAFC9711B032412AD@tayexc13.americas.cpqco rp.net> <14880000.1053978265@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: randy@psg.com Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: IESG restructuring (Re: Example of the One Liners out of context) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 do other people think here? A few days ago I was in support of having another AD, if for no other reason than I thought it might help us get past the issue of who can be trusted to manage the WG, and on to the real issue of how IETF should be run. After thinking about it some more and reading the conversations on this list I'm now slightly against the idea, because it seems to me to actually be encouraging the witch-hunt mentality. I'm also convinced that it would probably be disruptive to IESG--especially if that new AD saw it as his job to "fix" IESG. From problem-statement-bounces@alvestrand.no Mon May 26 19:05: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 TAA03356 for ; Mon, 26 May 2003 19:04:59 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 77BB262590; Tue, 27 May 2003 01:04:30 +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 B77FD622AC for ; Tue, 27 May 2003 01:04:28 +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 4A091BB52; Mon, 26 May 2003 19:04:27 -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, 26 May 2003 19:04:27 -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, 26 May 2003 19:04:26 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042845BA@tayexc13.americas.cpqcorp.net> Thread-Topic: Example of the One Liners out of context Thread-Index: AcMiyX34DwYvk1ODRUyvDtMqpBPYgwBEVdLQ From: "Bound, Jim" To: "Randy Bush" X-OriginalArrivalTime: 26 May 2003 23:04:27.0132 (UTC) FILETIME=[27EF73C0:01C323DB] Cc: problem-statement@alvestrand.no Subject: RE: Example of the One Liners out of context X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 TAA03356 > i do not think that adding a process director to the iesg is > constructive, and would be in fact destructive. we don't > need to politicize the wgs, iesg, secretariat as we already > have this wg. we should leave some parts of the organization > to do actual ietf work. No one is suggesting a process director? I have no idea what your talking about above and cannot parse it at all? What are you talking about? No mail below to reference? > > and all this seems like so much red herring, without even > sour cream, but plenty of confrontationalism, polarization, > etc. no real substance, all politics, at which we engnineers > are so expert (not). so we destroy our organization and our > culture with it. omplalo-sepsis. What is "all this"? > > dunno about you, but i spent years in the iso, ieee, ansi, > ... i came here to get engineering work done, not play > amateur power politics, voting blocks, .... the focus on > real work has been the ietf's strength and the root of its > success. i suggest we play to our strengths, not > divisiveness, mud-slinging, and demagoguery. I agree with this. But now it has much failure and a there appears to be a problem. /jim > > randy > > From problem-statement-bounces@alvestrand.no Mon May 26 19:10: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 TAA03602 for ; Mon, 26 May 2003 19:10:32 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B8A1362590; Tue, 27 May 2003 01:10:03 +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 3BDCD622AC for ; Tue, 27 May 2003 01:10:02 +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 3A80DB948; Mon, 26 May 2003 19:10:01 -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, 26 May 2003 19:09: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, 26 May 2003 19:09:58 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042845BB@tayexc13.americas.cpqcorp.net> Thread-Topic: Controlling the IETF -- Engineers vs. Marketeers and Politeers Thread-Index: AcMjq7WHXC3uNoz0TlSELjfDwWrkSwAMAGvA From: "Bound, Jim" To: "Dave Crocker" , X-OriginalArrivalTime: 26 May 2003 23:09:58.0754 (UTC) FILETIME=[ED98F420:01C323DB] Subject: RE: Controlling the IETF -- Engineers vs. Marketeers and Politeers X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 TAA03602 This is a key point of discussion. We should not let bad marketing interfere with our document classifcations and progressions. No matter what set we have to follow someone will abuse it. Most users I know are pretty clear on the difference between BCP, Info, PS to IS progression. The IETF has been around awhile now and those who use the standards are not stupid. /jim > -----Original Message----- > From: Dave Crocker [mailto:dhc@dcrocker.net] > Sent: Monday, May 26, 2003 1:24 PM > To: problem-statement@alvestrand.no > Subject: Controlling the IETF -- Engineers vs. Marketeers and > Politeers > > > Folks, > > The discussion about standards track status highlights a > basic source of disparity in quite a few of our discussions > about changing the IETF. > > I'm finding myself labeling this disparity "Who is in charge > of the IETF?" > > Historically, the IETF has done exceptionally well when it > focuses on the "E". When we act like engineers who are > concerned with engineering quality and core utility, we do great. > > When we wander into the territories of sociology, marketing > or politics, we do very badly. > > Input from those three areas can be useful. But there is a > difference between treating those considerations as "input" > and treating them as "critical concerns that must determine > strategic decisions". > > There is always someone, somewhere who will abuse our work in > some fashion. They will tout an I-D as being under IETF > consideration; they will tout an Informational RFC as an IETF > standard, they will pressure the IETF to use small key sizes; > etc., etc. > > We must not let these people control the IETF. > > We need to make sure that the meaning of I-D status is clear > and is applied correctly. The same for Informational. We > need to make sure that we choose key sizes that ensure the > ability to provide the level of protection that is needed. Etc. Etc. > > These are engineering factors and they are what we have > historically done well. > > When we make strategic decisions because someone, somewhere > has distorted things, we cease to be engineers. We pretend > to be politicians, marketeers and sociologists. > > Let's keep control of our work WITHIN the group doing the > work, namely the iEtf. > > Let's discuss changes to the IETF that pertain to doing > better engineering. That means focusing on engineering design > quality and the utility of our specifications. It means > focusing on deployment and use. > > It does not mean trying to react to "social" abuses and it > does not mean trying to anticipate them. > > We have management and quality problems. Let's fix them. > > But let's not be distracted by the folks outside the world of > IETF development and implementation. > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , > > From problem-statement-bounces@alvestrand.no Mon May 26 19:13: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 TAA03851 for ; Mon, 26 May 2003 19:13:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7646562590; Tue, 27 May 2003 01:13: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 EB969622AC for ; Tue, 27 May 2003 01:13:18 +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 1D127BA3E; Mon, 26 May 2003 19:13:18 -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, 26 May 2003 19:13: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: Mon, 26 May 2003 19:13:17 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042845BC@tayexc13.americas.cpqcorp.net> Thread-Topic: Can we learn something from IETF history? Thread-Index: AcMjvQFXyZy9w01eSI6Pw84/Nb/GXAAHyK2A From: "Bound, Jim" To: "Randy Bush" , "Dave Crocker" X-OriginalArrivalTime: 26 May 2003 23:13:18.0000 (UTC) FILETIME=[645B7B00:01C323DC] Cc: problem-statement@alvestrand.no Subject: RE: Can we learn something from IETF history? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 TAA03851 And this should end competely no more hallway to policy decisoins, and that at least for the WG effort is better today. Now we take to long to get anything done. The answer is somewhere in the middle. /jim > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, May 26, 2003 3:28 PM > To: Dave Crocker > Cc: problem-statement@alvestrand.no > Subject: Re: Can we learn something from IETF history? > > > > The original work was done far less formally, with hallway > > conversations as the means for floating ideas and exploring > reactions > > isn't this what some seem to call a closed conspiracy today? > > randy > > From problem-statement-bounces@alvestrand.no Mon May 26 19:15: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 TAA03899 for ; Mon, 26 May 2003 19:15:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5C504625A0; Tue, 27 May 2003 01:14:57 +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 5F7C9622AC; Tue, 27 May 2003 01:14:54 +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 85D82BA38; Mon, 26 May 2003 19:14: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); Mon, 26 May 2003 19:14: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="iso-8859-1" Date: Mon, 26 May 2003 19:14:52 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042845BD@tayexc13.americas.cpqcorp.net> Thread-Topic: IESG restructuring (Re: Example of the One Liners out of context) Thread-Index: AcMjvz5gFt3TsZ1VT6SLRXporoL1zwAHUHMg From: "Bound, Jim" To: "Harald Tveit Alvestrand" , "Randy Bush" X-OriginalArrivalTime: 26 May 2003 23:14:53.0284 (UTC) FILETIME=[9D26AA40:01C323DC] Cc: problem-statement@alvestrand.no Subject: RE: IESG restructuring (Re: Example of the One Liners out of context) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 TAA03899 if we are serious about this discussion having a process director is a very bad idea is my input. The IETF chair does this job. Lets not add more heads to the process to solve problems. /jim > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: Monday, May 26, 2003 3:44 PM > To: Randy Bush > Cc: problem-statement@alvestrand.no > Subject: IESG restructuring (Re: Example of the One Liners > out of context) > > > what do other people think here? > > --On søndag, mai 25, 2003 07:25:22 -0700 Randy Bush > wrote: > > > i do not think that adding a process director to the iesg is > > constructive, and would be in fact destructive. we don't need to > > politicize the wgs, iesg, secretariat as we already have > this wg. we > > should leave some parts of the organization to do actual ietf work. > > > > and all this seems like so much red herring, without even > sour cream, > > but plenty of confrontationalism, polarization, etc. no real > > substance, all politics, at which we engnineers are so > expert (not). > > so we destroy our organization and our culture with it. > > omplalo-sepsis. > > > > dunno about you, but i spent years in the iso, ieee, ansi, > ... i came > > here to get engineering work done, not play amateur power politics, > > voting blocks, .... the focus on real work has been the ietf's > > strength and the root of its success. i suggest we play to our > > strengths, not divisiveness, mud-slinging, and demagoguery. > > > > randy > > > > > > > From problem-statement-bounces@alvestrand.no Mon May 26 19:36: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 TAA04280 for ; Mon, 26 May 2003 19:36:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8A8FD625A0; Tue, 27 May 2003 01:35:33 +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 E1F71622AC; Tue, 27 May 2003 01:35:30 +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 h4QNZSFW021375; Mon, 26 May 2003 16:35:28 -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 AHQ45292; Mon, 26 May 2003 16:35:26 -0700 (PDT) Message-Id: <200305262335.AHQ45292@mira-sjc5-c.cisco.com> To: "Bound, Jim" From: Melinda Shore In-Reply-To: Message from Jim.Bound@hp.com <9C422444DE99BC46B3AD3C6EAFC9711B042845BD@tayexc13.americas.cpqcorp.net> Date: Mon, 26 May 2003 19:35:26 -0400 Cc: Randy Bush Cc: Harald Tveit Alvestrand Cc: problem-statement@alvestrand.no Subject: Re: IESG restructuring (Re: Example of the One Liners out of context) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no > if we are serious about this discussion having a process director is a = > very bad idea is my input. The IETF chair does this job. Lets not add = > more heads to the process to solve problems. The root issue here was conflict-of-interest avoidance, which is something that hasn't been discussed much yet. Are people feeling that we're okay on that? Melinda From problem-statement-bounces@alvestrand.no Tue May 27 01:44: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 BAA15668 for ; Tue, 27 May 2003 01:44:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E303F625BF; Tue, 27 May 2003 07:44:06 +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 C3819623CD; Tue, 27 May 2003 07:44:00 +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 A1E6ABAC9; Tue, 27 May 2003 01: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); Tue, 27 May 2003 01: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: Tue, 27 May 2003 01:43:54 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B032412B6@tayexc13.americas.cpqcorp.net> Thread-Topic: IESG restructuring (Re: Example of the One Liners out of context) Thread-Index: AcMj34AOi16uxoACSYugfO15aR941wAMJ/nQ From: "Bound, Jim" To: "Melinda Shore" X-OriginalArrivalTime: 27 May 2003 05:43:54.0392 (UTC) FILETIME=[F5891980:01C32412] Cc: Randy Bush Cc: Harald Tveit Alvestrand Cc: problem-statement@alvestrand.no Subject: RE: IESG restructuring (Re: Example of the One Liners out of context) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 BAA15668 Melinda, I don't want more heads at the helm. But I do believe there is much conflict of interest in the boundaries of the various roles, groups, and individual members. But like the good ole boy network it will never be totally clean, and maybe someday it will be called the good ole person network and IETF too can get past gender. I am debating one case on the NOMCOM currently and a straw person for some text has been presented. The rejection is to keep the IESG and IAB Liaisons current process in place. And others agree with me. We shall see. I don't view it as black or white or good or bad. But the question to ponder is in any situation where an authority can influence a process that is suppose to be done by a republic view (elected by others as the NOMCOM) or a democratic process (a WG vote) and then later influence by those in charge, and no other community member can, then that is a potential for investigation of a conflict of Interest. Note I said investigation not that in fact it was a conflict. It is a hint. Whether this has happened or not is irrelevant the question is should any potential be fixed? Some argue if it is not broke don't fix it. But the problem is that I personally believe that many in our community do not have absolute trust of the process or the leaders at all. Just this mail lists show that at best it is 50/50. That is a problem. If all were happy there would be no complaints and no problem working group. The other analogy is that I feel the IETF is run as an Academic process not modeled after a business process nor any government process except for a monarchy and I have already stated I hate monarchies. If no one was complaining it would be fine but many are complaining, we stink at time-to-market for standards, the process is too long, and I believe some very questionable technical review and hold ups have been completely out of line by the IESG process. It is like a lot of divorced men I know its always their wives fault, maybe 1 out of 10 will admit they were assholes. The IESG is sitting here and not one of them except Harald has admitted a fault on their part or even open to discuss it here. They are not infallable and have made mistakes that is the real point, and so has the community. Out in the IETF we have all kinds of reminders as Chairs, as Authors, as WG members to remind us we can be wrong and make mistakes. NOTHING like that exists for for the IESG and they need that and need it now. They need a higher authority to answer to. And that higher authority should be added process rules and forms of process that put a check on things they do wrong. I believe the priority for me is to ship specs faster and complete them. The other stuff is secondary. But for people to be here and tell me the IESG is fine thats simly not true. /jim /jim > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: Monday, May 26, 2003 7:35 PM > To: Bound, Jim > Cc: Harald Tveit Alvestrand; Randy Bush; > problem-statement@alvestrand.no > Subject: Re: IESG restructuring (Re: Example of the One > Liners out of context) > > > > if we are serious about this discussion having a process > director is a > > = very bad idea is my input. The IETF chair does this job. > Lets not > > add = more heads to the process to solve problems. > > The root issue here was conflict-of-interest avoidance, > which is something that hasn't been discussed much yet. Are > people feeling that we're okay on that? > > Melinda > From problem-statement-bounces@alvestrand.no Tue May 27 02:55: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 CAA29871 for ; Tue, 27 May 2003 02:55:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8484F625B7; Tue, 27 May 2003 08:54:35 +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 569E6621FA; Tue, 27 May 2003 08:54:28 +0200 (CEST) Date: Tue, 27 May 2003 08:54:34 +0200 From: Harald Tveit Alvestrand To: John C Klensin Message-ID: <50520000.1054018474@askvoll.hjemme.alvestrand.no> In-Reply-To: <134395019.1053721004@p3.JCK.COM> References: <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> <4318516885.20030522200444@brandenburg.com> <20030522234140.3387e2e0.moore@cs.utk.edu> <1815027409.20030522220356@brandenburg.com> <20030523011235.7478d87f.moore@cs.utk.edu> <118612545.1053705221@p3.JCK.COM><128024980.1053714634@p3.JCK.COM> <134395019.1053721004@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: Problem: Resolution mechanisms for when working group consensusreal 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 --On fredag, mai 23, 2003 20:16:44 -0400 John C Klensin wrote: > I don't know that I've mentioned it on this list (probably haven't, and > it intrudes into the "solution" space a bit anyway), but I've had > periodic thoughts that it would be a good idea to have ADs "invite" > particularly interesting and/or problematic WGs to present their problem > definition, work in progress, ideas, and plans at a plenary, and then > take questions, etc. This would act as a way to bring the whole > community in on questions of relevance and relationship to the overall > architecture and operation of the Internet. Both the audience and the WG > participants might learn a lot. And while "contemplate process changes", > "whine at the IESG" and "whine at the IAB" have an important place, > injecting some community-wide _technical_ review and discussion back into > the environment might be really helpful and interesting. I'm a little bit worried..... not that I don't recognize any number of instances of the scenario above, but there are other instances..... my counterexample is an example of something that is totally irrelevant to the Internet architecture per se, but has proved useful to a sharply limited community, has (as far as I can tell) not had any really bad effects on the architecture, and the only time the managing AD had to do some management was in order to insist that they should have some security (and they delivered!). TN3270E - Extending the Telnet protocol to handle IBM 3270 terminals, or emulators thereof. In the current climate of WG creation, we would have a 1000-message debate on the IETF list in order to take this on at all. And the debate would actually be more costly in terms of management time than the running of the activity. To paraphrase a quote attributed to Alan Kay: "Small things should be easy. Big things should be possible." [I'm sure someone will correct me if I'm totally wrong, and the TN3270E WG has now descended into an unmanageable cesspool of conflicts... it's been years since I managed it....] Harald From problem-statement-bounces@alvestrand.no Tue May 27 02:58: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 CAA29931 for ; Tue, 27 May 2003 02:58:37 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 62A4A623CD; Tue, 27 May 2003 08:57: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 EB2F862575 for ; Tue, 27 May 2003 08:57:37 +0200 (CEST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])h4R6vSL15285 for ; Tue, 27 May 2003 09:57:28 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com ; Tue, 27 May 2003 09:57:28 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 27 May 2003 09:57:28 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 27 May 2003 09:57:27 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 27 May 2003 09:57: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: Tue, 27 May 2003 09:57:26 +0300 Message-ID: Thread-Topic: NOT "inciting to riot" (was: Last Call: IP over MIME toProposed Standard) Thread-Index: AcMjrgR7R4laXhC8QgGMnoL72LMepwAbwd9Q From: To: X-OriginalArrivalTime: 27 May 2003 06:57:27.0250 (UTC) FILETIME=[3BCDCB20:01C3241D] Cc: problem-statement@alvestrand.no Subject: RE: NOT "inciting to riot" (was: Last Call: IP over MIME toProposed Standard) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 CAA29931 Hi Keith, At 09:29 PM 5/25/2003, Keith Moore wrote: >> What we need to do is come >> up with clear rules how things progress (and perhaps what is & is not >> appropriate for IETF standardization); a simple and straightforward >> way to resolve disputes; transparent leadership selection process and >> transparent decision making. If we had all of these, we probably would >> be about 80% done (in my opinion). > >I think it's more like 30%. The thing that we really need to do most is >to fix how working groups operate. Is there any reason why you think my comments did not include WGs? I do think that the above problems are applicable in WGs. I think that WGs often breakdown when trying to resolve problems - the result is that often some problems don't get resolved until IESG review, for example. John From problem-statement-bounces@alvestrand.no Tue May 27 04:15: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 EAA03596 for ; Tue, 27 May 2003 04:14:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1177A62575; Tue, 27 May 2003 10:14:23 +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 4973D6225B for ; Tue, 27 May 2003 10:14:10 +0200 (CEST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) h4R8DiDI082198 for ; Tue, 27 May 2003 10:13:48 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140])h4R8C14A119372 for ; Tue, 27 May 2003 10:12:03 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA31610 from ; Tue, 27 May 2003 10:12:00 +0200 Message-Id: <3ED31DEB.BFC86836@hursley.ibm.com> Date: Tue, 27 May 2003 10:12:27 +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: <200305262335.AHQ45292@mira-sjc5-c.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: IESG restructuring (Re: Example of the One Liners out ofcontext) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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: > > > if we are serious about this discussion having a process director is a = > > very bad idea is my input. The IETF chair does this job. Lets not add = > > more heads to the process to solve problems. > > The root issue here was conflict-of-interest avoidance, > which is something that hasn't been discussed much yet. Are > people feeling that we're okay on that? Conflict of interest is simply unavoidable. I could probably list ten conflicts of interest that apply to me this morning. * The issue is how to prevent conflicts of interest from tilting the metaphorical level playing field, and the best answer we have in general is to put checks and balances, and appeals mechanisms, in place. If the existing General AD handles the reform process, there will be one set of conflicts. If another AD is added to handle it, there will be another set of conflicts. Choose your poison. Brian * 1. I have a colleague in the IESG 2. I have a colleague in the IAB 3. The IETF Chair works for a company that has a strategic relationship with my employer. 4. I am an ISOC Trustee 5. I am a former member and chair of the IAB, hence part of the charmed circle 6. I drafted the current IAB charter 7. I am involved in the Global Grid Forum, an overlapping standards body 8. I have colleagues heavily involved in W3C, an overlapping standards body 9. I am co-author of a draft currently under IESG review 10.My former WG was really, really slow to complete its charter From problem-statement-bounces@alvestrand.no Tue May 27 06:50: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 GAA07336 for ; Tue, 27 May 2003 06:50:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8FE7C623CD; Tue, 27 May 2003 12:49:38 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7D7846225B for ; Tue, 27 May 2003 12:49:36 +0200 (CEST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19Kc1A-0006SU-00; Tue, 27 May 2003 03:49:21 -0700 Date: Tue, 27 May 2003 06:47:54 -0400 From: Keith Moore To: Message-Id: <20030527064754.72b1ac3f.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: NOT "inciting to riot" (was: Last Call: IP over MIME toProposed Standard) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 come > >> up with clear rules how things progress (and perhaps what is & is not > >> appropriate for IETF standardization); a simple and straightforward > >> way to resolve disputes; transparent leadership selection process and > >> transparent decision making. If we had all of these, we probably would > >> be about 80% done (in my opinion). > > > >I think it's more like 30%. The thing that we really need to do most is > >to fix how working groups operate. > > Is there any reason why you think my comments did not include WGs? I > do think that the above problems are applicable in WGs. I think > that WGs often breakdown when trying to resolve problems - the > result is that often some problems don't get resolved until IESG > review, for example. I did assume your comments included WGs; I just don't think that they address IETF's biggest problems either inside or outside of WGs. In my experience the breakdown isn't that WG fail to resolve problems so much as their failure to even acknowledge that those problems exist. And we could easily have "a simple and straightforward way to resolve disputes" which resolved them by choosing not to solve the underlying problems, which is often what happens in practice today. From problem-statement-bounces@alvestrand.no Tue May 27 07:05: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 HAA07802 for ; Tue, 27 May 2003 07:05:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B5FBD6257F; Tue, 27 May 2003 13:05:03 +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 8AFC26225B; Tue, 27 May 2003 13:04:59 +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 19KcG3-0005cM-00; Tue, 27 May 2003 04:04:43 -0700 Date: Tue, 27 May 2003 07:03:16 -0400 From: Keith Moore To: "Bound, Jim" Message-Id: <20030527070316.356e49e2.moore@cs.utk.edu> In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B032412B6@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B032412B6@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: mshore@cisco.com Cc: randy@psg.com Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Cc: harald@alvestrand.no Subject: Re: IESG restructuring (Re: Example of the One Liners out of context) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 other analogy is that I feel the IETF is run as an Academic process > not modeled after a business process nor any government process please don't cite either business or government practices as models for how IETF should work - at least not axiomatically. both of these have at least as much insanity as academic processes. Perhaps "academic processes" (whatever those are) are not quite right for IETF, but IETF's mission is closer to being an academic one (i.e. education and discovery of new technology) than it is to either business or government. From problem-statement-bounces@alvestrand.no Tue May 27 10:35: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 KAA14370 for ; Tue, 27 May 2003 10:35:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BCA25623CD; Tue, 27 May 2003 16:34:29 +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 DE9346230A for ; Tue, 27 May 2003 16:34:27 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=mail) by athene.wz-berlin.de with esmtp (Exim 4.20) id 19KfX1-00066R-DS; Tue, 27 May 2003 16:34:27 +0200 Received: from athene.wz-berlin.de ([127.0.0.1]) by localhost (athene [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23193-09; Tue, 27 May 2003 16:34:26 +0200 (CEST) Received: from medea.wz-berlin.de ([193.174.6.5]) by athene.wz-berlin.de with esmtp (Exim 4.20) id 19KfX0-000668-Gk; Tue, 27 May 2003 16:34:26 +0200 Received: from ERDE/SpoolDir by medea.wz-berlin.de (Mercury 1.48); 27 May 03 16:34:27 +0200 Received: from SpoolDir by ERDE (Mercury 1.48); 27 May 03 16:34:01 +0200 From: "Jeanette Hofmann" Organization: Wissenschaftszentrum Berlin To: Brian E Carpenter , problem-statement@alvestrand.no Date: Tue, 27 May 2003 16:34:00 +0200 MIME-Version: 1.0 Message-ID: <3ED39379.16218.E90F94@localhost> Priority: normal In-reply-to: <3ED31DEB.BFC86836@hursley.ibm.com> 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 Subject: Re: IESG restructuring (Re: Example of the One Liners out ofcontext) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 May 2003 at 10:12, Brian E Carpenter wrote: > Melinda Shore wrote: > > > > > if we are serious about this discussion having a process director is a = > > > very bad idea is my input. The IETF chair does this job. Lets not add = > > > more heads to the process to solve problems. > > > > The root issue here was conflict-of-interest avoidance, > > which is something that hasn't been discussed much yet. Are > > people feeling that we're okay on that? > > Conflict of interest is simply unavoidable. This might or might not be true. One crucial question is if those who are members of the IESG are equally open and neutral with regard to proposed problem solutions addressing the IESG than someone who is new to this club. A second question is if the whole process would benefit from a new AD, who would bring in fresh perspectives and ideas because she or he doesn't take the current structure so much for granted as those who have grown up in it. I think it would be good if more people on this list would speak up regarding this question. jeanette I could probably list > ten conflicts of interest that apply to me this morning. * > > The issue is how to prevent conflicts of interest from tilting > the metaphorical level playing field, and the best answer we have > in general is to put checks and balances, and appeals mechanisms, > in place. > > If the existing General AD handles the reform process, there will be > one set of conflicts. If another AD is added to handle it, there will > be another set of conflicts. Choose your poison. > > Brian > > * > 1. I have a colleague in the IESG > 2. I have a colleague in the IAB > 3. The IETF Chair works for a company that has a strategic relationship with > my employer. > 4. I am an ISOC Trustee > 5. I am a former member and chair of the IAB, hence part of the charmed circle > 6. I drafted the current IAB charter > 7. I am involved in the Global Grid Forum, an overlapping standards body > 8. I have colleagues heavily involved in W3C, an overlapping standards body > 9. I am co-author of a draft currently under IESG review > 10.My former WG was really, really slow to complete its charter From problem-statement-bounces@alvestrand.no Tue May 27 10:58: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 KAA15481 for ; Tue, 27 May 2003 10:58:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AF81C623CD; Tue, 27 May 2003 16:58: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 42A3F6230A for ; Tue, 27 May 2003 16:58:03 +0200 (CEST) Received: by romeo.rtfm.com (Postfix, from userid 556) id F3327ABA7; Tue, 27 May 2003 08:03:59 -0700 (PDT) To: "Jeanette Hofmann" References: <3ED39379.16218.E90F94@localhost> From: Eric Rescorla Date: 27 May 2003 08:03:59 -0700 In-Reply-To: <3ED39379.16218.E90F94@localhost> Message-ID: Lines: 28 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: IESG restructuring (Re: Example of the One Liners out ofcontext) 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 "Jeanette Hofmann" writes: > This might or might not be true. One crucial question is if those who are > members of the IESG are equally open and neutral with regard to proposed > problem solutions addressing the IESG than someone who is new to this club. I wouldn't expect them to be. Their incentives are different. > A second question is if the whole process would benefit from a new AD, who > would bring in fresh perspectives and ideas because she or he doesn't take > the current structure so much for granted as those who have grown up in it. Out of the current IESG... Three have served less than 2 years: Bill Fenner, Steve Bellovin, Alex Zinin Three were just appointed: Ted Hardie, Russ Housley, Jon Peterson So, I don't think you can characterize them as having "grown up in the system" to any greater extent than that to which the IETF as a whole is infected. If your point is that some real outsider should be brought in, I think that's worth considering, but I don't think that picking some non-IESG IETFer would do the job. -Ekr -- [Eric Rescorla ekr@rtfm.com] Web Log: http://www.rtfm.com/movabletype From problem-statement-bounces@alvestrand.no Tue May 27 11:04: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 LAA15947 for ; Tue, 27 May 2003 11:04:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CD50062575; Tue, 27 May 2003 17:04:07 +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 00D996259C for ; Tue, 27 May 2003 17:02:34 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.34]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA26887; Tue, 27 May 2003 08:01:44 -0700 (PDT) Message-Id: <5.1.0.14.2.20030527103301.04155aa0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 27 May 2003 10:56:00 -0400 To: "Jeanette Hofmann" From: Margaret Wasserman In-Reply-To: <3ED39379.16218.E90F94@localhost> References: <3ED31DEB.BFC86836@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: IESG restructuring (Re: Example of the One Liners out ofcontext) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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:34 PM 5/27/2003 +0200, Jeanette Hofmann wrote: > > Conflict of interest is simply unavoidable. > >This might or might not be true. One crucial question is if those who are >members of the IESG are equally open and neutral with regard to proposed >problem solutions addressing the IESG than someone who is new to this club. >A second question is if the whole process would benefit from a new AD, who >would bring in fresh perspectives and ideas because she or he doesn't take >the current structure so much for granted as those who have grown up in it. I think that it is important to remember that there are several leadership positions that are important to any WG: (1) The WG chair(s), providing direct management for the effort. (2) Any document editors and/or design team leads, as appointed by the WG chair. (3) The "responsible AD", providing director- level management for the effort and serving as the first-line of appeal for WG chair decisions. (4) The co-AD, who can serve as a mediator between the WG chair(s) and responsible AD, if needed. This person can also back the work of the WG to the IESG, even if the responsible AD is unwilling to do so. This offers a check against AD power abuse. In my experience, the WG chairs and both ADs form a fairly tight management team that works as a group to make the most important WG decisions, with the WG chairs making all of the routine and day-to-day decisions. The WG chairs often have as much or more influence on the direction and tone of the WG than the "responsible AD". For example, WG chairs typically write the WG charter, control the milestones/schedule, determine meeting agendas, etc. So, in many ways, it is more important how we choose the chair(s) for the process improvement efforts than it is how we choose the ADs. I'm not against the idea of an additional AD, and I actually think that the IETF might benefit in several ways from having two ADs for the General area (to provide a co-AD for existing work in that area, as well as helping to handle increased load from this effort). I am against the idea of creating another single-AD area, when we already know that there are some potential problems with the one-AD area that we already have. I don't think that it is important to make the new AD position temporary, as all leadership positions in the IETF may be subject to change based on the output of this effort, all ADs are appointed for a maximum of two years, and the IESG can remove an AD position at any time. So, I think having special rules for this position just introduces unnecessary complication. Margaret From problem-statement-bounces@alvestrand.no Tue May 27 11:35: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 LAA17163 for ; Tue, 27 May 2003 11:35:09 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A924C625A5; Tue, 27 May 2003 17:34:40 +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 F405D623CD for ; Tue, 27 May 2003 17:34:33 +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 h4RFYNk07667; Tue, 27 May 2003 11:34:24 -0400 (EDT) Date: Tue, 27 May 2003 11:34:22 -0400 From: Keith Moore To: Margaret Wasserman Message-Id: <20030527113422.674bf9f4.moore@cs.utk.edu> In-Reply-To: <5.1.0.14.2.20030527103301.04155aa0@mail.windriver.com> References: <3ED31DEB.BFC86836@hursley.ibm.com> <5.1.0.14.2.20030527103301.04155aa0@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 Cc: jeanette@wz-berlin.de Subject: Re: IESG restructuring (Re: Example of the One Liners out ofcontext) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 that the IETF might benefit in several ways from > having two ADs for the General area (to provide a co-AD > for existing work in that area, as well as helping to > handle increased load from this effort). I'd really hate to see IESG take on as anywhere close to as many WGs in the General Area as in other areas... From problem-statement-bounces@alvestrand.no Tue May 27 11:39: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 LAA17310 for ; Tue, 27 May 2003 11:39:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 94233625A5; Tue, 27 May 2003 17:38:31 +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 87D5D623CD for ; Tue, 27 May 2003 17:38:30 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19KgWy-0007La-RG; Tue, 27 May 2003 08:38:28 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 27 May 2003 08:38:28 -0700 To: Scott W Brim References: <9C422444DE99BC46B3AD3C6EAFC9711B032412AD@tayexc13.americas.cpqcorp.net> <14880000.1053978265@askvoll.hjemme.alvestrand.no> <20030526204142.GS2424@sbrim-w2k> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: IESG restructuring (Re: Example of the One Liners out of context) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > I would not have a process director per se -- that feels like too much > permanent infrastructure -- but we do have plenty to do on process. How > about something like NomCom -- let's not have 3000 people arguing > endlessly about process, but let's do have a periodically refreshed > small design team looking at problems, consulting with experienced > IETFers, proposing designs and determining rough consensus. i was not an advocate of the closing of the poised or poisson wg. randy From problem-statement-bounces@alvestrand.no Tue May 27 11:51: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 LAA17772 for ; Tue, 27 May 2003 11:51:30 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9DE0362575; Tue, 27 May 2003 17:51:01 +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 8EB58623CD for ; Tue, 27 May 2003 17:50:54 +0200 (CEST) Message-ID: <008a01c32467$8ca6d100$236015ac@DCLKEMPFTP> From: "James Kempf" To: "Brian E Carpenter" , References: <200305262335.AHQ45292@mira-sjc5-c.cisco.com> <3ED31DEB.BFC86836@hursley.ibm.com> Date: Tue, 27 May 2003 08:49:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: IESG restructuring (Re: Example of the One Liners out ofcontext) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 still in favor of having a limited short term AD-ship for the General Area to handle this. Personally, I'm not so concerned about conflict of interest as about the perception of conflict of interest which some seem to have. Also, one of the concerns expressed has been AD burn out due to too large a work load, and so it does not make sense to me to load Harald down with this and thereby potentially contribute to that problem. My understanding from previous email is that there is precedent for such an AD-ship, in the Standards Management AD from 1990-1991. Finally, I think it should be strictly limited in duration, designed to sunset within a year at most, so we don't end up with the kind of standards management bureaucracy that Randy has identified as a problem with other standarization groups. jak ----- Original Message ----- From: "Brian E Carpenter" To: Sent: Tuesday, May 27, 2003 1:12 AM Subject: Re: IESG restructuring (Re: Example of the One Liners out ofcontext) > Melinda Shore wrote: > > > > > if we are serious about this discussion having a process director is a = > > > very bad idea is my input. The IETF chair does this job. Lets not add = > > > more heads to the process to solve problems. > > > > The root issue here was conflict-of-interest avoidance, > > which is something that hasn't been discussed much yet. Are > > people feeling that we're okay on that? > > Conflict of interest is simply unavoidable. I could probably list > ten conflicts of interest that apply to me this morning. * > > The issue is how to prevent conflicts of interest from tilting > the metaphorical level playing field, and the best answer we have > in general is to put checks and balances, and appeals mechanisms, > in place. > > If the existing General AD handles the reform process, there will be > one set of conflicts. If another AD is added to handle it, there will > be another set of conflicts. Choose your poison. > > Brian > > * > 1. I have a colleague in the IESG > 2. I have a colleague in the IAB > 3. The IETF Chair works for a company that has a strategic relationship with > my employer. > 4. I am an ISOC Trustee > 5. I am a former member and chair of the IAB, hence part of the charmed circle > 6. I drafted the current IAB charter > 7. I am involved in the Global Grid Forum, an overlapping standards body > 8. I have colleagues heavily involved in W3C, an overlapping standards body > 9. I am co-author of a draft currently under IESG review > 10.My former WG was really, really slow to complete its charter > From problem-statement-bounces@alvestrand.no Tue May 27 12:35: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 MAA19076 for ; Tue, 27 May 2003 12:35:30 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 88B5D623CD; Tue, 27 May 2003 18:35:01 +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 270A16230A for ; Tue, 27 May 2003 18:34:58 +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 h4RGYtAV015983 for ; Tue, 27 May 2003 09:34:55 -0700 (PDT) Received: from cisco.com (sjc-vpn2-500.cisco.com [10.21.113.244]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AGM68465; Tue, 27 May 2003 09:27:49 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Tue, 27 May 2003 12:34:53 -0400 Date: Tue, 27 May 2003 12:34:53 -0400 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030527163453.GF2424@sbrim-w2k> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: <9C422444DE99BC46B3AD3C6EAFC9711B032412AD@tayexc13.americas.cpqcorp.net> <14880000.1053978265@askvoll.hjemme.alvestrand.no> <20030526204142.GS2424@sbrim-w2k> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Subject: Re: IESG restructuring (Re: Example of the One Liners out of context) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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, May 27, 2003 08:38:28AM -0700, Randy Bush allegedly wrote: > > I would not have a process director per se -- that feels like too much > > permanent infrastructure -- but we do have plenty to do on process. How > > about something like NomCom -- let's not have 3000 people arguing > > endlessly about process, but let's do have a periodically refreshed > > small design team looking at problems, consulting with experienced > > IETFers, proposing designs and determining rough consensus. > > i was not an advocate of the closing of the poised or poisson wg. But don't let it get entrenched and stuck in its ways (part of the problem) either, hence "something like NomCom". From problem-statement-bounces@alvestrand.no Tue May 27 15:40: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 PAA28054 for ; Tue, 27 May 2003 15:40:49 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 260DC6238A; Tue, 27 May 2003 21:40: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 314F2621B8; Tue, 27 May 2003 21:40:15 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19KkIw-000Adr-00; Tue, 27 May 2003 14:40:14 -0500 Date: Tue, 27 May 2003 15:40:02 -0400 From: John C Klensin To: Harald Tveit Alvestrand Message-ID: <5199987.1054050002@p3.JCK.COM> In-Reply-To: <50520000.1054018474@askvoll.hjemme.alvestrand.no> References: <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> <4318516885.20030522200444@brandenburg.com> <20030522234140.3387e2e0.moore@cs.utk.edu> <1815027409.20030522220356@brandenburg.com> <20030523011235.7478d87f.moore@cs.utk.edu> <118612545.1053705221@p3.JCK.COM> <128024980.1053714634@p3.JCK.COM> <134395019.1053721004@p3.JCK.COM> <50520000.1054018474@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: Problem: Resolution mechanisms for when working group consensusreal 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 --On Tuesday, 27 May, 2003 08:54 +0200 Harald Tveit Alvestrand wrote: > --On fredag, mai 23, 2003 20:16:44 -0400 John C Klensin > wrote: > >> I don't know that I've mentioned it on this list (probably >> haven't, and it intrudes into the "solution" space a bit >> anyway), but I've had periodic thoughts that it would be a >> good idea to have ADs "invite" particularly interesting >> and/or problematic WGs to present their problem definition, >> work in progress, ideas, and plans at a plenary, and then >> take questions, etc. This would act as a way to bring the >> whole community in on questions of relevance and relationship >> to the overall architecture and operation of the Internet. >> Both the audience and the WG participants might learn a lot. >> And while "contemplate process changes", "whine at the IESG" >> and "whine at the IAB" have an important place, injecting >> some community-wide _technical_ review and discussion back >> into the environment might be really helpful and interesting. > > I'm a little bit worried..... not that I don't recognize any > number of instances of the scenario above, but there are other > instances..... > > my counterexample is an example of something that is totally > irrelevant to the Internet architecture per se, but has proved > useful to a sharply limited community, has (as far as I can > tell) not had any really bad effects on the architecture, and > the only time the managing AD had to do some management was in > order to insist that they should have some security (and they > delivered!). > > TN3270E - Extending the Telnet protocol to handle IBM 3270 > terminals, or emulators thereof. > > In the current climate of WG creation, we would have a > 1000-message debate on the IETF list in order to take this on > at all. And the debate would actually be more costly in terms > of management time than the running of the activity. >... Hmm. I'm having trouble understanding what this has to do with my suggestion. I didn't contemplate any discussion on the IETF list. I didn't contemplate doing anything before a WG is chartered or, in general, given a work item. And, since there clearly is not enough plenary time (even if we expanded it) to get presentations from every WG, I indicated that ADs would need to choose useful candidates. So let me restate what I had in mind (since I obviously wasn't clear when I discussed this with you after some plenary a while back either). We have some WGs that raise important architectural and/or cross-area issues. We also have WGs which are doing things that might set important precedents for other work, or which are headed in a different direction than prior work, but which trends are not precisely "architectural". Often, but not always, those WGs know who they are. Often, I hope "almost always", the relevant ADs know which WGs these are. When one of these looms large enough on the radar, the AD gets to say "you just won the jackpot and get plenary time to explain what you are doing and where you are headed". The WG presents its work, the community gets a chance to ask questions and challenge assumptions. If things go well --which, I presume, would have a lot to do with the WG's clarity of thinking and degree of preparation-- then everyone learns something, the WG may get some mid-course calibration, and the sorts of surprises that now tend to show up as violent protests during Last Call get headed off. If things go seriously badly -- if, e.g., the community concludes that the WG is doing silly things and ignoring important operational or architectural principles -- we have what I referred to about as a public flogging. Not pleasant, but, by the time it is over, there would be no uncertainty as to whether unhappiness with the WG's approach represented some sort of community consensus or was just the idiosyncratic position of an unhappy AD. While I would hope ADs would be responsive to community input on what ought to be reviewed, I would assume that, if we had a WG that was doing important work that was of interest to a small community and whose impact was confined to that community (like TN3270x), it would not be a good candidate for this sort of presentation. Ok, so they don't make one... no harm done. john From problem-statement-bounces@alvestrand.no Tue May 27 17:23: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 RAA03050 for ; Tue, 27 May 2003 17:23:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CD9A462206; Tue, 27 May 2003 23:22:33 +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 BB459621B8 for ; Tue, 27 May 2003 23:22:25 +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 C2D8C80F3; Tue, 27 May 2003 17:22: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); Tue, 27 May 2003 17:22: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: Tue, 27 May 2003 17:22:23 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042845E5@tayexc13.americas.cpqcorp.net> Thread-Topic: IESG restructuring (Re: Example of the One Liners out ofcontext) Thread-Index: AcMkaCgxGqgdF+ujTwGLDGIiLhaVbwALcBgA From: "Bound, Jim" To: "James Kempf" , "Brian E Carpenter" , X-OriginalArrivalTime: 27 May 2003 21:22:24.0485 (UTC) FILETIME=[10F76950:01C32496] Subject: RE: IESG restructuring (Re: Example of the One Liners out ofcontext) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 RAA03050 I am no thinking that we need ISOC to play a role in the issues of process and fairness more to create the balance. Not technical appeals but if one believes the process was broken or something that is question/perception regarding conflict of Interest. /jim > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Tuesday, May 27, 2003 11:49 AM > To: Brian E Carpenter; problem-statement@alvestrand.no > Subject: Re: IESG restructuring (Re: Example of the One > Liners out ofcontext) > > > I'm still in favor of having a limited short term AD-ship for > the General Area to handle this. Personally, I'm not so > concerned about conflict of interest as about the perception > of conflict of interest which some seem to have. Also, one of > the concerns expressed has been AD burn out due to too large > a work load, and so it does not make sense to me to load > Harald down with this and thereby potentially contribute to > that problem. My understanding from previous email is that > there is precedent for such an AD-ship, in the Standards > Management AD from 1990-1991. Finally, I think it should be > strictly limited in duration, designed to sunset within a > year at most, so we don't end up with the kind of standards > management bureaucracy that Randy has identified as a problem > with other standarization groups. > > jak > > ----- Original Message ----- > From: "Brian E Carpenter" > To: > Sent: Tuesday, May 27, 2003 1:12 AM > Subject: Re: IESG restructuring (Re: Example of the One Liners out > ofcontext) > > > > Melinda Shore wrote: > > > > > > > if we are serious about this discussion having a process > director is a = > > > > very bad idea is my input. The IETF chair does this job. Lets > not add = > > > > more heads to the process to solve problems. > > > > > > The root issue here was conflict-of-interest avoidance, which is > > > something that hasn't been discussed much yet. Are > people feeling > > > that we're okay on that? > > > > Conflict of interest is simply unavoidable. I could > probably list ten > > conflicts of interest that apply to me this morning. * > > > > The issue is how to prevent conflicts of interest from tilting the > > metaphorical level playing field, and the best answer we have in > > general is to put checks and balances, and appeals mechanisms, in > > place. > > > > If the existing General AD handles the reform process, > there will be > > one set of conflicts. If another AD is added to handle it, there > will > > be another set of conflicts. Choose your poison. > > > > Brian > > > > * > > 1. I have a colleague in the IESG > > 2. I have a colleague in the IAB > > 3. The IETF Chair works for a company that has a strategic > relationship with > > my employer. > > 4. I am an ISOC Trustee > > 5. I am a former member and chair of the IAB, hence part of the > charmed circle > > 6. I drafted the current IAB charter > > 7. I am involved in the Global Grid Forum, an overlapping standards > body > > 8. I have colleagues heavily involved in W3C, an overlapping > standards body > > 9. I am co-author of a draft currently under IESG review > 10.My former > > WG was really, really slow to complete its charter > > > > From problem-statement-bounces@alvestrand.no Tue May 27 18: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 SAA05453 for ; Tue, 27 May 2003 18:12:24 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 772BE6238A; Wed, 28 May 2003 00:11:55 +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 383F8621B8; Wed, 28 May 2003 00:11: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 PAA12531; Tue, 27 May 2003 15:11:48 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4RMBl715906; Tue, 27 May 2003 15:11:47 -0700 X-mProtect: <200305272211> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.150, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNp0Lgi; Tue, 27 May 2003 15:11:43 PDT Message-Id: <4.3.2.7.2.20030527132518.0389cc98@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 May 2003 15:10:41 -0700 To: Harald Tveit Alvestrand From: Bob Hinden In-Reply-To: <610486322.1053714592@localhost> References: <04c701c31ec8$1efb8b40$0300a8c0@DFNJGL21> <5.1.0.14.2.20030515114433.04767ac8@mail.windriver.com> <4517643810.20030516200534@brandenburg.com> <04c701c31ec8$1efb8b40$0300a8c0@DFNJGL21> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: WG Chair Selection (in general) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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, >One thing I'm afraid of, though, is the degree to which the WG chair >selection can be a tool of "corporate gameplaying". >When an AD is the sole judge of which candidate is best for a position, >he/she can (and has been!) accused of picking the person based on personal >or company bias; this is hard to defend against, and the accusation, if >made, can be quite harmful to the cooperation climate of a working group - >one risks the AD going into "reverse discrimination mode" and seeking >candidates that are obviously unaffiliated, even if they are not the best >people available. Part of protecting against perceptions of company bias is to make sure that company affiliations are public. I noticed that we no longer list company affiliations on the IESG and IAB member pages. This makes it hard to tell some of the IAB and IESG members company affiliation. For example looking at the email address of the IESG and IAB, one might conclude that we have people affiliated with: 2 ATT 1 Cisco 1 Docomo 1 Hactrn 1 Hotmail 2 IBM 1 ICIR 1 IETF 1 IIJ 1 Lucent 1 Mindspring 1 Mrochek 1 Neustar 3 PSG 1 Qualcomm 1 RTFM 1 Sun 1 Telstra 1 Thinkingcat 1 UCL 1 Vigilsec But doing some research (RFCs, IDs, google, etc.) the following list is generated: 1 Alcatel 2 ATT 2 Cisco 1 Docomo 1 Hactrn 2 IBM 1 ICIR 2 IIJ 2 Lucent 1 Microsoft 1 Mindspring 1 Mrochek 1 Neustar 1 Qualcomm 1 RTFM 1 Sun 1 Telstra 1 Thinkingcat 1 UCL 1 Vigil Security A bit different. I think it is important to always show the company affiliations of IAB, IESG, Nomcom, working group chairs, and document authors. Having this information be hidden or murkey can give the appearance of "corporate game playing" too. Much better if everything be in the open and transparent. Bob From problem-statement-bounces@alvestrand.no Tue May 27 19:32: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 TAA08869 for ; Tue, 27 May 2003 19:32:14 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0299362206; Wed, 28 May 2003 01:31:45 +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 A353E621B8 for ; Wed, 28 May 2003 01:31:43 +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 h4RNVZk22372; Tue, 27 May 2003 19:31:35 -0400 (EDT) Date: Tue, 27 May 2003 19:31:35 -0400 From: Keith Moore To: "Bound, Jim" Message-Id: <20030527193135.4a0d74f3.moore@cs.utk.edu> In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B042845E5@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B042845E5@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: problem-statement@alvestrand.no Cc: kempf@docomolabs-usa.com Cc: moore@cs.utk.edu Cc: brian@hursley.ibm.com Subject: Re: IESG restructuring (Re: Example of the One Liners out ofcontext) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 no thinking that we need ISOC to play a role in the issues of > process and fairness more to create the balance. Not technical > appeals but if one believes the process was broken or something that > is question/perception regarding conflict of Interest. I guess I don't see how this would help. As far as I can tell, people don't trust the IESG because (a) because IESG sometimes pushes back on working groups (yes, this is their job) and (b) people frequently don't understand why IESG is doing this. ISOC isn't going to help either of those. We need to find ways to make the pushback less frequent, which generally means (a) improving the quality of WG output and(b) making IESG in general, and the criteria for acceptance of standards in particular, more transparent. We do not need to make the system more complicated by introducing yet another player. After all, ISOC is probably even less well understood by the average IETFer than IESG is. Give them more power and people will become more suspicious of them, too. From problem-statement-bounces@alvestrand.no Wed May 28 00: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 AAA20014 for ; Wed, 28 May 2003 00:39:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7C8E76238A; Wed, 28 May 2003 06:38:59 +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 1064E62206; Wed, 28 May 2003 06:38:52 +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 D9E7ADD58; Wed, 28 May 2003 00:38: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); Wed, 28 May 2003 00:38: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: Wed, 28 May 2003 00:38:50 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04284609@tayexc13.americas.cpqcorp.net> Thread-Topic: OPEN ISSUE: WG Chair Selection (in general) Thread-Index: AcMknQCmMTaN725URAaxbN03E0AYfgANgh8w From: "Bound, Jim" To: "Bob Hinden" , "Harald Tveit Alvestrand" X-OriginalArrivalTime: 28 May 2003 04:38:50.0700 (UTC) FILETIME=[092AB8C0:01C324D3] Cc: problem-statement@alvestrand.no Subject: RE: OPEN ISSUE: WG Chair Selection (in general) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 AAA20014 I agree. /jim > -----Original Message----- > From: Bob Hinden [mailto:hinden@IPRG.nokia.com] > Sent: Tuesday, May 27, 2003 6:11 PM > To: Harald Tveit Alvestrand > Cc: problem-statement@alvestrand.no > Subject: Re: OPEN ISSUE: WG Chair Selection (in general) > > > Harald, > > >One thing I'm afraid of, though, is the degree to which the WG chair > >selection can be a tool of "corporate gameplaying". > >When an AD is the sole judge of which candidate is best for > a position, > >he/she can (and has been!) accused of picking the person > based on personal > >or company bias; this is hard to defend against, and the > accusation, if > >made, can be quite harmful to the cooperation climate of a > working group - > >one risks the AD going into "reverse discrimination mode" > and seeking > >candidates that are obviously unaffiliated, even if they are > not the best > >people available. > > Part of protecting against perceptions of company bias is to > make sure that > company affiliations are public. I noticed that we no longer > list company > affiliations on the IESG and IAB member pages. This makes it > hard to tell > some of the IAB and IESG members company affiliation. For > example looking > at the email address of the IESG and IAB, one might conclude > that we have > people affiliated with: > > 2 ATT > 1 Cisco > 1 Docomo > 1 Hactrn > 1 Hotmail > 2 IBM > 1 ICIR > 1 IETF > 1 IIJ > 1 Lucent > 1 Mindspring > 1 Mrochek > 1 Neustar > 3 PSG > 1 Qualcomm > 1 RTFM > 1 Sun > 1 Telstra > 1 Thinkingcat > 1 UCL > 1 Vigilsec > > But doing some research (RFCs, IDs, google, etc.) the > following list is > generated: > > 1 Alcatel > 2 ATT > 2 Cisco > 1 Docomo > 1 Hactrn > 2 IBM > 1 ICIR > 2 IIJ > 2 Lucent > 1 Microsoft > 1 Mindspring > 1 Mrochek > 1 Neustar > 1 Qualcomm > 1 RTFM > 1 Sun > 1 Telstra > 1 Thinkingcat > 1 UCL > 1 Vigil Security > > A bit different. I think it is important to always show the company > affiliations of IAB, IESG, Nomcom, working group chairs, and document > authors. Having this information be hidden or murkey can give the > appearance of "corporate game playing" too. Much better if > everything be > in the open and transparent. > > Bob > > > From problem-statement-bounces@alvestrand.no Wed May 28 00:42: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 AAA20201 for ; Wed, 28 May 2003 00:42:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EF5F16238A; Wed, 28 May 2003 06:42:07 +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 E6ED562206 for ; Wed, 28 May 2003 06:42:05 +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 3EC78DF74; Wed, 28 May 2003 00:42: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); Wed, 28 May 2003 00:42: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: Wed, 28 May 2003 00:42:04 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0428460A@tayexc13.americas.cpqcorp.net> Thread-Topic: IESG restructuring (Re: Example of the One Liners out ofcontext) Thread-Index: AcMkqCK7Ggqi4UlzQNy0OcNJXS7yaQAKwLqg From: "Bound, Jim" To: "Keith Moore" X-OriginalArrivalTime: 28 May 2003 04:42:05.0046 (UTC) FILETIME=[7D019160:01C324D3] Cc: problem-statement@alvestrand.no Cc: kempf@docomolabs-usa.com Cc: brian@hursley.ibm.com Subject: RE: IESG restructuring (Re: Example of the One Liners out ofcontext) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 AAA20201 Yep valid logic. Oh Well..........I am puzzled. Sounds like chicken or egg again. If we fix all, then all works, if we can't fix all then all breaks and people want to check the process. Both are valid. Are we gettting anywhere here? I don't think so? I am going to go read the drafts again and come back later. Bye. /jim > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Tuesday, May 27, 2003 7:32 PM > To: Bound, Jim > Cc: moore@cs.utk.edu; kempf@docomolabs-usa.com; > brian@hursley.ibm.com; problem-statement@alvestrand.no > Subject: Re: IESG restructuring (Re: Example of the One > Liners out ofcontext) > > > > I am no thinking that we need ISOC to play a role in the issues of > > process and fairness more to create the balance. Not technical > > appeals but if one believes the process was broken or > something that > > is question/perception regarding conflict of Interest. > > I guess I don't see how this would help. As far as I can > tell, people don't trust the IESG because (a) because IESG > sometimes pushes back on working groups (yes, this is their > job) and (b) people frequently don't understand why IESG is > doing this. ISOC isn't going to help either of those. > > We need to find ways to make the pushback less frequent, > which generally means (a) improving the quality of WG output > and(b) making IESG in general, and the criteria for > acceptance of standards in particular, more transparent. We > do not need to make the system more complicated by > introducing yet another player. > > After all, ISOC is probably even less well understood by the > average IETFer than IESG is. Give them more power and people > will become more suspicious of them, too. > > From problem-statement-bounces@alvestrand.no Wed May 28 02:17: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 CAA05640 for ; Wed, 28 May 2003 02:17:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8CB9B6257F; Wed, 28 May 2003 08:16: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 5A8A262206; Wed, 28 May 2003 08:16:46 +0200 (CEST) Date: Wed, 28 May 2003 08:16:46 +0200 From: Harald Tveit Alvestrand To: Bob Hinden Message-ID: <99530000.1054102606@askvoll.hjemme.alvestrand.no> In-Reply-To: <4.3.2.7.2.20030527132518.0389cc98@mailhost.iprg.nokia.com> References: <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> 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: Listing affiliations (Re: OPEN ISSUE: WG Chair Selection (in general)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, mai 27, 2003 15:10:41 -0700 Bob Hinden wrote: > But doing some research (RFCs, IDs, google, etc.) the following list is > generated: > > 1 Alcatel > 2 ATT > 2 Cisco > 1 Docomo > 1 Hactrn > 2 IBM > 1 ICIR > 2 IIJ > 2 Lucent > 1 Microsoft > 1 Mindspring > 1 Mrochek > 1 Neustar > 1 Qualcomm > 1 RTFM > 1 Sun > 1 Telstra > 1 Thinkingcat > 1 UCL > 1 Vigil Security > > A bit different. I think it is important to always show the company > affiliations of IAB, IESG, Nomcom, working group chairs, and document > authors. Having this information be hidden or murkey can give the > appearance of "corporate game playing" too. Much better if everything be > in the open and transparent. good point. especially considering that I know that even after a bit of research, at least 2 and probably more of the affilliations in your table are still wrong! On the other hand, including the corporate information *everywhere* the names get listed seems like overkill, and against our principle of considering the person-as-an-individual (as well as increasing overhead). Where would you suggest we list them? (btw.... I use a non-Cisco email address because the corporate mail system doesn't work well for me, as well as liking the stability - I've had this email through 3 different employers - but the front page of my website tells you where I work....) Harald From problem-statement-bounces@alvestrand.no Wed May 28 04:37: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 EAA21291 for ; Wed, 28 May 2003 04:37:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 27B9F623CD; Wed, 28 May 2003 10:37:00 +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 71C3562206; Wed, 28 May 2003 10:36:53 +0200 (CEST) Date: Wed, 28 May 2003 10:36:53 +0200 From: Harald Tveit Alvestrand To: John C Klensin Message-ID: <112630000.1054111013@askvoll.hjemme.alvestrand.no> In-Reply-To: <5199987.1054050002@p3.JCK.COM> References: <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> <4318516885.20030522200444@brandenburg.com> <20030522234140.3387e2e0.moore@cs.utk.edu> <1815027409.20030522220356@brandenburg.com> <118612545.1053705221@p3.JCK.COM> <128024980.1053714634@p3.JCK.COM> <134395019.1053721004@p3.JCK.COM> <50520000.1054018474@askvoll.hjemme.alvestrand.no> <5199987.1054050002@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: Problem: Resolution mechanisms for when working group consensusreal 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 thanks; I see what you are aiming at now. my worry was probably tangential, but not entirely unrelated - that we could concentrate so much on getting the IETF to concentrate on the important matters with great impact (for good or bad) on the Internet architecture that we forget to allow for the smaller, peripheral things that Just Should Be Done. not that the impact is easy to gauge - see HTTP..... Harald From problem-statement-bounces@alvestrand.no Wed May 28 08:15: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 IAA26983 for ; Wed, 28 May 2003 08:15:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3F36D6238A; Wed, 28 May 2003 14:14:36 +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 A64D662206; Wed, 28 May 2003 14:14:27 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA05276; Wed, 28 May 2003 05:14:10 -0700 (PDT) Message-Id: <5.1.0.14.2.20030528080348.043e4b48@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 28 May 2003 08:06:57 -0400 To: Harald Tveit Alvestrand From: Margaret Wasserman 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: Bob Hinden Subject: Re: Listing affiliations (Re: OPEN ISSUE: WG Chair Selection (in general)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 08:16 AM 5/28/2003 +0200, Harald Tveit Alvestrand wrote: >On the other hand, including the corporate information *everywhere* the >names get listed seems like overkill, and against our principle of >considering the person-as-an-individual (as well as increasing overhead). >Where would you suggest we list them? Perhaps it would make sense to list them on the IETF website where you list the names of the current IESG members: http://www.ietf.org/iesg.html#members I don't think that anyone is actively trying to hide their affiliation, but it can be hard to figure them out... I know that people do work in the IETF as individuals, but all individuals' perspectives _are_ affected by their background/experience and self-interests. Margaret From problem-statement-bounces@alvestrand.no Wed May 28 08:24: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 IAA27517 for ; Wed, 28 May 2003 08:24:35 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B95466238A; Wed, 28 May 2003 14:24: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 357376238A; Wed, 28 May 2003 14:23:40 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19Kzxz-000FCE-00; Wed, 28 May 2003 07:23:39 -0500 Date: Wed, 28 May 2003 08:23:38 -0400 From: John C Klensin To: Harald Tveit Alvestrand Message-ID: <65415752.1054110218@p3.JCK.COM> In-Reply-To: <112630000.1054111013@askvoll.hjemme.alvestrand.no> References: <5.1.0.14.2.20030523095346.00bd9ea0@kahuna.telstra.net> <4318516885.20030522200444@brandenburg.com> <20030522234140.3387e2e0.moore@cs.utk.edu> <1815027409.20030522220356@brandenburg.com> <20030523011235.7478d87f.moore@cs.utk.edu> <118612545.1053705221@p3.JCK.COM> <128024980.1053714634@p3.JCK.COM> <134395019.1053721004@p3.JCK.COM> <50520000.1054018474@askvoll.hjemme.alvestrand.no> <5199987.1054050002@p3.JCK.COM> <112630000.1054111013@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: Problem: Resolution mechanisms for when working group consensusreal 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 --On Wednesday, 28 May, 2003 10:36 +0200 Harald Tveit Alvestrand wrote: > thanks; I see what you are aiming at now. > > my worry was probably tangential, but not entirely unrelated - > that we could concentrate so much on getting the IETF to > concentrate on the important matters with great impact (for > good or bad) on the Internet architecture that we forget to > allow for the smaller, peripheral things that Just Should Be > Done. I think the important point there is that, as with other things, we really need ADs and a functional IESG, to give them considerable discretion, and to avoid trying to micromanage the process from plenaries, mailing lists, or even a whipped-up mob. To keep an appropriate balance, that IESG needs to be open about its actions general directions, and priorities, and those things need to be available in a way that makes them subject to reviw. I think we have been doing relatively well, most of the time, on the "discretion" part, but somewhat less well on the openness, transparancy, and, on the part of a few ADs some of the time, receptiveness to review and community-mandated tuning of direction, strategies, or procedures. > not that the impact is easy to gauge - see HTTP..... indeed. john From problem-statement-bounces@alvestrand.no Wed May 28 10: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 KAA06502 for ; Wed, 28 May 2003 10:39:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CA12362206; Wed, 28 May 2003 16:38:57 +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 386FF62206; Wed, 28 May 2003 16:38:31 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19L24P-000Flc-00; Wed, 28 May 2003 09:38:25 -0500 Date: Wed, 28 May 2003 10:38:25 -0400 From: John C Klensin To: Margaret Wasserman , Harald Tveit Alvestrand Message-ID: <73502320.1054118305@p3.JCK.COM> In-Reply-To: <5.1.0.14.2.20030528080348.043e4b48@mail.windriver.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> <5.1.0.14.2.20030528080348.043e4b48@mail.windriver.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" Cc: Bob Hinden Subject: Re: Listing affiliations (Re: OPEN ISSUE: WG Chair Selection (in general)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, 28 May, 2003 08:06 -0400 Margaret Wasserman wrote: > At 08:16 AM 5/28/2003 +0200, Harald Tveit Alvestrand wrote: >> On the other hand, including the corporate information >> *everywhere* the names get listed seems like overkill, and >> against our principle of considering the >> person-as-an-individual (as well as increasing overhead). >> Where would you suggest we list them? > > Perhaps it would make sense to list them on the IETF website > where you list the names of the current IESG members: > > http://www.ietf.org/iesg.html#members > > I don't think that anyone is actively trying to hide their > affiliation, but it can be hard to figure them out... I > know that people do work in the IETF as individuals, but > all individuals' perspectives _are_ affected by their > background/experience and self-interests. Note that "current organizational affiliation" tells one very little about background and experience, and may not tell much about self-interest. Let me give a personal example... In what might be thought of as different lives, I did considerable work in the penetration and influence of mass media that originated in one country into a different country or set of countries. Separately, I did considerable work on nutritional databases and international interchange of food composition data and on some specific types of architectural image databases. Now, none of that "background and experience" would show up if you asked for my current organizational affiliation, or even for my last few organizational affiliations. But it probably had more influence on my sensitivities, and some of the positions I took, while on the IESG and IAB than any of those organizational affiliations: I learned a lot about the importance of low-tech, low-bandwidth, intermittent connections and that it was undesirable to have only protocols that operate well in resource-rich environments. I learned to think of the Internet as a two-way and multiway communications medium, not just a mechanism for moving bits. I learned a fair amount about internationalization and character sets in practice, not just in laboratory theory. Is knowing that background important? Only, IMO, if people are interested in theorizing about how I'm going to react to something rather than just watching what I do. But that same comment applies to current organizational affiliations alone. If we need to go down this path, then we perhaps ought to bite the bullet, require conflict of interest disclosures from IESG members (and maybe IAB members and ISOC Board members) and post those on web sites. Company affiliations alone are interesting (and shouldn't be a secret), but often don't provide very much information. I'm not convinced that it is really important except to fuel paranoid fantasies. Those with the most serious of those fantasies will always assume that the smoking gun is being hidden, no matter how much disclosure is required and supplied. The reality is that, if we are worried about affiliations as a sign of conflicts of interest, they often don't tell us much. Examples: * Someone with an academic affiliation may have consulting activities, or serve on corporate boards or advisory committees, and may be far more influenced --in ways we would be concerned about-- than by anything having to do with the academic institution. That is especially true because academic institutions are normally extremely hands-off on the outside positions of people with academic or research appointments. But, to complicate things further, people who are part of IT departments that serve universities are, for many institutions, much more like their peers in corporate IT departments with regard to pressures and constraints than they are like anyone with an academic appointment in the same institution. * Some of the companies that support IETF work take a strongly "hands off" view of IETF participation by some, or all, of their employees who participate. In them, the expectation of IETF participants is, at most, trip reports to keep others in the company informed as to what the IETF is doing that might be relevant (in the participant's area of interest/involvement or otherwise). In other companies, and sometimes in other divisions or with other people in the same company, there is at least an attempt at fairly tight management of what people do and say in the IETF. To untangle this, one would need to know, not only "which company", but a good deal about internal company policies, divisional structures, and, sometimes, individual employment agreements. * Some of the companies who support IETF work are fairly large and complex. As a trivial and obvious example, we usually think of Cisco as a "router company" with certain interests, but I imagine there are people who work for Cisco who go for very long periods in their day jobs without ever having a conversation about routing or talking with anyone who actually works on a router. And some companies have research departments that are deliberately isolated from product groups and vice versa -- a product group seeking to influence a researcher's IETF actions would have a lot of trouble finding the researcher and would be violating corporate policies by trying to exert any influence. Other companies have the split, but the relationships are considerably different. And these things sometimes change over time -- two-year-old information about company structure and relationships may be obsolete and misleading. * Whether as a primary job or a secondary one, if someone is carrying on a consulting business, it may be important to know who the clients are, and exactly what they think they are paying for, in order to judge conflicts of interest. Many consultants are far more subject to pressures from important paying customers than the typical large-company employee is to internal-to-the-company pressures, if only because of corporate inertia. A comprehensive conflict of interest statement requirement might tease these distinctions out in enough detail to be useful. It might also reduce the pool of people willing to serve on the IESG: Preparation of such statements can be onerous and unpleasant, even (especially when someone has nothing to hide but wants to comply with the spirit of things and disclose all entanglements. Worse, many companies (and consulting clients) insist that some or all of departmental structures, employment agreements, reporting relationships, projects and even areas of work are valuable corporate trade secrets. If those rules conflict with IESG service, it is likely that at least some otherwise-qualified and reasonable people will decline to serve on, or be considered for, the IESG. We might even see resignations if IESG members chose to take jobs with those companies. That is a fairly high price for the IETF to pay, given the comments/ complaints we have had already sbout the small size of the credible volunteer pool. So, sure, let's be sure we get organizational affiliations and list them on a web page somewhere. It can't hurt, and may help us notice if "too much" of the leadership is shifting into a single business sector or single company... which could be issues in and of themselves. But let's try to be very clear that there is much less information in such listings than some people might like to read into them. john From problem-statement-bounces@alvestrand.no Wed May 28 10:41: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 KAA06627 for ; Wed, 28 May 2003 10:41:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6830B6257F; Wed, 28 May 2003 16:41:27 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from gamma.jnpr.net (natint.juniper.net [207.17.136.129]) by eikenes.alvestrand.no (Postfix) with ESMTP id 325A462206 for ; Wed, 28 May 2003 16:41:25 +0200 (CEST) Received: from pi-smtp.jnpr.net ([10.10.2.36]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 28 May 2003 07:41:22 -0700 Received: from ophelia.jnpr.net ([10.10.2.95]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.5329); Wed, 28 May 2003 10:41:20 -0400 Received: from fkastenholzpc1.juniper.net ([10.10.132.71]) by ophelia.jnpr.net with Microsoft SMTPSVC(5.0.2195.5329); Wed, 28 May 2003 10:41:20 -0400 Message-Id: <5.1.1.5.2.20030528102714.02b1e630@pi> X-Sender: fkastenholz@pi X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 28 May 2003 10:31:22 -0400 To: problem-statement@alvestrand.no From: Frank Kastenholz In-Reply-To: References: <89860000.1053939264@askvoll.hjemme.alvestrand.no> <1861252390.20030526075823@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 28 May 2003 14:41:20.0257 (UTC) FILETIME=[33FB5F10:01C32527] Subject: Re: Can we learn something from IETF history? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 12:28 PM 5/26/2003 -0700, Randy Bush wrote: >> The original work was done far less formally, with hallway conversations >> as the means for floating ideas and exploring reactions > >isn't this what some seem to call a closed conspiracy today? We might call it that today but that is not what it was then. One simply needed to go up to the microphone during an IESG plenary and ask a pointed question... Or ask Phill Gross for 5 minutes to present an alternate idea. So maybe it was closed -- closed to those people who lacked motivation and/or coherency... F From problem-statement-bounces@alvestrand.no Wed May 28 11:28: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 LAA08362 for ; Wed, 28 May 2003 11:28:49 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3229A62581; Wed, 28 May 2003 17:28:19 +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 2E5A362206; Wed, 28 May 2003 17:28:15 +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 IAA27597; Wed, 28 May 2003 08:28:14 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4SFSDx16435; Wed, 28 May 2003 08:28:13 -0700 X-mProtect: <200305281528> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.150, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdV2xRmj; Wed, 28 May 2003 08:28:10 PDT Message-Id: <4.3.2.7.2.20030528080820.02c8d868@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 28 May 2003 08:24:44 -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 Subject: Re: Listing affiliations (Re: OPEN ISSUE: WG Chair Selection (in general)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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, At 11:16 PM 5/27/2003, Harald Tveit Alvestrand wrote: >>A bit different. I think it is important to always show the company >>affiliations of IAB, IESG, Nomcom, working group chairs, and document >>authors. Having this information be hidden or murkey can give the >>appearance of "corporate game playing" too. Much better if everything be >>in the open and transparent. > >good point. especially considering that I know that even after a bit of >research, at least 2 and probably more of the affilliations in your table >are still wrong! Right, my point exactly. It shouldn't be a mystery or require research. >On the other hand, including the corporate information *everywhere* the >names get listed seems like overkill, and against our principle of >considering the person-as-an-individual (as well as increasing overhead). >Where would you suggest we list them? On the IAB and IESG member pages, in the nomcom announcements (members and selections), and on working group charter pages (for w.g. chairs). I think that would be fine and we don't need to go any further. >(btw.... I use a non-Cisco email address because the corporate mail system >doesn't work well for me, as well as liking the stability - I've had this >email through 3 different employers - but the front page of my website >tells you where I work....) It's a fairly common problem these days. Many people in the IETF have their IETF roles continue while they change employers multiple times and/or have corporate email systems that are less than ideal. Thanks, Bob From problem-statement-bounces@alvestrand.no Wed May 28 11:37: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 LAA08829 for ; Wed, 28 May 2003 11:37:00 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8D806623CD; Wed, 28 May 2003 17:36:30 +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 BC3EA62206; Wed, 28 May 2003 17:36:22 +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 IAA27881; Wed, 28 May 2003 08:36:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4SFaLJ22428; Wed, 28 May 2003 08:36:21 -0700 X-mProtect: <200305281536> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.150, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdF0E50A; Wed, 28 May 2003 08:36:18 PDT Message-Id: <4.3.2.7.2.20030528083013.02c8d868@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 28 May 2003 08:35:17 -0700 To: Margaret Wasserman From: Bob Hinden In-Reply-To: <5.1.0.14.2.20030528080348.043e4b48@mail.windriver.com> References: <99530000.1054102606@askvoll.hjemme.alvestrand.no> <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 Subject: Re: Listing affiliations (Re: OPEN ISSUE: WG Chair Selection (in general)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Margaret, >I don't think that anyone is actively trying to hide their >affiliation, but it can be hard to figure them out... I >know that people do work in the IETF as individuals, but >all individuals' perspectives _are_ affected by their >background/experience and self-interests. I agree. It's part of making all of the IETF's operation open and transparent. Bob From problem-statement-bounces@alvestrand.no Wed May 28 12:02: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 MAA10050 for ; Wed, 28 May 2003 12:02:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B41C3623CD; Wed, 28 May 2003 18:02:15 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mta3.wss.scd.yahoo.com (mta3.wss.scd.yahoo.com [66.218.85.34]) by eikenes.alvestrand.no (Postfix) with ESMTP id B6A8062206; Wed, 28 May 2003 18:02:02 +0200 (CEST) Received: from AwducheHPlapt (68.100.145.226) by mta3.wss.scd.yahoo.com (7.0.016) (authenticated as awduche@awduche.com) id 3ED3A8380006E08A; Wed, 28 May 2003 09:02:01 -0700 From: "Daniel O. Awduche" To: "'John C Klensin'" , "'Margaret Wasserman'" , "'Harald Tveit Alvestrand'" Date: Wed, 28 May 2003 12:01:29 -0400 Message-ID: <008701c32532$673e6240$e2916444@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: <73502320.1054118305@p3.JCK.COM> Cc: problem-statement@alvestrand.no Cc: "'Bob Hinden'" Subject: RE: Listing affiliations (Re: OPEN ISSUE: WG Chair Selection (in general)) 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 John, These are all very good points. Overall, aside from current affiliations, I think it would be appropriate and beneficial to display a one paragraph bio of each IESG and IAB member on the respective websites. Cheers, /Dan -----Original Message----- From: problem-statement-bounces@alvestrand.no [mailto:problem-statement-bounces@alvestrand.no] On Behalf Of John C Klensin Sent: Wednesday, May 28, 2003 10:38 AM To: Margaret Wasserman; Harald Tveit Alvestrand Cc: problem-statement@alvestrand.no; Bob Hinden Subject: Re: Listing affiliations (Re: OPEN ISSUE: WG Chair Selection (in general)) Note that "current organizational affiliation" tells one very little about background and experience, and may not tell much about self-interest. Let me give a personal example... In what might be thought of as different lives, I did considerable work in the penetration and influence of mass media that originated in one country into a different country or set of countries. Separately, I did considerable work on nutritional databases and international interchange of food composition data and on some specific types of architectural image databases. Now, none of that "background and experience" would show up if you asked for my current organizational affiliation, or even for my last few organizational affiliations. But it probably had more influence on my sensitivities, and some of the positions I took, while on the IESG and IAB than any of those organizational affiliations: I learned a lot about the importance of low-tech, low-bandwidth, intermittent connections and that it was undesirable to have only protocols that operate well in resource-rich environments. I learned to think of the Internet as a two-way and multiway communications medium, not just a mechanism for moving bits. I learned a fair amount about internationalization and character sets in practice, not just in laboratory theory. Is knowing that background important? Only, IMO, if people are interested in theorizing about how I'm going to react to something rather than just watching what I do. But that same comment applies to current organizational affiliations alone. If we need to go down this path, then we perhaps ought to bite the bullet, require conflict of interest disclosures from IESG members (and maybe IAB members and ISOC Board members) and post those on web sites. Company affiliations alone are interesting (and shouldn't be a secret), but often don't provide very much information. I'm not convinced that it is really important except to fuel paranoid fantasies. Those with the most serious of those fantasies will always assume that the smoking gun is being hidden, no matter how much disclosure is required and supplied. The reality is that, if we are worried about affiliations as a sign of conflicts of interest, they often don't tell us much. Examples: * Someone with an academic affiliation may have consulting activities, or serve on corporate boards or advisory committees, and may be far more influenced --in ways we would be concerned about-- than by anything having to do with the academic institution. That is especially true because academic institutions are normally extremely hands-off on the outside positions of people with academic or research appointments. But, to complicate things further, people who are part of IT departments that serve universities are, for many institutions, much more like their peers in corporate IT departments with regard to pressures and constraints than they are like anyone with an academic appointment in the same institution. * Some of the companies that support IETF work take a strongly "hands off" view of IETF participation by some, or all, of their employees who participate. In them, the expectation of IETF participants is, at most, trip reports to keep others in the company informed as to what the IETF is doing that might be relevant (in the participant's area of interest/involvement or otherwise). In other companies, and sometimes in other divisions or with other people in the same company, there is at least an attempt at fairly tight management of what people do and say in the IETF. To untangle this, one would need to know, not only "which company", but a good deal about internal company policies, divisional structures, and, sometimes, individual employment agreements. * Some of the companies who support IETF work are fairly large and complex. As a trivial and obvious example, we usually think of Cisco as a "router company" with certain interests, but I imagine there are people who work for Cisco who go for very long periods in their day jobs without ever having a conversation about routing or talking with anyone who actually works on a router. And some companies have research departments that are deliberately isolated from product groups and vice versa -- a product group seeking to influence a researcher's IETF actions would have a lot of trouble finding the researcher and would be violating corporate policies by trying to exert any influence. Other companies have the split, but the relationships are considerably different. And these things sometimes change over time -- two-year-old information about company structure and relationships may be obsolete and misleading. * Whether as a primary job or a secondary one, if someone is carrying on a consulting business, it may be important to know who the clients are, and exactly what they think they are paying for, in order to judge conflicts of interest. Many consultants are far more subject to pressures from important paying customers than the typical large-company employee is to internal-to-the-company pressures, if only because of corporate inertia. A comprehensive conflict of interest statement requirement might tease these distinctions out in enough detail to be useful. It might also reduce the pool of people willing to serve on the IESG: Preparation of such statements can be onerous and unpleasant, even (especially when someone has nothing to hide but wants to comply with the spirit of things and disclose all entanglements. Worse, many companies (and consulting clients) insist that some or all of departmental structures, employment agreements, reporting relationships, projects and even areas of work are valuable corporate trade secrets. If those rules conflict with IESG service, it is likely that at least some otherwise-qualified and reasonable people will decline to serve on, or be considered for, the IESG. We might even see resignations if IESG members chose to take jobs with those companies. That is a fairly high price for the IETF to pay, given the comments/ complaints we have had already sbout the small size of the credible volunteer pool. So, sure, let's be sure we get organizational affiliations and list them on a web page somewhere. It can't hurt, and may help us notice if "too much" of the leadership is shifting into a single business sector or single company... which could be issues in and of themselves. But let's try to be very clear that there is much less information in such listings than some people might like to read into them. john From problem-statement-bounces@alvestrand.no Wed May 28 12:35: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 MAA11248 for ; Wed, 28 May 2003 12:35:25 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C251962581; Wed, 28 May 2003 18:34:55 +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 414F362206 for ; Wed, 28 May 2003 18:34:46 +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 h4SGbUi10121; Wed, 28 May 2003 09:37:30 -0700 Date: Wed, 28 May 2003 09:28:35 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1453120286.20030528092835@brandenburg.com> To: "Daniel O. Awduche" In-Reply-To: <008701c32532$673e6240$e2916444@awduche.com> References: <008701c32532$673e6240$e2916444@awduche.com> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Listing affiliations (Re: OPEN ISSUE: WG Chair Selection (in general)) 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 Daniel, DOA> These are all very good points. Overall, aside from DOA> current affiliations, I think it would be appropriate DOA> and beneficial to display a one paragraph bio of each DOA> IESG and IAB member on the respective websites. Good suggested. It should also be reasonably easy and reasonably helpful to have a pointer to the person's resume. That is, their extended biography. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Wed May 28 12:39: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 MAA11364 for ; Wed, 28 May 2003 12:39:18 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DEB87623CD; Wed, 28 May 2003 18:38: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 EB2A962206 for ; Wed, 28 May 2003 18:38:46 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19L3wo-000GHt-00; Wed, 28 May 2003 11:38:42 -0500 Date: Wed, 28 May 2003 12:38:42 -0400 From: John C Klensin To: "awduche@awduche.com" Message-ID: <80718877.1054125522@p3.JCK.COM> In-Reply-To: <008701c32532$673e6240$e2916444@awduche.com> References: <008701c32532$673e6240$e2916444@awduche.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: Listing affiliations (Re: OPEN ISSUE: WG Chair Selection (in general)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, 28 May, 2003 12:01 -0400 "Daniel O. Awduche" wrote: > John, > > These are all very good points. Overall, aside from > current affiliations, I think it would be appropriate > and beneficial to display a one paragraph bio of each > IESG and IAB member on the respective websites. Much as I find myself slipping into avoidance behavior --typically of the form of "what can I think of that absolutely has to be done first"-- every time someone says "would you please boil your career/ life down into one paragraph and put it in this box", I think very short bio sketches would be useful additions to affiliation information. Note that we used to publish such bios -- see RFCs 1251 and 1336 -- but stopped. I don't remember why we stopped, but assume it might have had to do with the change in tone and (expected) increased turnover rate that occurred around the time 1336 was published. Or Gary may have just run out of energy. Gary -- you listening and care to comment? john From problem-statement-bounces@alvestrand.no Wed May 28 12: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 MAA11478 for ; Wed, 28 May 2003 12:42:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BB0D7623CD; Wed, 28 May 2003 18:42:07 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from seraph2.grc.nasa.gov (seraph2.grc.nasa.gov [128.156.10.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED4B562206 for ; Wed, 28 May 2003 18:42:05 +0200 (CEST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 6DDC768A13 for ; Wed, 28 May 2003 12:42:04 -0400 (EDT) Received: from guns.lerc.nasa.gov (guns.grc.nasa.gov [139.88.122.88]) h4SGg4uW005448 for ; Wed, 28 May 2003 12:42:04 -0400 (EDT) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id MAA84054; Wed, 28 May 2003 12:42:03 -0400 (EDT) Message-Id: <200305281642.MAA84054@guns.lerc.nasa.gov> To: problem-statement@alvestrand.no From: Mark Allman In-Reply-To: <73502320.1054118305@p3.JCK.COM> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Layla Date: Wed, 28 May 2003 12:42:03 -0400 Subject: Re: Listing affiliations (Re: OPEN ISSUE: WG ChairSelection (in general)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mallman@grc.nasa.gov List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no (Appologies to John... it isn't just you... you're just the straw to my camel today...) Harald Tveit Alvestrand wrote: >> On the other hand, including the corporate information >> *everywhere* the names get listed seems like overkill, and >> against our principle of considering the >> person-as-an-individual (as well as increasing overhead). >> Where would you suggest we list them? Margaret Wasserman wrote: > Perhaps it would make sense to list them on the IETF website > where you list the names of the current IESG members: > > http://www.ietf.org/iesg.html#members > > I don't think that anyone is actively trying to hide their > affiliation, but it can be hard to figure them out... I > know that people do work in the IETF as individuals, but > all individuals' perspectives _are_ affected by their > background/experience and self-interests. John Klensin started: > Note that "current organizational affiliation" tells one very > little about background and experience, and may not tell much > about self-interest. ***1000+ damn words to basically agree***?!?! I thought this list was for discussing the **core problems** with the IETF?! I must be lost .... I tried to be part of the problems@ and solutions@ at the same time. But, my former coach was right... "if you're not part of the solution"... So, see y'all on the other list. I'll hope for better discussion. Ugh. allman my attempt at being L. frankly, L.'s much better at it. -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ From problem-statement-bounces@alvestrand.no Wed May 28 15:58: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 PAA20786 for ; Wed, 28 May 2003 15:58:50 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 235B362581; Wed, 28 May 2003 21:58: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 C7FD8623CD; Wed, 28 May 2003 21:58:16 +0200 (CEST) Date: Wed, 28 May 2003 21:58:17 +0200 From: Harald Tveit Alvestrand To: EKR Message-ID: <16500000.1054151897@askvoll.hjemme.alvestrand.no> In-Reply-To: References: <9C422444DE99BC46B3AD3C6EAFC9711B032412AD@tayexc13.americas.cpqco rp.net> <14880000.1053978265@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 Cc: Randy Bush Cc: problem-statement@alvestrand.no Subject: Re: IESG restructuring (Re: Example of the One Liners out of context) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, mai 26, 2003 13:35:46 -0700 Eric Rescorla wrote: > Harald Tveit Alvestrand writes: > >> what do other people think here? > Maybe I've misunderstood Randy, but "real work vs. politics" > strikes me as a false opposition. Getting real work done in > organizations with more than a few people who have divergent > goals is an inherently political activity. Sure, that sort > of politics can be conducted in a more or less civilized > manner, but I don't think it's really avoidable. I think we may have a language problem on our hands..... to me, the unique feature that attracted me to engineering is the fact that when an engineer has done his/her work well, the value of the result is greater than the value of what we started with. In the IETF, this translates to "standards are beneficial to everybody". I think "politics" derives from "polis" - city? - it's what humans do when they get together in large groups. But what an engineer who says he "hates politics" means is, I think, more often related to an image of "politics" where the underlying logic is that of splitting a fixed-size pie; in order to win, I have to make someone else lose; if someone else benefits, it means that I have less. I think that's not the kind of politics we want to play. But that's not the only form of politics there is. Harald From problem-statement-bounces@alvestrand.no Wed May 28 16:28: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 QAA22241 for ; Wed, 28 May 2003 16:28:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9E2766238F; Wed, 28 May 2003 22:27:40 +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 AF6976233E; Wed, 28 May 2003 22:27:37 +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 h4SKRWk14691; Wed, 28 May 2003 16:27:34 -0400 (EDT) Date: Wed, 28 May 2003 16:27:31 -0400 From: Keith Moore To: Harald Tveit Alvestrand Message-Id: <20030528162731.60443218.moore@cs.utk.edu> In-Reply-To: <16500000.1054151897@askvoll.hjemme.alvestrand.no> References: <9C422444DE99BC46B3AD3C6EAFC9711B032412AD@tayexc13.americas.cpqco rp.net> <14880000.1053978265@askvoll.hjemme.alvestrand.no> <16500000.1054151897@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: randy@psg.com Cc: problem-statement@alvestrand.no Cc: ekr@rtfm.com Cc: moore@cs.utk.edu Subject: Re: IESG restructuring (Re: Example of the One Liners out of context) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 what an engineer who says he "hates politics" means is, I think, > more often related to an image of "politics" where the underlying > logic is that of splitting a fixed-size pie; in order to win, I have > to make someone else lose; if someone else benefits, it means that I > have less. I've always thought of engineers' hatred of politics as a distaste for some of the practices considered necessary in political activity in order to accomplish what needs to be done -- such as pretending that things are different than they really are in order to avoid offending some powerful person or group, or manipulation of people and groups using power, coercion, propaganda, ego-stroking, etc. None of which means that you can't end up with a win-win situation, but the dishonesty inherent in such practices makes it difficult to see what a win-win situation might look like. From problem-statement-bounces@alvestrand.no Wed May 28 17:04: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 RAA23933 for ; Wed, 28 May 2003 17:04:27 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 90FE66238F; Wed, 28 May 2003 23:03:56 +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 DE7226233E; Wed, 28 May 2003 23:03:51 +0200 (CEST) Received: by romeo.rtfm.com (Postfix, from userid 556) id 37438ABA6; Wed, 28 May 2003 14:09:47 -0700 (PDT) To: Harald Tveit Alvestrand References: <9C422444DE99BC46B3AD3C6EAFC9711B032412AD@tayexc13.americas.cpqco rp.net> <14880000.1053978265@askvoll.hjemme.alvestrand.no> <16500000.1054151897@askvoll.hjemme.alvestrand.no> From: Eric Rescorla Date: 28 May 2003 14:09:46 -0700 In-Reply-To: <16500000.1054151897@askvoll.hjemme.alvestrand.no> Message-ID: Lines: 87 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: Randy Bush Cc: problem-statement@alvestrand.no Subject: Re: IESG restructuring (Re: Example of the One Liners out of context) 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 Harald Tveit Alvestrand writes: > --On mandag, mai 26, 2003 13:35:46 -0700 Eric Rescorla wrote: > > > Harald Tveit Alvestrand writes: > > > >> what do other people think here? > > Maybe I've misunderstood Randy, but "real work vs. politics" > > strikes me as a false opposition. Getting real work done in > > organizations with more than a few people who have divergent > > goals is an inherently political activity. Sure, that sort > > of politics can be conducted in a more or less civilized > > manner, but I don't think it's really avoidable. > > I think we may have a language problem on our hands..... > > to me, the unique feature that attracted me to engineering is the fact > that when an engineer has done his/her work well, the value of the > result is greater than the value of what we started with. > > In the IETF, this translates to "standards are beneficial to everybody". Unfortunately, the two statements "greater than the value of what we started with" and "beneficial to everybody" are not equivalent, and I think that's part of the communication problem. For example, consider what would happen if we were to magically deploy IPsec in such a way that it caused no pain to any user. Beneficial to everyone, right? Well, not to the bad guys who wanted to read your traffic. To take a more realistic example, it's not clear that AOL benefits from the IETF actually having a successful IM standard. [0] > I think "politics" derives from "polis" - city? - it's what humans do > when they get together in large groups. > > But what an engineer who says he "hates politics" means is, I think, > more often related to an image of "politics" where the underlying > logic is that of splitting a fixed-size pie; in order to win, I have > to make someone else lose; if someone else benefits, it means that I > have less. > > > I think that's not the kind of politics we want to play. But that's > not the only form of politics there is. Indeed, it's not. It's certainly true that there are political situations that are zero sum games, but that's not the only kind of politics there is. One of the most important kinds of politics is deciding how to coordinate positive-sum games. To take an example from standards again, consider what happens when we're trying to design a new network protocol. One decision we have to make is whether to use an XML encoding or an ASN.1 encoding. Neither is inherently better, but XML is much more convenient for people who already process XML and ASN.1 is much more convenient for people who already have ASN.1 codecs. So, assume we have company X-Ray, which currently uses XML and company Abel, which uses ASN.1. Their preference rankings are shown below: Abel: ASN.1, XML, No standard X-Ray: XML, ASN.1, No standard Now, both Abel and X-Ray are willing to lose the encoding battle if that's what it takes in order to get a standard, but they'd naturally rather win. [1] It's precisely this kind of situation where politics is important, even if not particularly attractive. Because if we don't find some way to do that kind of politics, then we're left with No standard, which is even worse. -Ekr [0] Generally, "better for everyone" is known as "Pareto-dominant" and "greater than the value of what we started with" is known as "economically efficient". [1] In this case, both ASN.1 and XML are Pareto-optimal. -- [Eric Rescorla ekr@rtfm.com] Web Log: http://www.rtfm.com/movabletype From problem-statement-bounces@alvestrand.no Wed May 28 17: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 RAA24188 for ; Wed, 28 May 2003 17:09:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 49D1E6238F; Wed, 28 May 2003 23:09:25 +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 0B7B06233E; Wed, 28 May 2003 23:09:18 +0200 (CEST) Received: from medea.wz-berlin.de ([193.174.6.5]) by athene.wz-berlin.de with esmtp (Exim 4.20) id 19L8Ad-00017T-KE; Wed, 28 May 2003 23:09:15 +0200 Received: from ERDE/SpoolDir by medea.wz-berlin.de (Mercury 1.48); 28 May 03 23:09:15 +0200 Received: from SpoolDir by ERDE (Mercury 1.48); 28 May 03 23:09:02 +0200 From: "Jeanette Hofmann" Organization: Wissenschaftszentrum Berlin To: EKR , Harald Tveit Alvestrand Date: Wed, 28 May 2003 23:08:58 +0200 MIME-Version: 1.0 Message-ID: <3ED5418E.5229.230B459@localhost> Priority: normal In-reply-to: <16500000.1054151897@askvoll.hjemme.alvestrand.no> References: 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: IESG restructuring (Re: Example of the One Liners out of context) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7BIT On 28 May 2003 at 21:58, Harald Tveit Alvestrand wrote: > > > --On mandag, mai 26, 2003 13:35:46 -0700 Eric Rescorla wrote: > > > Harald Tveit Alvestrand writes: > > > >> what do other people think here? > > Maybe I've misunderstood Randy, but "real work vs. politics" > > strikes me as a false opposition. Getting real work done in > > organizations with more than a few people who have divergent > > goals is an inherently political activity. Sure, that sort > > of politics can be conducted in a more or less civilized > > manner, but I don't think it's really avoidable. > > I think we may have a language problem on our hands..... > > to me, the unique feature that attracted me to engineering is the fact that > when an engineer has done his/her work well, the value of the result is > greater than the value of what we started with. > In the IETF, this translates to "standards are beneficial to everybody". > > I think "politics" derives from "polis" - city? - it's what humans do when > they get together in large groups. Polis in the Greek sense marks a social space, which consists of free people with equal status and rights who are concerned with the well being of all members. The polis strives for the good life. A distinction between politics and technology doesn't make sense in such a concept of politics. The IETF could be interpreted as a polis in the modern sense. It is supposed to care about the Internet as opposed to single companies or applications. Jeanette > But what an engineer who says he "hates politics" means is, I think, more > often related to an image of "politics" where the underlying logic is that > of splitting a fixed-size pie; in order to win, I have to make someone > else lose; if someone else benefits, it means that I have less. > > I think that's not the kind of politics we want to play. But that's not the > only form of politics there is. > > Harald > > From problem-statement-bounces@alvestrand.no Wed May 28 17: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 RAA24599 for ; Wed, 28 May 2003 17:19:14 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4C6DA623CD; Wed, 28 May 2003 23:18:44 +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 968786233E; Wed, 28 May 2003 23:18:41 +0200 (CEST) Received: by romeo.rtfm.com (Postfix, from userid 556) id B08B5ABA6; Wed, 28 May 2003 14:24:38 -0700 (PDT) To: "Jeanette Hofmann" References: <3ED5418E.5229.230B459@localhost> From: Eric Rescorla Date: 28 May 2003 14:24:37 -0700 In-Reply-To: <3ED5418E.5229.230B459@localhost> Message-ID: Lines: 16 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: Harald Tveit Alvestrand Cc: problem-statement@alvestrand.no Subject: Re: IESG restructuring (Re: Example of the One Liners out of context) 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 "Jeanette Hofmann" writes: > On 28 May 2003 at 21:58, Harald Tveit Alvestrand wrote: > The IETF could be interpreted as a polis in the modern sense. It is > supposed to care about the Internet as opposed to single companies or > applications. The problem, is that "care about the Internet" isn't really a well-formed concept, any more than "the public good" is. One can, of course, adopt any number of theories designed to give it concrete meaning, but I doubt we could get consensus on any of them. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From problem-statement-bounces@alvestrand.no Wed May 28 17:47: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 RAA25460 for ; Wed, 28 May 2003 17:47:08 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C0A516238A; Wed, 28 May 2003 23:46:38 +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 703B36233E for ; Wed, 28 May 2003 23:46:37 +0200 (CEST) Received: from medea.wz-berlin.de ([193.174.6.5]) by athene.wz-berlin.de with esmtp (Exim 4.20) id 19L8km-0001NP-9D; Wed, 28 May 2003 23:46:36 +0200 Received: from ERDE/SpoolDir by medea.wz-berlin.de (Mercury 1.48); 28 May 03 23:46:36 +0200 Received: from SpoolDir by ERDE (Mercury 1.48); 28 May 03 23:46:17 +0200 From: "Jeanette Hofmann" Organization: Wissenschaftszentrum Berlin To: EKR Date: Wed, 28 May 2003 23:46:16 +0200 MIME-Version: 1.0 Message-ID: <3ED54A4C.11967.252DC43@localhost> Priority: normal In-reply-to: References: <3ED5418E.5229.230B459@localhost> 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: IESG restructuring (Re: Example of the One Liners out of context) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7BIT On 28 May 2003 at 14:24, Eric Rescorla wrote: > "Jeanette Hofmann" writes: > > On 28 May 2003 at 21:58, Harald Tveit Alvestrand wrote: > > The IETF could be interpreted as a polis in the modern sense. It is > > supposed to care about the Internet as opposed to single companies or > > applications. > > The problem, is that "care about the Internet" isn't really a > well-formed concept, any more than "the public good" is. Actually, I meant to point out the difference between care about the Internet as a whole and more narrow minded interests. A Greek definition of politics covers the comprehensive approach. I agree with you, concepts such as care for the Internet are in need of specification. In any case, I made this whole point in support of your remark regarding false oppositions between real work and politics. One can, of > course, adopt any number of theories designed to give it concrete > meaning, but I doubt we could get consensus on any of them. Are you implying that the IETF could not agree on a mission? Because that is what I think a mission should also be about. jeanette > > -Ekr > > -- > [Eric Rescorla ekr@rtfm.com] > http://www.rtfm.com/ From problem-statement-bounces@alvestrand.no Wed May 28 18:02: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 SAA25755 for ; Wed, 28 May 2003 18:02:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0CBB56238A; Thu, 29 May 2003 00:02: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 C57D46233E for ; Thu, 29 May 2003 00:01:59 +0200 (CEST) Received: by romeo.rtfm.com (Postfix, from userid 556) id E4A77ABA6; Wed, 28 May 2003 15:07:56 -0700 (PDT) To: "Jeanette Hofmann" References: <3ED5418E.5229.230B459@localhost> <3ED54A4C.11967.252DC43@localhost> From: Eric Rescorla Date: 28 May 2003 15:07:56 -0700 In-Reply-To: <3ED54A4C.11967.252DC43@localhost> Message-ID: Lines: 40 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: IESG restructuring (Re: Example of the One Liners out of context) 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 "Jeanette Hofmann" writes: > On 28 May 2003 at 14:24, Eric Rescorla wrote: > > > "Jeanette Hofmann" writes: > > > On 28 May 2003 at 21:58, Harald Tveit Alvestrand wrote: > > > The IETF could be interpreted as a polis in the modern sense. It is > > > supposed to care about the Internet as opposed to single companies or > > > applications. > > > > The problem, is that "care about the Internet" isn't really a > > well-formed concept, any more than "the public good" is. > > Actually, I meant to point out the difference between care about the Internet > as a whole and more narrow minded interests. A Greek definition of politics > covers the comprehensive approach. I agree with you, concepts such as care > for the Internet are in need of specification. In any case, I made this whole > point in support of your remark regarding false oppositions between real work > and politics. Indeed. I was trying to sharpen the point rather than seem as if I was directly contradicting you. My writing could have been a bit better there :( > One can, of > > course, adopt any number of theories designed to give it concrete > > meaning, but I doubt we could get consensus on any of them. > > Are you implying that the IETF could not agree on a mission? Because that is > what I think a mission should also be about. I'm having a hard time believing that the IETF is going to come to some agreement on e.g., economic efficiency versus minimax as the metric for good of the Internet. -Ekr -- [Eric Rescorla ekr@rtfm.com] Web Log: http://www.rtfm.com/movabletype From problem-statement-bounces@alvestrand.no Wed May 28 18:14: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 SAA27272 for ; Wed, 28 May 2003 18:14:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 836476238A; Thu, 29 May 2003 00:14:06 +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 33E556233E for ; Thu, 29 May 2003 00:14:01 +0200 (CEST) Received: from medea.wz-berlin.de ([193.174.6.5]) by athene.wz-berlin.de with esmtp (Exim 4.20) id 19L9BH-0001WP-AO; Thu, 29 May 2003 00:13:59 +0200 Received: from ERDE/SpoolDir by medea.wz-berlin.de (Mercury 1.48); 29 May 03 00:13:59 +0200 Received: from SpoolDir by ERDE (Mercury 1.48); 29 May 03 00:13:42 +0200 From: "Jeanette Hofmann" Organization: Wissenschaftszentrum Berlin To: EKR Date: Thu, 29 May 2003 00:13:40 +0200 MIME-Version: 1.0 Message-ID: <3ED550B9.32553.26BF403@localhost> Priority: normal In-reply-to: References: <3ED54A4C.11967.252DC43@localhost> X-mailer: Pegasus Mail for Windows (v4.11) Content-type: text/plain; charset=ISO-8859-1 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: IESG restructuring (Re: Example of the One Liners out of context) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 SAA27272 On 28 May 2003 at 15:07, Eric Rescorla wrote: > > One can, of > > > course, adopt any number of theories designed to give it concrete > > > meaning, but I doubt we could get consensus on any of them. > > > > Are you implying that the IETF could not agree on a mission? Because that is > > what I think a mission should also be about. > > I'm having a hard time believing that the IETF is going to come > to some agreement on e.g., economic efficiency versus minimax > as the metric for good of the Internet. Perhaps this is naïve but I would think the starting point of a mission should be to make explicit the common ground of every day working group discussion. Now, don't tell me there is no or only little common ground. You wouldn't be able to communicate in the first place if you didn't share crucial concepts, goals and values. To some degree it depends on the language whether you can agree on value based issues. jeanette > > -Ekr > > -- > [Eric Rescorla ekr@rtfm.com] > Web Log: http://www.rtfm.com/movabletype > From problem-statement-bounces@alvestrand.no Wed May 28 18:43: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 SAA28223 for ; Wed, 28 May 2003 18:43:21 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5C5376238A; Thu, 29 May 2003 00:42:52 +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 9555B6233E for ; Thu, 29 May 2003 00:42:49 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19L9d8-000C6E-FA; Wed, 28 May 2003 15:42:46 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 28 May 2003 15:42:45 -0700 To: Frank Kastenholz References: <89860000.1053939264@askvoll.hjemme.alvestrand.no> <1861252390.20030526075823@brandenburg.com> <5.1.1.5.2.20030528102714.02b1e630@pi> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: Can we learn something from IETF history? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 original work was done far less formally, with hallway conversations >>> as the means for floating ideas and exploring reactions >>isn't this what some seem to call a closed conspiracy today? > We might call it that today > but that is not what it was then. indeed. and almost always, that is not what it is today. unless one needs to characterize things thusly to artificially polarize the situation. > So maybe it was closed -- closed to those people who > lacked motivation and/or coherency... that is life, i think. randy From problem-statement-bounces@alvestrand.no Wed May 28 18:53: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 SAA28532 for ; Wed, 28 May 2003 18:53:41 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2F18F6238A; Thu, 29 May 2003 00:53:12 +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 263496233E for ; Thu, 29 May 2003 00:53:09 +0200 (CEST) Received: by romeo.rtfm.com (Postfix, from userid 556) id 41939ABA6; Wed, 28 May 2003 15:59:06 -0700 (PDT) To: "Jeanette Hofmann" References: <3ED54A4C.11967.252DC43@localhost> <3ED550B9.32553.26BF403@localhost> From: Eric Rescorla Date: 28 May 2003 15:59:05 -0700 In-Reply-To: <3ED550B9.32553.26BF403@localhost> Message-ID: Lines: 19 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: problem-statement@alvestrand.no Subject: Re: IESG restructuring (Re: Example of the One Liners out of context) 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 Content-Transfer-Encoding: 8bit "Jeanette Hofmann" writes: > Perhaps this is naïve but I would think the starting point of a mission > should be to make explicit the common ground of every day working > group discussion. Now, don't tell me there is no or only little common > ground. You wouldn't be able to communicate in the first place if you > didn't share crucial concepts, goals and values. To some degree it > depends on the language whether you can agree on value based > issues. I think the problem is that we can all pretty much agree on what our individual incentives are but that we don't have a consensus on how to aggregate those preferences. But that's where a lot of the politicing comes in. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From problem-statement-bounces@alvestrand.no Wed May 28 19:02: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 TAA28863 for ; Wed, 28 May 2003 19:02:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0DAB16238A; Thu, 29 May 2003 01:02:07 +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 D59306233E for ; Thu, 29 May 2003 01:02:04 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19L9vn-000Cbr-Od for problem-statement@alvestrand.no; Wed, 28 May 2003 16:02:03 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 28 May 2003 16:02:03 -0700 To: problem-statement@alvestrand.no References: <73502320.1054118305@p3.JCK.COM> <008701c32532$673e6240$e2916444@awduche.com> Message-Id: Subject: RE: Listing affiliations (Re: OPEN ISSUE: WG Chair Selection (in general)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit fwiw, a - i agree that affiliations ahould be well-known b - this goes for everyone, not just i* members, wg chairs, etc. c - i was nonplussed to see they were not shown on the iesg web page d - there is a balance between affiliations being well-known and the desire to make it clear that we all act as individual experts e - those of us who have very long-lived email addresses but who occasionally change employers would strongly prefer to use the long-lived email addresses. f - i also prefer to use my private email address so that all know i speak as an individual, not an employee, as i have been known to speak against the interests and policies of my employer. g - in case you did not know and do care, i work for iij, internet initiative japan (legally, i work for iij/america in nyc), but work out of my home near seattle. randy From problem-statement-bounces@alvestrand.no Wed May 28 19:08: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 TAA29002 for ; Wed, 28 May 2003 19:08:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B79426238A; Thu, 29 May 2003 01:07:52 +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 62B966233E for ; Thu, 29 May 2003 01:07:47 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19LA1J-000CkI-Nm; Wed, 28 May 2003 16:07:45 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 28 May 2003 16:07:45 -0700 To: John C Klensin References: <008701c32532$673e6240$e2916444@awduche.com> <80718877.1054125522@p3.JCK.COM> Message-Id: Cc: problem-statement@alvestrand.no Subject: RE: Listing affiliations (Re: OPEN ISSUE: WG Chair Selection (in general)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit > Much as I find myself slipping into avoidance behavior > --typically of the form of "what can I think of that absolutely > has to be done first"-- every time someone says "would you > please boil your career/ life down into one paragraph and put it > in this box", I think very short bio sketches would be useful > additions to affiliation information. i would hope that the url of an already painful web page would be sufficient. randy From problem-statement-bounces@alvestrand.no Wed May 28 19:30: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 TAA29670 for ; Wed, 28 May 2003 19:30:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 164346238A; Thu, 29 May 2003 01:30:28 +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 663DB6233E for ; Thu, 29 May 2003 01:30:25 +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 QAA23465; Wed, 28 May 2003 16:30:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4SNUNr25910; Wed, 28 May 2003 16:30:23 -0700 X-mProtect: <200305282330> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.150, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxZznFX; Wed, 28 May 2003 16:30:21 PDT Message-Id: <4.3.2.7.2.20030528162659.02e57560@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 28 May 2003 16:29:21 -0700 To: Randy Bush From: Bob Hinden In-Reply-To: References: <73502320.1054118305@p3.JCK.COM> <008701c32532$673e6240$e2916444@awduche.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: RE: Listing affiliations (Re: OPEN ISSUE: WG Chair Selection (in general)) X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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, I agree that there is no reason to have anyone change email addresses. As you point out there are lots of good reason to have email addresses different from one employer. Bob At 04:02 PM 5/28/2003, Randy Bush wrote: >fwiw, > > a - i agree that affiliations ahould be well-known > > b - this goes for everyone, not just i* members, wg chairs, etc. > > c - i was nonplussed to see they were not shown on the iesg web > page > > d - there is a balance between affiliations being well-known and > the desire to make it clear that we all act as individual > experts > > e - those of us who have very long-lived email addresses but who > occasionally change employers would strongly prefer to use > the long-lived email addresses. > > f - i also prefer to use my private email address so that all > know i speak as an individual, not an employee, as i have > been known to speak against the interests and policies of my > employer. > > g - in case you did not know and do care, i work for iij, > internet initiative japan (legally, i work for iij/america in > nyc), but work out of my home near seattle. > >randy From problem-statement-bounces@alvestrand.no Wed May 28 20:55: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 UAA01485 for ; Wed, 28 May 2003 20:55:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C4E06623CD; Thu, 29 May 2003 02:55:18 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mta3.wss.scd.yahoo.com (mta3.wss.scd.yahoo.com [66.218.85.34]) by eikenes.alvestrand.no (Postfix) with ESMTP id 43C70622AF; Thu, 29 May 2003 02:55:16 +0200 (CEST) Received: from AwducheHPlapt (68.100.145.226) by mta3.wss.scd.yahoo.com (7.0.016) (authenticated as awduche@awduche.com) id 3ED3A838000A8617; Wed, 28 May 2003 17:55:13 -0700 From: "Daniel O. Awduche" To: "'Keith Moore'" , "'Harald Tveit Alvestrand'" Date: Wed, 28 May 2003 20:54:36 -0400 Message-ID: <009501c3257c$e1902ac0$e2916444@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: <20030528162731.60443218.moore@cs.utk.edu> Cc: randy@psg.com Cc: problem-statement@alvestrand.no Cc: ekr@rtfm.com Subject: RE: IESG restructuring (Re: Example of the One Liners out of context) 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 In the organizational setting, "politics" generally refers to 'activities taken to acquire power, influence, and other capabilities to obtain one's preferred outcomes in situations where there is disagreement or uncertainty about choices...' Cheers, /Dan -----Original Message----- From: problem-statement-bounces@alvestrand.no [mailto:problem-statement-bounces@alvestrand.no] On Behalf Of Keith Moore Sent: Wednesday, May 28, 2003 4:28 PM To: Harald Tveit Alvestrand Cc: randy@psg.com; problem-statement@alvestrand.no; ekr@rtfm.com; moore@cs.utk.edu Subject: Re: IESG restructuring (Re: Example of the One Liners out of context) > But what an engineer who says he "hates politics" means is, I think, > more often related to an image of "politics" where the underlying > logic is that of splitting a fixed-size pie; in order to win, I have > to make someone else lose; if someone else benefits, it means that I > have less. I've always thought of engineers' hatred of politics as a distaste for some of the practices considered necessary in political activity in order to accomplish what needs to be done -- such as pretending that things are different than they really are in order to avoid offending some powerful person or group, or manipulation of people and groups using power, coercion, propaganda, ego-stroking, etc. None of which means that you can't end up with a win-win situation, but the dishonesty inherent in such practices makes it difficult to see what a win-win situation might look like. From problem-statement-bounces@alvestrand.no Wed May 28 22:57: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 WAA04202 for ; Wed, 28 May 2003 22:57:36 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6A9486238A; Thu, 29 May 2003 04:57:06 +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 648646233E for ; Thu, 29 May 2003 04:57:03 +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 h4T2xmi11416; Wed, 28 May 2003 19:59:48 -0700 Date: Wed, 28 May 2003 19:56:58 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <4240823531.20030528195658@brandenburg.com> To: Randy Bush In-Reply-To: References: <89860000.1053939264@askvoll.hjemme.alvestrand.no> <1861252390.20030526075823@brandenburg.com> <5.1.1.5.2.20030528102714.02b1e630@pi> MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: Can we learn something from IETF history? 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, >>>isn't this what some seem to call a closed conspiracy today? >> We might call it that today >> but that is not what it was then. RB> indeed. and almost always, that is not what it is today. unless RB> one needs to characterize things thusly to artificially polarize RB> the situation. just like it is polarizing -- or at least distracting -- to bring it up in the middle of a thread that had nothing to do with conspiracies or polarization. nicely done. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Wed May 28 23: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 XAA05245 for ; Wed, 28 May 2003 23:42:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 81F3E62598; Thu, 29 May 2003 05:41:42 +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 6B6E16233E for ; Thu, 29 May 2003 05:41:35 +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 8225EDE81 for ; Wed, 28 May 2003 23:41:34 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 28 May 2003 23:41: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: Wed, 28 May 2003 23:41:33 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B032412CA@tayexc13.americas.cpqcorp.net> Thread-Topic: Lets discuss what we all agree about Thread-Index: AcMllDnoMOEkSaLyQhmWuPV1XP/LgQ== From: "Bound, Jim" To: X-OriginalArrivalTime: 29 May 2003 03:41:34.0325 (UTC) FILETIME=[33574250:01C32594] Subject: Lets discuss what we all agree about X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 XAA05245 I am doing what I said and re-reading our drafts and working on that for my own peace of mind. They are good too. More on that if I find bugs. Day job is demanding next few weeks though more than usual, but I try. But............Two points I was just getting ready to crash (uh. hipster talk for going to sleep) and the IETF problem-statement working group was in my head (this is very bad) and I thought about some smart person that said "why don't we discuss where we agree first" kinda like ecumenical view for moving forward in discussion. That might work. Point two below will prove that this works. In my country in U.S. we have this document called the constitution and its a life long study for me but it is very small and dense. I like it but I am what is called a strict constitutionalist. In others words don't change it unless it is really really necessary ergo like Women being able to vote, antitrust IMO was a good idea (Teddy Roosevelt one of my historical heros), and obviously all get to vote and express themselves, but yelling fire in a theatre is not cool. Would like to see all men are created equal to all "people" but creation causes polarization and that is not good. Now my point. If the ITU came to our process here and said let me help you structure the IETF just like the ITU and we will help you expand your processes just like ours and set you right up with a bunch of really good rules. I think 99% of this list would band together and reject that idea and some of us would want to feed them to pigs :--) We do agree on lot of things and none of us want more process but possibly short clear ammendmants to enhance our capabilities as a body and add some escape clauses for fairness for tomorrow. P.S. TRIVIA: The original pledge allegiance to the flag we do in the U.S. written by a minister in 1890's did not have GOD in the script that got done in the 1950's during the McCarthy years and a paranoid state in our history, very bad update as one bad example IMO (not because I do or do not believe in some god but because it has nothing to do with my allegiance to my country or my service there of) :--) Goodnight and I will not dream about our problem-statement I refuse :--) Feeding persons to pigs, well maybe :--) /jim From problem-statement-bounces@alvestrand.no Thu May 29 07: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 HAA27266 for ; Thu, 29 May 2003 07:30:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D605C625A0; Thu, 29 May 2003 13:29: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 5900F62278; Thu, 29 May 2003 13:29: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 EAA02119; Thu, 29 May 2003 04:29:11 -0700 (PDT) Message-Id: <5.1.0.14.2.20030529072003.044998c0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 29 May 2003 07:25:14 -0400 To: problem-statement@alvestrand.no, Harald Tveit Alvestrand From: Margaret Wasserman In-Reply-To: <5.1.0.14.2.20030516045138.039fad60@mail.windriver.com> References: <1689237845.1053038406@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: RE: OPEN ISSUE: Quality Process WG Charter X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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, do we have consensus to start the near-term WG to improve the WG quality processes and IETF review processes? Several people agreed with the idea, folks seemed to think that we should use the normal IETF process to start this effort, and we have at least one proposal on the table that could be considered (SIRs). So, is it worth holding a BOF to determine if we have IETF consensus to start this work? If so, has anyone proposed a BOF on this subject for Vienna? It would be great to see some work start up in this area. How can I help? Margaret At 04:57 AM 5/16/2003 -0400, Margaret Wasserman wrote: >Hi Harald, > >At 10:40 PM 5/15/2003 +0200, Harald Tveit Alvestrand wrote: >>timing issue..... >> >>is the creation of the Quality WG dependent on IETF consensus on the >>Problem and Process documentson this WG? >>If yes - the WG cannot be started until after Vienna. >>If no - the WG process can be started as soon as there appears to be >>reasonable consensus that the WG should be formed. It seems reasonable to >>expect that the WG could start before this WG produces its final output. > >IMO, we should start the near-term efforts described in this document >(all four of them) as soon as there is community consensus to start >them. In fact, at least two of them are already underway. > >I don't think that the problem-statement group should cause a delay >in our efforts to improve outselves. > >>identity issue.... >> >>is this WG in parallel to, in cooperation with, or orthogonal to, the >>proposal to form a WG (that is, an activity with a charter) focusing on >>training/education/leader development for the IETF? > >There are four near-term efforts identified in the document that >can proceed immediately and in parallel: > > - WG quality processes (the WG you're talking about). > - Training/Education (this is only defined as an > "effort" in the document, not explicitly as > a WG -- that discussion didn't start until > after I published the document). > - Identifying/deploying tools for issue tracking and > document revision control. > - Promoting/increasing communication between WG chairs. > >Hopefully all of the near-term efforts will spin-up while we are >still trying to define and start the longer-term effort which >will: > > - Improve the scalability and effectiveness of the > management structure of the IETF (i.e. > reorganize). > - Update the standards-track document processes to > be more effective and timely. > >If you've read the document carefully and this is unclear, please >let me know, so that I can attempt to make it clearer. > >Thanks, >Margaret > > From problem-statement-bounces@alvestrand.no Thu May 29 09: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 JAA01981 for ; Thu, 29 May 2003 09:07:19 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 98291625B5; Thu, 29 May 2003 15:06:48 +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 8B4C262278; Thu, 29 May 2003 15:06:41 +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 19LN6z-000345-00; Thu, 29 May 2003 06:06:29 -0700 Date: Thu, 29 May 2003 09:04:54 -0400 From: Keith Moore To: Margaret Wasserman Message-Id: <20030529090454.38dffd3c.moore@cs.utk.edu> In-Reply-To: <5.1.0.14.2.20030529072003.044998c0@mail.windriver.com> References: <1689237845.1053038406@localhost> <5.1.0.14.2.20030529072003.044998c0@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 Cc: harald@alvestrand.no Subject: Re: OPEN ISSUE: Quality Process WG Charter X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, do we have consensus to start the near-term WG to > improve the WG quality processes and IETF review > processes? I fear that if we do this, the WG will spend too much time on review processes and not enough time on WG operation. But I'm not sure what to do about it: both subjects need attention, and if we created two separate WGs then the one working on extra-WG review might attract a lot more interest than the one working on WG operation. From problem-statement-bounces@alvestrand.no Thu May 29 09:16: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 JAA02423 for ; Thu, 29 May 2003 09:16:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1C312625B5; Thu, 29 May 2003 15:15:40 +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 873A162278 for ; Thu, 29 May 2003 15:15:32 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA10931; Thu, 29 May 2003 06:15:13 -0700 (PDT) Message-Id: <5.1.0.14.2.20030529090437.044cb3d0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 29 May 2003 09:11:17 -0400 To: Keith Moore From: Margaret Wasserman In-Reply-To: <20030529090454.38dffd3c.moore@cs.utk.edu> References: <5.1.0.14.2.20030529072003.044998c0@mail.windriver.com> <1689237845.1053038406@localhost> <5.1.0.14.2.20030529072003.044998c0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Quality Process WG Charter X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 don't believe that adding extra review at the end of the WG process will improve anything... We need to establish some quality processes to be used during WG document production that will include (among other things) appropriately scoped reviews of documents at specific milestones. So, I don't see these two concepts (WG processes and review processes) as separable. Margaret At 09:04 AM 5/29/2003 -0400, Keith Moore wrote: > > So, do we have consensus to start the near-term WG to > > improve the WG quality processes and IETF review > > processes? > >I fear that if we do this, the WG will spend too much time on review processes >and not enough time on WG operation. But I'm not sure what to do about it: >both subjects need attention, and if we created two separate WGs then the one >working on extra-WG review might attract a lot more interest than the one >working on WG operation. From problem-statement-bounces@alvestrand.no Thu May 29 09:23: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 JAA02700 for ; Thu, 29 May 2003 09:23:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 72BC6625C0; Thu, 29 May 2003 15:23:25 +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 8864C62278; Thu, 29 May 2003 15:23:16 +0200 (CEST) Date: Thu, 29 May 2003 15:23:16 +0200 From: Harald Tveit Alvestrand To: Keith Moore , Margaret Wasserman Message-ID: <45250000.1054214596@askvoll.hjemme.alvestrand.no> In-Reply-To: <20030529090454.38dffd3c.moore@cs.utk.edu> References: <1689237845.1053038406@localhost> <5.1.0.14.2.20030529072003.044998c0@mail.windriver.com> <20030529090454.38dffd3c.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: OPEN ISSUE: Quality Process WG Charter X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, mai 29, 2003 09:04:54 -0400 Keith Moore wrote: >> So, do we have consensus to start the near-term WG to >> improve the WG quality processes and IETF review >> processes? > > I fear that if we do this, the WG will spend too much time on review > processes and not enough time on WG operation. But I'm not sure what to > do about it: both subjects need attention, and if we created two separate > WGs then the one working on extra-WG review might attract a lot more > interest than the one working on WG operation. I think this WG would/should be focused on the WG process, and review as one tool to improve that process. This should not be confused with the issues surrounding end-of-line IESG review (although one hopes that improving one would make the other far less problematic). My understanding.... Harald From problem-statement-bounces@alvestrand.no Thu May 29 09:27: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 JAA02825 for ; Thu, 29 May 2003 09:27:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4CCD9625C6; Thu, 29 May 2003 15:26:39 +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 57C9D625C3 for ; Thu, 29 May 2003 15:26:36 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA14991 for ; Thu, 29 May 2003 06:26:18 -0700 (PDT) Message-Id: <5.1.0.14.2.20030529092053.0446b648@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 29 May 2003 09:22:23 -0400 To: problem-statement@alvestrand.no From: Margaret Wasserman In-Reply-To: <45250000.1054214596@askvoll.hjemme.alvestrand.no> References: <20030529090454.38dffd3c.moore@cs.utk.edu> <1689237845.1053038406@localhost> <5.1.0.14.2.20030529072003.044998c0@mail.windriver.com> <20030529090454.38dffd3c.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: OPEN ISSUE: Quality Process WG Charter X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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:23 PM 5/29/2003 +0200, Harald Tveit Alvestrand wrote: >I think this WG would/should be focused on the WG process, and review as >one tool to improve that process. Sold. So, Harald, do you know if there is any effort underway to actually _start_ this WG? Any hope for a BOF in Vienna? Margaret From problem-statement-bounces@alvestrand.no Thu May 29 09: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 JAA02962 for ; Thu, 29 May 2003 09:30:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 79C73625C0; Thu, 29 May 2003 15:30:21 +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 BE02A62278 for ; Thu, 29 May 2003 15:29:58 +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 19LNTb-0005xv-00; Thu, 29 May 2003 06:29:51 -0700 Date: Thu, 29 May 2003 09:28:15 -0400 From: Keith Moore To: Margaret Wasserman Message-Id: <20030529092815.16a69e7b.moore@cs.utk.edu> In-Reply-To: <5.1.0.14.2.20030529090437.044cb3d0@mail.windriver.com> References: <5.1.0.14.2.20030529072003.044998c0@mail.windriver.com> <1689237845.1053038406@localhost> <5.1.0.14.2.20030529072003.044998c0@mail.windriver.com> <5.1.0.14.2.20030529090437.044cb3d0@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: OPEN ISSUE: Quality Process WG Charter X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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 believe that adding extra review at the end of > the WG process will improve anything... agree with that. by "extra-WG review" I meant review from outside of the WG, i.e. I was separating what goes on within a WG from what goes on outside of the WG...and lumping IESG in with the latter. and if the intention is to create a WG that looks at how WGs operate, I'm generally in favor of that. From problem-statement-bounces@alvestrand.no Thu May 29 09:39: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 JAA03143 for ; Thu, 29 May 2003 09:39:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D1507625C0; Thu, 29 May 2003 15:39:25 +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 15CC462278 for ; Thu, 29 May 2003 15:39:19 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA20266; Thu, 29 May 2003 06:39:00 -0700 (PDT) Message-Id: <5.1.0.14.2.20030529092800.04452738@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 29 May 2003 09:34:52 -0400 To: Keith Moore From: Margaret Wasserman In-Reply-To: <20030529092815.16a69e7b.moore@cs.utk.edu> References: <5.1.0.14.2.20030529090437.044cb3d0@mail.windriver.com> <5.1.0.14.2.20030529072003.044998c0@mail.windriver.com> <1689237845.1053038406@localhost> <5.1.0.14.2.20030529072003.044998c0@mail.windriver.com> <5.1.0.14.2.20030529090437.044cb3d0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Cc: moore@cs.utk.edu Subject: Re: OPEN ISSUE: Quality Process WG Charter X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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:28 AM 5/29/2003 -0400, Keith Moore wrote: > > I don't believe that adding extra review at the end of > > the WG process will improve anything... > >agree with that. by "extra-WG review" I meant review from outside of the WG, >i.e. I was separating what goes on within a WG from what goes on outside >of the >WG...and lumping IESG in with the latter. and if the intention is to create >a WG that looks at how WGs operate, I'm generally in favor of that. Well, this was _my_ intention when I wrote the process document... If that wasn't clear to you, though, maybe my document needs to be clarified? The purpose of this WG would be to improve the quality processes (including review process) used by WGs, with the goals of increasing the quality, timeliness and predictability of WG output. Margaret From problem-statement-bounces@alvestrand.no Thu May 29 10:01: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 KAA03770 for ; Thu, 29 May 2003 10:01:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4EFC9625A5; Thu, 29 May 2003 16:01: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 A0ABB62278; Thu, 29 May 2003 16:01:24 +0200 (CEST) Date: Thu, 29 May 2003 16:01:24 +0200 From: Harald Tveit Alvestrand To: Margaret Wasserman , problem-statement@alvestrand.no Message-ID: <48890000.1054216884@askvoll.hjemme.alvestrand.no> In-Reply-To: <5.1.0.14.2.20030529092053.0446b648@mail.windriver.com> References: <20030529090454.38dffd3c.moore@cs.utk.edu> <1689237845.1053038406@localhost> <5.1.0.14.2.20030529072003.044998c0@mail.windriver.com> <20030529090454.38dffd3c.moore@cs.utk.edu> <5.1.0.14.2.20030529092053.0446b648@mail.windriver.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: OPEN ISSUE: Quality Process WG Charter X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-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, mai 29, 2003 09:22:23 -0400 Margaret Wasserman wrote: > > At 03:23 PM 5/29/2003 +0200, Harald Tveit Alvestrand wrote: >> I think this WG would/should be focused on the WG process, and review as >> one tool to improve that process. > > Sold. > > So, Harald, do you know if there is any effort underway to > actually _start_ this WG? Any hope for a BOF in Vienna? as far as I know, the line of volunteers is completely empty.... but the deadline for scheduling BOFs in Vienna is not yet over (the scheduling officially closes on June 20). Harald From problem-statement-bounces@alvestrand.no Thu May 29 11:47: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 LAA07894 for ; Thu, 29 May 2003 11:47:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 17E8F6259C; Thu, 29 May 2003 17:46:57 +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 6336B6233E; Thu, 29 May 2003 17:46:46 +0200 (CEST) Message-ID: <00b201c325f9$4cd09b90$a66015ac@DCLKEMPFTP> From: "James Kempf" To: "Harald Tveit Alvestrand" , "Keith Moore" , "Margaret Wasserman" References: <1689237845.1053038406@localhost> <5.1.0.14.2.20030529072003.044998c0@mail.windriver.com> <20030529090454.38dffd3c.moore@cs.utk.edu> <45250000.1054214596@askvoll.hjemme.alvestrand.no> Date: Thu, 29 May 2003 08:45:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Quality Process WG Charter X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Agree. jak ----- Original Message ----- From: "Harald Tveit Alvestrand" To: "Keith Moore" ; "Margaret Wasserman" Cc: Sent: Thursday, May 29, 2003 6:23 AM Subject: Re: OPEN ISSUE: Quality Process WG Charter > > > --On torsdag, mai 29, 2003 09:04:54 -0400 Keith Moore > wrote: > > >> So, do we have consensus to start the near-term WG to > >> improve the WG quality processes and IETF review > >> processes? > > > > I fear that if we do this, the WG will spend too much time on review > > processes and not enough time on WG operation. But I'm not sure what to > > do about it: both subjects need attention, and if we created two separate > > WGs then the one working on extra-WG review might attract a lot more > > interest than the one working on WG operation. > > I think this WG would/should be focused on the WG process, and review as > one tool to improve that process. > This should not be confused with the issues surrounding end-of-line IESG > review (although one hopes that improving one would make the other far less > problematic). > > My understanding.... > > Harald > > From problem-statement-bounces@alvestrand.no Thu May 29 12:34: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 MAA09519 for ; Thu, 29 May 2003 12:34:02 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8D7DD6233E; Thu, 29 May 2003 18:33:25 +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 07FFB6233E for ; Thu, 29 May 2003 18:33:10 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([128.224.4.109]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA19351; Thu, 29 May 2003 09:32:49 -0700 (PDT) Message-Id: <5.1.0.14.2.20030529122553.042fafb8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 29 May 2003 12:28:50 -0400 To: "James Kempf" From: Margaret Wasserman In-Reply-To: <00b201c325f9$4cd09b90$a66015ac@DCLKEMPFTP> References: <1689237845.1053038406@localhost> <5.1.0.14.2.20030529072003.044998c0@mail.windriver.com> <20030529090454.38dffd3c.moore@cs.utk.edu> <45250000.1054214596@askvoll.hjemme.alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Quality Process WG Charter X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Well, if we're going to try to put a BOF together for Vienna, we better start soon... The scheduling cut-off is looming, and it would also be good for people to have time to get proposals/ideas documented before the -00 I-D cut-off on June 23rd. Who has cycles and would be willing to help? Margaret At 08:45 AM 5/29/2003 -0700, James Kempf wrote: >Agree. > > jak > >----- Original Message ----- >From: "Harald Tveit Alvestrand" >To: "Keith Moore" ; "Margaret Wasserman" > >Cc: >Sent: Thursday, May 29, 2003 6:23 AM >Subject: Re: OPEN ISSUE: Quality Process WG Charter > > > > > > > > --On torsdag, mai 29, 2003 09:04:54 -0400 Keith Moore > > > wrote: > > > > >> So, do we have consensus to start the near-term WG to > > >> improve the WG quality processes and IETF review > > >> processes? > > > > > > I fear that if we do this, the WG will spend too much time on >review > > > processes and not enough time on WG operation. But I'm not sure >what to > > > do about it: both subjects need attention, and if we created two >separate > > > WGs then the one working on extra-WG review might attract a lot >more > > > interest than the one working on WG operation. > > > > I think this WG would/should be focused on the WG process, and >review as > > one tool to improve that process. > > This should not be confused with the issues surrounding end-of-line >IESG > > review (although one hopes that improving one would make the other >far less > > problematic). > > > > My understanding.... > > > > Harald > > > > From problem-statement-bounces@alvestrand.no Thu May 29 13:14: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 NAA10691 for ; Thu, 29 May 2003 13:14:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8643A6256B; Thu, 29 May 2003 19:13: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 26C606233E for ; Thu, 29 May 2003 19:13:42 +0200 (CEST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])h4THDfW03944 for ; Thu, 29 May 2003 20:13:41 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com ; Thu, 29 May 2003 20:13:41 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 29 May 2003 20:13:40 +0300 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 29 May 2003 20:13:39 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 29 May 2003 20:13: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, 29 May 2003 20:13:38 +0300 Message-ID: Thread-Topic: OPEN ISSUE: Quality Process WG Charter Thread-Index: AcMmABBDsqujp8T3T7aBQgeZcPkvewABX7MA From: To: X-OriginalArrivalTime: 29 May 2003 17:13:39.0268 (UTC) FILETIME=[A5AB8840:01C32605] Cc: problem-statement@alvestrand.no Subject: RE: OPEN ISSUE: Quality Process WG Charter X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , 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 NAA10691 Hi Margaret, > Well, if we're going to try to put a BOF together for Vienna, > we better start soon... > > The scheduling cut-off is looming, and it would also be good for > people to have time to get proposals/ideas documented before the > -00 I-D cut-off on June 23rd. > > Who has cycles and would be willing to help? I don't have any proposals in mind - but I would be interested in helping out organizing, etc. John From problem-statement-bounces@alvestrand.no Thu May 29 14:56: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 OAA14250 for ; Thu, 29 May 2003 14:56:58 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4C46E6233E; Thu, 29 May 2003 20:56:26 +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 777EF6233E for ; Thu, 29 May 2003 20:56: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 LAA37799 for ; Thu, 29 May 2003 11:56:24 -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 8p90etF2 Thu, 29 May 2003 11:56:22 -0700 (PDT) Message-ID: <004601c32613$fde14960$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: <20030529090454.38dffd3c.moore@cs.utk.edu> <1689237845.1053038406@localhost> <5.1.0.14.2.20030529072003.044998c0@mail.windriver.com> <20030529090454.38dffd3c.moore@cs.utk.edu> <5.1.0.14.2.20030529092053.0446b648@mail.windriver.com> <48890000.1054216884@askvoll.hjemme.alvestrand.no> Date: Thu, 29 May 2003 13:56:19 -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: OPEN ISSUE: Quality Process WG Charter 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, Ouch! My understanding was that we were thinking "request NOMCOM to provide co-chairs for the WG". I guess I assumed this would happen before Vienna. Are you requesting volunteers (or, more likely, nominees) to chair a BoF in Vienna? Spencer ----- Original Message ----- From: "Harald Tveit Alvestrand" To: "Margaret Wasserman" ; Sent: Thursday, May 29, 2003 9:01 AM Subject: Re: OPEN ISSUE: Quality Process WG Charter > > > --On torsdag, mai 29, 2003 09:22:23 -0400 Margaret Wasserman > wrote: > > > > > At 03:23 PM 5/29/2003 +0200, Harald Tveit Alvestrand wrote: > >> I think this WG would/should be focused on the WG process, and review as > >> one tool to improve that process. > > > > Sold. > > > > So, Harald, do you know if there is any effort underway to > > actually _start_ this WG? Any hope for a BOF in Vienna? > > as far as I know, the line of volunteers is completely empty.... but the > deadline for scheduling BOFs in Vienna is not yet over (the scheduling > officially closes on June 20). > > Harald > From problem-statement-bounces@alvestrand.no Thu May 29 15: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 PAA15657 for ; Thu, 29 May 2003 15:13:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0D5996233E; Thu, 29 May 2003 21:12:40 +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 DB4A16233E for ; Thu, 29 May 2003 21:12:30 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([128.224.4.109]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA12296; Thu, 29 May 2003 12:12:07 -0700 (PDT) Message-Id: <5.1.0.14.2.20030529145318.0431df38@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 29 May 2003 15:01:48 -0400 To: Spencer Dawkins From: Margaret Wasserman In-Reply-To: <004601c32613$fde14960$0200a8c0@DFNJGL21> References: <20030529090454.38dffd3c.moore@cs.utk.edu> <1689237845.1053038406@localhost> <5.1.0.14.2.20030529072003.044998c0@mail.windriver.com> <20030529090454.38dffd3c.moore@cs.utk.edu> <5.1.0.14.2.20030529092053.0446b648@mail.windriver.com> <48890000.1054216884@askvoll.hjemme.alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Quality Process WG Charter X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 Spencer, There is no suggestion in our process document that the nomcom should choose the chairs for the near-term WG to improve the quality processes used by WGs. That is the WG we are discussing here... The problem-statement did list an open issue about how the charter for this WG should be determined. I proposed that the charter should be determined by the AD and chairs, probably through the normal BOF process. Several people agreed, and no one disagreed. The usual BOF process typically involves someone (or a group of people) proposing a BOF to the relevant AD (in this case, Harald). There is a suggestion that the nomcom (or a similar mechanism) could be used to choose chairs for the longer-term Improvement WG -- the one that will start by determining our mission/values/goals... There are still a lot of open question about how that longer term group will be managed, chartered, etc. Does this clear up your issue, or are you concerned that we may not be ready to hold a BOF for the near-term WG? Margaret At 01:56 PM 5/29/2003 -0500, Spencer Dawkins wrote: >Dear Harald, > >Ouch! > >My understanding was that we were thinking "request NOMCOM to provide >co-chairs >for the WG". I guess I assumed this would happen before Vienna. > >Are you requesting volunteers (or, more likely, nominees) to chair a BoF in >Vienna? > >Spencer > >----- Original Message ----- >From: "Harald Tveit Alvestrand" >To: "Margaret Wasserman" ; > >Sent: Thursday, May 29, 2003 9:01 AM >Subject: Re: OPEN ISSUE: Quality Process WG Charter > > > > > > > > --On torsdag, mai 29, 2003 09:22:23 -0400 Margaret Wasserman > > wrote: > > > > > > > > At 03:23 PM 5/29/2003 +0200, Harald Tveit Alvestrand wrote: > > >> I think this WG would/should be focused on the WG process, and review >as > > >> one tool to improve that process. > > > > > > Sold. > > > > > > So, Harald, do you know if there is any effort underway to > > > actually _start_ this WG? Any hope for a BOF in Vienna? > > > > as far as I know, the line of volunteers is completely empty.... but the > > deadline for scheduling BOFs in Vienna is not yet over (the scheduling > > officially closes on June 20). > > > > Harald > > From problem-statement-bounces@alvestrand.no Thu May 29 15:15: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 PAA15856 for ; Thu, 29 May 2003 15:15:04 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CA44F6233E; Thu, 29 May 2003 21:14:33 +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 09B7D622AC; Thu, 29 May 2003 21:14:17 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([128.224.4.109]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA13420; Thu, 29 May 2003 12:13:58 -0700 (PDT) Message-Id: <5.1.0.14.2.20030529150311.0433fdf8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 29 May 2003 15:10:01 -0400 To: problem-statement@alvestrand.no From: Margaret Wasserman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Thomas Narten Cc: Harald Tveit Alvestrand Subject: Fwd: Re: Education BOF Request X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem 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 All, You may be interested in the status of the training efforts. Thomas Narten has played a big part in leading these efforts, but he's currently on vacation, so I get the privilege of telling you about them... Over the past year, we've seen an increased interest in training/ preparation for WG Chairs, Editors and IETF Participants. The need for improvement in this area was also identified as a problem in the problem statement. The process document mentions our ongoing efforts in this area. We also discussed our WG Chairs training programs on this list a couple of months back, and folks pointed out the need for more visibility and openness in this effort. So, to advance our educational programs, invite community participation and provide increased visibility into this effort, we'll be holding an Education BOF in Vienna (see the approved BOF request below). One goal of this BOF will be to decide how to organize and manage our internal educational efforts moving forward. I thought folks might be interested to know that the problem-statement effort is already making a difference. Margaret BOF NAME & ACRONYM: Education BOF (edu) AREA: General BOF CHAIR(S): Margaret Wasserman MAILING LIST: List: wgchairs-training@ops.ietf.org Subscribe: majordomo@ops.ietf.org Body: "subscribe wgchairs-training" (no quotes) Archive: http://ops.ietf.org/lists/wgchairs-training/ AGENDA: - Intro and Agenda Bashing (5 min) - Review Existing Programs and Resources (10 min) - Newcomer/Participant Training - WG Chair Training - Other Educational Resources - Plans/Direction for Participant Education (15 min) - Plans/Direction for Editor Education (15 min) - Plans/Direction for WG Chair Education (15 min) - Options for Training Organization/Management (10 min) - Open Discussion (30 min) - Next Steps and Action Items (20 min) FULL DESCRIPTION: This BOF will discuss internal training and development programs and educational resources for IETF participants and leaders. The IETF has been educating IETF participants and leaders for many years, via formal training classes, educational web sites, published materials and formal and informal mentoring programs. Our educational efforts have included training sessions for newcomers, introductory training sessions for new WG chairs, and educational web resources for WG chairs, document editors and other participants. There have also been educational sessions for IETF participants held at some IETF plenary meetings. Over the past year, there has been an increasing awareness of the need for better educational programs and resources for IETF WG chairs, document editors and other participants. A grass-roots effort was initiated to expand the WG Chairs training program to include ongoing education for continuing WG chairs. The Newcomers training, formerly provided by the IETF Secretariat, has been folded in to the WG Chairs training effort. Also, we've discussed the development of training programs or resources for document editors and other IETF participants. As this effort expands beyond the area of WG chairs training, it is increasingly important to have the IETF community involved in this effort -- both to give the community more visibility into these activities, and to receive input and assistance from the wider community in developing our educational programs and resources. In this BOF, we'll discuss the IETF's existing educational programs and resources, and we'll discuss how those programs could be enhanced or expanded in the future. We will also discuss how best to organize and managed our educational programs on an ongoing basis, including a discussion of whether we should form a Working Group to further this effort. At the San Francisco IETF in March 2003, a voluntary session was held for IESG members and WG chairs to discuss training for ongoing WG chairs. The notes from that session can be found at: http://www.psg.com/~mrw/WGChairs_Training_Notes_Mar03.txt BOF attendees should also familiarize themselves with our existing training materials and on-line educational resources. For Newcomers: http://www.ietf.org/newcomer/frame.htm http://www.ietf.org/overview.html For WG Chairs: http://psg.com/~mrw/WGChairs_Training_Mar03.ppt http://www.ietf.org/IESG/wgchairs.html Examples of Participant Training: http://www.ietf.org/proceedings/01dec/slides/plenary-3/index.html http://www.ietf.org/proceedings/02mar/slides/plenary-3/index.html From problem-statement-bounces@alvestrand.no Thu May 29 15:35: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 PAA16685 for ; Thu, 29 May 2003 15:35:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 20B93625A5; Thu, 29 May 2003 21:35:08 +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 3C9B9625A5 for ; Thu, 29 May 2003 21:34:58 +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 MAA87347; Thu, 29 May 2003 12:34:47 -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 ViM01nS2 Thu, 29 May 2003 12:34:46 -0700 (PDT) Message-ID: <00d901c32619$5af9e3f0$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: "Margaret Wasserman" References: <20030529090454.38dffd3c.moore@cs.utk.edu> <1689237845.1053038406@localhost> <5.1.0.14.2.20030529072003.044998c0@mail.windriver.com> <20030529090454.38dffd3c.moore@cs.utk.edu> <5.1.0.14.2.20030529092053.0446b648@mail.windriver.com> <48890000.1054216884@askvoll.hjemme.alvestrand.no> <5.1.0.14.2.20030529145318.0431df38@mail.windriver.com> Date: Thu, 29 May 2003 14:34:37 -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 Cc: problem-statement@alvestrand.no Subject: Re: OPEN ISSUE: Quality Process WG Charter 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 Margaret, Ah, I see - I WAS confused. Thanks, Spencer ----- Original Message ----- From: "Margaret Wasserman" To: "Spencer Dawkins" Cc: Sent: Thursday, May 29, 2003 2:01 PM Subject: Re: OPEN ISSUE: Quality Process WG Charter > > Hi Spencer, > > There is no suggestion in our process document that the nomcom > should choose the chairs for the near-term WG to improve the > quality processes used by WGs. That is the WG we are discussing > here... > > The problem-statement did list an open issue about how the > charter for this WG should be determined. I proposed that > the charter should be determined by the AD and chairs, probably > through the normal BOF process. Several people agreed, and > no one disagreed. > > The usual BOF process typically involves someone (or a group > of people) proposing a BOF to the relevant AD (in this case, > Harald). > > There is a suggestion that the nomcom (or a similar mechanism) > could be used to choose chairs for the longer-term > Improvement WG -- the one that will start by determining > our mission/values/goals... There are still a lot of open > question about how that longer term group will be managed, > chartered, etc. > > Does this clear up your issue, or are you concerned that we > may not be ready to hold a BOF for the near-term WG? > > Margaret > > > > At 01:56 PM 5/29/2003 -0500, Spencer Dawkins wrote: > >Dear Harald, > > > >Ouch! > > > >My understanding was that we were thinking "request NOMCOM to provide > >co-chairs > >for the WG". I guess I assumed this would happen before Vienna. > > > >Are you requesting volunteers (or, more likely, nominees) to chair a BoF in > >Vienna? > > > >Spencer > > > >----- Original Message ----- > >From: "Harald Tveit Alvestrand" > >To: "Margaret Wasserman" ; > > > >Sent: Thursday, May 29, 2003 9:01 AM > >Subject: Re: OPEN ISSUE: Quality Process WG Charter > > > > > > > > > > > > > --On torsdag, mai 29, 2003 09:22:23 -0400 Margaret Wasserman > > > wrote: > > > > > > > > > > > At 03:23 PM 5/29/2003 +0200, Harald Tveit Alvestrand wrote: > > > >> I think this WG would/should be focused on the WG process, and review > >as > > > >> one tool to improve that process. > > > > > > > > Sold. > > > > > > > > So, Harald, do you know if there is any effort underway to > > > > actually _start_ this WG? Any hope for a BOF in Vienna? > > > > > > as far as I know, the line of volunteers is completely empty.... but the > > > deadline for scheduling BOFs in Vienna is not yet over (the scheduling > > > officially closes on June 20). > > > > > > Harald > > > > > From problem-statement-bounces@alvestrand.no Thu May 29 15:45: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 PAA16995 for ; Thu, 29 May 2003 15:45:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A56C56233E; Thu, 29 May 2003 21:44:37 +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 CD8B8622AC for ; Thu, 29 May 2003 21:44: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 MAA91500 for ; Thu, 29 May 2003 12:44:36 -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 knN0GsT2 Thu, 29 May 2003 12:44:36 -0700 (PDT) Message-ID: <011401c3261a$ba6bfbb0$0200a8c0@DFNJGL21> From: "Spencer Dawkins" To: References: Date: Thu, 29 May 2003 14:44:32 -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: OPEN ISSUE: Quality Process WG Charter 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 Same as John - no proposals, interested in helping to organize the BoF... Spencer ----- Original Message ----- From: To: Cc: Sent: Thursday, May 29, 2003 12:13 PM Subject: RE: OPEN ISSUE: Quality Process WG Charter Hi Margaret, > Well, if we're going to try to put a BOF together for Vienna, > we better start soon... > > The scheduling cut-off is looming, and it would also be good for > people to have time to get proposals/ideas documented before the > -00 I-D cut-off on June 23rd. > > Who has cycles and would be willing to help? I don't have any proposals in mind - but I would be interested in helping out organizing, etc. John From problem-statement-bounces@alvestrand.no Thu May 29 17:13: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 RAA20170 for ; Thu, 29 May 2003 17:13:49 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1DDA06233E; Thu, 29 May 2003 23:13:18 +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 F2BB0622AC for ; Thu, 29 May 2003 23:12:56 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19LUhj-000Kt5-Hu; Thu, 29 May 2003 14:12:55 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 29 May 2003 14:12:55 -0700 To: Dave Crocker References: <89860000.1053939264@askvoll.hjemme.alvestrand.no> <1861252390.20030526075823@brandenburg.com> <5.1.1.5.2.20030528102714.02b1e630@pi> <4240823531.20030528195658@brandenburg.com> Message-Id: Cc: problem-statement@alvestrand.no Subject: Re: Can we learn something from IETF history? X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit >>>>isn't this what some seem to call a closed conspiracy today? >>> We might call it that today >>> but that is not what it was then. >> indeed. and almost always, that is not what it is today. unless >> one needs to characterize things thusly to artificially polarize >> the situation. > just like it is polarizing -- or at least distracting -- to bring it up > in the middle of a thread that had nothing to do with conspiracies or > polarization. thanks for the example randy From problem-statement-bounces@alvestrand.no Thu May 29 17:14: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 RAA20194 for ; Thu, 29 May 2003 17:14:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C99366259C; Thu, 29 May 2003 23:13:36 +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 DC762622AC for ; Thu, 29 May 2003 23:13: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 h4TLG8x31199; Thu, 29 May 2003 14:16:08 -0700 Date: Thu, 29 May 2003 14:13:17 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <40106599391.20030529141317@brandenburg.com> To: Margaret Wasserman In-Reply-To: <5.1.0.14.2.20030529150311.0433fdf8@mail.windriver.com> References: <5.1.0.14.2.20030529150311.0433fdf8@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: Fwd: Re: Education BOF Request 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> For WG Chairs: MW> http://psg.com/~mrw/WGChairs_Training_Mar03.ppt these slides look quite good. besides offering an introduction to the necessary structure and formality, they hammer at the need for forward progress, and the responsibility of the wg chair to achieve it. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Thu May 29 17:24: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 RAA20598 for ; Thu, 29 May 2003 17:24:53 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2A8816233E; Thu, 29 May 2003 23:24: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 424A5622AC for ; Thu, 29 May 2003 23:24:13 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([128.224.4.109]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA10904; Thu, 29 May 2003 14:23:49 -0700 (PDT) Message-Id: <5.1.0.14.2.20030529171819.0433fdf8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 29 May 2003 17:19:52 -0400 To: Dave Crocker From: Margaret Wasserman In-Reply-To: <40106599391.20030529141317@brandenburg.com> References: <5.1.0.14.2.20030529150311.0433fdf8@mail.windriver.com> <5.1.0.14.2.20030529150311.0433fdf8@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: problem-statement@alvestrand.no Subject: Re: Fwd: Re: Education BOF Request X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.1 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Thanks, Dave! I'm working on an updated version for Vienna that will further trim down the Administrivia and will add more information about the role and responsibilities of WG chairs, based on feedback received in SF. If anyone has constructive comments on these materials, they are certainly welcome! Margaret At 02:13 PM 5/29/2003 -0700, you wrote: >Margaret, > > >MW> For WG Chairs: >MW> http://psg.com/~mrw/WGChairs_Training_Mar03.ppt > >these slides look quite good. besides offering an introduction to the >necessary structure and formality, they hammer at the need for forward >progress, and the responsibility of the wg chair to achieve it. > > >d/ >-- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Fri May 30 09:33: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 JAA06262 for ; Fri, 30 May 2003 09:33:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7FD516256B; Fri, 30 May 2003 15:33:06 +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 005A76223F for ; Fri, 30 May 2003 15:32:56 +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 h4UDWrNb024687 for ; Fri, 30 May 2003 06:32:54 -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 AHU57215; Fri, 30 May 2003 06:32:52 -0700 (PDT) Message-Id: <200305301332.AHU57215@mira-sjc5-c.cisco.com> To: problem-statement@alvestrand.no From: Melinda Shore Date: Fri, 30 May 2003 09:32:52 -0400 Subject: 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 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 From problem-statement-bounces@alvestrand.no Fri May 30 09:51: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 JAA07276 for ; Fri, 30 May 2003 09:51:29 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 040496230F; Fri, 30 May 2003 15:49:27 +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 2B2B06256B for ; Fri, 30 May 2003 15:49:17 +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 19LkFs-0004gw-00; Fri, 30 May 2003 06:49:13 -0700 Date: Fri, 30 May 2003 09:47:30 -0400 From: Keith Moore To: Melinda Shore Message-Id: <20030530094730.457d825d.moore@cs.utk.edu> In-Reply-To: <200305301332.AHU57215@mira-sjc5-c.cisco.com> References: <200305301332.AHU57215@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: problem-statement@alvestrand.no Cc: moore@cs.utk.edu 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 > Question: Should we add an additional AD to deal with process issues? my opinion: no. and on reflection, I don't think it's in scope for this group to decide such matters. From problem-statement-bounces@alvestrand.no Fri May 30 09:54: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 JAA07411 for ; Fri, 30 May 2003 09:54:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 293F16256B; Fri, 30 May 2003 15:54:13 +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 228556223F for ; Fri, 30 May 2003 15:54:04 +0200 (CEST) Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4688967 for problem-statement@alvestrand.no; Fri, 30 May 2003 09:54:02 -0400 Message-Id: <5.1.0.14.0.20030530095315.02893ae0@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 30 May 2003 09:53:35 -0400 To: problem-statement@alvestrand.no From: "Joel M. Halpern" In-Reply-To: <200305301332.AHU57215@mira-sjc5-c.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 No. At 09:32 AM 5/30/2003 -0400, 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 From problem-statement-bounces@alvestrand.no Fri May 30 10:09: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 KAA08709 for ; Fri, 30 May 2003 10:09:07 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 067386220B; Fri, 30 May 2003 16:08:37 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from mta3.wss.scd.yahoo.com (mta3.wss.scd.yahoo.com [66.218.85.34]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9463F625A0 for ; Fri, 30 May 2003 16:08:20 +0200 (CEST) Received: from AwducheHPlapt (68.100.145.226) by mta3.wss.scd.yahoo.com (7.0.016) (authenticated as awduche@awduche.com) id 3ED64BF50004C89C; Fri, 30 May 2003 07:08:12 -0700 From: "Daniel O. Awduche" To: "'Melinda Shore'" , Date: Fri, 30 May 2003 10:07:45 -0400 Message-ID: <004601c326b4$d8bf2480$e2916444@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 In-Reply-To: <200305301332.AHU57215@mira-sjc5-c.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: Query: adding additional AD 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 No. Ordinarily, I would have said 'yes', but the effectiveness of change processes depends significantly on the individuals leading it and Harald is doing a good job. Cheers, /Dan -----Original Message----- From: problem-statement-bounces@alvestrand.no [mailto:problem-statement-bounces@alvestrand.no] On Behalf Of Melinda Shore Sent: Friday, May 30, 2003 9:33 AM To: problem-statement@alvestrand.no Subject: Query: adding additional AD 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 From problem-statement-bounces@alvestrand.no Fri May 30 10:20: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 KAA09975 for ; Fri, 30 May 2003 10:20:48 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7364562571; Fri, 30 May 2003 16:20:18 +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 BEBAA621FB for ; Fri, 30 May 2003 16:20:15 +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 h4UEKCFV007196; Fri, 30 May 2003 10:20:12 -0400 (EDT) Message-Id: <200305301420.h4UEKCFV007196@rtp-core-1.cisco.com> To: Melinda Shore In-reply-to: Your message of Fri, 30 May 2003 09:32:52 -0400. <200305301332.AHU57215@mira-sjc5-c.cisco.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, 30 May 2003 10:20:12 -0400 From: Eric Rosen 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 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 > Question: Should we add an additional AD to deal with process issues? Yes. Otherwise the designated AD is likely to be seen as an apologist for the current system, and the credibility of the effort will suffer. From problem-statement-bounces@alvestrand.no Fri May 30 10:40: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 KAA10806 for ; Fri, 30 May 2003 10:40:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9A8FD6220B; Fri, 30 May 2003 16:39:39 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from beta.jnpr.net (natint.juniper.net [207.17.136.129]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6A6B8621FB for ; Fri, 30 May 2003 16:39:33 +0200 (CEST) Received: from pi-smtp.jnpr.net ([10.10.2.36]) by beta.jnpr.net with Microsoft SMTPSVC(5.0.2195.5329); Fri, 30 May 2003 07:39:31 -0700 Received: from ophelia.jnpr.net ([10.10.2.95]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.5329); Fri, 30 May 2003 10:39:30 -0400 Received: from fkastenholzpc1.juniper.net ([10.10.132.71]) by ophelia.jnpr.net with Microsoft SMTPSVC(5.0.2195.5329); Fri, 30 May 2003 10:39:30 -0400 Message-Id: <5.1.1.5.2.20030530103551.02968dd0@pi> X-Sender: fkastenholz@pi X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 30 May 2003 10:39:17 -0400 To: Melinda Shore , problem-statement@alvestrand.no From: Frank Kastenholz In-Reply-To: <200305301332.AHU57215@mira-sjc5-c.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 30 May 2003 14:39:30.0652 (UTC) FILETIME=[477A79C0:01C326B9] 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 no other deliberative bodies that have need for A Process Person go out and create a staff position called parliamentarian. furthermore, one of the main jobs of an AD is The Process so adding another person to manage The Process is an indictment on how well ADs are doing their job, and when someone is not doing their job, they usually are replaced... At 09:32 AM 5/30/2003 -0400, 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 From problem-statement-bounces@alvestrand.no Fri May 30 10:44: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 KAA11026 for ; Fri, 30 May 2003 10:44:14 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D37896223F; Fri, 30 May 2003 16:43:43 +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 191466220B for ; Fri, 30 May 2003 16:43:37 +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 h4UEhY9N029044 for ; Fri, 30 May 2003 07:43:34 -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 AGP42894; Fri, 30 May 2003 07:35:44 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Fri, 30 May 2003 10:43:29 -0400 Date: Fri, 30 May 2003 10:43:29 -0400 From: Scott W Brim To: problem-statement@alvestrand.no Message-ID: <20030530144328.GA2052@sbrim-w2k> Mail-Followup-To: Scott W Brim , problem-statement@alvestrand.no References: <200305301332.AHU57215@mira-sjc5-c.cisco.com> <5.1.1.5.2.20030530103551.02968dd0@pi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.1.5.2.20030530103551.02968dd0@pi> User-Agent: Mutt/1.4i 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 no From problem-statement-bounces@alvestrand.no Fri May 30 10:55: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 KAA11399 for ; Fri, 30 May 2003 10:55:49 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3CE9B6223F; Fri, 30 May 2003 16:55:19 +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 F08176220B for ; Fri, 30 May 2003 16:55:11 +0200 (CEST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])h4UEt9b01154 for ; Fri, 30 May 2003 09:55:10 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com ; Fri, 30 May 2003 09:55:09 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 30 May 2003 07:54:51 -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, 30 May 2003 09:54:50 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44013EFB2D@daebe007.americas.nokia.com> Thread-Topic: Query: adding additional AD Thread-Index: AcMmsBRFMDv7e+IUQ9Spv+hAARIMfgACqKSQ From: To: , X-OriginalArrivalTime: 30 May 2003 14:54:51.0517 (UTC) FILETIME=[6C5B52D0:01C326BB] 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 KAA11399 Yes. An additional AD is preferred for this process. However there is no necessity to create a new process area. With all the discussion about ADs being overloaded, having a separate AD tackle process change or deal with problems identified by this WG would be more effective. -Basavaraj > > 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 > > From problem-statement-bounces@alvestrand.no Fri May 30 11: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 LAA12294 for ; Fri, 30 May 2003 11:10:10 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7AC286258B; Fri, 30 May 2003 17:09:37 +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 C3B0F6220B for ; Fri, 30 May 2003 17:09: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 h4UFBxx18286; Fri, 30 May 2003 08:11:59 -0700 Date: Fri, 30 May 2003 08:09:07 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <83171145924.20030530080907@brandenburg.com> To: Melinda Shore In-Reply-To: <200305301332.AHU57215@mira-sjc5-c.cisco.com> References: <200305301332.AHU57215@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: Query: adding additional AD 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> Let's try to come to some closure on this. Question: Should MS> we add an additional AD to deal with process issues? If No. I was under the impression that the resounding testimony at the IESG plenary, in Yokohama, was of a rather broad and rather deep discontent in the community, and that the discontent very much includes concerns with IESG performance. Placing responsibility for strategic change directly into the hands of the people who have resisted making it is not a good way to ensure results that are credible. This is not about "intent" or "integrity" or anything else that is personal. It is about designing a process that makes sense for the work that is to be done. For this kind of process, what makes sense is to have it led by people with a largely unencumbered history. d/ ps. Lest we delve into the usual recitations of the wonderfulness of all the people on the IESG, I'll note that indeed, everyone on the IESG is wonderful. However, we are 10 months after Yokohama with no changes implemented (compared with the entire process being done in 4 months after Kobe) and the change process had no visible effort involving the IESG until an independent change proposal was circulated. -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Fri May 30 11:22: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 LAA12867 for ; Fri, 30 May 2003 11:22:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D2E4C6257F; Fri, 30 May 2003 17:21:46 +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 38D2B621FB for ; Fri, 30 May 2003 17:21:36 +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 h4UFOOx18996 for ; Fri, 30 May 2003 08:24:24 -0700 Date: Fri, 30 May 2003 08:21:32 -0700 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/6) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <57171890715.20030530082132@brandenburg.com> To: problem-statement@alvestrand.no In-Reply-To: <83171145924.20030530080907@brandenburg.com> References: <200305301332.AHU57215@mira-sjc5-c.cisco.com> <83171145924.20030530080907@brandenburg.com> MIME-Version: 1.0 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 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 Dave, MS>> Let's try to come to some closure on this. Question: Should MS>> we add an additional AD to deal with process issues? If DC> No. I wish that more coffee would be all that is needed for me to read more carefully. As is obvious from the comments I included, the above 'no' was meant to be a 'yes'. We need the change process to be led by folk who are not current on the IESG. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From problem-statement-bounces@alvestrand.no Fri May 30 11:25: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 LAA13025 for ; Fri, 30 May 2003 11:25:54 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1F0CD6223F; Fri, 30 May 2003 17:25:19 +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 59C0A621FB for ; Fri, 30 May 2003 17:25:16 +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 h4UFPAk13900; Fri, 30 May 2003 11:25:10 -0400 (EDT) Date: Fri, 30 May 2003 11:25:10 -0400 From: Keith Moore To: Dave Crocker Message-Id: <20030530112510.6b74a8af.moore@cs.utk.edu> In-Reply-To: <83171145924.20030530080907@brandenburg.com> References: <200305301332.AHU57215@mira-sjc5-c.cisco.com> <83171145924.20030530080907@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: mshore@cisco.com Cc: problem-statement@alvestrand.no Cc: dhc@dcrocker.net Cc: moore@cs.utk.edu 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 > Placing responsibility for strategic change directly into the hands of > the people who have resisted making it is not a good way to ensure > results that are credible. then whatever we do, we should definitely not form a new working group - because the working groups are the ones who are most resistant to change. you're way out of line accusing the IESG of being resistant to change - the IESG has been changing incrementally for several years, and the result has improved. but the IESG fundamentally can't cause working groups to produce better quality documents. From problem-statement-bounces@alvestrand.no Fri May 30 11: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 LAA13510 for ; Fri, 30 May 2003 11:36:16 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0305A6223F; Fri, 30 May 2003 17:35:47 +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 EF2C96220B for ; Fri, 30 May 2003 17:34:52 +0200 (CEST) Message-ID: <00c701c326c0$cda58920$a66015ac@DCLKEMPFTP> From: "James Kempf" To: , "Melinda Shore" References: <200305301332.AHU57215@mira-sjc5-c.cisco.com> Date: Fri, 30 May 2003 08:33:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Yes, but it is conditional on the term being limited to avoid instantiating a process bureaucracy. I don't care whether a new area is created or not, for economy, it should be under General. jak ----- Original Message ----- From: "Melinda Shore" To: Sent: Friday, May 30, 2003 6:32 AM Subject: Query: adding additional AD > 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 > > From problem-statement-bounces@alvestrand.no Fri May 30 11:44: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 LAA13786 for ; Fri, 30 May 2003 11:44:13 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 56D826220B; Fri, 30 May 2003 17:43:43 +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 54B8C6220B for ; Fri, 30 May 2003 17:43:33 +0200 (CEST) Received: from [209.187.148.215] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.10) id 19Lm2U-0003HT-00; Fri, 30 May 2003 10:43:30 -0500 Date: Fri, 30 May 2003 11:43:30 -0400 From: John C Klensin To: Melinda Shore , "problem-statement@alvestrand.no" Message-ID: <250204294.1054295010@p3.JCK.COM> In-Reply-To: <200305301332.AHU57215@mira-sjc5-c.cisco.com> References: <200305301332.AHU57215@mira-sjc5-c.cisco.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: 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 Uh... a firm, definitive, "Maybe". I think "new AD" (or "new Area") are decisions the process explicitly reserves to the IESG. Attempted micromanaging of that process (or decision) from a WG (or even a plenary) is almost certain to cause more harm than the value of either a "yes" or "no" decision is worth. So I hope the IESG will weigh the considerations --based, presumably, on the input they have already and their understanding of their own needs and constraints-- and make a decision. I hope they will do so swiftly, because it is important to get on with the work. And I hope they will choose to explain their reasoning, since there are clearly tradeoffs involved. For the record, my original suggestion was contingent: not "let's do this" but "if we need to do something, a new AD (with or without a new Area) is preferable to inventing procedures". And, to the extent to which I think a new AD would be useful (I'm not convinced one way or the other), my focus is more on IESG work load levels, possible appeals, and possibly an increase in openness resulting from less load and stress than on any issues of distrust or "who is reporting to whom" process. I hope the IESG will consider those issues for whatever value they might have in the balance. john --On Friday, 30 May, 2003 09:32 -0400 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 > From problem-statement-bounces@alvestrand.no Fri May 30 11:51: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 LAA14031 for ; Fri, 30 May 2003 11:51:51 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 993E76220B; Fri, 30 May 2003 17:51:21 +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 10AF7621FB for ; Fri, 30 May 2003 17:51:12 +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 h4UFowra028499; Fri, 30 May 2003 11:50:58 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h4UFow8e028498; Fri, 30 May 2003 11:50:58 -0400 (EDT) Date: Fri, 30 May 2003 11:50:58 -0400 (EDT) From: Scott Bradner Message-Id: <200305301550.h4UFow8e028498@newdev.harvard.edu> To: mshore@cisco.com, problem-statement@alvestrand.no In-Reply-To: <200305301332.AHU57215@mira-sjc5-c.cisco.com> 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 prefer "no" but "yes" is fine --- >From problem-statement-bounces@alvestrand.no Fri May 30 09:33:13 2003 Delivered-To: problem-statement@alvestrand.no To: problem-statement@alvestrand.no From: Melinda Shore Date: Fri, 30 May 2003 09:32:52 -0400 Subject: 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 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 From problem-statement-bounces@alvestrand.no Fri May 30 12:00: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 MAA14305 for ; Fri, 30 May 2003 12:00:42 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7E2C46220B; Fri, 30 May 2003 18:00:12 +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 2AF0F621FB for ; Fri, 30 May 2003 18:00:06 +0200 (CEST) Received: from backin5.merit.edu (backin5.merit.edu [198.108.60.28]) by segue.merit.edu (Postfix) with ESMTP id 5418E5DDA7; Fri, 30 May 2003 12:00:03 -0400 (EDT) Date: Fri, 30 May 2003 12:00:03 -0400 (EDT) From: Susan Harris To: Melinda Shore In-Reply-To: <200305301332.AHU57215@mira-sjc5-c.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Yes. On Fri, 30 May 2003, 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 > > From problem-statement-bounces@alvestrand.no Fri May 30 12:04: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 MAA14386 for ; Fri, 30 May 2003 12:04:05 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E4AC762571; Fri, 30 May 2003 18:03:35 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by eikenes.alvestrand.no (Postfix) with ESMTP id AE569621FB for ; Fri, 30 May 2003 18:03:32 +0200 (CEST) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id E1672137F25; Fri, 30 May 2003 09:03:30 -0700 (PDT) Date: Fri, 30 May 2003 09:03:30 -0700 (PDT) From: April Marine To: Melinda Shore In-Reply-To: <200305301332.AHU57215@mira-sjc5-c.cisco.com> Message-ID: <20030530090327.K69840-100000@shell.nominum.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 no. On Fri, 30 May 2003, 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 > > From problem-statement-bounces@alvestrand.no Fri May 30 13:12: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 NAA17424 for ; Fri, 30 May 2003 13:12:28 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7239D6220B; Fri, 30 May 2003 19:11:58 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from znsgs01r.nortelnetworks.com (h3s128a211n47.user.nortelnetworks.com [47.211.128.3]) by eikenes.alvestrand.no (Postfix) with ESMTP id DA7386220B for ; Fri, 30 May 2003 19:11:55 +0200 (CEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124])id h4UHBh107797; Fri, 30 May 2003 18:11:43 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 May 2003 18:11:44 +0100 Message-ID: <4103264BC8D3D51180B7002048400C4501623494@zhard0jd.europe.nortel.com> From: "Elwyn Davies" To: "'Melinda Shore'" , "'problem-statement@alvestrand.no'" Date: Fri, 30 May 2003 18:11:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C326CC.5C62007A" 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 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_01C326CC.5C62007A Content-Type: text/plain; charset="iso-8859-1" Yes. Elwyn > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: 30 May 2003 14:33 > To: problem-statement@alvestrand.no > Subject: Query: adding additional AD > > > 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 > > ------_=_NextPart_001_01C326CC.5C62007A Content-Type: text/html; charset="iso-8859-1" RE: Query: adding additional AD

Yes.

Elwyn

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: 30 May 2003 14:33
> To: problem-statement@alvestrand.no
> Subject: Query: adding additional AD
>
>
> 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
>
>

------_=_NextPart_001_01C326CC.5C62007A-- From problem-statement-bounces@alvestrand.no Fri May 30 13:19: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 NAA17525 for ; Fri, 30 May 2003 13:19:57 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AFA446220B; Fri, 30 May 2003 19:19:27 +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 2F909621FB for ; Fri, 30 May 2003 19:19:21 +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 KAA10258; Fri, 30 May 2003 10:19:20 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4UHJJS11930; Fri, 30 May 2003 10:19:19 -0700 X-mProtect: <200305301719> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.150, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCjaJXg; Fri, 30 May 2003 10:19:18 PDT Message-Id: <4.3.2.7.2.20030530101443.02bbafd8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 May 2003 10:18:14 -0700 To: Melinda Shore From: Bob Hinden In-Reply-To: <200305301332.AHU57215@mira-sjc5-c.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Melinda, Yes, as long as the it does not include creating and approving rules for how the IESG operates. The IESG should not be approving it's own operating rules. Bob At 06:32 AM 5/30/2003, 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 From problem-statement-bounces@alvestrand.no Fri May 30 20:37: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 UAA05540 for ; Fri, 30 May 2003 20:37:40 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 511F66220B; Sat, 31 May 2003 02:37:09 +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 1CE9A621FB for ; Sat, 31 May 2003 02:37:08 +0200 (CEST) Received: from medea.wz-berlin.de ([193.174.6.5]) by athene.wz-berlin.de with esmtp (Exim 4.20) id 19LuMs-0001s9-W7; Sat, 31 May 2003 02:37:06 +0200 Received: from ERDE/SpoolDir by medea.wz-berlin.de (Mercury 1.48); 31 May 03 02:37:07 +0200 Received: from SpoolDir by ERDE (Mercury 1.48); 31 May 03 02:36:57 +0200 From: "Jeanette Hofmann" Organization: Wissenschaftszentrum Berlin To: Melinda Shore Date: Sat, 31 May 2003 02:36:48 +0200 MIME-Version: 1.0 Message-ID: <3ED81541.14755.10282EC@localhost> Priority: normal In-reply-to: <200305301332.AHU57215@mira-sjc5-c.cisco.com> 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: 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 On 30 May 2003 at 9:32, 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? Yes, an additional AD, who is not part of the body that is in need of change might be able to manage the process more forcefully and directively. And a new AD is a cleaner approach in my view. However, I think the option "additional AD" is only worth pursuing if there is a clear majority who supports it. Otherwise the weaker option seems more legitimate. jeanette 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 > From problem-statement-bounces@alvestrand.no Fri May 30 23:00: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 XAA09569 for ; Fri, 30 May 2003 23:00:26 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AD9A762207; Sat, 31 May 2003 04:59:56 +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 82FCC621FB for ; Sat, 31 May 2003 04:59:53 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.15]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id TAA15168; Fri, 30 May 2003 19:59:27 -0700 (PDT) Message-Id: <5.1.0.14.2.20030530225052.03bc3058@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 30 May 2003 22:51:38 -0400 To: Melinda Shore From: Margaret Wasserman In-Reply-To: <200305301332.AHU57215@mira-sjc5-c.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Just for the record... No, I'd prefer that the IESG didn't add a new AD. Margaret At 09:32 AM 5/30/2003 -0400, 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 From problem-statement-bounces@alvestrand.no Sat May 31 01:19: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 BAA12031 for ; Sat, 31 May 2003 01:19:45 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 780F162207; Sat, 31 May 2003 07:19:13 +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 B694C621FB for ; Sat, 31 May 2003 07:19:11 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19Lylp-000KjV-DN; Fri, 30 May 2003 22:19:09 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 30 May 2003 22:19:08 -0700 To: Margaret Wasserman References: <200305301332.AHU57215@mira-sjc5-c.cisco.com> <5.1.0.14.2.20030530225052.03bc3058@mail.windriver.com> Message-Id: 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: 7bit > No, I'd prefer that the IESG didn't add a new AD. agree From problem-statement-bounces@alvestrand.no Sat May 31 12:48: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 MAA05493 for ; Sat, 31 May 2003 12:48:31 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 60F1A62573; Sat, 31 May 2003 18:48:01 +0200 (CEST) Delivered-To: problem-statement@alvestrand.no Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by eikenes.alvestrand.no (Postfix) with ESMTP id 272566256B for ; Sat, 31 May 2003 18:48:00 +0200 (CEST) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id EB8EE18F0 for ; Sat, 31 May 2003 12:47:57 -0400 (EDT) Date: Sat, 31 May 2003 12:47:57 -0400 From: Rob Austein To: problem-statement@alvestrand.no In-Reply-To: <200305301332.AHU57215@mira-sjc5-c.cisco.com> References: <200305301332.AHU57215@mira-sjc5-c.cisco.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030531164758.EB8EE18F0@thrintun.hactrn.net> 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. From problem-statement-bounces@alvestrand.no Sat May 31 21:58: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 VAA16186 for ; Sat, 31 May 2003 21:58:17 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0F63C6238A; Sun, 1 Jun 2003 03:57: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 1D11661DEC for ; Sun, 1 Jun 2003 03:57:44 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id SAA20922 for ; Sat, 31 May 2003 18:57:23 -0700 (PDT) Message-Id: <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 31 May 2003 21:53:20 -0400 To: problem-statement@alvestrand.no From: Margaret Wasserman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: 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 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 Sat May 31 22:10: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 WAA16373 for ; Sat, 31 May 2003 22:10:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED5E66238C; Sun, 1 Jun 2003 04:09:58 +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 520DF61D30 for ; Sun, 1 Jun 2003 04:09:45 +0200 (CEST) Received: from IDLEWYLDE.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id TAA23806 for ; Sat, 31 May 2003 19:09:24 -0700 (PDT) Message-Id: <5.1.0.14.2.20030531215652.04333d20@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 31 May 2003 22:05:24 -0400 To: problem-statement@alvestrand.no From: Margaret Wasserman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: 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 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'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. If not, what process should we use to improve the quality of WG output? Margaret --- 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. From problem-statement-bounces@alvestrand.no Sat May 31 23:40: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 XAA17943 for ; Sat, 31 May 2003 23:40:39 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1C50F62251; Sun, 1 Jun 2003 05:40:09 +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 1D5D061D30 for ; Sun, 1 Jun 2003 05:40:07 +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 19MJhR-0006q1-00; Sat, 31 May 2003 20:40:01 -0700 Date: Sat, 31 May 2003 23:38:16 -0400 From: Keith Moore To: Margaret Wasserman Message-Id: <20030531233816.40e5dbf9.moore@cs.utk.edu> In-Reply-To: <5.1.0.14.2.20030531213807.03008e18@mail.windriver.com> References: <5.1.0.14.2.20030531213807.03008e18@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: 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 > Do people think that these are the right things to do? I think we need to take on a few other things besides: 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) The reason I say this is that several groups have demonstrated the inability to define the problem they are working on, and several groups have reached the Last Call stage while failing to meet some basic requirement (like authentication) or failing to understand some important negative impact of their protocols (like the effect of scoped addresses on applications). By establishing a series of steps that should be undertaken in protocol design, we should be able to gain confidence much earlier that a protocol design has taken into account needs that can be anticipated, and in turn, this should provide confidence that the protocol will ultimately be approved without significant late changes. This will be awkward and uncomfortable for people to do at first, but it's the very basis of engineering. 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. 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. 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. ***************************************************************************** Problems 1 and 2 are deeply embedded in IETF culture, but they are also probably the things that most need to change, if we want to improve the timeliness or quality of IETF's output. And due to the amount of inertia, it will be very hard to make small changes work. The changes will need to appear to be drastic to overcome that inertia - it will need to _feel different_ than it does now (and probably different than it ever has) when you're participating in an IETF WG - whether over the net or at a f2f meeting. ***************************************************************************** 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. 4. We need to reorganize our document series. (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.