Re: Proposed text for IESG Handling of Historic Status

Alexey Melnikov <alexey.melnikov@isode.com> Sat, 04 June 2011 21:00 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F9711E8071; Sat, 4 Jun 2011 14:00:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100
X-Spam-Level:
X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ti9Lu7lCYjx; Sat, 4 Jun 2011 14:00:21 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id E2FEC22800C; Sat, 4 Jun 2011 14:00:19 -0700 (PDT)
Received: from [188.28.114.130] (188.28.114.130.threembb.co.uk [188.28.114.130]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <Teqc3gA-uUx9@rufus.isode.com>; Sat, 4 Jun 2011 22:00:15 +0100
Message-ID: <4DEA9CBC.6080608@isode.com>
Date: Sat, 04 Jun 2011 21:59:40 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
Subject: Re: Proposed text for IESG Handling of Historic Status
References: <4DE7E1CA.9010309@ieca.com> <4DE88420.2070202@gmail.com>
In-Reply-To: <4DE88420.2070202@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, The IESG <iesg@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
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>
X-List-Received-Date: Sat, 04 Jun 2011 21:00:22 -0000

Mykyta Yevstifeyev wrote:

> Hello,
>
> The proposed statement is mostly fine.  But, since RFC 2026 gives very 
> little information on some issues, I'd like you considered them in the 
> statement.
>
> First, for RFCs of what categories is it legitimate to move them to 
> Historic.  Whether Experimental or Informational RFCs could be 
> considered for such action?  As far as I understand RFC 2026, Historic 
> can be assigned to Standards Track documents; however it won't be 
> excessive to clarify this regulation in the IESG statement additionally.

My understanding is that any RFC can be moved to Historic. But if this 
is not clear from RFC 2026, maybe it is worth clarifying.

> I support the opinion that the information on what the particular RFC 
> moves to Historic shouldn't go in the Abstract; the current practice 
> is also the same (see eg. http://tools.ietf.org/html/rfc6265, end of 
> Section 1).  Let's mention it is only put in the Introduction.
>
> The proposed statement says almost nothing about how the RFC may be 
> moved to Historic status without the necessity to publish a separate 
> RFC for this purpose.  Here I agree with John Klensin.  Let's adopt 
> something like proposed in 
> http://tools.ietf.org/id/draft-ietf-newtrk-cruft-00.txt, but more 
> lightweight.  What I mean is that the procedure should be:
>
> (1) an individual or a group of individuals apply to the appropriate 
> AD for moving some specification to Historic;
>
> (2) AD asks Secretariat to issue a 2-to-4-week Last Call on 
> reclassification;
>
> (3) once community consensus is determined, AD brings the question to 
> IESG's attention via putting it on agenda as "Management Issue";

 From the pedantic deparment:

As a matter of clarification: it is already possible to move an RFC to 
Historic without new draft using the datatracker. The RFC is added to 
datatracker (just like a draft), etc. This is not going to be a 
management item, it would appear as a proper document on IESG agenda.

"Management items" are second class citizens during IESG telechats...

> (4) if IESG does not object, the announcement is sent to RFC Editor 
> and copied to IETF Announce list containing request to change the 
> particular RFC's status to Historic.
>
> Such procedure seems lightweight enough not to create dozens of new 
> RFCs reclassifying the old ones but have the appropriate community 
> involvement.