Re: Proposed text for IESG Handling of Historic Status
Mykyta Yevstifeyev <evnikita2@gmail.com> Sun, 05 June 2011 04:40 UTC
Return-Path: <evnikita2@gmail.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 F1DE221F84A8; Sat, 4 Jun 2011 21:40:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 DOz8V1-f1GBF; Sat, 4 Jun 2011 21:40:10 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4800E21F8474; Sat, 4 Jun 2011 21:39:49 -0700 (PDT)
Received: by fxm15 with SMTP id 15so2179754fxm.31 for <multiple recipients>; Sat, 04 Jun 2011 21:39:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NlHLzVq/4ah/nxWsNVf8ApNDxRWdvgmAQXjyKt4BOb0=; b=GR7IDJD0jr7TB2/sjM5V0YAPnevwFuSa1N5pqA51t0NMLTzJZQF9niv5gj5jyJ3wtL eD0lzJ0FqI2datAqrAr1iq1En0jL9knK6Xk9CcBU5gmBdZJvdNi4QVAqI3FcfZLpdpwi bhVurS4YhwaYODj1fegTR5rOVAZfiFKcZQbu0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ndD+2Laa1+4+PTdm9xdnW234x46D9P04/fZGmJltEmk2LYX8BscvjPdGbns5JePR/2 JT3MglsPmgossan2yF8i28g/Sl1mmNBXQyELZwO2TtM3LBVApfnl5yzy5m2VF4YbQxiX 6KxIuR3fE9VArInv2PPywpjQXw+D+TF17qmoY=
Received: by 10.223.14.139 with SMTP id g11mr1850342faa.103.1307248788380; Sat, 04 Jun 2011 21:39:48 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id a18sm933328fak.29.2011.06.04.21.39.46 (version=SSLv3 cipher=OTHER); Sat, 04 Jun 2011 21:39:47 -0700 (PDT)
Message-ID: <4DEB08BF.8000302@gmail.com>
Date: Sun, 05 Jun 2011 07:40:31 +0300
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: Proposed text for IESG Handling of Historic Status
References: <4DE7E1CA.9010309@ieca.com> <4DE88420.2070202@gmail.com> <4DEA9CBC.6080608@isode.com>
In-Reply-To: <4DEA9CBC.6080608@isode.com>
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: Sun, 05 Jun 2011 04:40:11 -0000
04.06.2011 23:59, Alexey Melnikov wrote: > 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. It isn't really clear from RFC 2026 - so let's mention this in the statement. > >> 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. This is possible as well and even more preferable. I surely don't know, but I haven't seen any RFCs moved to Historic in this way, but I agree this way is good. So, I'd like to make the following corrections to my proposal: (1) the reclassification issue should firstly be discussed in the appropriate WG (or on the appropriate mailing list); (2) once a rough consensus is achieved, an individual or a group of individuals apply to the appropriate AD for moving some RFC to Historic; (3) upon ensuring the adequate pre-IESG community involvement, the AD adds the RFC in the Datatracker with the Interned Status "Historic" and requests the Secretariat to issue a 2-to-4-week Last Call on reclassification; (4) once community consensus is determined, AD brings the question to IESG's attention by issuing a ballot and putting the issue on the IESG agenda; (5) as soon as IESG approve the reclassification, the announcement is sent to RFC Editor and copied to IETF Announce list containing request to change the particular RFC's status to Historic. Here the new (1) was missing from the old one; other changes incorporate Alexey's comment. All the best, Mykyta Yevstifeyev > > "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. > > >
- Proposed text for IESG Handling of Historic Status Sean Turner
- Re: Proposed text for IESG Handling of Historic S… Sam Hartman
- Re: Proposed text for IESG Handling of Historic S… John C Klensin
- RE: Proposed text for IESG Handling of Historic S… Murray S. Kucherawy
- Re: Proposed text for IESG Handling of Historic S… Scott Brim
- Re: Proposed text for IESG Handling of Historic S… Pete Resnick
- Re: Proposed text for IESG Handling of Historic S… SM
- Re: Proposed text for IESG Handling of Historic S… John C Klensin
- Re: Proposed text for IESG Handling of Historic S… Mykyta Yevstifeyev
- Re: Proposed text for IESG Handling of Historic S… Alexey Melnikov
- Re: Proposed text for IESG Handling of Historic S… Alexey Melnikov
- Re: Proposed text for IESG Handling of Historic S… Mykyta Yevstifeyev
- RE: Proposed text for IESG Handling of Historic S… Murray S. Kucherawy
- Re: Proposed text for IESG Handling of Historic S… Barry Leiba
- Re: Proposed text for IESG Handling of Historic S… Fred Baker