Jeff,

> Disclaimer - I wasn't even aware of this document before reading this
> 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.
>
> (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 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.
>
>
> 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.
The registry isn't accurate today.  And traffic analysis tools really
can't do much with a protocol that isn't documented.

Eliot

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

Reply via email to