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

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 18 Nov 2010 18:42:52 +0000

This is just a brief reminder of the working group last call for
draft-ietf-tsvwg-iana-ports-08, "Internet Assigned Numbers Authority
(IANA) Procedures for the Management of the Service Name and Transport
Protocol Port Number Registry". This document has already received quote 
a lot of discussion on the security aspects - but people may also
wish to contribute on other topics, please do so by the 26th Nov. by 
sending any comments to the TSVWG list.

The draft is available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-iana-ports-08

Emails saying "I support" or "I don't support" publication are also most 
helpful in judging the WG consensus.

James and Gorry
(TSVWG Chairs)

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 22 Nov 2010 14:14:26 -0800

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.

- 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",
               http://www.iana.org/cgi-bin/sys-port-number.pl.

   [USRFORM]  Internet Assigned Numbers Authority (IANA), "Application
              for User (Registered) Port Number",
               http://www.iana.org/cgi-bin/usr-port-number.pl.
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.

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

--Paul Hoffman, Director
--VPN Consortium

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 24 Nov 2010 17:17:06 +0100

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

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.

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

I think we can remove these URL and just point at the IANA website as it
was.

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

Cheers

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: [email-masked]
----------------------------------------------------------------------

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Nov 2010 08:27:07 -0800

At 5:17 PM +0100 11/24/10, Magnus Westerlund wrote:
>perceived difference between the two ranges.

That is only because *we* said there was a difference.

> Also, isn't there still
>install a listener?

Not in any sane system, no.

> So I think the difference is in peoples heads. The

If not now, while the registry is open, when?

>system and registered range.

In the IETF, tomorrow's tomorrow is never.

>I think we can remove these URL and just point at the IANA website as it

That would probably be better than instantiating the Perl script's address.

--Paul Hoffman, Director
--VPN Consortium

---

From: Eliot Lear <[email-masked]>
Date: Wed, 24 Nov 2010 17:48:01 +0100

I agree with Paul on these points.