Re: individual submission Last Call -- default yes/no.

John C Klensin <john-ietf@jck.com> Fri, 07 January 2005 12:05 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08151; Fri, 7 Jan 2005 07:05:25 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmt4v-0007ON-1Q; Fri, 07 Jan 2005 07:18:53 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmsmS-0001gm-HU; Fri, 07 Jan 2005 06:59:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmsm2-0001LQ-8b for ietf@megatron.ietf.org; Fri, 07 Jan 2005 06:59:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07919 for <ietf@ietf.org>; Fri, 7 Jan 2005 06:59:19 -0500 (EST)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmsz0-0006zN-NH for ietf@ietf.org; Fri, 07 Jan 2005 07:12:47 -0500
Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1Cmslz-000NcA-Hy; Fri, 07 Jan 2005 06:59:19 -0500
Date: Fri, 07 Jan 2005 06:59:19 -0500
From: John C Klensin <john-ietf@jck.com>
To: Harald Tveit Alvestrand <harald@alvestrand.no>, Dave Crocker <dcrocker@bbiw.net>, ietf@ietf.org
Message-ID: <BD6FF9EAC7CAF0C287F20A6A@scan.jck.com>
In-Reply-To: <ED5B83D1964A42A623818CE1@B50854F0A9192E8EC6CDA126>
References: <200516104826.996163@bbprime> <ED5B83D1964A42A623818CE1@B50854F0A9192E8EC6CDA126>
X-Mailer: Mulberry/3.1.6 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Content-Transfer-Encoding: 7bit
Subject: Re: individual submission Last Call -- default yes/no.
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Content-Transfer-Encoding: 7bit

Harald,

Using these --and my recent experience with
draft-klensin-ip-service-terms, which is still in the RFC
Editor's queue-- as examples, let me suggest that advancing all
of them is still consistent with what I took Dave to be
suggesting.   In each case, there was evidence of a problem that
"some people" felt was worth solving.  There was no indication
that there was controversy in the community about whether they
were right on the problem (again, independent of whether they
were right on the solution).  

For the IESG to look at a completely quiet last call (or at
least quiet on the problem statement) and say "looks like there
is interest, like the problem is real, and there is no sign of
lack of consensus" seems to me to be a reasonable position.
But, if the Last Call produces an argument about whether the
problem being solved is reasonable or relevant to the
community, _then_ I think the burden shifts to the advocates to
demonstrate that there really is adequate community support for
the idea _and_ for their solution.  And, if there isn't
relatively clear consensus on the answers, the default had best
be either "no" or "if there is really enough interest, it is
time to start thinking about WGs or equivalent mechanisms"
(which is a different form of "no" where approval as an
individual submission is involved).

I don't know if that is what Dave intended, but it is how I
interpreted his "default no" condition.

It does bother me that we can approve a something as a
standards-track document about which everyone but the authors
and the IESG are sound asleep, but the solution to that problem
is for the community to wake up and start taking responsibility.

     john


--On Friday, 07 January, 2005 10:46 +0100 Harald Tveit
Alvestrand <harald@alvestrand.no> wrote:

> [note - this note does NOT talk about the language tags
> document]
> Recent standards-track/BCP RFCs that came in as individual
> submisssions (you can tell this from the draft name in the
> rfc-editor.xml file):
> 
> RFC 3936 - draft-kompella-rsvp-change
> RFC 3935 - draft-alvestrand-ietf-mission
> RFC 3934 - draft-wasserman-rfc2418-ml-update
> RFC 3915 - draft-hollenbeck-epp-rgp
> RFC 3912 - draft-daigle-rfc954bis
> 
> Apart from draft-alvestrand, I don't remember any of these
> causing much of a stir at Last Call. Still, I think the
> decision to advance them was appropriate.
> The usual case for an individual submission is, I think:
> 
> - there are a number of people who see a need for it
> - there are a (usually far lower) number of people who are
> willing to work on it
> - someone thinks that this isn't controversial enough for a
> WG, isn't work enough that the extra effort of setting up a WG
> is worth it, is too urgently needed to wait for a WG to get up
> to speed, or other version of "doesn't fit with our WG process
> - nobody's significantly opposed to getting the work done
> 
> A "default no" doesn't seem like a correct procedure here.
> 
>               Harald





_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf