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

From: Magnus Westerlund <[email-masked]>
Date: Thu, 2 Dec 2010 13:42:26 +0100

Hi,

A new version has been submitted that intends to address all the issues
we have consensus on addressing. I have attempted to list all the
individual comments here and their resolution as I view them.

New draft version:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-iana-ports-09.txt

Diff from previous version.
http://tools.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-iana-ports-09

In addition to the below issues raised, the authors has done some
editorial fixes to improve the language.

Paul Hoffman's comments on 22 Nov
---------------------------------

1. Proposal to make the system port range equal to the registered range.

Outcome: No clear consensus on making the change. There was some support
for this change. But also push back on doing the change. The push back
can be summarized as: Agreement that in theory there should be no
differences, however in reality there are a number of implementations,
mostly UNIX dialects that do make a difference. Thus there is anyway
need to differentiate the system ports range from the regular. This
document isn't the one to make a statement that systems should be
implemented without any real difference between the ranges.

I hope this issue is closed, but I recognize that the all has not been
given sufficient time to respond to it. If the outcome changes a new
version will be submitted.

2. References with URLs that point to pearl script for the forms.

Outcome: Removed the explicit URLs, now only pointing to IANA.

3. Concern over the few WG last call reviews.

Outcome: Noted, and agree that more reviews are desirable. It is clear
that at least 2 has done a review beyond the author team. The number of
different people engaging in discussion issues has been more than 10.

Paul Hoffman's comments around security on the 4th of Nov
---------------------------------------------------------

Summary of concern: Strong recommendations for only using one port, this
has security impact on protocols that needs to run both with and without
TLS.

Outcome: Major discussion including people from the TLS WG mailing list.
Views on the issue was diverse. In the end only minor changes had
consensus along the lines:  The policy is to try to conserve port space
as much as possible, it is not impossible to get a second port for TLS
usage. However, you need to convince the expert review team that you
have a real problem otherwise.

The draft has been changed in the following way:
- Changed the policy description so it uses "strive" to make it clear
that it is an strong goal not a unbudging requirement.
- Changed the introductory wording in Section 7.2 to make it clear that
there are room for discussion.

Tom Petch's comment on the 3 of Nov
-----------------------------------

Mixed usage of assignment, allocation and registration.

Outcome: Fixed in new draft, using assignment.

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: Eliot Lear <[email-masked]>
Date: Thu, 02 Dec 2010 13:52:57 +0100

Magnus,

On 12/2/10 1:42 PM, Magnus Westerlund wrote:
> mostly UNIX dialects that do make a difference. 

This is a distinction without a difference.  Nobody cares anymore about
the port range, and the argument is circular, if it was every really
stable to begin with.  This distinction was made at a time when perhaps
the only port in use over 100 (not 1000) was RIP, with the assumption
being that services would be registered.  That flew out the window
largely with X, and then out of the planet with Windows, and out of the
solar system with mobile devices.  Please.  Let's move this distinction
into history, where it belongs.

Eliot

---

From: Lars Eggert <[email-masked]>
Date: Thu, 2 Dec 2010 15:58:02 +0200

Hi,

> into history, where it belongs.

Assume we got rid of the distinction between ports larger and smaller than 1024 like you're asking us to. IANA just treats them the same, i.e., FCFS with Expert Review.

Assume that someone asks for a port number. IANA rolls the dice and gives them 842.

They put that in their code and all of a sudden realize that on many platforms, they need to ask the user for admin rights in order to bind to that port.

They won't be happy.

Right?

Because in practice, on many systems, it DOES matter if you have a low port or not.

(So instead what we do is we limit the FCFS range to 1024-49151 and make people who think they want a low port go via the IETF.)

Lars

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 2 Dec 2010 15:05:04 +0100

> (So instead what we do is we limit the FCFS range to 1024-49151 and make people who think they want a low port go via the IETF.)

Eliot,

>From a practical point of view we still need to treat the <1024 ports
special. We don't get rid of these systems quickly even if we say: This
was a stupid idea, don't do it, treat them all the same. Thus we need
special assignment rules anyway.

If we want IETF to publish a document, saying this was bad idea. Fine,
but lets not do it in this document. The fix to the service name
registry has been long awaited. Lets try to avoid further delay.

Cheers

Magnus Westerlund

---

From: Eliot Lear <[email-masked]>
Date: Thu, 02 Dec 2010 15:06:07 +0100

