Re: Questions about draft-lear-iana-no-more-well-known-ports-00.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi,

On May 24, 2006, at 4:06 PM, Jeffrey Hutzelman wrote:
On Wednesday, May 24, 2006 03:11:29 PM +0200 Eliot Lear <lear at cisco.com> wrote:
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

Heh. :-)

and that they should use some discretion
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.

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.


(2) As I understand it, for ports above 1024, the IANA does _not_ assign
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


_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf




Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.