Re: Call for Community Feedback: Retiring IETF FTP Service

Keith Moore <> Tue, 17 November 2020 05:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43FC53A0E3F for <>; Mon, 16 Nov 2020 21:42:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nIklfGV6P1un for <>; Mon, 16 Nov 2020 21:42:13 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 32B963A0E3A for <>; Mon, 16 Nov 2020 21:42:13 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 5A73C5C01D2; Tue, 17 Nov 2020 00:42:11 -0500 (EST)
Received: from mailfrontend1 ([]) by compute3.internal (MEProxy); Tue, 17 Nov 2020 00:42:11 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=9uJ2qt isvob7kHiNtjLlb5Jf7hmqgN8PN5nidLRGStE=; b=gBpi37oYqHuMYCRnow5QTu D9cv6fFC5oU7DKQlCIZgBuQSo2lqiXbpZL2TuDMuOvPk70zMj3F5ijOFDvKGosm/ NCHobf5AmRv2DheYJwepIeTxuOHvVm/jDPsCpLxuUDy2H1KfkBjN2+spBc8lezO7 YwfgQjTt9WMROvk7rH9aFWfygV8RbAWQQlAI4jEGAW77zFKrgm1jSK3MyhNs0f2i IWsmt0YFjpUsud0WhZ4I4Xc2dncbufoBDZegsRvTJXrzIdexRpwiJhD0x1h2O6+g Z6lLdFcqlMC6dOcZxNBFgBFypkxpea06y/ZUtrozbUDGL9birV1M0JxuBkmAAwog ==
X-ME-Sender: <xms:s2KzXx6JC7gnsAAU2vmhVwjJJPoDQHPiEcIHDI2Q9aW6uuuSyouc9A> <xme:s2KzX-5xuG1_zpLil0V4sOX0pgZXEI5y0x-lRfLjYLXLcXsduyV0xxrB543_ME2fx TzWTKrpbBl8bg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefvddgjeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtsegrtderredtfeejnecuhfhrohhmpefmvghithhh ucfoohhorhgvuceomhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhmqe enucggtffrrghtthgvrhhnpeevfeetudeigedtledvvddtudefjeejffdvfeetjeeiueel gfdtgfegtdffkeetudenucfkphepuddtkedrvddvuddrudektddrudehnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhm
X-ME-Proxy: <xmx:s2KzX4eurNAKy6xAjCzp64ElDCU_WYHHUj2Vh36WtbmtTbH7OVSq1A> <xmx:s2KzX6IFqzn__PNyP-eh0bDErrzYNGT1cSzjHkavVlqcrzlQJ_pAsg> <xmx:s2KzX1K2fB6pq5tuRhEYpr93rv9RtXSfHKo0K20bcGvPP1qTsjHhPw> <xmx:s2KzX6W5TOOc4t_eADTR1l_eixllGSm8HtAxV_Xn7VRiOX7itMhzQg>
Received: from [] ( []) by (Postfix) with ESMTPA id 7F3D8328005E; Tue, 17 Nov 2020 00:42:10 -0500 (EST)
Subject: Re: Call for Community Feedback: Retiring IETF FTP Service
To: Adam Roach <>,
References: <> <> <> <> <> <>
From: Keith Moore <>
Message-ID: <>
Date: Tue, 17 Nov 2020 00:42:08 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------8DAF73610FD53A5AAC6E70DC"
Content-Language: en-US
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Nov 2020 05:42:15 -0000

On 11/16/20 5:15 PM, Adam Roach wrote:

>>> In the analysis, I think there are two costs to consider and one 
>>> benefit. The benefit of leaving it online, of course, is that some 
>>> small group of users still find utility in FTP.
>> IMO that misstates the benefit.   A stable service can have a large 
>> (and long-term) benefit even if only a few clients at a time use it.
> Only read in a vacuum. If you read further, I argue for the stable 
> interfaces you want.

Ok, so why not use an existing interface that has proven to be stable 
through decades of use, instead of one that _might_ be stable in the future?