Lars,

> They put that in their code and all of a sudden realize that on many platforms, they need to ask the user for admin rights in order to bind to that port.

The only circumstances in which this would happen would be if this were
user-installed code without administrative privileges.  Not bloody
likely, these days.

Eliot

---

From: Lars Eggert <[email-masked]>
Date: Thu, 2 Dec 2010 16:21:20 +0200

Hi,

> user-installed code without administrative privileges.  Not bloody

quite likely, actually, at least on some platforms. (Drag & drop installing to /Applications on the Mac, for example.)

But I guess neither of is will convince the other. Time for other folks to chime in.

Thanks,
Lars

---

From: George Neville-Neil <[email-masked]>
Date: Thu, 2 Dec 2010 10:11:17 -0500

> But I guess neither of is will convince the other. Time for other folks to chime in.

As an active maintainer of a system on which this distinction remains (FreeBSD) I can tell you that
there are no plans to change this, no matter what the WG decides to vote.  I think we should think
of this as a de-facto standard at this point, and just let it go.

Best,
George

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 2 Dec 2010 07:32:10 -0800

>But I guess neither of is will convince the other. Time for other folks to chime in.

As the person who brought this up originally: if there is even one major platform that has a problem with users not being allowed to launch sub-1024 apps, then it is premature for IANA to pretend that they are equivalent.

I would be happy to review (but not write) a document on getting rid of the differentiation. I propose that it say "in five years after publication", but would be willing to discuss that.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 2 Dec 2010 07:33:40 -0800

At 10:11 AM -0500 12/2/10, George Neville-Neil wrote:
>there are no plans to change this, no matter what the WG decides to vote.

Even if there is later guidance that the distinction will go away? That seems rash.

> I think we should think

--Paul Hoffman, Director
--VPN Consortium

---

From: George Neville-Neil <[email-masked]>
Date: Thu, 2 Dec 2010 10:49:06 -0500

> Even if there is later guidance that the distinction will go away? That seems rash.

Perhaps, but, I don't think that the proposals I've read thus far, and I admit to just
having joined and re-read the posted threads, would get very far in the community.

Best,
George

---

From: Eliot Lear <[email-masked]>
Date: Thu, 02 Dec 2010 17:46:19 +0100

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.

---

From: George Neville-Neil <[email-masked]>
Date: Thu, 2 Dec 2010 12:24:03 -0500

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

Best,
George

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Dec 2010 09:24:50 -0800

Hi, all,

On 12/2/2010 4:42 AM, Magnus Westerlund wrote:
...
> Outcome: No clear consensus on making the change.

IMO this is also out of scope for this document. This doc is intended to 
be clearly focused on procedural issues:

     - unifying the registries
     - updating the procedures

Although we mention some principles of allocation, that discussion 
doesn't change anything; the principles are not binding, and they're 
just generally conservative and exceptions will obviously occur.

The idea of deprecating the separate meaning and handling of the system 
ports belongs in a separate proposal, and we're not advocating that at 
this time.

> different people engaging in discussion issues has been more than 10.

It's also worth noting that there is a team working on this doc that 
extends beyond the author list, and that they have been tracking the doc 
in detail as well.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Dec 2010 09:26:47 -0800

> user-installed code without administrative privileges.  Not bloody

Hmm. Users run apps all the time that aren't "installed"; they're just run.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Dec 2010 09:29:25 -0800

On 12/2/2010 9:24 AM, George Neville-Neil wrote:
> happens to hand a number<  1024 to someone they're going to need privs on many machines

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

---

From: George Neville-Neil <[email-masked]>
Date: Thu, 2 Dec 2010 13:21:08 -0500

> 	I'm not clear on that being a problem that needs solving.

OK, thanks for the clarifications.

Best,
George

---

From: Eliot Lear <[email-masked]>
Date: Fri, 03 Dec 2010 13:52:30 +0100

George,

This is a fair question:

> I tried to ask this before, but I think that mail got rejected.  What problem

In my own mind, what I would like to see is a modernized set of
procedures that articulate the principles upon which decisions by IANA
and their technical reviewers (of which I am one) should be made, so
that there is transparency.  This helps the applicant in predicting a
reasonable response prior to even an application.

