Subject: [tcpm] 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: The IESG <[email-masked]>
Date: Mon, 04 Jan 2016 07:31:13 -0800

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.

Abstract

   This document reclassifies several TCP extensions and TCP-related
   documents that have either been superseded, have never seen
   widespread use, or are no longer recommended for use to "Historic"
   status.  The affected RFCs are RFC 675, RFC 721, RFC 761, RFC 813,
   RFC 816, RFC 879, RFC 896, RFC 1078, and RFC 6013.  Additionally,
   this document reclassifies RFC 700, RFC 794, RFC 814, RFC 817, RFC
   872, RFC 889, RFC 964, and RFC 1071 to "Informational" status.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tcpm-undeployed/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tcpm-undeployed/ballot/

No IPR declarations have been submitted directly on this I-D.

---

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

> 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: Joe Touch <[email-masked]>
Date: Tue, 5 Jan 2016 18:22:09 -0800

> On Jan 5, 2016, at 5:53 PM, [email-masked] wrote:
> 
> On Tue, 05 Jan 2016 16:51:09 -0800, Joe Touch said:
> 
> 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.

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. 

> 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).

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

Joe

---

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