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

Magnus Westerlund <> Wed, 24 November 2010 16:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 288DF28C27F for <>; Wed, 24 Nov 2010 08:16:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.55
X-Spam-Status: No, score=-106.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3YQJBlEwaExZ for <>; Wed, 24 Nov 2010 08:16:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 96FF328C275 for <>; Wed, 24 Nov 2010 08:16:07 -0800 (PST)
X-AuditID: c1b4fb39-b7c5aae000003b0f-be-4ced3a82bbee
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 68.BF.15119.28A3DEC4; Wed, 24 Nov 2010 17:17:06 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Wed, 24 Nov 2010 17:17:06 +0100
Message-ID: <>
Date: Wed, 24 Nov 2010 17:17:06 +0100
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv: Gecko/20101027 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@[]>
In-Reply-To: <p06240827c9108fb7d7f0@[]>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: 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:16:09 -0000

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. Also, isn't there still
some difference in what rights are needed on a number of unix systems to
install a listener? 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.

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.

> - 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

> On a process note, am I really the only person doing a WG LC review of this document? I'm not really even a WG member...

you are not the only one. But, I do agree that more reviews would be
highly appreciated. If if it is only to say. I read it and I have no
comment. We did requrest reviews beyond the WG, as this has a wider
impact than only in transport.


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: