Re: Old transport-layer protocols to Historic?

Lixia Zhang <lixia@cs.ucla.edu> Sat, 08 January 2011 16:10 UTC

Return-Path: <lixia@cs.ucla.edu>
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 6A38828C120; Sat, 8 Jan 2011 08:10:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 KC1vGZNqb6O0; Sat, 8 Jan 2011 08:10:48 -0800 (PST)
Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by core3.amsl.com (Postfix) with ESMTP id 5469128C11D; Sat, 8 Jan 2011 08:10:42 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 32CF939E80F0; Sat, 8 Jan 2011 08:12:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu
Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F2mAThflSfq; Sat, 8 Jan 2011 08:12:49 -0800 (PST)
Received: from [10.0.1.2] (cpe-76-174-94-219.socal.res.rr.com [76.174.94.219]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 4870F39E8083; Sat, 8 Jan 2011 08:12:49 -0800 (PST)
Subject: Re: Old transport-layer protocols to Historic?
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Lixia Zhang <lixia@cs.ucla.edu>
In-Reply-To: <4D27F280.1020205@gmail.com>
Date: Sat, 08 Jan 2011 08:12:48 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <4AE9FE30-47F2-4966-BDAF-B27B6437906F@cs.ucla.edu>
References: <4D2556C9.9020901@gmail.com> <AFC50009-6908-4AAB-89FB-45C776F40BE2@gmail.com> <4D27F280.1020205@gmail.com>
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
X-Mailer: Apple Mail (2.1082)
Cc: Bob Hinden <bob.hinden@gmail.com>, tsvwg@ietf.org, IETF Discussion <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: Sat, 08 Jan 2011 16:10:50 -0000

On Jan 7, 2011, at 9:13 PM, Mykyta Yevstifeyev wrote:

> 07.01.2011 21:53, Bob Hinden wrote:
>> Mykyta,
>> 
>> 
>> On Jan 5, 2011, at 9:44 PM, Mykyta Yevstifeyev wrote:
>> 
>>> Hello all,
>>> 
>>> There have been a discussion on tsvwg mailing list about old transport layer protocols - exactly IRTP (RFC938), RDP (RFC908,1151) and NETBLT (RFC998). Initially there have been proposed to define IANA considerations for them. But after a discussion it was found out that it would be better to move them to Historic. I am writing to request more wider discussion on this topic.
>> I see little value even thinking about this.  It's looks like a "make work" project to me.  Just because something is "old", doesn't mean it is "historic" in the sense the label is used in the IETF.
>> 
>> Regarding RDP (RFC908, RFC1151), of which I am one of the authors, both are currently labeled as Experimental.  I do not see any reason to change that.
>> 
>> Bob
>> 
>> 
> Dear all,
> 
> RFC2026 mentions:
> 
>>  A specification that has been superseded by a more recent
>>    specification or is for any other reason considered to be obsolete is
>>    assigned to the "Historic" level.
> and gives 2 reasons for making the RFC Historic: 1) RFC is obsoleted (superseded) or 2) obsolete.
> 
> Obsoleted = made obsolete. This is obvious. When one RFC replaces another, it obsoletes it, and second becomes obsolete.
> 
> What is obsolete (adj.)? Obsolete = deprecated, outdated, out of use, non-current, etc.
> 
> Moreover, RFC2026 does not set any other guidelines for setting the Historic status.

that is because only standard track protocols need such guidelines

> That is why if the protocol is out of use, even specified by Experimental RFC, it is a reason to move its spec. to Historic, in accordance with RFC2026.

First, you said RFC2026 did *not* say anything on moving non-standard protocols to Historic status.

Then you said Experimental RFCs need to move to Historic, in accordance with RFC2026.

Doesn't this sound self-conflicting to you?

Lixia