Subject: Re: Last Call: <draft-ietf-tcpm-undeployed-03.txt> (Moving Outdated TCP Extensions and TCP-related Documents to Historic and Informational Status) to Informational RFC

From: [email-masked]
Date: Mon, 04 Jan 2016 15:53:50 -0500

On Mon, 04 Jan 2016 07:31:13 -0800, The IESG said:
>
> The IESG has received a request from the TCP Maintenance and Minor
> Extensions WG (tcpm) to consider the following document:
> - 'Moving Outdated TCP Extensions and TCP-related Documents to Historic
>    and Informational Status'
>   <draft-ietf-tcpm-undeployed-03.txt> as Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2016-01-18. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.

The draft says in section 2.1:

   o  [RFC1078] U, "TCP Port Service Multiplexer (TCPMUX)" should be
      deprecated, because:
....
      *  There are no known client-side deployments.

SGI's Data Migration Facility does in fact use tcpmux on port 1 for client
systems to contact the DMF server for out-of-band administrative functions.
However, this usage is (as far as I know, after been the admin of a DMF system
for 5 years) strictly confined to intercommunication between the clients and
server of a DMF cluster, and I know of no other vendors or packages that
try to talk to DMF over tcpmux (everything uses the SGI-provided DMF client
tools to do the heavy lifting, and then operates on the output of the tool).

Whether that should be sufficient to deter moving RFC1078 to deprecated is a
question for somebody else to answer.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 05 Jan 2016 13:40:38 +0100

>      *  There are no known client-side deployments.

Just for reference. I use TCPMUX for a private protocol. It is nice for
prototyping because it is easier pick a unique string for a protocol than
to pick un unused port.

(Obviously, when DNS is used, SRV can also be used for this)

The second argument is a weird. 
      *  It requires all new connections to be received on a single
          port, which limits the number of connections between two
	  machines."

There are many systems that receive essentially all of their traffic over 
one port. So those system already have this problem. It also is very rare
that a single host connects to a remote host more than 16000 times
in parallel. So I wonder if this is a practical limitation.

---

From: Joe Touch <[email-masked]>
Date: Tue, 5 Jan 2016 16:51:09 -0800

> question for somebody else to answer.

This sounds like an opportunity for SGI to shift over to DNS-SD.

We can change the line about "no known" to "only one known". We could
refer to DNS-SD going to PS as a rationale for obsoleting TCPMUX if
necessary, IMO.

Joe

---

From: [email-masked]
Date: Tue, 05 Jan 2016 20:53:43 -0500

> refer to DNS-SD going to PS as a rationale for obsoleting TCPMUX if

Not a really good fit. In general, you already *know* the hostname that
has the service - it's the host you have the NFS mount from, or the current
CXFS metadata server if you're inside the cluster. And trying to use DNS-SD
for two logically distinct DMF archives is just *looking* for trouble.

It would be a much better fit for portmapper actually (although that would
involve leaving a daemon running to answer/forward queries - probably not as
big an issue today as it was when they started coding DMF almost 25 years ago).

---

From: Joe Touch <[email-masked]>
Date: Tue, 5 Jan 2016 18:22:09 -0800

> On Jan 5, 2016, at 5:53 PM, [email-masked] wrote:
> 

You can use DNS-SD to just find the port number given s known hostname. 

The simplest alternative to that is to get an assigned (user) port number. 

> big an issue today as it was when they started coding DMF almost 25 years ago).

The forwarding is why import mapper might not be a good fit.

Joe