Re: Issues around sponsoring individual documents

Keith Moore <moore@cs.utk.edu> Mon, 10 September 2007 16:43 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 1IUmLv-0000Ts-2I; Mon, 10 Sep 2007 12:43:11 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUmLt-0000Tm-OL for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 12:43:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUmLt-0000Te-Ep for discuss@apps.ietf.org; Mon, 10 Sep 2007 12:43:09 -0400
Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUmLs-0002k5-7q for discuss@apps.ietf.org; Mon, 10 Sep 2007 12:43:09 -0400
Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 2D0F71EE262; Mon, 10 Sep 2007 12:43:07 -0400 (EDT)
X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu
Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSTiUCAQKsjW; Mon, 10 Sep 2007 12:43:04 -0400 (EDT)
Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 2CB2A1EE251; Mon, 10 Sep 2007 12:42:54 -0400 (EDT)
Message-ID: <46E5740E.9090909@cs.utk.edu>
Date: Mon, 10 Sep 2007 12:42:54 -0400
From: Keith Moore <moore@cs.utk.edu>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>
Subject: Re: Issues around sponsoring individual documents
References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> <549EFD98-2A83-4E57-994C-E52A40729152@nokia.com> <0BDD887F6192620BD79F5C4D@[192.168.1.110]>
In-Reply-To: <0BDD887F6192620BD79F5C4D@[192.168.1.110]>
X-Enigmail-Version: 0.95.3
OpenPGP: id=E1473978
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: Apps Discuss <discuss@apps.ietf.org>, ext Lisa Dusseault <ldusseault@commerce.net>
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

>>
>> 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.
Certainly the WG process needs to be made more efficient, and the noise
reduced.  I just don't see the IS process as a way to solve this
problem.  If not used judiciously the IS process will just further lower
the quality of IETF's work. 

>> 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.
True enough.  That discussion does take at least four to six months -
independent of how difficult the problem actually is.  You want to
reserve WGs for the tasks where such discussions are useful and
appropriate and will contribute to the quality of the overall effort. 
And really this four to six months is what it takes for a group of
people with diverse backgrounds to begin to understand each other and
start speaking in somewhat the same language.  For new standards that
need input from people with diverse backgrounds, this process is
necessary - even though product development people will hate it.  For
established standards that just need revision, I agree that the process
is usually not necessary and just wasteful.  One exception would be when
an established standard has seen widespread use outside its intended
scope, and needs to be revised in light of the scope as newly understood.

(Actually my impression is that if a WG is chartered to only develop
"requirements" before needing re-chartering, then the WG takes about
12-18 months just to develop requirements.  If the WG is chartered to do
additional work, there's more incentive to get the requirements part
done faster.  And IMHO WGs should never be chartered to do
"requirements", because this causes too many decisions to be carved in
stone before their effects are understood.  "design goals" would be much
better.   But somehow the "requirements" meme has stuck in IETF and
won't go away.)

Keith