Subject: Questions about draft-lear-iana-no-more-well-known-ports-00.txt

From: John C Klensin <[email-masked]>
Date: Tue, 23 May 2006 16:46:30 -0400

Eliot,

I haven't made up my mind whether I think this is a good idea or
not, but I two have two questions about issues that interact
with this draft that are not covered in it.

(1) At present, the IESG reviews and approves applications for
well-known ports.  If the IESG does not believe a particular
protocol proposal is "worthy" (my terminology, not theirs), then
a low-numbered port is not assigned although the author is free
to go to IANA for a higher-numbered one.   Would the effect, and
intention, of deprecating the distinction between "well known"
and other ports be to take the IESG entirely out of the approval
loop for port assignments except as described in the first two
paragraphs of section 2?

(2) Your charging plan ties a potential charge to port requests
originating outside the IETF process for which there is no
corresponding RFC.  However, there have been cases in which IANA
has assigned a port number, the requester has submitted a
document for RFC publication, but the RFC Editor has not found
the description of the associated protocol to be of sufficient
interest to the community to be worth publishing.  It seems to
me that this creates an uncomfortable situation which could be
resolved by:

	(i) Requiring that the RFC Editor publish, on request,
	any protocol description for which IANA assigns a port
	number of for which it has assigned a port number in the
	past.  or
	
	(ii) Permits that charge only for ports and protocols
	for which no documentation has been submitted to the RFC
	Editor for publication.  or
	
	(iii) Creates a two-track process for assignment of port
	numbers that are not based on IETF-approved protocols.
	In one, the RFC Editor approves a specification document
	and then requests that the port assignment be made,
	while, in the other, requesters go to IANA directly but
	agree to pay any fees necessary.    Of course, our
	normal procedures and conventions would presumably
	require an appeals procedure if the RFC Editor turned
	something down. That would raise all sorts of other
	issues that might not make either the community or the
	RFC Editor very happy (see
	draft-klensin-rfc-independent-01.txt)

So, what did you have in mind?

     john

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Eliot Lear <[email-masked]>
Date: Wed, 24 May 2006 15:11:29 +0200

John C Klensin wrote:
> not

I'm not sure all the ideas in the document are a good idea either!

> loop for port assignments except as described in the first two

Yes, the distinction between well known ports and just assigned ports is
outdated.  The overarching theme of the document is that the IANA should
be treated as a group of adults and that they should use some discretion
with oversight only where needed.
> So, what did you have in mind?

What I have in mind is that the protocol be documented in some normative
way, not necessarily via the RFC Editor.  But your observations are
astute and deserve further consideration in the next revision.

Eliot

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 24 May 2006 19:06:49 -0400

Disclaimer - I wasn't even aware of this document before reading this 
thread.  However, I have now read it, so feel prepared to comment.

> with oversight only where needed.

Careful here...

(1) The IANA is a group of adults, but it is no longer a group of
    protocol subject matter experts.  IMHO there is probably no need
    for IESG oversight of port number allocation, especially if we are
    eliminating the (artificial) scarcity of so-called well-known ports.

(2) As I understand it, for ports above 1024, the IANA does _not_ assign
    values - it just registers uses claimed by others.  Eliminating
    well-known ports eliminates any assignment role, and leaves us with
    just a registry of what people have claimed.  Note that this means
    there is no mechanism which prevents the same number from being
    registered by more than one registry.

That said, I support the elimination of well-known ports and transformation 
of the port number registry into a "flat" registry in which all ports are 
basically considered equal.

I do _not_ support the introduction of a charging model, for a couple of 
reasons.  First, I don't want to see port numbers become a politicized 
commodity, like IP address space and domain names have.

Second, I believe that having a complete, accurate registry of port numbers 
is highly valuable.  If there is a charge to register a port, and a 
recurring charge to maintain a registration, then no one will register 
their ports for private or vendor-specific use and/or minor protocols. 
That means that they won't be known to network administrators or network 
traffic analysis tools, and people looking for an unused port - even if 
they intend to register and pay for it - will have a difficult time finding 
one that is actually free.  It also means that registrations will tend to 
disappear over time, such that valuable historical information is lost.

A charging model works for domain names because they have to appear in a 
central registry or they don't work.  It works for IP addresses, mostly(*), 
because if two unrelated networks publish routes for the same address 
space, each of them loses some of the time, and no one wants to lose.  It 
won't work for port numbers because only very widely-deployed protocols 
need port numbers that aren't in use by _anything_ else.

