Re: Call for Community Feedback: Retiring IETF FTP Service

[Keith Moore <[e-mail]>]

On 11/30/20 12:07 PM, Theodore Y. Ts'o wrote:

> Changed once or twice over years or decades is not "constant flux".

The aggregate of changes to many different interfaces or services or 
tools, each changing once or twice over a few years, may look a lot like 
constant flux.

(what's the saying?  "No raindrop thinks it is to blame for the flood.")

> 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.

Something I've consistently found throughout my career is that people 
don't like to change from tools and interfaces that work well for them, 
to new tools that require different habits of working.   For example, I 
knew professors who clung to VMS MAIL for years even though it was never 
a great tool for managing Internet mail and even gmail's web interface 
(as much as I personally loathe it) was arguably much better.  I first 
got James Gosling's emacs to run on VMS in 1980, and I've been using the 
same key bindings ever since.   I've adapted more editors than I can 
count to use those key bindings.   I vastly prefer aircraft instrument 
panels with "steam gauges" to modern instruments that try to cram all 
information into one tiny display and are also more difficult to read 
(the old instruments were very carefully designed to maximize 
readability even in low light conditions, part of which meant they were 
relatively uncluttered).   etc.

IMO, that reluctance to change interfaces is entirely understandable.   
People literally invest years or decades into learning to work 
effectively with a certain set of tools, and trying to use new tools 
sometimes drastically affects those people's ability to work 
effectively.   (And sometimes the people get blamed for this.)

Basically I think there needs to be very good reasons to force people to 
abandon tools and interfaces that work well for them. And it seems that 
there's a very unfortunate and widely-held belief that "newer is better" 
that simply is not true in the general case (e.g. does not withstand 
rigorous measurement).

> 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.

There is indeed a problem here, but part of the problem is a constant 
demand for "new features".   It's not clear to me where that demand is 
coming from.   It seems to me that it's often better to design stable 
interfaces that won't need much change over time (because people don't 
like to change user interfaces) than to keep changing things.   Every 
time Windows changes versions and user interfaces, I hear my 
Windows-using colleagues gripe about how inconvenient the changes are.   
The other day I needed to format a USB stick exactly as Windows would do 
so, so I asked a friend if I could use her Windows machine to do that.  
It took the two of us about two hours to figure out how to do it, 
because none of the old user interfaces worked and the user interfaces 
that did exist had changed all of the terminology to the point that we 
couldn't tell for sure exactly what the PC was going to do.   And all I 
needed was to initialize a USB stick with a single partition and a 
single Windows file system on that partition.

If I look at old automobiles there are lots of different ways of 
operating them.   But fairly soon in the development of automobiles, a 
fairly common user interface seemed to emerge.   I don't know of any 
modern car that is steered with a lever.   Even though newer automobiles 
have some newer features the basic driving interface has mostly stayed 
compatible since the 1930s or so.   Maybe we're just still in the early 
phase of Internet user interfaces and things haven't settled out yet.

> I suspect the people who are so concerned about FTP overheads are
> doing so for philosophical reasons, more than anything else.

I don't think it's "philosophical" to want to have stable and effective 
interfaces.  I think it's human nature.

But the fundamental nature of engineering is taking components with 
known and predictable characteristics (because they are designed, 
tested, and/or selected to have those characteristics), and assembling 
reliable systems out of those predictable components.  Without 
predictable components, the whole discipline of engineering falls apart 
and becomes basically guesswork.   So a lot of us understand at a very 
deep level that when you start trying to use components that don't have 
predictable behavior, things break.

 From that point of view valuing predictable and stable services is not 
philosophy, it's reality.

And this kind of breakage seems to be happening with increasing 
frequency.   For example, it used to be that applications could count on 
the network making a best effort to deliver packets intact from source 
to destination.  Since the network was making a best-effort, there was 
no need to second-guess the network. Nowdays, applications cannot depend 
on that happening.   There are middleboxes in the network that try to 
second-guess the applications (whether to "improve" performance or to 
enforce restrictions or whatever)   And then the applications have to 
second-guess the network and try to work around the damage. That's a 
classic tussle which we're all familiar with.  No matter how it's 
resolved (if it even is), does not promote the development of reliable, 
predictable systems.


> 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.

Unless, perhaps, you're using one of those new very thin notebooks with 
a small amount of flash memory, or you're trying to work from your phone 
or tablet.   Just because my last N laptops have had at least 1TB drives 
in them, doesn't mean the next one will.   (Apple wants a LOT of money 
for an M1 laptop with a 1TB drive.)

But I think this is missing the point.   It's not just that people may 
need to change sources or protocols - though in the aggregate that is a 
problem - but also that the new protocols being proposed and interfaces 
presumed are less functional than the old ones in important ways, and 
their behavior is also less predictable.

If IETF said, for example, we're going to change from FTP to WebDAV as 
the means to provide remote file access to our documents, some of us 
would adapt.   We'd write new tools or modify existing tools if we had 
to.   The same would be true if IETF decided to use anonymous NFS, or 
anonymous CIFS, or sshfs, or FTPS, or whatever.   But what we were 
essentially told is that we'd have to completely do without such an 
interface and (at least in the initial message) that the decision had 
already been made (it was in the past tense), and that the powers that 
be had decided this based on extremely flawed analysis and basically a 
disregard for any use of the existing FTP server other than mirroring.

Note also that /any/ change at all will still probably deter some users 
to the point that they stopped participating in IETF or reduced their 
participation significantly.   That's part of the cost of changing 
interfaces, and needs to be considered as such.   And unlike some, I 
think that people who have habituated to familiar workflows and 
interfaces should not be disregarded out-of-hand as if they were irrelevant.

More broadly,  anyone who thinks that they can predict how other people 
/should/ behave under changing conditions is likely to be surprised, 
even moreso when they think they have a right to demand that people 
adapt as they expect.

> 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.

Well, every change is an unknown.   You don't know how much trouble it's 
going to be, but potentially any change might be a lot of trouble and 
very disruptive to other things you need to do.   For that reason alone 
there's a tendency to avoid such changes.

As for the long-term question:   IMO the thing to do is to very 
consciously pick interfaces (machine and user) that are standardized, 
functional, and can be stable over long periods of time, so that there's 
less frequently a need to consider such questions.   And sure, once in a 
great while there's an unavoidable need for change, and when that 
happens, those transitions need to be managed, generally with plenty of 
advance notice and overlap.

> 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.

Certainly I think a transition window is often better than a hard cutoff.

Keith

(I still suspect it might make more sense overall to fix FTP than to 
abandon it.   But part of that is based on a realization that FTP is 
still the tool of choice for some circumstances and usage scenarios that 
needs to be maintained; and also a belief that IETF should eat its own 
dog food whenever it makes sense.  But it might also be the case that 
say WebDAV is better for IETF's document access purposes even if FTP 
continues to be useful elsewhere, and dog food consumption is not the 
most important thing in this case.   I just don't think the dog food 
consumption should be disregarded out-of-hand - it does affect both our 
reputation and the quality of our work. )