Re: Progressing I-Ds Immediately Before Meetings

Ned Freed <ned.freed@mrochek.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 D577828C138; Mon, 21 Jul 2008 09:33:56 -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 6B5B83A6AC1 for <ietf@core3.amsl.com>; Fri, 18 Jul 2008 09:45:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.587
X-Spam-Level:
X-Spam-Status: No, score=-0.587 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATIC=1.172]
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 d0l411aAfRu4 for <ietf@core3.amsl.com>; Fri, 18 Jul 2008 09:45:32 -0700 (PDT)
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 29AAB3A6992 for <ietf@ietf.org>; Fri, 18 Jul 2008 09:45:31 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MXAOVJMLTS00DKGP@mauve.mrochek.com> for ietf@ietf.org; Fri, 18 Jul 2008 09:46:03 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MX5LSJN1YO00007A@mauve.mrochek.com>; Fri, 18 Jul 2008 09:46:00 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1216399562; h=Date: From:Subject:MIME-version:Content-type; b=Vzrevte7crBViMpoHVuvZ20ba SC11c019+IRcDA/yRswQXyDwqspaFgTVSUPAijsNtzoD7OZlDbVcfRO5VSCNA==
Date: Fri, 18 Jul 2008 09:29:50 -0700
From: Ned Freed <ned.freed@mrochek.com>
Subject: Re: Progressing I-Ds Immediately Before Meetings
In-reply-to: "Your message dated Fri, 18 Jul 2008 16:43:06 +0100" <043101c8e8ec$fa67c650$0200a8c0@your029b8cecfe>
To: Adrian Farrel <adrian@olddog.co.uk>
Message-id: <01MXAOVIGXH000007A@mauve.mrochek.com>
MIME-version: 1.0
References: <043101c8e8ec$fa67c650$0200a8c0@your029b8cecfe>
X-Mailman-Approved-At: Mon, 21 Jul 2008 09:33:51 -0700
Cc: ietf@ietf.org
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

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

I'm afraid this is another case where we're trying to use processes to control
the uncontrollable.

A document is either stable or it isn't. If it isn't stable and is being
actively revised those changes are going to happen irrespective of whether or
not they get posted to some archive. All this rule does is insure that everyone
sees stale data in the archive in such cases.

And even if you think having groups consider stale data is a good thing, it
doesnt' even accomplish that. Over the years I've gotten many notices to the
effect of "revision didn't make the cutoff, please go do this other place for
the latest revision". Alternately, there's the slide listing the revisions that
have already been made.

In my experience the only useful thing the cutoff has done is to provide a neat
example Sieve script for RFC 5260.

> However, some I-Ds are beyond WG last call and are going through other
> review cycles. Why should updates to these be barred?

And for that matter why have a cutoff for new drafts? If there's was ever a
problem with people creating new documents and bringing them to the attention
of the group during the meeting I sure wasn't aware of it. And since we now
reopon the gates during the week, the only meeting that's actually protected by
this is monday morning slot.

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

Almost certainly because enforcing the restriction on documents under
consideration by the group would require that the posting facility be aware of
document statuses at the group level. AFAIK that's not information that's
centrally tracked at this time.

IMO the draft cutoff does a lot more harm than good and should be absolished.
And if groups need to have rules about late changes or new documents why not
leave that to the groups themselves?

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