Re: Issues around sponsoring individual documents

Keith Moore <moore@cs.utk.edu> Fri, 07 September 2007 02:04 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 1ITTCi-0003kl-Sq; Thu, 06 Sep 2007 22:04:16 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1ITTCh-0003il-Nb for discuss-confirm+ok@megatron.ietf.org; Thu, 06 Sep 2007 22:04:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITTCh-0003id-Dk for discuss@apps.ietf.org; Thu, 06 Sep 2007 22:04:15 -0400
Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITTCg-00038P-4x for discuss@apps.ietf.org; Thu, 06 Sep 2007 22:04:15 -0400
Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 888121EE24F; Thu, 6 Sep 2007 22:04:09 -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 IuVQC3WGCIyW; Thu, 6 Sep 2007 22:04:05 -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 945701EE249; Thu, 6 Sep 2007 22:04:00 -0400 (EDT)
Message-ID: <46E0B18D.6030805@cs.utk.edu>
Date: Thu, 06 Sep 2007 22:03:57 -0400
From: Keith Moore <moore@cs.utk.edu>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: Lisa Dusseault <ldusseault@commerce.net>
Subject: Re: Issues around sponsoring individual documents
References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net>
In-Reply-To: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net>
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: 932cba6e0228cc603da43d861a7e09d8
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

Lisa Dusseault wrote:
>
> The Applications area does not have a lot of attendees or WGs (I
> oversee five, and of those five, three are within a document or two of
> closing).  Much of the current work is being done as individual
> submissions (abbreviated IS in this email) [0].  I'd like to get some
> input on how IS's should be handled.  I have many opinions on IS
> tradeoffs, having written several and sponsored more, but I'm trying
> to phrase these questions without entirely presupposing my own
> answers, and to reflect conflicted opinions and the criticisms I've
> heard.
>
> (BTW, I'm sure I can follow the advice of "Use your judgement" if
> anybody decides to say that, but it doesn't really inform that
> judgement does it?  )
>
> Is an IS that defines a new protocol for the Standards Track fine in
> general?
> Is an IS that extends a standard protocol developed in a WG fine in
> general?
> Is an IS that obsoletes a standard protocol developed in a WG fine in
> general?
None of the above.  All of them are acceptable according to process, but
that doesn't mean that they're fine in general.

I see two cases where ISes are appropriate vehicles for standards actions:

1. The proposal is simple and noncontroversial, and there is already a
significant and identifiable community in the IETF (or close to it) that
can competently evaluate it.   There's really no need for a WG to refine
the proposal because the proposal is simple enough that its effects are 
easily understood.  (examples include some - not all - proposals for new
email headers, new MIME types, that sort of thing)

2. Careful analysis reveals that the proposal only affects a narrow and
well-identified group of people, and those people have already reached
consensus on the proposal. So there's no need to spin up a WG that
consists only of that set of people.


> Do IS's suffer from less review?  Is that a problem?
> Whose responsibility is it to get sufficient review?
Yes they do, in general.  It's not a problem as long as the process is
used only for cases like the ones I mention above.  generally, having
the IS process seems like a good thing, but it does require AD/IESG
discretion to prevent it from being used as a end-run around the full WG
process.
> Is it mostly well-connected individuals that can use the IS track,
> knowing an AD to do the sponsoring?  Or mostly individuals with a lot
> of time on their hands?
It's not an either-or.  Both sets of individuals enjoy an advantage.  A
well-connected individual with a lot of time on his hands enjoys an even
greater advantage.  :)

