Re: Issues around sponsoring individual documents

James M Snell <jasnell@gmail.com> 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-00087c-TO; Fri, 07 Sep 2007 11:59:04 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1ITfob-0001yu-Rp for discuss-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 11:32:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITfob-0001ym-I9 for discuss@apps.ietf.org; Fri, 07 Sep 2007 11:32:13 -0400
Received: from an-out-0708.google.com ([209.85.132.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITfoa-0003Sh-CJ for discuss@apps.ietf.org; Fri, 07 Sep 2007 11:32:13 -0400
Received: by an-out-0708.google.com with SMTP id d26so81651and for <discuss@apps.ietf.org>; Fri, 07 Sep 2007 08:32:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=sWL+tsJoHpZRxv+/DpSaR8Uz9VvoVEkeZEZcibeo9Q4=; b=rsRb2v/rIuhrl7apiK58LeajZlX4/PQQgS+XTi1smX2g6rycLei7EWyCA6YRYvRG5SqElFSFSIGrmMYw+1NUl6cuTJucI2jnMuctaOouAca/cZB/aZLvIL3CW1lINMqPUP0yMjzClpF1Yqx8O9b36TANDVtDh0Ts4aWPJjf0x70=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=Gr/Ha0jyceTlBts08PabHcCO751ys6J85KIVVlnLKnBKMVOQY+0DRDZfcMBOwuU4hEDpp98ixVrWNCguxmODFY05+tzz2AwUwOMfh6nVEgjJmbabA7UbobIbF2bT4u9iKj3An8CNNRNN9PaJ0CY+97eJptmnELhtZ0s4f4fdUQY=
Received: by 10.100.106.5 with SMTP id e5mr2242070anc.1189179131875; Fri, 07 Sep 2007 08:32:11 -0700 (PDT)
Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id 3sm910296wrs.2007.09.07.08.32.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Sep 2007 08:32:10 -0700 (PDT)
Message-ID: <46E16EF7.5060907@gmail.com>
Date: Fri, 07 Sep 2007 08:32:07 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/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
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1
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,

Having written several IS drafts, one of which reached Proposed Standard
status and another Experimental RFC, and another that I believe might
have helped to motivate this particular note from you, I'd have to say
that I think individual submissions are an important part of the process
if handled properly.

IS's can suffer from less review.  The only way they can succeed is if
there is an existing community that is interested enough to provide
adequate review and if the author(s) of the spec are willing to active
engage and respond to that community.

In the case of the Atom-related specifications that I have produced, I
have been fortunate in that the existing WG has been very willing to
provide adequate feedback and the chairs have been very willing to put
up with discussion about non-chartered topics.  Controversies that have
come up have been dealt with openly and honestly and the result has been
very positive overall.

I think the burden to demonstrate that standards track IS's have had
adequate review falls on the author(s) and the AD who chooses to sponsor
it.  If the AD does not want to sponsor the draft, then so be it.  The
author(s) have the option of pursuing the creation of a formal WG if
they think the work is important enough.  Alternatively, the author(s)
can choose to take another path such as publishing as an Informational
or Experimental RFC, or publishing outside the IETF entirely.

I would suggest that IS's that have a demonstrated record of being
discussed and hashed out within an existing community such as a WG
should be given priority in the queue.  Doing so should encourage spec
author(s) to take their IS's to the community and helps to address the
concerns you are raising.  If the community shows an interest, and if
the author(s) demonstrate a willingness to listen and respond to the
community, then the IS should be allowed to progress.

- James

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?
> 
> 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?  Or mostly individuals with a lot of
> time on their hands?
> 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?
> 
> Should I limit time spent sponsoring IS's? [1]  IESG work plus IS work
> could consume 30 hours a week, or 40, or 50...
> 
> 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]
> 
> 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?
> 
> 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?
> 
> 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?
> 
> Lisa
> 
> [0] Note "Independent Submission" is a different thing, an I-D that goes
> through the RFC Editor to RFC and never gets an IETF last call, so it's
> marked as not an IETF document
> 
> [1] So far I have been sponsoring nearly every document I'm asked to,
> not really limiting.  However I can see time limiting becoming required.
> 
> [2] My current practice is to do WG-related work first, then
> IS-sponsoring work in rotation.  Note that with WG-related work, the WG
> chair does some work which I have to do with IS documents. IS documents
> are usually more work for me than WG products.
> 
> [3] I'll take a first stab at this one:
>  - creating buy-in among potential implementors,
>  - developing relationships that can lead to more interop work than
> otherwise,
>  - choosing document editors that can reflect or build consensus,
> strongarm them if necessary
> 
> 
> 
> 
> 
> 
> 
>