Re: Issues around sponsoring individual documents
John C Klensin <john-ietf@jck.com> Mon, 10 September 2007 14:58 UTC
Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkiI-0008N9-Pq; Mon, 10 Sep 2007 10:58:10 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUkiH-0008N3-JX for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 10:58:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkiH-0008Mv-A3 for discuss@apps.ietf.org; Mon, 10 Sep 2007 10:58:09 -0400
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUkiB-0008DX-OA for discuss@apps.ietf.org; Mon, 10 Sep 2007 10:58:09 -0400
Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1IUki8-000M3v-Jg; Mon, 10 Sep 2007 10:58:01 -0400
Date: Mon, 10 Sep 2007 10:57:58 -0400
From: John C Klensin <john-ietf@jck.com>
To: Lars Eggert <lars.eggert@nokia.com>, ext Lisa Dusseault <ldusseault@commerce.net>
Subject: Re: Issues around sponsoring individual documents
Message-ID: <0BDD887F6192620BD79F5C4D@[192.168.1.110]>
In-Reply-To: <549EFD98-2A83-4E57-994C-E52A40729152@nokia.com>
References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> <549EFD98-2A83-4E57-994C-E52A40729152@nokia.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
Cc: Apps Discuss <discuss@apps.ietf.org>
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org
--On Monday, September 10, 2007 2:17 PM +0300 Lars Eggert <lars.eggert@nokia.com> wrote: > Hi, > > you've gotten a lot of good feedback already. My viewpoint > differs a bit, in that I'm more hesitant about the widespread > use of the IS path. An IS should be a rare exception, with the > much more well-defined and -tested WG process the rule. Lars, I have to disagree, unless the WG process can be made both a lot more efficient and a lot lower noise. See my earlier note about this and please understand that the Apps area may be more subject to the noise factor than other areas... for several reasons, some good and some bad. > Because people see the IS path as a shortcut - and even worse, > an "insider" shortcut - the more you let them take it, the > more requests you will get in the future. Well, some of us don't see it primarily as a shortcut (although sometimes it might be) but as a more efficient way to get some kinds of work done. > It starts to erode > the process. Just say no. Or, actually, ask yourself if the > gain from pushing something through as an IS is worth the pain > in terms of extra management and maybe future work. If the > gain is worth it *to you* (don't forget the IS path is at your > discretion, and your judgement decides) then sure, go ahead. > But in general, I'd encourage you to tell people to publish > their documents through the appropriate working group, and if > there isn't one, tell them to prepare a BOF. Which, under most circumstances, immediately adds at least four to six months to the process without, in most cases, getting any incremental work done. It also tends to open up discussions about what problem should be solved. That is extremely useful in some cases and a total waste of time in others, but the length of time it takes seems to be independent of value. As costs rise and industry pressure for timely results increases, "go spend an extra six (or more) months organizing a WG and then take twice the time a WG should take, not due to tying down details but with trying to deal fairly with irrelevant noise" is going to be increasingly equivalent to "take that work outside the IETF". I don't think an IETF effort should take one day less time than it takes to get things right (separating me from some folks who favor "accept the tolerably good as long as it is timely") but I don't think it should take one week longer, either. I don't think that convincing people to go elsewhere is a desirable outcome. That is especially true when the issue at hand is revision/ advancement of existing IETF standards, where we know who most of the experts are, have mailing lists on which to "advertise" for participants, have constraints about what changes can be made, and really don't need to spend WG time reopening old issues. > WGs have existed > to only work on one or two documents (PMTUD, for example). WGs > come with chairs and they come with an established management > process, both of which reduce your workload (even more so with > PROTO). Having been an AD, although long ago, and watched the process for years, I question that generality of this assertion too. Sometimes they do, sometimes they don't. > PS: Another alternative to IS is something like TSVWG (and now > OPSAWG) to work in a more open fashion on documents and topics > that maybe don't warrant their own WG. Sure. But it is not clear to me that those groups really force the kind of topic-specific expert review that we assume that we get from "ordinary" WGs. If they do, that is fine. But, if they don't, we may delude ourselves by then using a shortcut community review process that is inappropriate to those groups. With the diversity of Apps such groups tend to be particularly inappropriate (been there, tried that). We have tried, or at least discussed, a number of other alternatives to "pure" individual submission handling in Apps. I've shared some of these with Lisa. They include special open directorate review meetings (perhaps more like SAAG than like TSVWG, but I'm not sure any more), extending the Apps Area review process (which seems to work well), open review sessions at IETF meetings (tried once with IDNAbis and something I would recommend based on that experience) and generally holding independent submission authors and advocates responsible for demonstrating that adequate review has occurred. One size does not fit all. regards, john
- Issues around sponsoring individual documents Lisa Dusseault
- Re: Issues around sponsoring individual documents John Leslie
- Re: Issues around sponsoring individual documents Keith Moore
- Re: Issues around sponsoring individual documents Martin Duerst
- Re: Issues around sponsoring individual documents Eliot Lear
- Re: Issues around sponsoring individual documents John C Klensin
- Re: Issues around sponsoring individual documents tom.petch
- Re: Issues around sponsoring individual documents Jari Arkko
- Re: Issues around sponsoring individual documents James M Snell
- Re: Issues around sponsoring individual documents Dave Crocker
- Re: Issues around sponsoring individual documents Lisa Dusseault
- Re: Issues around sponsoring individual documents Lisa Dusseault
- Re: Issues around sponsoring individual documents Martin Duerst
- Re: Issues around sponsoring individual documents Dave Crocker
- Re: Issues around sponsoring individual documents Lars Eggert
- Re: Issues around sponsoring individual documents Lars Eggert
- Re: Issues around sponsoring individual documents John C Klensin
- Re: Issues around sponsoring individual documents Lars Eggert
- Re: Issues around sponsoring individual documents Keith Moore
- Re: Issues around sponsoring individual documents tom.petch
- Re: Issues around sponsoring individual documents Keith Moore
- Re: Issues around sponsoring individual documents Lisa Dusseault
- Re: Issues around sponsoring individual documents Graham Klyne