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

"Hallam-Baker, Phillip" <pbaker@verisign.com> Tue, 06 June 2006 11:43 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnZyL-0006yY-Of; Tue, 06 Jun 2006 07:43:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnZyJ-0006x4-SY for ietf@ietf.org; Tue, 06 Jun 2006 07:43:43 -0400
Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnZyI-0005iQ-B1 for ietf@ietf.org; Tue, 06 Jun 2006 07:43:43 -0400
Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id k56BhdWu015319; Tue, 6 Jun 2006 04:43:39 -0700
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jun 2006 04:43:31 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 06 Jun 2006 04:43:38 -0700
Message-ID: <198A730C2044DE4A96749D13E167AD37B5571E@MOU1WNEXMB04.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Questions about draft-lear-iana-no-more-well-known-ports-00.txt
Thread-Index: AcZ/h0dfl40deSwLRR+rMy1g9hHumgJ0vDVQ
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: Jeffrey Hutzelman <jhutz@cmu.edu>, Eliot Lear <lear@cisco.com>, John C Klensin <john-ietf@jck.com>
X-OriginalArrivalTime: 06 Jun 2006 11:43:31.0720 (UTC) FILETIME=[6F7F9080:01C6895E]
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Cc: ietf@ietf.org
Subject: RE: Questions about draft-lear-iana-no-more-well-known-ports-00.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

> From: Jeffrey Hutzelman [mailto:jhutz@cmu.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 same 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 this 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 restrictions 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 fact 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 write an RFC or go through the IESG to register a code point. The implicit assumption here is that the IESG controls the Internet through control of discovery aparatus, a silly notion that the other Internet standards bodies are not going to accept.

If the W3C or OASIS develops a spec for a Web service it makes no sense for them to then be required to write an RFC and the group be required to grovel to 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 charging is more likely to lead to speculation and premature exhaustion of the supply.


> (*) 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 be exercised with increasing frequency when the IPv4 address store begins to reach exhaustion. 

One can well imagine that a large ISP operating in Asia might decide that rather than pay an exhorbitant amount to buy another 4 million addresses it might just make a private agreement to divy up net 18 (18... = MIT) and make a private 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 is going to upset some people (Mbone users for instance).


The governance mechanisms of the Internet assume a degree of authoritarian control that simply does not exist. It is goodwill rather than authority that keeps the Internet together.

My theory (which I make no appologies for acting on) is that Vint Cerf and Jon Postel intended the mechanisms set up to control and allocate to act as the Gordian knot.

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