Re: [port-srv-reg] [tsvwg] draft-ietf-tsvwg-iana-ports-02

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Lars Eggert wrote:
> Hi,
> 
> On 2009-10-7, at 17:10, Joe Touch wrote:
>> You heard from me regarding several issues with some of Stuart's mods,
>> with no further discussion on the points I raised except for the issue
>> of some items being better placed in a separate document, leaving this
>> as procedural.
> 
> true, this slipped my mind.
> 
>>>> +      <t>It should be noted that over time the assumption that
>>>> +      a particular port number necessarily implies a particular
>>>> +      service has become less true:</t>
>>
>> If it is true, it needs a citation. If there is no citation, I'd suggest
>> dropping this.
> 
> I don't have a citation, but I'll argue that as more and more services
> migrate onto HTTP and its extensions, at least those become
> indistinguishable.

In some cases, these are true web servers running on other ports. In
other cases, they are application protocols that implement a subset of
HTTP used as an application protocol.

I don't see why this is relevant. The rate of port assignment has not
varied, and we don't consider all CLIs to be "telnet running on other
ports".

Finally, the fact that a variants of a service run on more than one port
doesn't diminish the fact that a port number implies a specific service.

>>>> +        <list style="symbols">
>>>> +          <t>When different background applications on a single
>>>> computer
>>>> +          each export a web-based user interface, (e.g. as done by the
>>>> +          Common Unix Printing System <xref target="CUPS" />) they
>>>> cannot
>>>> +          all get TCP port 80, especially if that computer is also
>>>> hosting
>>>> +          a conventional web site on TCP port 80. Consequently, a
>>>> single
>>>> +          host may have several different processes all answering HTTP
>>>> +          requests of various kinds, on ports other than port 80.</t>
>>
>> HTTP is a format for messages, but doesn't necessarily imply an
>> application service or application protocol. There are many systems that
>> use HTTP formatting for a variety of services, defined by the particular
>> HTTP messages exchanged.
>>
>> The same has been true for ASCII command-line interfaces; they all could
>> run over telnet, but they back onto different application services. This
>> does not validate the idea that the protocol is any less a new service,
>> just because it uses a web engine for its implementation or HTML for its
>> markup.
>>
>> I'm not clear on why this is relevant; it appears to suggest that
>> computers are increasingly using the same service on different ports,
>> but I don't see that as the case.
> 
> I wouldn't call HTTP a service, it's basically become a transport layer.
> In other words, I agree that this bullet doesn't make sense. Or I don't
> get it.

I'll try to explain how I read it. There are two different uses of HTTP
on ports other than 80:

1) same as on port 80, just to a different server

2) as framing, like a presentation layer, to an application protocol

The bullet above implies that #1 is "the web" on a different port, but I
doubt we could argue that #2 is.

I'd argue that both are the same thing. The application protocol is
defined both by the framing and the service provided, and running a CUPS
configuration interface on a port other than 80 is a service intended to
be different from a web server.

Otherwise, should be calling all CLI services "telnet", and that doesn't
make sense either.

>>>> +          <t>When different users are running multiple copies
>>>> +          of the same application on a single computer, multiple
>>>> +          instances of the application cannot listen on the same
>>>> +          port at the same time. Consequently, applications of
>>>> +          this kind need to be programmed to expect that they
>>>> +          may not always be able to get the port they want,
>>>> +          and may have to listen on an alternative port instead.</t>
>>
>> There are a small number of assigned alternative ports as well. However,
>> it is also increasingly common that such services are virtualized,
>> sending one of a number of DNS names that resolve to the same IP address
>> inside the command (as with HTTP 1.1) or running copies of a service on
>> different IP addresses on the same machine.
>>
>> I.e., I agree that this may be true, but this is basically saying "when
>> you can't run on a registered port, there are problems" - which are
>> either solved by using a backup registered port, or are unsolvable.
> 
> What you write are other options for running multiple services, but I
> believe Stuart has a point when he says that in some cases you'll see
> service A running on its registered port as well as another port. Hence,
> port numbers don't indicate services as strongly as they did in the past.

As I explain above, I don't think this is any different from running
what is essentially telnet on other ports. We've *always* reused framing
protocols for different services, and so even if this is true I claim
that nothing has substantially changed.

>>>> +          <t>When different computers in a home are using a NAT
>>>> gateway
>>>> +          to share a single IP address, the computers can request that
>>>> +          the NAT gateway create port mappings to enable them to
>>>> receive
>>>> +          inbound connections <xref target="I-D.cheshire-nat-pmp" />,
>>>> +          but they can't all get the same external port at the same
>>>> time.
>>>> +          Consequently, some applications on some of those computers
>>>> +          may be receiving inbound connections on port other than the
>>>> +          port usually used for the service in question.
>>>> +          As ISPs begin to deploy large-scale NAT, sharing a single
>>>> +          IP address between multiple homes, it is likely to become
>>>> even
>>>> +          more common to have applications receiving connections on
>>>> +          dynamically allocated ports.</t>
>>
>> The focus of the document is registered names and numbers. It's true
>> that NATs defeat that, but what's the reason for discussing that in this
>> doc?
> 
> I believe the argument is that if someone else behind that NAT has
> gotten "your" external port (the one that is registered for your
> service), you'll run on another port. Hence, port numbers don't indicate
> services as strongly as they did in the past.

This document should be focusing on the *process* for registering and
modifying registrations of port names and numbers.

It should stay clear of assertions about possible future issues with
these assignments. That can be in a separate document, and should
include some evidence about the current scale of impact (e.g., my
Westell modem has u-PNP turned off by default, and port forwarding is
largely done manually AFAICT since most people's NATs aren't Apple
devices or opensource alternate firmware).


>> Stuart Cheshire wrote:
>> ...
>>> Choosing an appropriate service name can be harder than it seems at
>>> first. In draft-gudmundsson-dns-srv-iana-registry they propose "overlay"
>>> protocols (such as HTTP and XMPP), e.g. for SRV records like
>>> _service._http.example.com.
>>
>> is this intended to be:
>>
>> _service._http._tcp.example.com ??
> 
> No, I think they want _service._http.example.com
> 
> Including the protocol in the service name was really not such a great
> idea...

Hmmm. That's quite different from the discussion I've been having on the
TAE list, and from what is suggested in
draft-cheshire-dnsext-dns-sd.txt, e.g.:

_http._tcp.example.com.

It would also defeat some current efforts to add support for alternate
transports for HTTP, e.g., HTTP over SCTP.

Though, as we agree, this is out of scope.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkrMrpMACgkQE5f5cImnZruHPgCg9zSD59igu3OGEYubEw4D2fU1
FWAAn0/QaB229Snb7c4PeM1mmtmV/7CJ
=v0k8
-----END PGP SIGNATURE-----