Re: Draft Review Request - IRTP IANA Considerations

Joe Touch <touch@isi.edu> Fri, 07 January 2011 06:34 UTC

Return-Path: <touch@isi.edu>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3A2B3A67C1 for <tsvwg@core3.amsl.com>; Thu, 6 Jan 2011 22:34:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.106
X-Spam-Level:
X-Spam-Status: No, score=-102.106 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, 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 MYrC5FGYjPPP for <tsvwg@core3.amsl.com>; Thu, 6 Jan 2011 22:34:39 -0800 (PST)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 836E53A67B4 for <tsvwg@ietf.org>; Thu, 6 Jan 2011 22:34:39 -0800 (PST)
Received: from [192.168.1.90] (pool-71-105-94-39.lsanca.dsl-w.verizon.net [71.105.94.39]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p076aLxP007660 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 6 Jan 2011 22:36:31 -0800 (PST)
Message-ID: <4D26B462.3040001@isi.edu>
Date: Thu, 06 Jan 2011 22:36:18 -0800
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
Subject: Re: Draft Review Request - IRTP IANA Considerations
References: <4D1715BE.6040100@gmail.com> <4D199D89.4080508@gmail.com> <00eb01cba6a5$b5606840$4001a8c0@gateway.2wire.net> <4D1D6EB3.40803@gmail.com> <4D2223E4.2040104@isi.edu> <D3AB3EC9-7C73-4CDA-8702-3B70CD778ED7@nokia.com> <4D240101.6090308@gmail.com> <5131531F-D1E6-44F1-8FC0-94CBCF6CC2A8@isi.edu> <024801cbaccd$e347d580$4001a8c0@gateway.2wire.net> <4D2554F8.7060201@gmail.com> <4D257766.7060808@isi.edu> <4D25A0BC.9050505@gmail.com> <84DCE00C-E6FE-4148-9ADB-A573672DC5F0@isi.edu> <4D26ADE8.5080001@gmail.com>
In-Reply-To: <4D26ADE8.5080001@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: p076aLxP007660
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, "tsvwg@ietf.org" <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jan 2011 06:34:42 -0000

Mykyta,

On 1/6/2011 10:08 PM, Mykyta Yevstifeyev wrote:
> Dear Joe,
>
> Firstly, what draft we are speaking about? I consider the topic we are
> discussing to be 'moving old transport protocols to Historic'. So why
> you talk about IANA considerations for that?

Your first drafts focused on creating IANA registries for experimental 
protocols that are not in current use in the public Internet.

> Moreover, let me cite your message I received before:
>
>> That's the key. This (and the other protocols you wrote similar docs
>> for, e.g., NETBLT and RDP) don't use IANA-assigned values. They have
>> values, but there was not a need for a registry for several reasons,
>> including the fact that they were experimental.
>>
>> At this point, they might be *better moved to historic* than anything
>> else. There's no reason to have IANA track or manage their values.
>>
>> Joe

Just because I prefer moving these to historic to creating IANA 
registries does NOT mean I think that they *****NEED***** to be moved to 
historic.

> Lastly, toy said: "You need to explain why these protocols *need* to be
> deprecated, and why that has to happen now". Let me explain this issues.
> They are *already* deprecated and my draft explains reasons that caused
> it clearly. Read it please carefully.

The protocols you cited are currently listed as Experimental. 
"Deprecated" is something we do to protocols in the IETF, typically by 
moving them to Historic. I did not use the term to mean "how the public 
informally views these protocols.".

I.e., my statement above is equivalent to:

"You need to explain why these protocols *need* to be moved to 
Historic". Such actions are typically reserved for protocols in current 
use that are dangerous, or protocols that are in current use that are 
being replaced by other protocols. Neither is the case here. There is no 
need to "move to Historic" (i.e., "deprecate", within the IETF process) 
such protocols.

Joe