Re: Call for Community Feedback: Retiring IETF FTP Service

[Benjamin Kaduk <[e-mail]>]

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