not merely how they may be accessed (which is important), but also who can access themHi 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?
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.