(*) Some years ago, there was a period of time lasting several months when 
users of a particular large network provider were unable to communicate 
with CMU, because that provider had usurped 128.2/16 for some private use 
within its network.  We were Not Amused(tm), and had quite a time getting 
it fixed.  And that was in the days when you could usually look up a 
network in the internic whois server, then pick up the phone and reach 
someone who actually understood something about his network.

-- Jeff

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 May 2006 21:16:45 -0400

--On Wednesday, 24 May, 2006 19:06 -0400 Jeffrey Hutzelman
<[email-masked]> wrote:

> Disclaimer - I wasn't even aware of this document before
> reading this thread.  However, I have now read it, so feel
> prepared to comment.
>...
 
>     registered by more than one registry.

This is not correct.  They do, indeed, assign values.  They also
apply some minimal rules in doing so.  Squatting on unassigned
values, while it does happen, is considered to be in bad taste.

> Second, I believe that having a complete, accurate registry of
> port numbers is highly valuable.  If there is a charge to
> register a port, and a recurring charge to maintain a
> registration, then no one will register their ports for
> private or vendor-specific use and/or minor protocols. That
> means that they won't be known to network administrators or
> network traffic analysis tools, and people looking for an
> unused port - even if they intend to register and pay for it -
> will have a difficult time finding one that is actually free.
> It also means that registrations will tend to disappear over
> time, such that valuable historical information is lost.
>...

FWIW, I tend to agree.

     john

---

From: David Conrad <[email-masked]>
Date: Wed, 24 May 2006 20:51:57 -0700

Hi,

On May 24, 2006, at 4:06 PM, Jeffrey Hutzelman wrote:
> On Wednesday, May 24, 2006 03:11:29 PM +0200 Eliot Lear  
> <[email-masked]> wrote:
>> be treated as a group of adults

Heh.  :-)

>> and that they should use some discretion

The scarcity of ports is not artificial.  There are only 16 bits of  
port space and changing the number of bits in ports will be ...  
interesting.

>    values - it just registers uses claimed by others.

This is not accurate.  The IESG has been explicit in that IANA  
assigns port numbers (both well known and user), it does not register  
use.

> Second, I believe that having a complete, accurate registry of port  
> numbers is highly valuable.

As do I.  It does not currently exist.

> That means that they won't be known to network administrators or  
> network traffic analysis tools,

Of course, the port registry does nothing to stop any protocol using  
any port.

It might be useful to figure out what function folks expect the IANA  
port registry to perform.

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Wed, 24 May 2006 21:18:06 -0700

Hi,

On May 24, 2006, at 6:16 PM, John C Klensin wrote:
> This is not correct.  They do, indeed, assign values.

Yes.

> They also apply some minimal rules in doing so.

IANA does a basic sanity check and if there is any question as to  
whether a port should be allocated, we pass the request to an IESG  
Designated Expert who says yes or no.

> Squatting on unassigned values, while it does happen, is considered  
> to be in bad taste.

It is often disappointing to folks who have gone to the trouble to  
obtain a port to find out that nothing stops someone else from using  
the same port for a different protocol.

Rgds,
-drc

---

From: Eliot Lear <[email-masked]>
Date: Fri, 26 May 2006 15:23:57 +0200

Jeff,

> thread.  However, I have now read it, so feel prepared to comment.
As it only just came out, you haven't missed much of a debate.
>    eliminating the (artificial) scarcity of so-called well-known ports.

The point of the document is NOT really to deal with scarcity but to
deal with an outdated process, and to attempt to encourage use of SRV
records where appropriate, and to have some documentation for the port
use.  The charging aspect is something that should be explored really
only as a means for encouraging people to document use via a normative
persistent reference.  And so...
>
> I do _not_ support the introduction of a charging model, for a couple
> of reasons.  First, I don't want to see port numbers become a
> politicized commodity, like IP address space and domain names have.
I do not think the draft calls for politicization.  All it calls for is
documentation.  Failing documentation you might get charged a modest tax
by the IANA for them to keep track of whether the port is still in use.
> numbers is highly valuable.  If there is a charge to register a port,
> and a recurring charge to maintain a registration, then no one will
> register their ports for private or vendor-specific use and/or minor
> protocols. That means that they won't be known to network
> administrators or network traffic analysis tools, and people looking
> for an unused port - even if they intend to register and pay for it -
> will have a difficult time finding one that is actually free.  It also
> means that registrations will tend to disappear over time, such that
> valuable historical information is lost.
The registry isn't accurate today.  And traffic analysis tools really
can't do much with a protocol that isn't documented.

Eliot