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