From: Jeffrey Hutzelman [mailto:jhutz(_at_)cmu(_dot_)edu]
(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.
So how is a server to support two services that happen to have chosen the sam
e port number?
I think that what is indicated here is that service discovery by port number
is broken and no longer scalable.
There are only 65536 possible port numbers, we expect to see rather more Web
Services become established. We have 10,000 registrations already. This is a
failed discovery strategy.
The scalable discovery strategy for the Internet is to use SRV records. For t
his to be possible it has to become as easy to register an SRV code point as
it is currently to register a port. It makes no sense for there to be more re
strictions on issue of the unlimited resource than on the limited one.
Getting an SRV code point registered is not a trivial task and there is in fa
ct a parallel non-IANA registry already operating because most people cannot
be bothered to deal with the IETF process. It should not be necessary to writ
e an RFC or go through the IESG to register a code point. The implicit assump
tion here is that the IESG controls the Internet through control of discovery
aparatus, a silly notion that the other Internet standards bodies are not go
ing to accept.
There was never any intention of making getting SRV labels hard.
The reason for the RFC was to handle *existing* protocols and to
handle protocols which wished to use the fields in a non standard
manner.
Retrofiting SRV usage into a existing protocol is not straight
forward.
http://www.watersprings.org/pub/id/draft-andrews-http-srv-01.txt
is a attempt to retrofit SRV into HTTP.
Designing a new protocol to use SRV should be straight forward.
I would expect it to be about 1 paragraph in the new protocol's
description.
If the W3C or OASIS develops a spec for a Web service it makes no sense for t
hem to then be required to write an RFC and the group be required to grovel t
o the IESG and worse be held captive by the IESG work schedule. Not going to
happen, nor does it. People who want SRVs cut in those groups just do it.
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 think this is a very bad idea at this stage. At this point introducing char
ging is more likely to lead to speculation and premature exhaustion of the su
pply.
(*) 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.
This particular weakness with the allocation of IPv4 addresses is likely to b
e exercised with increasing frequency when the IPv4 address store begins to r
each exhaustion.
One can well imagine that a large ISP operating in Asia might decide that rat
her than pay an exhorbitant amount to buy another 4 million addresses it migh
t just make a private agreement to divy up net 18 (18... = MIT) and make a pr
ivate agreement with its neighboring ISPs to do so.
The bad effects resulting from such practices hardly need to be stated. If we
are lucky people will go for the Class D and Class E space first. But that i
s going to upset some people (Mbone users for instance).
The governance mechanisms of the Internet assume a degree of authoritarian co
ntrol that simply does not exist. It is goodwill rather than authority that k
eeps the Internet together.
My theory (which I make no appologies for acting on) is that Vint Cerf and Jo
n Postel intended the mechanisms set up to control and allocate to act as the
Gordian knot.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf