Re: Call for Community Feedback: Retiring IETF FTP Service

["Theodore Y. Ts'o" <[e-mail]>]

On Mon, Nov 30, 2020 at 07:58:01AM -0800, [e-mail] wrote:
> > Am 30.11.2020 um 16:18 schrieb [e-mail]:
> > > ...
> > > The failure mode is that browser behavior is in a constant state of flux. Some
> > > time ago you got HTML-ized text, yesterday you got text without the form feeds,
> > > today you get the text file verbatim. Who knows what you'll get tomorrow?
> > > ...
> 
> > Is it really in "constant flux"? Pointers appreciated.
> 
> > > ...
> 
> You just heard from two people on this list - Keith and Tom - that things have
> changed over time. If you don't believe them, say so in so many words.

Changed once or twice over years or decades is not "constant flux".
Stepping back a bit, it seems to me that that one of the hidden
assumptions which has turned this into a long, drawn-out discussion,
is whether or not change should be tolerated, and over what time
scales.  It may very well be that for some people a change once a
decade is "contant flux".  In other cases, people may be willing to
accept some change every 2-4 years, so long as reasonable methods of
getting their work done are available, even if it does mean that they
have to adjust their workflow every few years.

Ultimately, if we have to support all workflows forever, then the job
of the people maintaining the tools and servies is going to either (a)
stagnate, by not adding new features, since that will increase their
maintenance load, or (b) grow without bound, as new features to ease
IETF participants' work are added, with no means of transitioning off
of older technologies.

I suspect the people who are so concerned about FTP overheads are
doing so for philosophical reasons, more than anything else.  For
while, when my preferred access method was over AFS, I was mirroring
FTP and I-D's to a local archive on an AFS cell at MIT.  It was *not*
a big deal, and if I needed to change the URL used to keep my local
mirror in sync (as I recall I needed to do once or twice over the 10
or so years), it really wasn't a big deal.  And disk space has gotten
cheaper over the years, so it *really* isn't that hard for people to
keep their own local mirrors if they really wanted to.

So I wonder if this whole, long, debate, is really more about people
who don't want to deal with any kind of change, because while *this*
change might be relatively easy to work around, the *next* one might
require a bit more work.  But the long-term question about how access
portals and other technologies should get retired is still going to
remain.

Perhaps if there was a deprecation window of, say, a year?  Maybe two
years?  This gives people *plenty* of time to investigate alternate
workflows and methods, and still allows for the secretariat and tool
teams to be able to continue to innovate without having to maintain
older mechanisms forever.

Cheers,

						- Ted