Re: Call for Community Feedback: Retiring IETF FTP Service

Keith Moore <moore@network-heretics.com> Wed, 18 November 2020 14:22 UTC

Return-Path: <moore@network-heretics.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D653A0995 for <ietf@ietfa.amsl.com>; Wed, 18 Nov 2020 06:22:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kbt5G24qw-0L for <ietf@ietfa.amsl.com>; Wed, 18 Nov 2020 06:22:21 -0800 (PST)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D21293A0992 for <ietf@ietf.org>; Wed, 18 Nov 2020 06:22:13 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 05AEDE22 for <ietf@ietf.org>; Wed, 18 Nov 2020 09:22:12 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 18 Nov 2020 09:22:13 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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=IInLJ1 p0fu/mA/xe6yU42rttgF7zqwYEHdPLQ9QNBFE=; b=EzsHy2G6BLcydanlwQKUXa 70oL8VfHJLxc1BbBuIc6u7DDRKK34R3DJV8ZYMqTQK9q55s46juGsc89ieebFA2O zfeNYGBuOlJWk0nWH+JeFAANPizak6cJBPiGn9YaggUYMJMZc7Ggl8la8bb52mcR YpR8i1UDaeeasYYwzdpih77DaX6znCYJL3pK19+wrPZav5k8vKSre79+YyT3ydJO 0x/I4hUc4oHabxxh42bd6p9ol6igI7RmXB7qgYRJRqQiAyYIbgbZb5TbRzlB01yc tz4jSpIk7gpzNIiqFqqNW6cGPF22aKgS5wJAVBECrzCDoC/hfTo6h+no90FiaAvA ==
X-ME-Sender: <xms:FC61X-S06Voy4kfFz0X8hATMFEweczzNxjOFGfV_Xcxg9QWWZBGJ3w> <xme:FC61Xzz5LHDm2pd_gpyvh8mqk5Nw31OnKnP6SpfmRKNdgFz2BQy0jPANFvOTpTlDo UNu-md-pxbyAA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefhedgieehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgesrgdtre ertdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnheptdefjeelheffhf fhhfdvjeejhedufffhleefvdehtdefffevtdetfeekuedtkeeknecuffhomhgrihhnpehh thhtphgvtghlihhpshgvughithgrlhhmohhsthhimhhmvgguihgrthgvlhihrdhsohenuc fkphepuddtkedrvddvuddrudektddrudehnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitg hsrdgtohhm
X-ME-Proxy: <xmx:FC61X71ewu2o86NF-fM-gyTO5Fs0cdXt9paLax0kn_qIs0Iy21a-3A> <xmx:FC61X6CQ_1355in-kNk62ni3qAq_OJZYA7XUwAwooq9KNix-smZmGA> <xmx:FC61X3gYhPFCWIGXHUzJgdSCVSy76PG6XE5l6ERw3fuy1brwObDiMg> <xmx:FC61X2SlUFu19BAxDnkkrY-pfCsWXqr8gSDlXlykJ15ytJPIPUuugQ>
Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 256AA328005D for <ietf@ietf.org>; Wed, 18 Nov 2020 09:22:12 -0500 (EST)
Subject: Re: Call for Community Feedback: Retiring IETF FTP Service
To: ietf@ietf.org
References: <a8bdd67a-13ea-4433-aa38-9cfd48ea28da@network-heretics.com> <0e875497-9986-a0d9-8354-3eac26b7f882@nostrum.com> <a02e15f2-34fb-4124-7ba0-c0ee0070b39f@network-heretics.com> <6a29096e-c76e-9bde-388c-bf411b235346@nostrum.com> <6ff3c8a8-57c9-a278-51ce-ce24fd2dfc0e@network-heretics.com> <01RS3W7DNPHA005PTU@mauve.mrochek.com> <7057e29825514008a06b749cb5c476f6@cert.org> <01RS3Y1AZ65A0085YQ@mauve.mrochek.com> <365930470c214fbd982da633c69b3b67@cert.org> <5172d442-6bb0-0e11-81fb-3da6e828166e@network-heretics.com> <20201118121725.GN39170@kduck.mit.edu>
From: Keith Moore <moore@network-heretics.com>
Message-ID: <4cf6e485-b64b-9980-5d5d-602fd602bd74@network-heretics.com>
Date: Wed, 18 Nov 2020 09:22:11 -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: <20201118121725.GN39170@kduck.mit.edu>
Content-Type: multipart/alternative; boundary="------------41AA44DEFDDC4DED2241CA92"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/EdWraCD8R_j_pr1RS2Qe_P9d1Dw>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Nov 2020 14:22:23 -0000

