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
