Re: draft-ietf-tsvwg-iana-ports-09: How we have resolved WG last call comments

Eliot Lear <lear@cisco.com> Fri, 03 December 2010 12:51 UTC

Return-Path: <lear@cisco.com>
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 C813928C0D6 for <tsvwg@core3.amsl.com>; Fri, 3 Dec 2010 04:51:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.216
X-Spam-Level:
X-Spam-Status: No, score=-110.216 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 M-ftqaD0G9n4 for <tsvwg@core3.amsl.com>; Fri, 3 Dec 2010 04:51:01 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 60FE63A6938 for <tsvwg@ietf.org>; Fri, 3 Dec 2010 04:51:01 -0800 (PST)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAMx2+EyQ/khMgWdsb2JhbACDUZ9jFgEWIiKnGIo/kGmEVXMEims
X-IronPort-AV: E=Sophos; i="4.59,292,1288569600"; d="scan'208,217"; a="70727245"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 03 Dec 2010 12:52:18 +0000
Received: from dhcp-10-61-103-64.cisco.com (dhcp-10-61-103-64.cisco.com [10.61.103.64]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id oB3CqHxh013129; Fri, 3 Dec 2010 12:52:17 GMT
Message-ID: <4CF8E80E.7050308@cisco.com>
Date: Fri, 03 Dec 2010 13:52:30 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: George Neville-Neil <gnn@freebsd.org>
Subject: Re: draft-ietf-tsvwg-iana-ports-09: How we have resolved WG last call comments
References: <4CF79432.8070508@ericsson.com> <4CF796A9.9070608@cisco.com> <7A4B44A1-8A53-4819-82A2-5583D52218B4@nokia.com> <4CF7A7CF.50006@cisco.com> <38C6B891-838A-4124-9061-28C51E354DCB@nokia.com> <A6DF5386-C1DA-4A1A-B381-A8B58EFBD26C@freebsd.org> <p0624081cc91d6c95c104@[10.20.30.150]> <9FD12A39-EEFE-4F48-A80E-110FFCF87993@freebsd.org> <4CF7CD5B.3040903@cisco.com> <72C0AA6E-2F52-47A2-BE59-EF9B6E07DB42@freebsd.org>
In-Reply-To: <72C0AA6E-2F52-47A2-BE59-EF9B6E07DB42@freebsd.org>
X-Enigmail-Version: 1.1.1
Content-Type: multipart/alternative; boundary="------------090907020507060605030105"
Cc: Paul Hoffman <paul.hoffman@vpnc.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, 03 Dec 2010 12:51:02 -0000

George,

This is a fair question:

On 12/2/10 6:24 PM, George Neville-Neil wrote:
> I tried to ask this before, but I think that mail got rejected.  What problem
> are we trying to solve?

In my own mind, what I would like to see is a modernized set of
procedures that articulate the principles upon which decisions by IANA
and their technical reviewers (of which I am one) should be made, so
that there is transparency.  This helps the applicant in predicting a
reasonable response prior to even an application.

As such, continuing a distinction that was around in the day of the WKS
record is the wrong way to go.  I want to briefly summarize again the
reasons for removing the System Port designation in this draft:

    * From an architectural perspective there is no underlying
      difference between System and User Ports.  Because of this,
      interoperating implementations can make no assumptions about this
      range being any different (e.g., privileged in any way).
    * From a registration listing perspective there is also no
      underlying difference.
    * Any implementation difference is just that- an implementation
      issue, and not the business of IANA or the IETF.  EVEN SO...
    * The draft as it stands already allows for applicants to request a
      specific port.
    * As a matter of practical application, the document does not
      provide sufficient guidance as to when a System port SHOULD be
      requested, in contradiction with the goal of transparency.
    * As a matter of history, one cannot reasonably support an argument
      FOR OR AGAINST an application based on the existing database.  For
      instance, why is whois++ (63/tcp/udp) or ups (401/tcp/udp) in the
      system port range, whereas Radius and Diameter are up in the User
      range?

The reason THIS document needs to deal with the matter is that it is
THIS document that is reaffirming the distinction.  I am sorry to sound
like a stick in the mud, but Magnus did ask (and I'm sure he is VERY
sorry he did and will NEVER do that again ;-).

Eliot