Subject: RE: [newtrk] ... and, speaking of cruft ...

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 4 Oct 2004 10:03:54 -0700

As far as I am concerned there is no reason to use reserved ports. They
should be discontinued. 95% of the assignments are for applications that
will never be used by more than a handful of users.

SRV made static port assignments obsolete. NAPTR went further.

Get rid of the assigned ports registry entirely. Instead have a first come
first served SRV/NAPTR prefix registry. This is not a scarce resource so
there is no need to wait until a protocol has proved itself before
allocating a port.

There is sense in having an assigned port for a small number of legacy
protocols where SRV signalling is not going to be practical.

Apart from SMTP, DNS, HTTP and NTP pretty much everything else is legagy.
FTP and NNTP are still moving but there is no excuse for gopher or the rack
of pre Web port allocations for niche information services.

Sure people will continue to use cruft, but they should not be under the
mistaken impression anyone is managing their cruft.

		Phill

> -----Original Message-----
> From: Harald Tveit Alvestrand [mailto:[email-masked]]
> Sent: Sunday, October 03, 2004 3:59 PM
> To: Spencer Dawkins; NEWTRK Mailing List
> Subject: Re: [newtrk] ... and, speaking of cruft ...
> 
> 
> The only area where I know there has been serious work on reclaiming 
> IETF-controlled numbers is in DHCP options.
> 
> Certainly not in ports.
> 
>                      Harald
> 
> --On 2. oktober 2004 12:38 -0500 Spencer Dawkins 
> <[email-masked]> 
> wrote:
> 
> > Dear All,
> >
> > We are having a conversation in BEHAVE about port number 
> ranges, and I
> > happened to look at 
> http://www.iana.org/assignments/port-numbers. I DID
> > see a couple of notes about port numbers that had been 
> reclaimed, but
> > does this happen more often than once in a blue moon?
> >
> > Just wondering ...
> >
> > Spencer
> >
> > .
> > newtrk 
> resources:_____________________________________________________
> > web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
> > mhonarc archive: 
> http://darkwing.uoregon.edu/~llynch/newtrk/index.html
> >
> >
> 
> 
> 
> 
> .
> newtrk resources:_____________________________________________________
> web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
> mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html
> 
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Keith Moore <[email-masked]>
Date: Wed, 6 Oct 2004 20:50:22 -0400

> SRV made static port assignments obsolete. NAPTR went further.

uh, no.  SRV allowed new apps to determine at runtime to use a 
non-default port.  it did not affect existing apps.  whether SRV was 
actually a good idea is debatable, but there wasn't much risk in trying 
it as long as it didn't affect existing apps.  OTOH expecting old apps 
to honor SRV would clearly degrade interoperability.

NAPTR allows URIs to be mapped onto service locations via DNS, but 
that's a separate issue.

both SRV and NAPTR slow down new connections, because they require 
extra DNS lookups.  this can also affect reliability, especially if 
additional servers have to be consulted.  (DNS is too unreliable and 
too slow already, SRV and NAPTR make it worse.)

SRV also makes it difficult to monitor and/or intercept particular 
kinds of traffic which is either good or bad depending on your 
point-of-view.

Keith

.