Re: Progressing I-Ds Immediately Before Meetings

[Jari Arkko <jari.arkko at piuha.net>]

I am in favor of relaxations in this area. I realize that new code would 
be needed in the submissions tool, but I don't think it would be too 
hard either. We already treat expirations differently depending on the 
tracker state. I have not looked at the submission tool code, but I 
would be surprised if it cannot access drafts database and tracker contents.

I currently have several drafts in a state where the IESG, authors, and 
the WG are talking about the changes needed to approve the document. In 
one case we have a very long list of RFC Editor notes that appear 
satisfactory. In theory we could approve the draft with those, but I 
would like to use RFC Editor notes for minor corrections, and this one 
is not... so a new draft would be preferred. Yet it cannot be posted at 
this time. Having the new draft would also make it easier to have a 
discussion with the WG, because then the usual tools diffs etc would be 
available.

So, my suggestion would be to add a change to our long list of tool 
development tasks. In its simplest form, submissions should be allowed 
even after the deadline has passed if tracker state > pubrequest. Other, 
more complex policies might also be possible, but they would need more 
discussion. For instance, chair decision, allowing updates of drafts 
that have already been updated shortly before, etc.

Jari

___________From ietf-bounces at ietf.org  Sat Jul 19 04:28:12 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 0DC533A6A7F;
	Sat, 19 Jul 2008 04:28:12 -0700 (PDT)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 271273A6A7F
	for <ietf at core3.amsl.com>; Sat, 19 Jul 2008 04:28:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.54
X-Spam-Level: 
X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 
	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 Jyj5WHj9olZ8 for <ietf at core3.amsl.com>;
	Sat, 19 Jul 2008 04:28:10 -0700 (PDT)
Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130])
	by core3.amsl.com (Postfix) with ESMTP id 048373A689C
	for <ietf at ietf.org>; Sat, 19 Jul 2008 04:28:10 -0700 (PDT)
Received: from smtp.piuha.net (localhost [127.0.0.1])
	by smtp.piuha.net (Postfix) with ESMTP id EF55F1986D6;
	Sat, 19 Jul 2008 14:28:43 +0300 (EEST)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130])
	by smtp.piuha.net (Postfix) with ESMTP id 989811986A4;
	Sat, 19 Jul 2008 14:28:43 +0300 (EEST)
Message-ID: <4881CFF5.3090008 at piuha.net>
Date: Sat, 19 Jul 2008 14:28:53 +0300
From: Jari Arkko <jari.arkko at piuha.net>
User-Agent: Thunderbird 2.0.0.14 (X11/20080505)
MIME-Version: 1.0
To: "James M. Polk" <jmpolk at cisco.com>, 
Russ Housley <housley at vigilsec.com>
Subject: Re: Progressing I-Ds Immediately Before Meetings
References: <043101c8e8ec$fa67c650$0200a8c0 at your029b8cecfe>	<200807181819.m6IIJCIR025085 at mta6.iomartmail.com>	<048401c8e924$ab2ce600$0200a8c0 at your029b8cecfe>
	<XFE-SJC-211BBtNtxy0000033b7 at xfe-sjc-211.amer.cisco.com>
In-Reply-To: <XFE-SJC-211BBtNtxy0000033b7 at xfe-sjc-211.amer.cisco.com>
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: ietf at ietf.org
X-BeenThere: ietf at 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 at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org

I am in favor of relaxations in this area. I realize that new code would 
be needed in the submissions tool, but I don't think it would be too 
hard either. We already treat expirations differently depending on the 
tracker state. I have not looked at the submission tool code, but I 
would be surprised if it cannot access drafts database and tracker contents.

I currently have several drafts in a state where the IESG, authors, and 
the WG are talking about the changes needed to approve the document. In 
one case we have a very long list of RFC Editor notes that appear 
satisfactory. In theory we could approve the draft with those, but I 
would like to use RFC Editor notes for minor corrections, and this one 
is not... so a new draft would be preferred. Yet it cannot be posted at 
this time. Having the new draft would also make it easier to have a 
discussion with the WG, because then the usual tools diffs etc would be 
available.

So, my suggestion would be to add a change to our long list of tool 
development tasks. In its simplest form, submissions should be allowed 
even after the deadline has passed if tracker state > pubrequest. Other, 
more complex policies might also be possible, but they would need more 
discussion. For instance, chair decision, allowing updates of drafts 
that have already been updated shortly before, etc.

Jari

_______________________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


____________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf