Re: Reminder: WGLC Announcement for draft-ietf-tsvwg-iana-ports-08 - 26th November 2010

Eliot Lear <lear@cisco.com> Wed, 01 December 2010 10:36 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 3BDCB28C117 for <tsvwg@core3.amsl.com>; Wed, 1 Dec 2010 02:36:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.081
X-Spam-Level:
X-Spam-Status: No, score=-110.081 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599, 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 bI6vwgkTXwUh for <tsvwg@core3.amsl.com>; Wed, 1 Dec 2010 02:36:40 -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 461F428C119 for <tsvwg@ietf.org>; Wed, 1 Dec 2010 02:36:29 -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: AhsEACS09UyQ/khLgWdsb2JhbACDUJ9BFQEBFiIiqGKKO5BygSGDM3MEimM
X-IronPort-AV: E=Sophos;i="4.59,282,1288569600"; d="scan'208";a="70519595"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 01 Dec 2010 10:36:14 +0000
Received: from dhcp-10-61-103-232.cisco.com (dhcp-10-61-103-232.cisco.com [10.61.103.232]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id oB1AaE3A025587; Wed, 1 Dec 2010 10:36:14 GMT
Message-ID: <4CF6252A.2020303@cisco.com>
Date: Wed, 01 Dec 2010 11:36:26 +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: Magnus Westerlund <magnus.westerlund@ericsson.com>
Subject: Re: Reminder: WGLC Announcement for draft-ietf-tsvwg-iana-ports-08 - 26th November 2010
References: <4CE573AC.6050708@erg.abdn.ac.uk> <p06240827c9108fb7d7f0@[10.20.30.150]> <4CED3A82.5050708@ericsson.com> <p0624089fc912ec9557a7@[10.20.30.150]> <4CF60F04.60101@ericsson.com>
In-Reply-To: <4CF60F04.60101@ericsson.com>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, tsvwg WG <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: Wed, 01 Dec 2010 10:36:43 -0000

Magnus,

There were only two issues with that draft:

1.  I mangled a few issues together (like how to keep port assignments
current, and the value of SRV records);
2.  I ran out of time to do the work at that time.

I would be happy to revive a simpler draft but I think it's better that
you just deal with the matter now, so that we don't have to go through
multiple iterations of this.

As I recall, though, nobody really had a problem with dropping the
distinction.  It's only there in some UNIX flavors; and the only real
issue is on multi-user systems where the port could conceivably be
grabbed by someone.  Realistically, that's not a concern because if it's
important, there is something listening from start-up.

Eliot

On 12/1/10 10:01 AM, Magnus Westerlund wrote:
> WG, Paul and Eliot,
>
> I will respond in detail. However, I do need to do a bit of history
> digging and and go review the fairly big discussion that was held on the
> IETF@ietf.org list back in 2006 that was started by Eliot Lear.
>
> The threads of relevance appears to be:
> https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=30752&tid=1291193700
>
> https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=31742&tid=1291193820
>
> Elliot's individual draft:
> http://tools.ietf.org/html/draft-lear-iana-no-more-well-known-ports-02
>
> Maybe Eliot can summarize what was the reason his effort failed to gain
> sufficient traction to be published?
>
> Cheers
>
> Magnus
>
>
> Paul Hoffman skrev 2010-11-24 17:27:
>> At 5:17 PM +0100 11/24/10, Magnus Westerlund wrote:
>>> Paul Hoffman skrev 2010-11-22 23:14:
>>>> In general, this document seems fairly worthwhile. I have a two reservations, however:
>>>>
>>>> - There is no justification for retaining the differentiation between System Ports and User Ports. Given the wide disparity in assignment rates, I would have thought that this would be a good time to say "there is no longer a difference". The text in 8.1 doesn't explain the difference in a way I could discern. At a minimum, this needs to be covered in much more detail in sections 7.1 and 7.2.
>>> My personal view is that I agree that there really are no significant
>>> difference between the two ranges. There has traditionally been a
>>> perceived difference between the two ranges.
>> That is only because *we* said there was a difference.
>>
>>> Also, isn't there still
>>> some difference in what rights are needed on a number of unix systems to
>>> install a listener?
>> Not in any sane system, no.
>>
>>> So I think the difference is in peoples heads. The
>>> registration rules do require you to clearly motivate why you should be
>>> given a port in the system range.
>>>
>>> In chapter 6, there is the following text:
>>>
>>>    Such confirmation of intended use is
>>>    especially important when these ports are associated with privileged
>>>    (e.g., system or administrator) processes.
>>>
>>>
>>> For the difference in allocation rates there is a reason why there such
>>> a low rate for "System" ports, and that is due to the high bar that
>>> already is set by the port expert reviewers.
>>>
>>> We are trying to focus on getting the new registry and its structure in
>>> place. Rather than changing all details, like if the system port range
>>> should be removed. There was previous discussion on this in IETF without
>>> any consensus so we haven't been interested in driving this.
>> If not now, while the registry is open, when?
>>
>>> I think removing the system ports range is beyond our intentions with
>>> this document. Secondly, we can try to clarify the difference between
>>> system and registered range.
>> In the IETF, tomorrow's tomorrow is never.
>