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

Eliot Lear <> Wed, 24 November 2010 16:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DAAC628C10E for <>; Wed, 24 Nov 2010 08:46:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.049
X-Spam-Status: No, score=-110.049 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LnXIgzRXq1RN for <>; Wed, 24 Nov 2010 08:46:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7B96528C10C for <>; Wed, 24 Nov 2010 08:46:49 -0800 (PST)
Authentication-Results:; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuYEAAfR7EyQ/khNgWdsb2JhbACDTp8zFQEBFiIio1aKO5EGgSGDM3MEimA
X-IronPort-AV: E=Sophos;i="4.59,249,1288569600"; d="scan'208";a="13935973"
Received: from ([]) by with ESMTP; 24 Nov 2010 16:47:48 +0000
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id oAOGlmRq030801; Wed, 24 Nov 2010 16:47:48 GMT
Message-ID: <>
Date: Wed, 24 Nov 2010 17:48:01 +0100
From: Eliot Lear <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: Paul Hoffman <>
Subject: Re: Reminder: WGLC Announcement for draft-ietf-tsvwg-iana-ports-08 - 26th November 2010
References: <> <p06240827c9108fb7d7f0@[]> <> <p0624089fc912ec9557a7@[]>
In-Reply-To: <p0624089fc912ec9557a7@[]>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: Magnus Westerlund <>, tsvwg WG <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Nov 2010 16:46:51 -0000

I agree with Paul on these points.

On 11/24/10 5:27 PM, Paul Hoffman wrote:
> 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.
>>> - Two of the references seem ill-advised for a long-lived RFC:
>>>    [SYSFORM]  Internet Assigned Numbers Authority (IANA), "Application
>>>               for System (Well Known) Port Number",
>>>    [USRFORM]  Internet Assigned Numbers Authority (IANA), "Application
>>>               for User (Registered) Port Number",
>>> For years, URI-aware IETF participants have been trying to get IANA to not instantiate URIs that hard-code the source and type of content in public URLs. The above two URLs force IANA to keep using an Apache-based directory structure, and to keep using Perl scripts, for the life of this RFC. It would be far better if IANA would start following Web best practices before this document is published as an RFC and use more universal local parts in these URLs.
>> I think we can remove these URL and just point at the IANA website as it
>> was.
> That would probably be better than instantiating the Perl script's address.
> --Paul Hoffman, Director
> --VPN Consortium