Return-Path: Received: from murder ([unix socket]) by eikenes.alvestrand.no (Cyrus v2.2.8-Mandrake-RPM-2.2.8-4.2.101mdk) with LMTPA; Wed, 04 May 2005 17:09:07 +0200 X-Sieve: CMU Sieve 2.2 Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DCF2161B5A for ; Wed, 4 May 2005 17:09:07 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19471-03 for ; Wed, 4 May 2005 17:09:05 +0200 (CEST) X-Greylist: domain auto-whitelisted by SQLgrey-1.4.8 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id 28CCA61AF1 for ; Wed, 4 May 2005 17:08:58 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTLRb-0008N9-BB; Wed, 04 May 2005 11:05:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTLRX-0008Kv-ES for ietf@megatron.ietf.org; Wed, 04 May 2005 11:05:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18911 for ; Wed, 4 May 2005 11:05:40 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTLfc-0000xD-RI for ietf@ietf.org; Wed, 04 May 2005 11:20:18 -0400 Received: from lns-p19-8-idf-82-65-78-79.adsl.proxad.net ([82.65.78.79] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DTLRK-0006uI-Hr; Wed, 04 May 2005 08:05:31 -0700 Message-Id: <6.2.1.2.2.20050504111230.0347eae0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 04 May 2005 17:05:21 +0200 To: Ralph Droms , Keith Moore From: "JFC (Jefsey) Morfin" In-Reply-To: <1115166149.5285.15.camel@localhost.localdomain> References: <20050428062402.XZEM20133.fep01-app.kolumbus.fi@mta.im ail.kolumbus.fi> <20050428141236.0f9a9fab.moore@cs.utk.edu> <51B6ED2812DB71A87A1BF836@scan.jck.com> <20050428150045.62a627e8.moore@cs.utk.edu> <42715967.80508@isi.edu> <892331f072cf1b9741218f679fa366f3@cs.utk.edu> <1114728905.11628.34.camel@localhost.localdomain> <482f91815aa54a99c4d772a997e94554@cs.utk.edu> <1114781735.18867.35.camel@localhost.localdomain> <20050429121933.4c622ee6.moore@cs.utk.edu> <1115166149.5285.15.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ietf@ietf.org Subject: Re: text suggested by ADs X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org X-Virus-Scanned: amavisd-new at alvestrand.no I see that many points made _may_ lead to personal controversy (not the target). I hate rigidity and procedures but I love method. We may like it or not, but IETF is only subject to good practices as a guidance to imperfect members trying their best. Rules will not change that. But we might accept some IETFiquette permitting to achieve more. I have always been impressed by RFC 1958 which actually defines the architecture of the Internet without any rule. I think it misses a model, the same as I think sometimes IETF misses method; but it seems to work. I would suggest that instead of commenting at length on each others comments, those who have a suggestion makes it a short sentence and we make a list of it. Not as a rule, but as guidance. After a while, the ones which work would de facto become part of the Thao of the IETF. I would suggest one: "When a Charter is assigned or updated, the WG should review it until the AD are satisfied it has been understood, and the WG is satisfied the AD and the IESG have understood the enhancements proposed by the WG from its own members experience." As discussed here AD and IESG may know better than the WG in some cases, or less in other cases. It is important that in both cases they first understand each other over the expected deliverables, rather than dispute at the end. IETFiquette should prevent any WG work before there is a consensus that such a common understanding has been reached. A Charter should not be "not up for debate" until the Chair and a part of the WH has complete their work on a predetermined proposition. jfc At 02:22 04/05/2005, Ralph Droms wrote: >On Fri, 2005-04-29 at 12:19 -0400, Keith Moore wrote: > > Let me also restate for clarity: > > > > > Let me restate for clarity - ADs aren't necessarily more technically > > > astute than *all* the rest of us. That is, we need to be careful that > > > technical input from ADs isn't automatically assigned extra weight or > > > control (veto power). > > > > There's no way to avoid that happening and still have quality control. > >Why is that? If an AD has a compelling reason that a specification >needs work, the AD should be able to make a convincing argument to the >IETF as a whole. Best way to do that is in an open conversation during >the IETF last call. > > > > Which is why I suggest ADs provide technical input in open mailing lists > > > during last calls, to make sure their technical input is on the same > > > footing as everyone else's technical input. I agree that the IESG's job > > > is to ensure correctness, completeness, etc. That feedback should be > > > provided earlier, in an open forum. > > > > I agree that input should be provided as early as possible. But some > > kinds of feedback inherently follow Last Call, > >Such as? > > > and limiting IESG input > > to before Last Call would just serve to make the process even slower > > than it already is (by requiring multiple IESG reviews rather than just > > one), > >I disagree - suppose the gating function comes *before* the IETF last >call: before a draft goes to IETF last call, the ADs all agree that they >are prepared (have cycles, aren't travelling, etc.) to review and >comment on the draft. > >My experience has been that the there can be an unbounded delay between >the IETF last call and the IESG review. > > > while lowering publication quality (by preventing IESG from > > objecting to valid technical issues noticed after Last Call, and perhaps > > discovered while considering Last Call input, but not directly related > > to issues raised in Last Call). > > > > Keith > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf