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
- Progressing I-Ds Immediately Before Meetings Adrian Farrel
- Re: Progressing I-Ds Immediately Before Meetings Russ Housley
- Re: Progressing I-Ds Immediately Before Meetings Adrian Farrel
- Re: Progressing I-Ds Immediately Before Meetings James M. Polk
- Re: Progressing I-Ds Immediately Before Meetings Jari Arkko
- Re: Progressing I-Ds Immediately Before Meetings Spencer Dawkins
- Re: Progressing I-Ds Immediately Before Meetings Scott Brim
- Re: Progressing I-Ds Immediately Before Meetings Marshall Eubanks
- Re: Progressing I-Ds Immediately Before Meetings John C Klensin
- Re: Progressing I-Ds Immediately Before Meetings ned+ietf
- Re: Progressing I-Ds Immediately Before Meetings John C Klensin
- Re: Progressing I-Ds Immediately Before Meetings Scott Brim
- Re: Progressing I-Ds Immediately Before Meetings John C Klensin
- Re: Progressing I-Ds Immediately Before Meetings Russ Housley
- Re: Progressing I-Ds Immediately Before Meetings Jari Arkko
- Re: Progressing I-Ds Immediately Before Meetings Dave Crocker
- Re: Progressing I-Ds Immediately Before Meetings John C Klensin
- Re: Progressing I-Ds Immediately Before Meetings Steven M. Bellovin
- Re: Progressing I-Ds Immediately Before Meetings John Leslie
- Re: Progressing I-Ds Immediately Before Meetings ned+ietf
- Re: Progressing I-Ds Immediately Before Meetings ned+ietf
- Re: Progressing I-Ds Immediately Before Meetings Brian E Carpenter
- Re: Progressing I-Ds Immediately Before Meetings ned+ietf
- Re: Progressing I-Ds Immediately Before Meetings Brian E Carpenter
- Re: Progressing I-Ds Immediately Before Meetings ned+ietf
- Re: Progressing I-Ds Immediately Before Meetings Dave Crocker
- Re: Progressing I-Ds Immediately Before Meetings ned+ietf
- Re: Progressing I-Ds Immediately Before Meetings Dave Crocker
- Re: Progressing I-Ds Immediately Before Meetings Spencer Dawkins
- Re: Progressing I-Ds Immediately Before Meetings ned+ietf
- Re: Progressing I-Ds Immediately Before Meetings Spencer Dawkins
- Re: Progressing I-Ds Immediately Before Meetings Pete Resnick
- Re: Progressing I-Ds Immediately Before Meetings Russ Housley
- Re: Progressing I-Ds Immediately Before Meetings Dave Crocker
- Re: Progressing I-Ds Immediately Before Meetings John C Klensin
- Re: Progressing I-Ds Immediately Before Meetings ned+ietf
- Re: Progressing I-Ds Immediately Before Meetings Spencer Dawkins
- RE: Progressing I-Ds Immediately Before Meetings Eric Gray
- RE: Progressing I-Ds Immediately Before Meetings ned+ietf
- Re: Progressing I-Ds Immediately Before Meetings John C Klensin
- Re: Progressing I-Ds Immediately Before Meetings Ned Freed
- RE: Progressing I-Ds Immediately Before Meetings Eric Gray
- RE: Progressing I-Ds Immediately Before Meetings ned+ietf