Subject: Re: Guidance needed on well known ports

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 20 Mar 2006 08:54:59 -0800

I concur.

On the firewalls issue I see no problem moving from port numbers to a coherent architected alternative.

What we should fear is the emergence of numerous ad hoc schemes because nobody proposed an acceptable common architecture. I am disappointed that the response to dkim, marid has been 'don't do too much' and not 'don't drive us into a dead end'

We have to work with what we have here, that unfortunately means original dns plus the srv record. 

 -----Original Message-----
From: 	Spencer Dawkins [mailto:[email-masked]]
Sent:	Mon Mar 20 04:38:16 2006
To:	[email-masked]
Subject:	Re: Guidance needed on well known ports

Re: Guidance needed on well known portsTwo points here.

First, I totally agree with Phillip that closing the registry is the right direction to head. It would be lovely if this became a consideration in new protocol work at the IETF. I'm not sure how quickly we can actually close it, but having a chosen and stated direction that points somewhere else seems very appropriate for new protocol work. Please note how long it is taking to kill the classful addressing terminology. If you want to change directions on port number interpretation, please start soon..

Second, as long as the current mechanism is "widely used" (and, with the rise of HTTP-as-transport and port-agile protocols, it's less widely used every day anyway), people try to use the current mechanism to understand and characterize traffic on their networks (you may laugh, and it is getting funnier every day, but they do exactly this with firewall rules, protocol analyzers - and the good ones DON'T use port numbers much any more - and traffic monitors).

The definition of an application port is what the two ends of the application think it is. If I think that port 25 is a good port, you do, too, and we never use it for anything else, why is this wrong? It seems to me that saying, "if you want to understand what the traffic on this network looks like, our direction is that you'll need to check SRV records most of the time in the future" seems to give people who do firewalls, traffic monitors, etc. the right signal as well.

Thanks,

Spencer
  ----- Original Message ----- 
  From: Hallam-Baker, Phillip 
  To: Stephane Bortzmeyer 
  Cc: [email-masked] 
  Sent: Monday, March 20, 2006 6:13 AM
  Subject: Re: Guidance needed on well known ports

  Refusing new registrations is what I meant by closing the registry.

  Of course it is not possible to change the way deployed systems work retrospectively.

  The question was about a new protocol.

  We are about to see several thousand new web services protocols being developed per year. A port each would be idiotic. Expecting UDDI deployment is at this point futile.

  The solution that people are going to turn to is to use the existing dns as deployed. Fortunately windows 2k uses srv extensively.

  We should also promote the use of srv for existing protocols for configuration. _pop3._tcp.example.com can only advertise the location of the pop server. Why not use it and save me debugging mail config for friends and familly?

   -----Original Message-----
  From:   Stephane Bortzmeyer [mailto:[email-masked]]
  Sent:   Mon Mar 20 03:06:23 2006
  To:     Hallam-Baker, Phillip
  Cc:     [email-masked]
  Subject:        Re: Guidance needed on well known ports

  On Sat, Mar 18, 2006 at 02:09:47PM -0800,
   Hallam-Baker, Phillip <[email-masked]> wrote
   a message of 163 lines which said:

  > The Internet has a signalling layer, the DNS. Applications should
  > use it.  The SRV record provides an infinitely extensible mechanism
  > for advertising ports.

  I agree here but this means we should keep at least one well-known
  port, 53.

  > IANA should be told to close the well known ports
  > registry. Applications should use DNS SRV records for service
  > location.

  I agree with that rule for the *future* protocols. But it does not
  help with current (and widely deployed) protocols. So, asking IANA to
  refuse new registrations in the well-known ports registry is one
  thing, shutting down the registry is another.

------------------------------------------------------------------------------

  _______________________________________________
  Ietf mailing list
  [email-masked]
  https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Mar 2006 12:09:15 -0500

> We have to work with what we have here, that unfortunately means original dns plus the srv record. 

I never cease to be amazed at people who insist on taking things that
basically work fairly well and replacing them with more complex
mechanisms that are known to work more slowly and less reliably.

Probably the worst problem with destination port numbers is that there
aren't enough of them.  That's probably something that needs to be
addressed in TCP and UDP, but a simple extension to each would do the
trick.  

SRV provides fairly limited utility in exchange for the number of
problems it presents.

Keith