Re: Progressing I-Ds Immediately Before Meetings
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Progressing I-Ds Immediately Before Meetings
Dear Jari;
On Jul 19, 2008, at 7:28 AM, Jari Arkko wrote:
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.
Wouldn't it be a lot simpler just to give the ADs the ability to
advance a draft during the block-out period, maybe through an email to
the Secretariat ?
They, of course, have to know about a draft getting upgraded in any of
the above situations, this would not require a tool change, and of
course if this were misused they are the ones who would have to face
the wrath of the IESG.
Regards
MarFrom ietf-bounces at ietf.org Sat Jul 19 06:06:37 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 CCBBF3A67E7;
Sat, 19 Jul 2008 06:06:37 -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 66BF33A67E7
for <ietf at core3.amsl.com>; Sat, 19 Jul 2008 06:06:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.588
X-Spam-Level:
X-Spam-Status: No, score=-103.588 tagged_above=-999 required=5
tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1,
USER_IN_WHITELIST=-100]
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 4Qk5FdTnby3Q for <ietf at core3.amsl.com>;
Sat, 19 Jul 2008 06:06:35 -0700 (PDT)
Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7])
by core3.amsl.com (Postfix) with ESMTP id 5B8043A67D4
for <ietf at ietf.org>; Sat, 19 Jul 2008 06:06:35 -0700 (PDT)
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1])
by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
with ESMTP-TLS id 12163728; Sat, 19 Jul 2008 09:07:10 -0400
Message-Id: <1EFD708A-8509-42A6-BBC9-824C27A7DCFA at multicasttech.com>
From: Marshall Eubanks <tme at multicasttech.com>
To: Jari Arkko <jari.arkko at piuha.net>
In-Reply-To: <4881CFF5.3090008 at piuha.net>
Mime-Version: 1.0 (Apple Message framework v926)
Subject: Re: Progressing I-Ds Immediately Before Meetings
Date: Sat, 19 Jul 2008 09:07:09 -0400
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>
<4881CFF5.3090008 at piuha.net>
X-Mailer: Apple Mail (2.926)
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"; DelSp="yes"
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org
Dear Jari;
On Jul 19, 2008, at 7:28 AM, Jari Arkko wrote:
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.
Wouldn't it be a lot simpler just to give the ADs the ability to
advance a draft during the block-out period, maybe through an email to
the Secretariat ?
They, of course, have to know about a draft getting upgraded in any of
the above situations, this would not require a tool change, and of
course if this were misused they are the ones who would have to face
the wrath of the IESG.
Regards
Marshall
shall
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
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
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