IMHO, there's nothing wrong with the standards process having a lower
barrier for simple, uncontroversial, easy to analyze proposals, than it
has for proposals that require more deliberation  by a WG and/or by
IESG.  However if a well-connected individual can somehow use this lower
barrier to get his IS adopted as a standard before a less well-connected
individual or industry group can get his/their IS on a similar topic
submitted to IESG (or before they can get a WG formed to work on that
problem), that might be a problem.
> An IS can have a non-AD document shepherd.  Does encouraging that
> improve the situation or make IS publishing even more dependent on the
> author's connections?
Offhand I think the more people available to shepherd a document, the
wider the set of authors who might obtain sponsors. 
> Should I limit time spent sponsoring IS's? [1]  IESG work plus IS work
> could consume 30 hours a week, or 40, or 50...
Yes.  WG proposals should take precedence over ISs, and you should
probably set limits on the time you spend doing IESG work.  Otherwise it
will eat your life (it did mine).    I don't think that we should expect
ADs or IESG to evaluate IS proposals within strict time limits like we
do for WG proposals.
> Assuming I limit the potentially endless amount of work devoted to
> IS's, do I limit it algorithmically (e.g. first come first served), 
> as a matter of pure taste, or other?
> How should I prioritize IS sponsoring work? Which documents get my
> attention first?  [2]
I think if I were doing it, I'd basically use a rough FIFO order so that
old proposals would definitely get looked at.  but within a set of
documents submitted within a particular time-slot, I'd use a greedy
algorithm - the documents that involve the least work for the AD would
get handled first.  after that, the documents that are harder to review
or provide feedback for, but which seemed to have the most benefit for
the community would get processed. 
> When there's a question of consensus for an IS document, should I just
> drop the document?
> Assuming I try to determine consensus how do I do so without an
> official owning WG -- consensus calls to the IETF discuss list? 
> Choose a related list and hope people are paying attention?
> Do I need to ensure there's a quorum?
I don't think such documents should be dropped immediately.  But neither
do I think the AD needs to spend a lot of effort sorting them out. 
Basically I'd try to make it up to the IS author and those who commented
on it to try to reach a compromise by themselves.  Give them, say, a 4
week timeout. After that timeout, one of two things happens: (1) the
parties are in agreement that this (perhaps updated) document is the way
forward.  (2) the parties couldn't fully agree but the author argues
that the (perhaps updated) document has rough community consensus (the
objections notwithstanding) and meets the quality requirements for
standards-track outlined in RFC2026 or wherever.   If the document was
updated, a new Last Call is needed.  After that Last Call (if any) the
AD re-evaluates the situation and makes a recommendation to the full
IESG to either drop the document (requiring the author to re-apply for
IS action after some time) or approve it as-is (despite objections if any).
> How would appeals against IS documents affect answers to these issues?
> (Usually individual ADs take the first stab at handling appeals,
> formal or informal, against WG chair decisions.  When there's no WG
> chair involved with a doc, I guess the appeal would go straight to the
> whole IESG...)
> Does sponsoring many IS documents give an AD, and the IESG as a whole,
> too much power?
AD and IESG discretion is needed to keep this from happening.  But
should IESG decide that the way to make progress in IETF is to do as
much as possible with ISes and avoid forming working groups, it's hard
to know what the best remedy is.

Basically I think that it might be wise to have more formal criteria for
what makes a valid IS, and to make approval of an IS subject to appeal
if those criteria are violated.
> Are we discouraging legitimate WGs by encouraging IS's?
I think that there are cases where ISs are used to process things that
really need more discussion and review, because many in industry see our
WG process is seen as burdensome...and sometimes, subject to input from
the "wrong" people.  but that might be more indicative of problems with
our WG process than of problems with our IS process.
> What other purposes do WG's serve besides simply publishing documents,
> that are not met by IS's? [3]
Assuming that IETF can artract a wide enough set of interested parties,
WGs are much better than non-WGs at determining requirements,  avoiding
output that harms valid interests, and review and refinement of
nontrivial specifications.  Also, there are processes required of WGs to
ensure fairness that can't be applied to individuals.
> If we turned down ISs in Apps, would the proposed work die, go
> elsewhere or ... ?  Would that be bad?
What would happen, and whether that would be bad, depends on the
specific work. 

Keith