![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
|
Two 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
|
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.