Re: Progressing I-Ds Immediately Before Meetings

John C Klensin <john@jck.com> Mon, 21 July 2008 16:33 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A94D28C13D; Mon, 21 Jul 2008 09:33:55 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01A533A6802 for <ietf@core3.amsl.com>; Fri, 18 Jul 2008 09:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSdXxfUkcbBR for <ietf@core3.amsl.com>; Fri, 18 Jul 2008 09:21:09 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 01A4C3A6992 for <ietf@ietf.org>; Fri, 18 Jul 2008 09:21:09 -0700 (PDT)
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1KJsiD-000HNx-5G; Fri, 18 Jul 2008 12:21:41 -0400
Date: Fri, 18 Jul 2008 12:21:40 -0400
From: John C Klensin <john@jck.com>
To: Adrian Farrel <adrian@olddog.co.uk>, ietf@ietf.org
Subject: Re: Progressing I-Ds Immediately Before Meetings
Message-ID: <2E1B2AB9703690B8E1EEBE90@p3.JCK.COM>
In-Reply-To: <043101c8e8ec$fa67c650$0200a8c0@your029b8cecfe>
References: <043101c8e8ec$fa67c650$0200a8c0@your029b8cecfe>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
X-Mailman-Approved-At: Mon, 21 Jul 2008 09:33:51 -0700
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.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://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--On Friday, 18 July, 2008 16:43 +0100 Adrian Farrel
<adrian@olddog.co.uk> wrote:

> Hi,
> 
> The cut-off period before IETF meetings has (IMHO) some value
> to help people read an digest stable documents that will be
> discussed face-to-face.
> 
> However, some I-Ds are beyond WG last call and are going
> through other review cycles. Why should updates to these be
> barred?
> 
> For example, I have an I-D that has just completed IESG
> review. The updates are relatively simple and I would like to
> submit them and get the IESG to clear their Discusses.
> Apparently I cannot do this until July 27th. can anyone see a
> reason why this should be the case?

The original reason for those cutoffs -- even more important
than giving people time to read drafts -- was that the
submissions were overwhelming the Secretariat.  Not only did
they have other things to do in the weeks before the meeting, it
was becoming unpredictable whether a draft submitted in advance
of the meeting would be posted early enough for the relevant WG
to look at it.  The split between "new" and "revised" drafts was
another attempt to protect the Secretariat -- notions of having
to formally approve WG drafts came later.

Of course, all of those original reasons vanished when the vast
majority of I-Ds started being posted by a tool that doesn't
require human intervention, leaving, as far as I can tell, three
reasons:

	(1) Assuming adequate lead time for discussions.  As you
	point out, that may not apply to all drafts.  It might
	also be outweighed by other considerations for other
	drafts.
	
	(2) Since the automated submission tool is not
	infallible and sometimes forces perfectly good documents
	into manual submission, we want to preserve a level
	playing field between those who can post drafts via the
	submission tool and those who cannot.
	
	(3) We just like our rules and, once something becomes a
	rule, it is too hard to review and change it.

I hope (3) isn't operating here, but I've seen some small amount
of evidence to the contrary.

    john

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