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

Joe Touch <touch@isi.edu> Thu, 02 December 2010 17:28 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 12D0928C1CD for <tsvwg@core3.amsl.com>; Thu, 2 Dec 2010 09:28:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.547
X-Spam-Level:
X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 2JIYQhZerItp for <tsvwg@core3.amsl.com>; Thu, 2 Dec 2010 09:28:38 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 09D4928C1B4 for <tsvwg@ietf.org>; Thu, 2 Dec 2010 09:28:38 -0800 (PST)
Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id oB2HTPNn011774 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 2 Dec 2010 09:29:25 -0800 (PST)
Message-ID: <4CF7D775.9020107@isi.edu>
Date: Thu, 02 Dec 2010 09:29:25 -0800
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 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>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
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: Thu, 02 Dec 2010 17:28:39 -0000

On 12/2/2010 9:24 AM, George Neville-Neil wrote:
>
> On Dec 2, 2010, at 11:46 , Eliot Lear wrote:
>
>> Thanks for pointing this out.  It nails another reason why we should do
>> away with the distinction: this is a host implementation issue.  The
>> IETF doesn't touch host implementations.  Why should IANA?  You guys
>> over in FreeBSD land want to maintain the restriction?  Fine.  That's
>> your implementation.  But let's not knit IANA policy around it.
>>
>
> That's fine, my point is that I was echoing the person who pointed out that if IANA
> happens to hand a number<  1024 to someone they're going to need privs on many machines
> to run the daemon.  Amusingly there are 2 experimental allocations in that range:
>
> exp1            1021/tcp   #RFC3692-style Experiment 1 (*)    [RFC4727]
> exp1            1021/udp   #RFC3692-style Experiment 1 (*)    [RFC4727]
> exp2            1022/tcp   #RFC3692-style Experiment 2 (*)    [RFC4727]
> exp2            1022/udp   #RFC3692-style Experiment 2 (*)    [RFC4727]
>
>
> I tried to ask this before, but I think that mail got rejected.  What problem
> are we trying to solve?

With the experimental ports:
	
	a safe way to test experiments without picking a port number
	that could be assigned to some other party while your app is
	being developed, and an obvious way for admins to block
	such experimental use when intended as such

With deprecating the user/system port distinction:
	
	I'm not clear on that being a problem that needs solving.

Joe