Re: Request for Review - draft-yevstifeyev-genarea-historic-01
Mykyta Yevstifeyev <evnikita2@gmail.com> Mon, 31 January 2011 06:10 UTC
Return-Path: <evnikita2@gmail.com>
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 F3B203A6B95 for <ietf@core3.amsl.com>; Sun, 30 Jan 2011 22:10:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.193
X-Spam-Level:
X-Spam-Status: No, score=-3.193 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 BjRW2e2DsPj6 for <ietf@core3.amsl.com>; Sun, 30 Jan 2011 22:10:32 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 96B513A6B90 for <ietf@ietf.org>; Sun, 30 Jan 2011 22:10:31 -0800 (PST)
Received: by fxm9 with SMTP id 9so5745412fxm.31 for <ietf@ietf.org>; Sun, 30 Jan 2011 22:13:44 -0800 (PST)
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; bh=fPA7hz14QGRDd+BGrt6vfGV8xEt4RM7eZkmq7wIG+oU=; b=f7p+MxrHsdPH8DXEbYllcZZCehg3LY9ZKO0klbQ6gj3mmdiCSUU+RapFKFOsAgozkc OhVwgiX+MQzzTNQhUiV19G23ors0GRA3Jsb3AgPxqwmXBBQRfUEG6pM94ENVrmuPO9Az G3+/oJHsZkURcsgra1k6ATFz9vBud4EybeHhM=
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; b=GdH+fiT46zGb7APT+Ys86sIb+rI+whjUihPhJWGlfgIrNRx0Pal7RyXlyI77LT2QLI Np95ETLyxmklIqWsRpsbvQ3zxI+Nun39ZCV3VCXt8bHjuziKyXgmZeFs4ucZ+2fpA6aO pQHcjCdbDMFhT9gc4NAcaRYhBMTbQTLacbXt0=
Received: by 10.223.96.73 with SMTP id g9mr5627636fan.24.1296454424358; Sun, 30 Jan 2011 22:13:44 -0800 (PST)
Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id n15sm7191358fam.12.2011.01.30.22.13.42 (version=SSLv3 cipher=RC4-MD5); Sun, 30 Jan 2011 22:13:43 -0800 (PST)
Message-ID: <4D46532E.7080308@gmail.com>
Date: Mon, 31 Jan 2011 08:14:06 +0200
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Doug Ewell <doug@ewellic.org>
Subject: Re: Request for Review - draft-yevstifeyev-genarea-historic-01
References: <20110128075753.665a7a7059d7ee80bb4d670165c8327d.30b3acba39.wbe@email03.secureserver.net> <AANLkTi=w1B1Op9Qbua=zFnQj3refWc_ZX1=aXr=gZUKP@mail.gmail.com> <CD7CBA8E03324FD1B6D06B7B6221D9D1@DougEwell>
In-Reply-To: <CD7CBA8E03324FD1B6D06B7B6221D9D1@DougEwell>
Content-Type: multipart/alternative; boundary="------------040200090000010800040005"
Cc: rfc-interest@rfc-editor.org, 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-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: Mon, 31 Jan 2011 06:10:34 -0000
Doug, all, 30.01.2011 20:51, Doug Ewell wrote: > Mykyta Yevstifeyev wrote: > >> I'd like to see some kind of guideline that the RFC should not be > considered obsolete solely because of security or performance concerns > in some particular, specific context. For example, the fact that > vanilla FTP is not sufficiently secure for use in some applications > where high security is paramount is not a rationale for deprecating > FTP in all applications. > > > > In the case I mentioned as c the key words are 'is not possible or > is not advised to be used in the Internet' but not what you mentioned. > The document says “is not advised to be used in the Internet because > of its security issues, impact on its performance or any other > reason.” (Do you agree that the document says that?) My point is > that, because security or performance issues in one context do not > necessarily imply security or performance issues in all contexts, they > should not by themselves (or together with the 7-year criterion) be > sufficient to trigger deprecation. I've recently thought on how to formulate this criterion. My most current thoughts are the following: c. The RFC describes the technology that is not possible to be used in the current Internet because of its technical characteristics or possible problems with its implementation. However this is not a final variant - any other proposals are welcome. > > The phrase 'or any other reason' is put because there is no > possibility to put the exhaustive list of such purposes. Anyway, > what would you like to propose here? > I don’t have exact replacement wording. “Any other reason” could > permit me to propose deprecation or “historicization” of a protocol > because I don’t like the guy who created it, or because my company is > promoting a rival protocol. Agreed here. See what I think below. --------- And now a few questions for discussion: 1) Should historicizing Informational RFCs be allowed? My proposal is to allow this only if they describe the protocol (see Section 4.2.2 of RFC 2026) with the authors' approval REQUIRED. 2) Definition of obsolete RFCs are still unclear. The most recent what I have is: The RFC SHALL be considered to be obsolete if it meets the following criteria: a. It has been publicly available for at least 7 years; b. During this period of time the technology, described in this RFC has not been seen used in the Internet; or c. The RFC describes the technology that is not possible to be used in the current Internet because of its technical characteristics or possible problems with its implementation. Any proposals on this? 3) Procedures on Experimental RFCs to Historic. What I have in my working version is different from what is in -01 version. See below: 3.2.3. Experimental RFCs Procedures for historicizing Experimental RFCs depend on their origin and the way it is being historicized with. 3.2.3.1. Separate Historicizing Document The procedures described in this section apply to the case, mentioned as 'b' at the beginning of Section 3.2 (separate historicizing document). If the Experimental RFCs has been processed on IETF stream [RFC4844], 'IETF Consensus' [RFC5226] is REQUIRED to historicize it. If the Experimental RFCs has been processed on IAB stream [RFC4844], 'IETF Consensus' [RFC5226] and IAB Chair approval is REQUIRED to historicize it. If the Experimental RFCs has been processed on IRTF stream [RFC4844], 'IETF Consensus' [RFC5226] and IRTF Chair approval is REQUIRED to historicize it. If the Experimental RFCs has been processed on Independent Submissions stream [RFC4844], 'IETF Consensus' [RFC5226] and authors' approval is REQUIRED to historicize it. In essential cases the approval of the director of the area the historicized document is considered to be related to MAY be used instead the authors' one. In the cases described above IESG is responsible for recording their approval. 3.2.3.2. Superseding Document Historicizes the Superseded One The procedures described in this section apply to the case, mentioned as 'a' at the beginning of Section 3.2 (superseding document historicizes the superseded one). The superseding document that is being processed on the same stream [RFC4844] as the superseded one MAY move it to Historic without any special procedures; a simple mention of such action is therefore REQUIRED in superseding document. If the superseding document is being processed on the stream, different from that of superseded one, the approval of corresponding party is REQUIRED. Section 3.2.3.1 describes some cases that apply this one as well (for IAB-, IETF-, and Independent Submissions streams [RFC4844]). Historicizing IETF-stream documents by non-IETF- stream ones SHALL be made following usual procedures for RFCs of such stream with IETF Chair approval REQUIRED. 4) Are there any thoughts on other consideration connected with historic docs.? Except referencing, there might be appropriate to discuss what should be done with IANA registries defined by Historic RFCs. Anything else? All the best, Mykyta Yevstifeyev > -- > Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org > RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s
- Request for Review - draft-yevstifeyev-genarea-hi… Mykyta Yevstifeyev
- Re: Request for Review - draft-yevstifeyev-genare… Doug Ewell
- Re: Request for Review - draft-yevstifeyev-genare… Mykyta Yevstifeyev
- Re: Request for Review - draft-yevstifeyev-genare… Doug Ewell
- Re: Request for Review - draft-yevstifeyev-genare… Mykyta Yevstifeyev