Re: Issues around sponsoring individual documents

Eliot Lear <lear@cisco.com> Fri, 07 September 2007 11:29 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 1ITc29-00063s-49; Fri, 07 Sep 2007 07:29:57 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1ITc28-00063m-Ej for discuss-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 07:29:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITc28-00062b-4d for discuss@apps.ietf.org; Fri, 07 Sep 2007 07:29:56 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITc26-0005xi-KC for discuss@apps.ietf.org; Fri, 07 Sep 2007 07:29:56 -0400
X-IronPort-AV: E=Sophos;i="4.20,220,1186351200"; d="scan'208";a="152493347"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 07 Sep 2007 13:29:36 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l87BTWHJ005999; Fri, 7 Sep 2007 13:29:32 +0200
Received: from adsl-247-5-fixip.tiscali.ch (ams3-vpn-dhcp4722.cisco.com [10.61.82.113]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l87BTNgX004897; Fri, 7 Sep 2007 11:29:27 GMT
Message-ID: <46E1360E.6010001@cisco.com>
Date: Fri, 07 Sep 2007 13:29:18 +0200
From: Eliot Lear <lear@cisco.com>
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>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7034; t=1189164572; x=1190028572; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20<lear@cisco.com> |Subject:=20Re=3A=20Issues=20around=20sponsoring=20individual=20documents |Sender:=20; bh=Na6DfiZuLsssDgMnAG8qbb0erpQ6KWg4MlNo/Hgtte4=; b=IO/x1axb0s4U3Hw7nHbAU0pIdvDUjA0spFYwBL/0O79y4At6QJ0utAaK6K1zl3QPNEeVPE0W TFAB9CwGB9jBHLHV9jg+8fBHsmHi2v1s7+gkxzUlrBzoW/amHk8HAqUr;
Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250
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

Hello Lisa,

First let me say that I appreciate your openness in raising this issue.  
Obviously you're in the role because we do trust your judgment (nyeh 
nyeh nyeh ;-).  That having been said:


>
> Is an IS that defines a new protocol for the Standards Track fine in 
> general?

It Depends. 

Could you imagine DKIM going forward as an individual submission?  I 
couldn't.  We could never get the community to agree to it.    Let's 
return to the purpose of WGs in the first place.  They exist, in my 
opinion, as a convenience for area directors.  You use them as a tool to 
drive consensus.  It's a very heavy weight process which should be 
avoided when it can be.  In spite of what I write below, however, I 
largely agree with Keith in terms of applicability of ISes.

And so the standard (ahem) I would apply were I in your shoes (ouch) 
would be the following six questions:

   1. Is this work appropriate to standardize?  Is it important enough
      and is it in an area in which we have competence?  If no, stop
      here and kill.
   2. Will there be more than one or two implementors?  If no, stop here
      and kill.  Without sufficient intent from implementors, you
      probably don't have a viable specification, with or without a
      working group.  Otherwise you're now to the point where you or a
      stuckee probably have to read the whole thing.  So...
   3. Are you confident that the community would agree with the approach
      taken?  If not, perhaps a BoF?
   4. Would the work benefit from working group review through forging
      of consensus through compromise and dialog?  If yes, create a
      working group.  Otherwise..
   5. Is the work ready for advancement?  You have the right and
      responsibility to say, sometimes, "yes, this is improtant, but no
      this is not of sufficient quality that I believe it should be
      advanced, because...", followed by "take the following actions to
      improve the document and come back to me..."  Some people say a WG
      can help here, but I'm not convinced.
   6. Otherwise, sure, go ahead.  But again, use your judgment.  I can't
      envision all the exigencies.

I take the tact that individual submissions should have the same 
priority as working group submissions once you've answered yes to both 
(1) and (2), with the understanding that you will then prioritize your 
work so as not to consume more than a reasonable amount of time on the 
AD job.  The last thing we want is for ADs to burn out.  If this means 
that documents are not put out fast enough, let's deal with that problem 
separately.  To answer (3) and (4) there's no reason why you couldn't 
really on a group of advisors you trust.  Call them document shepherds 
or whatever.

If after last call you judge there not to be consensus there is no 
reason you couldn't send the thing to a working group to go get fixed.  
This will of course depend on the authors' wishes to a great extent.  If 
they don't want to go through the pain of a working group, it's very 
hard to push something through in those circumstances.


> Is an IS that extends a standard protocol developed in a WG fine in 
> general?

Same answer as above.

> Is an IS that obsoletes a standard protocol developed in a WG fine in 
> general?

Same answer as above.
>
> Do IS's suffer from less review?  Is that a problem?
> Whose responsibility is it to get sufficient review?

Joint between you and the authors.
>
> 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?

How does one answer this?

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

In an informal sense, yes.  No reason for you not to have help.

>
> Should I limit time spent sponsoring IS's? [1]  IESG work plus IS work 
> could consume 30 hours a week, or 40, or 50...

You should limit the time you put into the IESG, but prioritize what is 
important, be it IS or WG.

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

I'm going to presume from this line of questioning that you receive a 
lot of garbage.  If the abstract looks stupid, unimportant, or otherwise 
indicates that the doc is not appropriate for the IETF, trust that the 
rest of the document is as well and say so and move on.

> How should I prioritize IS sponsoring work? Which documents get my 
> attention first?  [2]
See above.

>
> When there's a question of consensus for an IS document, should I just 
> drop the document?
No.  If it's important figure out what to do.  Perhaps that's a working 
group.  Perhaps that's a set of clearly defined changes.  Perhaps you 
have to drop it, but if it really is important, others will be willing 
to offer alternatives, given the chance.

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

Yes.  Consensus calls to the IETF discuss list, as well as anywhere else 
the info comes from.  But you might want to draw people's attention to 
something you think is important.


> Do I need to ensure there's a quorum?

You don't need a quorum, but you'd better be very sure of yourself 
without one.  I think it's a good idea for people to step and say, "this 
is a good idea" or "this is a bad idea" or "here is what would make this 
a good idea".  Absent that, you should be conservative.

>
> 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...)

If someone questions your consensus call that's a pretty easy appeal to 
handle.  Also, your peers should give you advice about consensus before 
you make the call.


> Does sponsoring many IS documents give an AD, and the IESG as a whole, 
> too much power?

No.  You still should heavily weight community consensus.  And the IAB 
needs to pay attention.

>
> Are we discouraging legitimate WGs by encouraging IS's?
Since a WG is a heavy weight tool for you, who cares?
 
> 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?

It Depends.  If it's bad work, no.  If it's work that's not appropriate 
for the IETF, no.  If it's unimportant, no.  Otherwise, yes.

Eliot