As such, continuing a distinction that was around in the day of the WKS
record is the wrong way to go.  I want to briefly summarize again the
reasons for removing the System Port designation in this draft:

    * From an architectural perspective there is no underlying
      difference between System and User Ports.  Because of this,
      interoperating implementations can make no assumptions about this
      range being any different (e.g., privileged in any way).
    * From a registration listing perspective there is also no
      underlying difference.
    * Any implementation difference is just that- an implementation
      issue, and not the business of IANA or the IETF.  EVEN SO...
    * The draft as it stands already allows for applicants to request a
      specific port.
    * As a matter of practical application, the document does not
      provide sufficient guidance as to when a System port SHOULD be
      requested, in contradiction with the goal of transparency.
    * As a matter of history, one cannot reasonably support an argument
      FOR OR AGAINST an application based on the existing database.  For
      instance, why is whois++ (63/tcp/udp) or ups (401/tcp/udp) in the
      system port range, whereas Radius and Diameter are up in the User
      range?

The reason THIS document needs to deal with the matter is that it is
THIS document that is reaffirming the distinction.  I am sorry to sound
like a stick in the mud, but Magnus did ask (and I'm sure he is VERY
sorry he did and will NEVER do that again ;-).

Eliot

---

From: "t.petch" <[email-masked]>
Date: Fri, 3 Dec 2010 16:00:24 +0100

Some possible, insubstantial corrections.

 The UDP-Lite specification [RFC5237] says: "UDP-Lite
**RFC3828 I think

   Furthermore, "Assigned Numbers" is now obsolete [RFC3232]
** I still see it as INFORMATIONAL - should we obsolete it? or do you mean that
RFC3232 obsoleted RFC1700?

HYPHEN  = %x2d              ; "-"
**%x2D would be consistent with the other statements

separating protocol variants based on security capabilities (e.g., HTTP on TCP
port 80 vs. HTTPS on TCP port 443) is not recommended for new protocols
** NOT RECOMMENDED ??

and MUST accompanied by a statement
** //be/ ??

Yes, I have read it:-)

Tom Petch

----- Original Message -----
From: "Magnus Westerlund" <[email-masked]>
To: "tsvwg" <[email-masked]>; "Paul Hoffman" <[email-masked]>; "Eliot
Lear" <[email-masked]>; "t.petch" <[email-masked]>
Sent: Thursday, December 02, 2010 1:42 PM
Subject: draft-ietf-tsvwg-iana-ports-09: How we have resolved WG last call
comments

---

From: Joe Touch <[email-masked]>
Date: Fri, 03 Dec 2010 14:24:02 -0800

Hi, Eliot,

> reasonable response prior to even an application.

Well, I'll push back on that. There should be a best practices that 
helps users understand how to do a good job, but I don't think the 
existing expert review process needs detailed codifying. It's intended 
to be flexible. To the extent that there are policies, the general ones are:
	- follow the current specs
	- conserve ports where possible

That's it, in a nutshell.

>       requested, in contradiction with the goal of transparency.

RFC 1340, which was the first to explain the difference, can be cited or 
quoted:

---

The Well Known Ports are controlled and	assigned by the	IANA and on most
systems	can only be used by system (or root) processes or by programs
executed by privileged users.

---

> THIS document that is reaffirming the distinction.

I don't think it is; it's just not changing it.

I agree this issue needs debate, but it's independent and can/should be 
dealt with as a separate issue.

FWIW - I just submitted a doc on ports use with some issues that have 
come up in the past, as well as some recent discussions 
(draft-touch-tsvwg-port-use-00.txt). It will be posted to the list shortly.

Perhaps that can serve as a place we can make recommendations *to users* 
on how to use/request ports. Right now it has a lot of detailed history, 
but only mostly placeholders for the rest. Suggestions welcome...

Joe

---

From: Lars Eggert <[email-masked]>
Date: Tue, 7 Dec 2010 10:53:45 +0200

Hi,

thanks for the comments!

> The UDP-Lite specification [RFC5237] says: "UDP-Lite

Fixed (in our working copy.)

> RFC3232 obsoleted RFC1700?

The latter. I rephrased this now as "Assigned Numbers [RFC1700] has been obsoleted [RFC3232]".

> **%x2D would be consistent with the other statements

Fixed.

> port 80 vs. HTTPS on TCP port 443) is not recommended for new protocols

Unsure. This is not the document to make normative statements about HTTP, I believe, especially in an example. I rephrased this as "is strongly discouraged".

> and MUST accompanied by a statement

Fixed.

Thanks!

KLars