Re: Saying no (was: Re: Last Call: <draft-ietf-opsec-lla-only-07.txt> (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC)
John C Klensin <john-ietf@jck.com> Sun, 30 March 2014 20:42 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5041A08D1; Sun, 30 Mar 2014 13:42:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNM0mznfxLHK; Sun, 30 Mar 2014 13:42:06 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA411A07D7; Sun, 30 Mar 2014 13:42:05 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1WUMYD-000Osu-V7; Sun, 30 Mar 2014 16:41:53 -0400
Date: Sun, 30 Mar 2014 16:41:48 -0400
From: John C Klensin <john-ietf@jck.com>
To: Andrew Sullivan <ajs@anvilwalrusden.com>, John Leslie <john@jlc.net>
Subject: Re: Saying no (was: Re: Last Call: <draft-ietf-opsec-lla-only-07.txt> (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC)
Message-ID: <A1B5D847B9E664DAAE6DAA8B@JcK-HP8200.jck.com>
In-Reply-To: <20140327234136.GC51988@mx1.yitter.info>
References: <CF59AE52.16403%wesley.george@twcable.com> <53349FFB.7050108@qti.qualcomm.com> <m2r45nfdwk.wl%randy@psg.com> <20140327233422.GD87785@verdi> <20140327234136.GC51988@mx1.yitter.info>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.115
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/jtT045kx8HNNjftPOrJ1Eisz7ZE
Cc: Pete Resnick <presnick@qti.qualcomm.com>, IETF Disgust <ietf@ietf.org>, opsec wg mailing list <opsec@ietf.org>, The IESG <iesg@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Mar 2014 20:42:08 -0000
--On Thursday, March 27, 2014 17:55 -0500 Pete Resnick <presnick@qti.qualcomm.com> wrote: > Oh, don't get me wrong. When I say "fix it", I don't mean that > they necessarily need to fix the protocol the approach. I > simply mean fix the document, which may amount to the WG > getting sufficient text in to say, "This is only useful in X Y > and Z circumstances and is otherwise a bad idea and you > shouldn't do it." We are happy to publish all sorts of > applicability statements that say, "This is stupid in all but > these circumstances." I just don't want the IESG to have to > write it up. The WG should make their document reflect what > the community wants. --On Thursday, March 27, 2014 19:41 -0400 Andrew Sullivan <ajs@anvilwalrusden.com> wrote: > On Thu, Mar 27, 2014 at 07:34:22PM -0400, John Leslie wrote: >> >> The sad truth is, the IESG no longer has the spare cycles >> to "Just say No." > > I was on the receiving end of an IESG that simply stalled a > document until the WG changed its approach, because of IETF > concerns, so I disagree with that claim. But if it is true, > then we might as well give up. If there's weak IETF consensus > (with some strong objections) to a document that comes from a > WG and has strong consensus inside the WG, the _only_ people > who can say no are the IESG; and they must. Hi. Two observations: (1) If the IESG were to ever reach the point that it doesn't have the cycles to properly evaluate community consensus about a document and to make sure that the document reflects that consensus before it is published, then they, and we, are in bad trouble. That is one or only two key parts of the IESG job (the other being WG oversight). If the IESG doesn't have the cycles do that that and still do anything else, then the "anything else" should go. If doing this type of work is still not possible, I'd expect to see the IESG giving serious consideration to procedural changes that would reduce their workload [1], reducing the number of WGs to what they can handle [2], or resigning in the hope that the Nomcom can find people with either the cycles or the willingness to make changes. (2) Like Pete, I strongly prefer getting a document to the point where it is consistent with community consensus by having the responsible WG and document editors make changes rather than using IESG statements. The latter should, IMO, be reserved for the most unusual situations if they are used at all. But the priority should be that we never publish an IETF-stream document, especially a standards track one, that doesn't reflect community consensus without its being very clear about that. (3) If a WG and the community run out of cycles to get a document right, then the document ought to be dead, especially if it is proposed for standards track. Too bad, but,... (4) Some of the notes in this thread -- and some IESG actions in the past-- have implied that at appropriate goal of the IESG review process is to find compromise positions that make everyone more or less happy. IMO, if we ever reach the point where we believe that, we will have given up everything that makes IETF standards superior to those of SDOs who believe that something produced by a WG, or even seriously proposed to one, is entitled to standardization. Our standards, and the Internet itself, work because we have focused on good, workable, solutions -- ideally with a minimum of options that could lead, intentionally or not, to lack of interoperability-- not compromises among ground who want "their" ideas standardized and the resulting "almost anything conforms" standards. john we should expect to see a lot of resignations (1) If we reach the point that either the IESG [1] (there has been no shortage of such proposals
- Re: Last Call: <draft-ietf-opsec-lla-only-07.txt>… George, Wes
- Re: Last Call: <draft-ietf-opsec-lla-only-07.txt>… Pete Resnick
- Re: Last Call: <draft-ietf-opsec-lla-only-07.txt>… joel jaeggli
- Re: Last Call: <draft-ietf-opsec-lla-only-07.txt>… Pete Resnick
- Re: Last Call: <draft-ietf-opsec-lla-only-07.txt>… Randy Bush
- Re: Last Call: <draft-ietf-opsec-lla-only-07.txt>… John Leslie
- Saying no (was: Re: Last Call: <draft-ietf-opsec-… Andrew Sullivan
- Re: Saying no joel jaeggli
- Re: Saying no (was: Re: Last Call: <draft-ietf-op… John Leslie
- Re: Saying no (was: Re: Last Call: <draft-ietf-op… Ted Lemon
- Re: Saying no (was: Re: Last Call: <draft-ietf-op… Abdussalam Baryun
- Re: Last Call: <draft-ietf-opsec-lla-only-07.txt>… George, Wes
- Re: Saying no (was: Re: Last Call: <draft-ietf-op… John C Klensin
- RE: Last Call: <draft-ietf-opsec-lla-only-07.txt>… Gunter Van de Velde (gvandeve)