Re: Call for Community Feedback: Retiring IETF FTP Service

Lou Berger <lberger@labn.net> Wed, 18 November 2020 14:21 UTC

Return-Path: <lberger@labn.net>
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 EA9A33A0989 for <ietf@ietfa.amsl.com>; Wed, 18 Nov 2020 06:21:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=labn.onmicrosoft.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 BcESlGawOpMh for <ietf@ietfa.amsl.com>; Wed, 18 Nov 2020 06:21:05 -0800 (PST)
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2123.outbound.protection.outlook.com [40.107.94.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F36003A098E for <ietf@ietf.org>; Wed, 18 Nov 2020 06:21:04 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GX18L6AAeDR7/AenPQgORI74Qo+lsDjMO9W2xZNqCN4qABeFiDh9DQegSDbKYywSFuwNGNrD6luXvuOEYaIm01ljY385AMXl58DzvDIGt8W0tJn0jEdSE3p2uJBODZCr9Q25+9eTHBw/SZ1IJVpn1VagEj4bLlUXIuJGKvBZrFKdCNaRc6c3TVQtikiQNVLNXBAVHBi1kEXurLajTumdK6KhncQGZRyMvNjvExGIJsvAMrD2vOuMuwACNmwj5rKTl5FT9z057Mo6Pq1SPwA3W3j850KMkACoe4Au5mAHhKyL4MjECwC8rsMcy41cK54MR4YlHjiGn4Ydea1nka55ag==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q77IRi+gk3hMNUBAD86OhJCYWVckryCc1GmAwqzSEjo=; b=Dax9MU62A8NO71xEwvH6FAwiyN7k9NryfspgzJphaSQlgWpkPDjVeZcRFhcgSOOiZaPdVrHTaH4Oe3fEnlR+gNuR0GGyh3ilyo+LTHfcQ88qmGJqiw6w6KkOgJO6aupRxb0/lwSdMJ8RIQ7QMaVgSGe8drDRlFuydKA9QZDrHBYQLP4/soCHvA2+oZF233lYhAbT1YGwiP7f6lO6JMqdq/GagbsbThzoQVZWQAgt2FZL4r6C1SW9D2mQ6iI/r/jxubOtVrQd2Yy/RtCURoxmNVAEDVEdLCGugYDQFUcFxrCvsApiXcw1apZrK/2TBTK11Xlgj5BkssUMgCh7xuhiiw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=labn.net; dmarc=pass action=none header.from=labn.net; dkim=pass header.d=labn.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=labn.onmicrosoft.com; s=selector2-labn-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q77IRi+gk3hMNUBAD86OhJCYWVckryCc1GmAwqzSEjo=; b=EpW0pf6S4Uty5i8WQU/UnZBjmG/nqNIcdN3aQ+Rf3Gcw2mpD0MlGmZLZRSYm5owscSPIRxU44p7FSEvbk9p1IaFSoqb0AlEEwFeUAzohV5q/ffQaOalnCQyznK0xLH5aUv5ToR1q/vrUFuVTx0xfeSWluZ6uIKLlXLD6xaLVK3Y=
Received: from BL0PR14MB3779.namprd14.prod.outlook.com (2603:10b6:208:1c7::24) by MN2PR14MB3981.namprd14.prod.outlook.com (2603:10b6:208:19a::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.25; Wed, 18 Nov 2020 14:21:03 +0000
Received: from BL0PR14MB3779.namprd14.prod.outlook.com ([fe80::cc1f:b1ba:b525:74da]) by BL0PR14MB3779.namprd14.prod.outlook.com ([fe80::cc1f:b1ba:b525:74da%9]) with mapi id 15.20.3589.020; Wed, 18 Nov 2020 14:21:03 +0000
From: Lou Berger <lberger@labn.net>
To: Benjamin Kaduk <kaduk@mit.edu>, Keith Moore <moore@network-heretics.com>
CC: "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: Call for Community Feedback: Retiring IETF FTP Service
Thread-Topic: Call for Community Feedback: Retiring IETF FTP Service
Thread-Index: Ada3CD1BnAYFDyoMT8WUdvX4VBiWMQE/QScAAABKqIAADHZ8AAAA1a8AAAqaGQAAD5dtAAADcuWAAAdFdIAABzpngAABOf4AAACbIWEAKZ4GgAACSQWAAABpzIAABFFS5A==
Date: Wed, 18 Nov 2020 14:21:03 +0000
Message-ID: <BL0PR14MB3779D2DF5858884E97727CF2C3E10@BL0PR14MB3779.namprd14.prod.outlook.com>
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>
In-Reply-To: <20201118121725.GN39170@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=labn.net;
x-originating-ip: [172.58.27.1]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 233365a2-7edc-468f-ec58-08d88bcd2e6a
x-ms-traffictypediagnostic: MN2PR14MB3981:
x-microsoft-antispam-prvs: <MN2PR14MB3981B8976BC758F6A92338A5C3E10@MN2PR14MB3981.namprd14.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: /o9cEkDGaqmTPX5e1uQFzNOKZzVaffC0P/FDhOduaOxTW5XgJcAS9qxs53nYIww3qj9vB1PJfyIfSbUPrauiZBSbxAYlTJdUlNL02VCeU36eHXOWB1vpcdhIr4Ll4/EI4BVWQRpdHjnPIJmxPmC1xnXPGT1nYmxHW3oyy4DGTGknMgmFbTqRthxP8QnsYZ7zlZectlY+nZHAEUeZHznGIeK9N8D3oq1qOsk0ww9nBVoZSaEFtIKPN0SYb9o9ogGuiPP8droucq6vRdcG2nNJAHR+mC86CNoM6WqMXTblVtbLhEtVTj8WuhQcYOmMuLZRHUZHy/YI0S6IdouTsMl4ng==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR14MB3779.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(396003)(346002)(39830400003)(366004)(136003)(26005)(71200400001)(9686003)(86362001)(76116006)(6506007)(478600001)(316002)(4326008)(52536014)(33656002)(8936002)(83380400001)(110136005)(5660300002)(66476007)(55016002)(66556008)(2906002)(66446008)(7696005)(66946007)(186003)(64756008)(8676002)(91956017); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 5vEBxtpU+U52lpc6F7pErWUWCZAO8copyWqY2Hyt/qOrlRvPz2/LN7jfHSVvc1fV1FWSwAOWAltEZohjkamsJxB58xPBFIJw3EJVoTggH/3KF9/CpYMiRMpsVPqPzbMdTMpvNH+XdCwPwafMN6Uc19ppTPth4YXxy0MamQaI8V6fd/rUHNyu9FefwBPHmyYABP7YhKIVI/MjnTkbDCN7OaA3tGjKwP+8dBWJ2WyWlDRiQNCbUlUDYrodWOYBXl9lxdwNvd0Cs9VKlqfCsZFnjHzd5LKsx1XjJ+olAamaDydkn/0qUcN2sFY6t0jASPvPy29J0+DOQ7jJ2nhtOx7SXmDAmOxI6l0mTWzN5YPryCHqGO19Ah/9vLSmgHlQsGfKs0v8T65XllMT3URjb/ovqUJ/0Fvy2CAQuA35zd3kcx3d70Ahi5mMvymnfXPpOdv2rQnnY0+LYUHLSkvS+k2eqwxFcHI1vfGhbWcBeV+c1Nv1bV/97LCTA+oBDuKXTNudlnLu4PzAkRdI2UbOPg+PsnJ2k26Bzerp9mZSv5VfEapbD9GGO1drDZuoxlntVzGut5bVKPfOTGV7UGTZgbZHUlQ/tSFnCZnoHlTSeHps8ygkmE67wnpo40HvDbyhaal34qjdGtrv2tGtLFMLikcA1Q==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BL0PR14MB3779D2DF5858884E97727CF2C3E10BL0PR14MB3779namp_"
MIME-Version: 1.0
X-OriginatorOrg: labn.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR14MB3779.namprd14.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 233365a2-7edc-468f-ec58-08d88bcd2e6a
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2020 14:21:03.4448 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: eb60ac54-2184-4344-9b60-40c8b2b72561
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Mq9zlx8KQIe55TQA6TR19s9TXaaPyHFv427bsGuUYV98Fvb4uBoOY7iQnwnfeAwTf4Dy9wh+Ec0JJKM6SuP+zw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR14MB3981
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/RiLbxnebKQxpQaJf_Xv11fdEWfc>
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:21:09 -0000

Ben

> but I don't think I've seen it formulated in a very useful fashion (yet).

How about: the FTP Service will be discontinued when FTP (RFC959) is moved to Historic status.

Lou

----------
On November 18, 2020 4:17:51 AM Benjamin Kaduk <kaduk@mit.edu> 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" even though it's a
somewhat convoluted logical exercise to get there.  But what threshold do
you use, then?  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?

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.  You say that "traffic volume is not an indicator of importance",
but what metric can you offer in its stead?  As I see it, Roman and the
tools team have been attempting to run the numbers with the numbers
presently available, and those numbers are at least facially useful
numbers.  (If there were literally zero logged users of the FTP service
over a year, would you be complaining?  What about one?  Where is the
boundary?)  If you can't offer alternative numbers or ways to run the
numbers, I don't think you will be very effective at achieving a different
outcome.  The point we've been getting from Ned and others about
unencrypted access could potentially become one, but I don't think I've
seen it formulated in a very useful fashion (yet).

Thanks,

Ben