> I believe that your objections (here and elsewhere) mentioning "user 
> interface" conflate HTTP (transport) with HTML (markup), and mixing 
> user interface into the RFCs isn't a foregone conclusion: the 
> requirement you have of not mixing display in with documents is why I 
> suggest that raw versions be made available. 

Sorry if I wasn't clear, but that was not my concern.  My concern is 
that the web interface taken as a whole (including not only the RFCs 
themselves but also any browsers, HTML, JS, CSS, fonts, etc. that are 
used to make up the entire user interface) are all optimized for one 
kind of user experience, and NOT for use as an API to be used by 
programs.   So if someone later decides to rearrange or otherwise alter 
the RFCs, or reconfigure servers, or whatever, in order to improve user 
experience, that will be seen as the Right Thing to do regardless of any 
concerns that people might have about the API changing.

I would argue that that's really the argument in favor of deprecating 
FTP that we are seeing now - that the stable API for accessing RFCs is 
irrelevant, because it's only the user experience via the web that 
matters.  And I do have a big problem with that.

It has been claimed that the use of FTP constrains file system layout, 
but it's mostly the API that constrains the file system layout.

> And I even argue for making the filesystem mountable like you 
> requested, even if I consider that use case to be a bit baroque.

With FTP, I can mount the RFCs as a file system this very minute (as I 
just did) and treat those RFCs as local files (say by grepping through 
them, as I just did).  With FTP it's unambiguous as to how to do this 
and the code to do this has existed for many platforms for many years.  
With WebDAV, this is also possible, but at the cost of ALL current users 
having to retool.   And I have no idea how widely WebDAV is supported - 
though I did verify that a FUSE interface to it exists for Linux.

(I don't personally consider remote file system access to be baroque at 
all; to me it seems relatively straightforward and much easier to use in 
some ways than a web service.  For instance, I can very easily download, 
or print, multiple RFCs in one command, without having to click on each 
link separately, specify its download directory and file name, etc.   
This works because FTP always was quite clearly a protocol for accessing 
files on disk. )

> I'm sympathetic to the position that all change can be disruptive, and 
> I understand that you know how FTP works and are comfortable with it. 
> At the same time, I'm not yet seeing any requirements that you've put 
> forth that can't be met pretty trivially with HTTP, other than an 
> inferred bedrock requirement of "this must not change at all."

I believe change to long-valuable services needs to be justified, and 
not made merely out of a desire to be in fashion.

I never have stated a position that all change can be disruptive.  I 
suspect that's true as a generalization, but I'm certainly not arguing 
that nothing should ever change.  I'm talking specifically about a 
single service here.

But there really should be a good reason to make such a change. I have 
run FTP servers before; they're not much trouble.  (another advantage of 
using a stable protocol).   Taken both client and server overhead into 
account, I see less overhead associated with continued use of FTP, than 
with WebDAV.   It's possible that there's even more opex on the server 
side using WebDAV, as the arguments that have been cited as detriments 
to continuing FTP might also apply to WebDAV support.

One thing that might make me change my mind might be if WebDAV were 
considerably more efficient or more functional.  That is possible.  
HTTP/webdav should require less TCP setup overhead, and does offer the 
potential for seek/read capability using byte ranges.

Another thing that might make me reconsider is if IETF wished to host 
its servers in some sort of dysfunctional cloud environment (probably 
using NAT within the cloud) that didn't support FTP's use of ports.   
But I think PASV should still work and it's pretty much the default 
these days anyway.

> I get it. It's annoying when a technology we like falls by the wayside. 

FTP hasn't fallen by the wayside.

I suspect what's happened instead is this:  There are people who think 
that the way /they/ use computers is the way /everyone/ should use 
computers.   And if so, I think they should reexamine their assumptions.

> YMMV, of course, but I encourage you to reflect a bit more on how much 
> of your reaction is pushback on any change at all versus actually 
> losing the ability to do what you want to do.

I think you're reading between the lines far more than is intended or 


p.s. we could have set up the server in far less time than it has taken 
to write these messages.