On 11/18/20 7:17 AM, Benjamin Kaduk wrote:
> Hi Keith,
>
> On Wed, Nov 18, 2020 at 07:05:35AM -0500, Keith Moore wrote:
>> More broadly, I keep seeing examples of people arguing for restrictions
>> on how IETF resources may be accessed, based on the assumption that
>> /everyone should use IETF resources the way most people use IETF
>> resources/.  Trying to force everyone to be alike is deeply offensive
>> and counterproductive to IETF's goals.   IETF works best when it has
>> wide participation.
> I think I can accept a sentiment that "not offering FTP access is a
> restriction on how IETF resources may be accessed"
not merely /how/ they may be accessed (which is important), but also 
/who/ can access them
> even though it's a
> somewhat convoluted logical exercise to get there.  But what threshold do
> you use, then?

I would say that the broad spectrum of IETF document users should be 
considered, and the decision be made in terms of what is reasonable 
accommodation for that broad spectrum of users.

It doesn't mean you have to support everything forever, but changing the 
access methods without considering how to accommodate that broad 
spectrum of users (and also URLs that will become stale) doesn't seem 
appropriate.

> It's a restriction on how IETF resources may be accessed
> that I can't get them via gopher, too, yet I am not expecting you to jump
> up and demand that the IETF set up a gopher server by which I can obtain
> RFCs.  Is the only difference between FTP and gopher that we happen to have
> been running FTP for some time?

There are many differences between FTP and gopher.   FTP was widely used 
for at least a decade before gopher appeared, and gopher was a flash in 
the pan - http eclipsed it almost immediately.   So there was never any 
long-term use of gopher.   A lot of people never even saw gopher before 
they got their hands on a web browser.

> My understanding is that we are at a juncture where staff are migrating
> services to a new generation of hardware (or possibly "hardware"; I'm not
> very close to the details), and asking whether we need to put in the work
> to build support for FTP on the new generation of stuff.  This is not a
> "just keep the lights on" question of leaving be what's currently running,
> but a question of actively putting in work to build a new thing to provide
> the service, and I think it's fair to ask for the cost/benefit analysis to
> be done.

I haven't seen any cost analysis at all.   The benefit analysis that 
I've seen seems to only care about users in terms of traffic volume, 
which seems to me to be a rather narrow and myopic view.

It's not wrong to ask the question, but the benefits of FTP need to be 
understood and taken seriously rather than dismissed out of hand.    
It's useful to be able to access RFCs and I-Ds as if they were files in 
directories (which they are) and to have a stable API for doing that.  
It's useful to be able to download, or print, many RFCs and I-Ds at once 
as an alternative to having to deal with a web browser's crippled user 
interface.   It's useful to have an alternative to https just in case 
https is blocked by whatever party for whatever reason.  And more 
generally, it's useful to facilitate tool building and to have long-term 
stable and widely-implemented interfaces that those tools can use.

> You say that "traffic volume is not an indicator of importance",
> but what metric can you offer in its stead?

I often find myself thinking that people are too enamored with numbers, 
that people trust numbers because they seem to be precise /even when 
those numbers aren't at all representative of what actually needs to be 
measured./

So my answer is: /maybe stop trying so hard to quantify things/. How do 
you measure the value of one additional IETF participant, one additional 
point-of-view that might shed valuable light on some protocol design 
choices that otherwise would not be shed?   I tend to think that input 
from people who would otherwise be marginalized or excluded can be 
extremely valuable precisely because they can help give the other 
participants a more representative picture of the global Internet 
environment.

Keith

p.s. One kind of answer to whether it's worth it to maintain a service 
might be: how many people are willing to volunteer to fund and perhaps 
maintain it?    If it's important enough to a few people that they're 
willing to fund and run it, maybe that's important enough to keep on.   
I realize that there are inevitably some issues and tensions associated 
with having volunteers run services that IETF participants use.   But 
IETF is fundamentally a volunteer organization, and I believe IETF is 
better at its core mission when the organization actively cooperates 
with and facilitates volunteers - not only at standards development but 
at providing tools and services that improve its ability to function.   
Lately there seems to be organizational hostility toward tool makers, 
though I'm not exactly sure where that's coming from.   IMO the 
organization should see tool making by participants and users as a 
fundamental part of IETF.