Re: Call for Community Feedback: Retiring IETF FTP Service

[tom petch <[e-mail]>]

Retiring the FTP service will impair my ability to contribute to the IETF.

For a long time, I struggled to download copies of IETF documents in the 
form that the author intended.  The topic arose on this list and I was 
pointed at the FTP service and this solved my problems; the amount of 
work I could do in the IETF increased.

FTP is so simple to use, a list of what I need to know with no 
extraneous information or fancy formats from which I can drag and drop 
or open and save; and which AFAICT accurately reproduces what is there 
on the FTP site; and I can do it all with a mouse, no keying needed, 
always a gain. Drag and drop preserves the original date which is 
valuable as I can use that to order work.

The availability is good; I cannot recall when last I could not access 
it.  With HTTP/HTML, there are days every week when my access is 
impaired and I have to try again later.  Again, this has been discussed 
on this list and the suggestion was that middleware, such as Cloudflare, 
was to blame.  Keep trying and it works but when I am reviewing an I-D 
with 47 somewhat elderly references in it, then the hassle becomes too much.

I have tried the URL given elsewhere in this thread.  I know that with 
.pdf, on (almost) every website, if I open and save, then Acrobat Reader 
will tell me that the file is damaged and cannot be repaired.  Rather, I 
must Right Mouse Click, 'save target as' and will get a message that the 
save has failed except that the file is now on my PC and Acrobat Reader 
is happy with it.

Using this technique and the given URL, each line has been slit in two, 
neatly indented, as if the server has decided what size window I will 
use in future and has reformatted the document accordingly.

Trying a separate technique of open and save, then all ASCII control 
characters have been removed to leave a Unix style stream of 86kbyte, 
equally useless.

Since HTTP/HTML is used by almost everyone to access almost everything, 
I imagine that there is an army of workers constantly seeking to 
'improve' the user experience.  Thus with another, non-IETF service, I 
have to logon but when I came to logoff, the other day, nothing 
happened.  I dislike leaving secure connections dangling so spent what 
became several hours trying to close the connection and found that when 
I clicked on signout, I could Right Mouse Click, get a drop down menu in 
which the 'Open' option closed the connection. Doubtless some web 
designer is feeling satisfied at having 'improved' the user experience 
but, for me, it took up the time I as going to spend on the QUIC I-D, 
then in Last Call.

Or again, I resized the window I use and when next I restarted the PC I 
was given the shrunken window with a message that (essential to me) 
fields were supressed because they would not fit.  I resized the window, 
carefully shut down, rebooted and got the shrunken window.  This 
persisted for days.  HTTP/HTML seems to have decided that because I had 
changed the size once, then anything else must be a mistake.  Another 
triumph for a web designer improving the user experience.

All this experience of HTTP/HTML is on shrink-wrapped Windows, 
factory-installed on a HP PC, accessing the Internet via a ISP-mandated 
ADSL modem.

Public services on a local authority PC are no better. I wanted to 
review a backlog of e-mail that had built up and every time I started to 
scroll down the list, wanting then to work forwards in time, I was taken 
back to the top.  I worked out that this was caused by a new e-mail 
arriving, a common occurence on several IETF lists.  I raised an 
incident and was told that the system was working as designed; when a 
new e-mail arrives, you MUST stop what you are doing and look at it. 
Another pat on the back for a web designer, another barrier to work.

Just as a hammer knows that everything is a nail, so a HTTP/HTML service 
knows that everything is a web page and 'improves' it accordingly, to 
the detriment of getting work done.  I cannot recall when I have ever 
had a comparable problem with the IETF FTP service.


Tom Petch



On 10/11/2020 02:23, Roman Danyliw wrote:
> Hi!
>
> The Internet Engineering Steering Group (IESG) is seeking community input on retiring the IETF FTP service (ftp://ftp.ietf.org, ftp://ops.ietf.org, ftp://ietf.org).  A review of this service has found that FTP appears to serve a very small community and HTTP has become the access mechanism of choice.  Given this shift in community usage, reducing the operational complexity of the overall IETF infrastructure seems to outweigh the very limited community served with FTP.
>
> In reviewing the additional impacts of such a service retirement, the dependencies on FTP have been assessed.  Additionally, it has been confirmed that all information currently reachable through FTP will continue to be available through other services (HTTP, RSYNC, IMAP).
>
> In consultation with the Tools team (Robert, Glen, Henrik, Russ, and Alexey), Communications team (Greg), affected SDO liaisons, IAB Chair, and LLC ED, a proposed retirement plan was developed and is available at:
>
> https://www.ietf.org/media/documents/Retiring_IETF_FTP_Service.pdf
>
> The IESG appreciates any input from the community on this proposal and will consider all input received by December 4, 2020 (to account for the upcoming IETF 109 and holidays).
>















> Regards,
> Roman
> (as the IESG Tools Liaison)
>
> .
>