Re: Issues around sponsoring individual documents

Jari Arkko <jari.arkko@piuha.net> Fri, 07 September 2007 15:59 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 1ITgEa-00087X-Pv; Fri, 07 Sep 2007 11:59:04 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1ITd0D-0004fJ-SA for discuss-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 08:32:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITd0D-0004fB-If for discuss@apps.ietf.org; Fri, 07 Sep 2007 08:32:01 -0400
Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITd0C-0007lr-09 for discuss@apps.ietf.org; Fri, 07 Sep 2007 08:32:01 -0400
Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A5FE8198659; Fri, 7 Sep 2007 15:31:58 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 349E7198658; Fri, 7 Sep 2007 15:31:58 +0300 (EEST)
Message-ID: <46E144BF.1010909@piuha.net>
Date: Fri, 07 Sep 2007 15:31:59 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 1.5.0.13 (X11/20070824)
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>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
X-Mailman-Approved-At: Fri, 07 Sep 2007 11:59:04 -0400
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,

You already got excellent feedback, but a couple of additional notes
below:

First, you know but the readers of this list might not know that there's
an ION on this topic:

  http://www.ietf.org/IESG/content/ions/ion-ad-sponsoring.html

The ION talks about, among other things, what factors the AD should
consider when thinking about sponsoring a document (Section 5)
and in what situations requiring all work to come from WGs is
problematic (Section 6).

> Do IS's suffer from less review?  Is that a problem?
> Whose responsibility is it to get sufficient review?
>
> Is it mostly well-connected individuals that can use the IS track,
> knowing an AD to do the sponsoring?

The AD should not accept proposals only from his or her friends;
they can come from anybody and the same criteria should be
used to judge all proposals. However, the ability to make such
submissions is not perhaps widely enough known.

> Does encouraging that improve the situation or make IS publishing even
> more dependent on the author's connections?

In my experience, having a shepherd does help. You get one more
additional pair of eyes looking at the document, plus you can delegate
some of the discussion during Last Call or with other reviewers to the
shepherd.

However, I don't always find a shepherd for individual submissions
even if I want to. That's fine, too.

> Should I limit time spent sponsoring IS's?
> How should I prioritize IS sponsoring work?

There's really no other answer than use your judgment. Work
important for the Internet should get priority. Documents with
many problems can consume a lot of time; in practice I at least
also give priority for good and/or small documents that do
not take a lot of my time. (My bar for sponsoring, say, a bug
fix document to an existing RFC where the WG no longer
exists is very low.)

> 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?

The ION says that all individual documents (even Experimental ones)
should go through IETF Last Call, because no last call was performed
in a WG. So the minimum bar is review on the IETF discuss list.
However, acceptance through silence is not a good option for this
type of documents, as there is no guarantee that no one outside
the authors and the AD has read them. As a result, it is often useful
to solicit review from specific experts or lists, and make sure you
get that review.

> How would appeals against IS documents affect answers to these issues?

The same rules apply. In this case there is no WG chair action to appeal.
However, just as your actions in AD review can be appealed for regular
documents, they can also be appealed for these documents.

> Are we discouraging legitimate WGs by encouraging IS's?
> What other purposes do WG's serve besides simply publishing documents,
> that are not met by IS's? [3]
> If we turned down ISs in Apps, would the proposed work die, go
> elsewhere or ... ?  Would that be bad?

Both tools should be used for their appropriate purpose. There's
a middleground where you could do something either in a WG
or as an individual submission. If you find that your area has
a significant number of individual submissions that could or
perhaps even should be WG documents instead, maybe you
need more working groups :-)

For instance, some areas have area working groups that
also deliver documents (bug fixes, architectural
discussion documents, small extensions, etc).

A protocol set that has a lot of maintenance issues could
get a maintenance working group to deal with it instead
of sending documents directly to you.

Jari