Subject: Regarding "Call for Community Feedback: Retiring IETF FTP Service"

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 24 Nov 2020 17:12:04 +0000

Hi Roman, Hi all,

I wasn't even aware that we are still offering an FTP service.
It is time to retire the FTP service.

Ciao
Hannes

Hi!

The Internet Engineering Steering Group (IESG) is seeking community input on retiring the IETF FTP service (ftp://ftp.ietf.org<http://ftp://ftp.ietf.org>, ftp://ops.ietf.org<http://ftp://ops.ietf.org>, ftp://ietf.org<http://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)

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 25 Nov 2020 10:19:45 -0600

Hi Hannes,

On Tue, Nov 24, 2020 at 11:12 AM Hannes Tschofenig <
[email-masked]> wrote:

> Hi Roman, Hi all,
>
>
>
> I wasn’t even aware that we are still offering an FTP service.
>
ftp has been used extensively in some places, like 3GPP.
The other day I pressed a link, it turned out to be ftp link
and surprise: it worked as major Web browsers support it.

Behcet

>
>
> Ciao
>
> Hannes
>
>
>
> 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.
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 25 Nov 2020 16:26:09 +0000

Hi Behcet,

the question is not whether FTP works or not. For me the question is whether we need to provide multiple protocols for making our documents available to others.
I am sure the 3GPP can fetch our RFCs also via HTTPS in 2020.

Ciao
Hannes

From: Behcet Sarikaya <[email-masked]>
Sent: Wednesday, November 25, 2020 5:20 PM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: Regarding "Call for Community Feedback: Retiring IETF FTP Service"

Hi Hannes,

On Tue, Nov 24, 2020 at 11:12 AM Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi Roman, Hi all,

Behcet

Ciao
Hannes

Hi!

Regards,

Roman

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Nov 2020 13:13:34 -0500

On 11/25/20 11:26 AM, Hannes Tschofenig wrote:

> For me the question is whether we need to provide multiple protocols 
> for making our documents available to others. 
I find these handwaving arguments unhelpful in the extreme as they fail 
to consider the actual issues with using HTTPS instead of FTP.

Vanilla HTTP provides no reliable way to list the documents in a 
folder.  (like FTP XLST or WebDAV PROPFIND)

Vanilla HTTP also provides no reliable way to distinguish a directory 
from an ordinary file from a symlink, and there are symlinks in the RFC 
repository.

Even if we were to support WebDAV, tor me the question is whether we 
should break a stable protocol that has worked for decades and is very 
widely supported in clients, in favor of something new.

Keith

(I will acknowledge the NAT issue with FTP, though I think that PASV 
mode in FTP should still work.  What I don't know is whether there are 
ALGs or other interception proxies out there that break all FTP even 
when it uses passive mode.   It may be that the best feature of TLS for 
this kind of retrieval of non-sensitive information, is that it thwarts 
most interception proxies.)

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 25 Nov 2020 19:27:47 +0000

>The other day I pressed a link, it turned out to be ftp link and surprise: it worked as major Web browsers support it.

[JL] That will end fairly soon. Chromium will disable FTP in 1Q2021 and fully remove the supporting code a few months after that.
https://docs.google.com/document/d/1JUra5HnsbR_xmtQctkb2iVxRPuhPWhMB5M_zpbuGxTY/edit

---

From: John C Klensin <[email-masked]>
Date: Wed, 25 Nov 2020 14:59:30 -0500

--On Wednesday, November 25, 2020 19:27 +0000 "Livingood, Jason"
<Jason_Livingood=[email-masked]> wrote:

> [JL] That will end fairly soon. Chromium will disable FTP in
> 1Q2021 and fully remove the supporting code a few months after
> that.

But, fwiw, part of the justification given in that article (from
the first paragraph) is:

	"In addition more capable FTP clients are available on
	all affected platforms."

It goes on to say that that their implementation is broken and,
essentially, that they don't feel like fixing it.  "Broken and
we don't want to invest resources in fixing it" feels quite
different to me than "we have a service that works (almost)
perfectly well and we'd like to discontinue it".

And, fwiw, their explanation sounds very nearly like an
invitation for someone to add support back in via a third-party
plug-in.

So, yes, their dropping support is interesting but I don't think
has much to do with the IETF issue.

   john

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 25 Nov 2020 20:25:53 +0000

Keith,

I am curious why you need these features.

Ciao
Hannes

-----Original Message-----
From: ietf <[email-masked]> On Behalf Of Keith Moore
Sent: Wednesday, November 25, 2020 7:14 PM
To: [email-masked]
Subject: Re: Regarding "Call for Community Feedback: Retiring IETF FTP Service"

> I am sure the 3GPP can fetch our RFCs also via HTTPS in 2020.
I find these handwaving arguments unhelpful in the extreme as they fail to consider the actual issues with using HTTPS instead of FTP.

Vanilla HTTP provides no reliable way to list the documents in a folder.  (like FTP XLST or WebDAV PROPFIND)

Vanilla HTTP also provides no reliable way to distinguish a directory from an ordinary file from a symlink, and there are symlinks in the RFC repository.

Even if we were to support WebDAV, tor me the question is whether we should break a stable protocol that has worked for decades and is very widely supported in clients, in favor of something new.

Keith

(I will acknowledge the NAT issue with FTP, though I think that PASV mode in FTP should still work.  What I don't know is whether there are ALGs or other interception proxies out there that break all FTP even when it uses passive mode.   It may be that the best feature of TLS for this kind of retrieval of non-sensitive information, is that it thwarts most interception proxies.)

---

From: Michael Richardson <[email-masked]>
Date: Wed, 25 Nov 2020 17:50:16 -0500

Keith Moore <[email-masked]> wrote:
    > mode in

IPv6 makes this irrelevant.

That NAT makes FTP hard to use isn't an argument to turn off FTP, it's an argument
for joining this century, and using IPv6.

[me: I'm just annoyed that rsync isn't an RFC, because that's the protocol to
use. And we have it now, but it's not an STD RFC]
{I deleted most of the thread.  I'm fine with turning off FTP at some point.
Maybe today is too soon.  Maybe Dec.31, 2021...}

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Nov 2020 18:49:52 -0500

> I am curious why you need these features.

You mean, you really don't understand why these features are useful and 
can save significant time for many IETF participants?

- An ftp server can be treated as a remote file system by many 
platforms.  That means, for example, if you're editing an I-D and you 
want to refer to some other document, you can open that document in your 
favorite text editor without the editor needing specific support for 
FTP.  If your editor has windows (such editors have existed since at 
least the late 1970s), you can see the I-D you are editing and the 
document you're referring to side-by-side with no wasted screen space.   
This is a LOT more effective than trying to deal with your editor in one 
window and a web browser in another, partly because web browsers and web 
pages both tend to make very poor utilization of screen space, but also 
because multiple windows within your editor have the same UI, whereas 
the web browser and your editor probably have different UIs.   The same 
feature makes it possible to _easily_ print some set of documents ("lpr 
draft-*workinggroupname*.pdf), or copy some set of documents, or search 
through ("grep") some set of documents ("which internet-draft contains 
the text...") or ("which internet-drafts reference RFCXXXX?")

[I personally find printing is the best way to review documents because 
then I can easily annotate them with ancient writing utensils, which is 
far better than trying to do so using any keyboard-based tool I've ever 
seen.   And I refuse to feel bad about that :) ]

- Some FTP clients have filename completion.   So if you're looking for 
a particular file, you don't have to search through all of the text on a 
web page.   Sure the web browser has a Search feature, but it doesn't 
distinguish file names from other text, and there's no assurance that 
the files you're looking for are all grouped together.   Filename 
completion can be implemented fairly efficiently in FTP, because if you 
type "a" the client can do "LIST a*", then when you type "b" after "a" 
the client can do "LIST ab*", etc.

- Most FTP clients support multiple file transfer via wildcards (e.g. 
draft-*-workinggroupname-*) .   Many support an effective "batch" 
transfer UI: Select the files you want and press "start" or some such, 
and all of the files you selected are quickly transferred for you.   
This has been an effective interface for file transfer ever since at 
least the Xerox Alto, and has been duplicated by many clients since then 
because it works well.  Web browsers generally require you to start each 
transfer separately, maybe specify a destination for each separately, 
and often, to manage them separately (they may queue up multiple 
transfers or do multiple concurrent transfers but you still have to go 
back and check to see that they were successfully downloaded because 
failures are common for some reason.  The browser is really optimized 
around letting you read things rather than letting you transfer files, 
especially multiple files, robustly.).

- Similarly, many editors have built-in or plug-in support for FTP.   A 
lot of Windows users like Notepad++ which has a plugin for this.  GNU 
Emacs for Unix/Linux has an "ftp" command (M-x ftp) that basically lets 
you talk to the local ftp client on your machine, but it also ships with 
"remote file" support so you can directly open (for example) 
/ftp:[email-masked]:ftp/internet-drafts/draft-moore-exclusionary-language-00.txt 
.   Filename completion is supported here so at any point  you can type 
? to list potential completions or TAB to complete the filename as far 
as it can be given the alternatives available. MUCH faster than 
searching in a web browser.

- Using FTP, I can search for an internet-draft or RFC from my phone; I 
can browse the documents by name or date order or size; I can edit the 
document on my phone or import text into notes or email; I can send the 
document to a printer from my phone.    Yes, the phone has a built-in 
web browser but many web sites are far from ideal for a handheld 
device.   By contrast the FTP client is written specifically to be used 
on such a device, so it doesn't waste screen space AND it's more 
functional for some purposes than the web browser.

- And there's a lot of value in NOT expecting participants to learn a 
new interface when an old one works well.   "The Web" is not better than 
FTP for all purposes; it's a different tool with different strengths and 
limitations.   Expecting people to use new, crippled interfaces is not 
only a kind of age discrimination, it also deprives newer people of the 
ability to use those interfaces which could improve their productivity also.

A huge benefit of FTP is that the client can be small and relatively 
simple.   That makes it feasible to embed FTP clients in very many 
applications, which provide improved user interfaces as compared to 
having to use a separate client to do file access than the one used to 
manipulate the files.   That's not to say that you can't embed a web 
browser in an application - often you can - but then you don't easily 
get the benefit of an application that's well-tailored for your 
particular purpose and you also get a lot of baggage that you might 
rather do without.

Keith

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 26 Nov 2020 07:52:47 +0000

Hi Keith,

here is my workflow:

1. I have an idea that may be worthwhile to share with the community. At this point in time I have read various other documents and RFCs already. The outline is either in my head or written on paper.

2. I write the draft in my favorite text editor. Currently, this is Notepad++. I change editors all the time and do not feel emotionally attached to any of them.

3. If I need to verify text from a referenced RFC/draft or want to cite a specific paragraph then I open the draft/RFC in my browser.
There is little difference between swapping between two programs vs. changing between two tabs in an editor. Notepad++ has a multi-tab concept and so I could open an RFC in one tab and then edit my draft in another tab. I don't do that because I got so used to the app swapping. Does it require FTP support to do that? No, it doesn't.

Screen space is an issue with implementation work. This is where multiple screens are super useful. For example, I often have a draft open on one screen and use the IDE (uVision 5, Visual Studio, etc.) on the other. Having three monitors would even be better because then you can run the test scripts on the third monitor.

I also print drafts for review. Does it matter how quickly the print-command is invoked or even how fast the documents are printed? No, it doesn't because the time needed for the review is the dominating factor here. It typically takes me many hours to review documents. (FWIW the task of reviewing is still very much underappreciated even though it is very time consuming.)

Your description below (and thanks for the details) shows one thing: everyone has come up with different ways of working. Everyone likes their style most. Nobody wants to see a change (which probably extends beyond draft editing).

Regarding change let me give you an example from another organization I am involved in. We wanted to change the document format of our specifications from Word to Markdown and faced huge resistance. For the test specification, we have actually to switched from Word to Markdown, then from Markdown to HTML (because the test specification uses lots of tables, which is a mess in Markdown), and then we switched back to Word. Some people in the group got so used to Word that the transition to another format made them very unhappy. (Funny detail on the side: those who resisted most didn't edit a lot of documents.)

I believe the real question is how do we manage change in this organization? In this specific case, how long are we going to support workflows of a smaller and smaller number of people? (I assume that your workstyle is less common than mine. Maybe a bold assumption.)

Something to think about is whether you are trying to optimize your workflow for something that, in practice, doesn't really matter much. Think about the 80-20 rule. I believe you will loose very little by switching from FTP to HTTP in terms of overall draft writing productivity.

Ciao
Hannes

-----Original Message-----
From: ietf <[email-masked]> On Behalf Of Keith Moore
Sent: Thursday, November 26, 2020 12:50 AM
To: [email-masked]
Subject: Re: Regarding "Call for Community Feedback: Retiring IETF FTP Service"

> I am curious why you need these features.

You mean, you really don't understand why these features are useful and can save significant time for many IETF participants?

- An ftp server can be treated as a remote file system by many platforms.  That means, for example, if you're editing an I-D and you want to refer to some other document, you can open that document in your favorite text editor without the editor needing specific support for FTP.  If your editor has windows (such editors have existed since at least the late 1970s), you can see the I-D you are editing and the document you're referring to side-by-side with no wasted screen space. This is a LOT more effective than trying to deal with your editor in one window and a web browser in another, partly because web browsers and web pages both tend to make very poor utilization of screen space, but also because multiple windows within your editor have the same UI, whereas the web browser and your editor probably have different UIs.   The same feature makes it possible to _easily_ print some set of documents ("lpr draft-*workinggroupname*.pdf), or copy some set of documents, or search through ("grep") some set of documents ("which internet-draft contains the text...") or ("which internet-drafts reference RFCXXXX?")

[I personally find printing is the best way to review documents because then I can easily annotate them with ancient writing utensils, which is far better than trying to do so using any keyboard-based tool I've ever seen.   And I refuse to feel bad about that :) ]

- Some FTP clients have filename completion.   So if you're looking for a particular file, you don't have to search through all of the text on a web page.   Sure the web browser has a Search feature, but it doesn't distinguish file names from other text, and there's no assurance that the files you're looking for are all grouped together.   Filename completion can be implemented fairly efficiently in FTP, because if you type "a" the client can do "LIST a*", then when you type "b" after "a"
the client can do "LIST ab*", etc.

- Most FTP clients support multiple file transfer via wildcards (e.g.
draft-*-workinggroupname-*) .   Many support an effective "batch"
transfer UI: Select the files you want and press "start" or some such, and all of the files you selected are quickly transferred for you. This has been an effective interface for file transfer ever since at least the Xerox Alto, and has been duplicated by many clients since then because it works well.  Web browsers generally require you to start each transfer separately, maybe specify a destination for each separately, and often, to manage them separately (they may queue up multiple transfers or do multiple concurrent transfers but you still have to go back and check to see that they were successfully downloaded because failures are common for some reason.  The browser is really optimized around letting you read things rather than letting you transfer files, especially multiple files, robustly.).

- Similarly, many editors have built-in or plug-in support for FTP.   A lot of Windows users like Notepad++ which has a plugin for this.  GNU Emacs for Unix/Linux has an "ftp" command (M-x ftp) that basically lets you talk to the local ftp client on your machine, but it also ships with "remote file" support so you can directly open (for example) /ftp:[email-masked]:ftp/internet-drafts/draft-moore-exclusionary-language-00.txt
.   Filename completion is supported here so at any point  you can type ? to list potential completions or TAB to complete the filename as far as it can be given the alternatives available. MUCH faster than searching in a web browser.

- Using FTP, I can search for an internet-draft or RFC from my phone; I can browse the documents by name or date order or size; I can edit the document on my phone or import text into notes or email; I can send the document to a printer from my phone.    Yes, the phone has a built-in web browser but many web sites are far from ideal for a handheld device.   By contrast the FTP client is written specifically to be used on such a device, so it doesn't waste screen space AND it's more functional for some purposes than the web browser.

- And there's a lot of value in NOT expecting participants to learn a new interface when an old one works well.   "The Web" is not better than FTP for all purposes; it's a different tool with different strengths and limitations.   Expecting people to use new, crippled interfaces is not only a kind of age discrimination, it also deprives newer people of the ability to use those interfaces which could improve their productivity also.

A huge benefit of FTP is that the client can be small and relatively simple.   That makes it feasible to embed FTP clients in very many applications, which provide improved user interfaces as compared to having to use a separate client to do file access than the one used to manipulate the files.   That's not to say that you can't embed a web browser in an application - often you can - but then you don't easily get the benefit of an application that's well-tailored for your particular purpose and you also get a lot of baggage that you might rather do without.

Keith

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 26 Nov 2020 12:12:38 +0000

Hi Keith!

> Sent: Wednesday, November 25, 2020 6:50 PM
> To: [email-masked]
> You mean, you really don't understand why these features are useful and can
> save significant time for many IETF participants?

Thanks for the details.  The comments I'm making below are in the spirit of clarifying that the workflows (as I understand them) could likely be enabled through non-FTP services albeit with different trade-offs.  I am not attempting to convince you to change your personal workflow.

> - An ftp server can be treated as a remote file system by many platforms.  That
> means, for example, if you're editing an I-D and you want to refer to some
> other document, you can open that document in your favorite text editor
> without the editor needing specific support for FTP.  If your editor has windows
> (such editors have existed since at least the late 1970s), you can see the I-D you
> are editing and the document you're referring to side-by-side with no wasted
> screen space. This is a LOT more effective than trying to deal with your editor in
> one window and a web browser in another, partly because web browsers and
> web pages both tend to make very poor utilization of screen space, but also
> because multiple windows within your editor have the same UI, whereas the
> web browser and your editor probably have different UIs.   

Multi-editor windows doesn't seem tied to mounting a remote filesystem via FTP at all.  Likewise, I'm not sure why a web-browser needs to be used at all.

A remote filesystems seems to be about the convenience of accessing the files.

> The same feature
> makes it possible to _easily_ print some set of documents ("lpr draft-
> *workinggroupname*.pdf), or copy some set of documents, or search through
> ("grep") some set of documents ("which internet-draft contains the text...") or
> ("which internet-drafts reference RFCXXXX?")

Up front -- there is no way to currently mount a remote filesystem from IETF services with anytime but FTP.

I will point out that the equivalent if this workflow (command line manipulation of directories of files) can be done by rsyncing the repo (whereby making an explicit cache) and all CLI sequences should work.  Several GB of explicit storage will be required though (so perhaps this is a constraint).  It also might be that case (all depends on the file driver's caching strategy) that if multiple commands which inspect a large number of drafts are used, it may be faster and use less bandwidth (e.g., grep multiple times across all I-Ds).

As said previously, every top-level directory currently in FTP has an rsync point.  See https://mailarchive.ietf.org/arch/msg/ietf/b8BfvrcpLmvvjkhJ1MW8DUEzmQ8/.  

> [I personally find printing is the best way to review documents because then I
> can easily annotate them with ancient writing utensils, which is far better than
> trying to do so using any keyboard-based tool I've ever seen.   And I refuse to
> feel bad about that :) ]
> 
> - Some FTP clients have filename completion.   So if you're looking for a
> particular file, you don't have to search through all of the text on a web
> page.   Sure the web browser has a Search feature, but it doesn't distinguish file
> names from other text, and there's no assurance that the files you're looking
> for are all grouped together.   Filename completion can be implemented fairly
> efficiently in FTP, because if you type "a" the client can do "LIST a*", then when
> you type "b" after "a"
> transfer UI: Select the files you want and press "start" or some such, and all of
> the files you selected are quickly transferred for you. This has been an effective
> interface for file transfer ever since at least the Xerox Alto, and has been
> duplicated by many clients since then because it works well.  Web browsers
> generally require you to start each transfer separately, maybe specify a
> destination for each separately, and often, to manage them separately (they
> may queue up multiple transfers or do multiple concurrent transfers but you
> still have to go back and check to see that they were successfully downloaded
> because failures are common for some reason.  The browser is really optimized
> around letting you read things rather than letting you transfer files, especially
> multiple files, robustly.).

As above -- use of rsync + OS shell may provide similar functionality (with different assumptions, local storage and periodic refresh).
 
> - Similarly, many editors have built-in or plug-in support for FTP.   A lot of
> Windows users like Notepad++ which has a plugin for this.  GNU Emacs for
> Unix/Linux has an "ftp" command (M-x ftp) that basically lets you talk to the
> local ftp client on your machine, but it also ships with "remote file" support so
> you can directly open (for example) /ftp:[email-masked]:ftp/internet-
> drafts/draft-moore-exclusionary-language-00.txt

Plugins into favorite editors doesn't strike me as a unique feature.

I'm not a user of GNU Emacs, but I suspect you could load arbitrary URLs into your buffer by:

C-u C-M-! curl -s https://www.ietf.org/archive/id/draft-moore-exclusionary-language-00.txt'

Courtesy of https://lists.gnu.org/archive/html/help-gnu-emacs/2007-03/msg00335.html

I also found this Notepad++ plugin that would nicely interact with an rsync cache (https://github.com/funap/npp-explorer-plugin) 

> .   Filename completion is supported here so at any point  you can type ? to list
> potential completions or TAB to complete the filename as far as it can be given
> the alternatives available. MUCH faster than searching in a web browser.
> 
> - Using FTP, I can search for an internet-draft or RFC from my phone; I can
> browse the documents by name or date order or size; I can edit the document
> on my phone or import text into notes or email; I can send the document to a
> printer from my phone.    Yes, the phone has a built-in web browser but many
> web sites are far from ideal for a handheld device.   By contrast the FTP client is
> written specifically to be used on such a device, so it doesn't waste screen
> space AND it's more functional for some purposes than the web browser.

I'm not so sure about FTP being unique here.  My personal experience is that the mobile app and OS feature set is very robust.  I have sent RFCs to print from my phone/tablet +and imported text into an email too without using FTP.

Regards,
Roman

---

From: Keith Moore <[email-masked]>
Date: Thu, 26 Nov 2020 07:39:54 -0500

> I believe the real question is how do we manage change in this organization? In this specific case, how long are we going to support workflows of a smaller and smaller number of people? (I assume t…

Yes it comes down to that.  But optimizing for the "common" workflow 
actually pessimizes against people who have more effective workflows, 
makes the organization less able to attract creative and experienced 
people to work for it, and makes the organization less adaptable 
overall.  I assert that this is exactly the wrong direction for IETF.   
IETF should not treat becoming more restrictive and less flexible at 
supporting people's workflows as a virtue.  It's bad enough when some 
company hampers its employees' productivity in that way, even worse when 
a volunteer organization does that.

IETF, of all organizations, should be trying to encourage its 
participants to try out new and varying ideas, not to coerce everyone 
into doing things the same way as everyone else.  IETF is not a factory 
that turns out huge numbers of identical goods.

Now granted there are always costs associated with maintaining multiple 
services, and at some point the usage of some service might not justify 
the cost.  But zero data has been presented to support this argument.   
Roman's data doesn't say anything about it because it's almost entirely 
about traffic volume, and I've seen zero assessment of the actual cost - 
just handwaving.

Really this is a textbook case for why "IT" shouldn't be allowed to make 
such decisions anywhere, but especially not in an organization that 
values creativity.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 26 Nov 2020 08:31:38 -0500

> A remote filesystems seems to be about the convenience of accessing the files.
Perhaps I have imperfectly separated out all of the points.   Remote 
file system access is useful for many reasons.   Being able to treat 
remote documents very similarly to local files, without each application 
needing specific support for that access, is useful, and one of those 
benefits (among many others) is that the same application can seamlessly 
access documents from different locations at the same time.  The editor 
with windows was just one example from my own experience, citing 
something that I do fairly regularly.

> I will point out that the equivalent if this workflow (command line manipulation of directories of files) can be done by rsyncing the repo (whereby making an explicit cache) and all CLI sequences s…
Ah, the rsync argument again.   Yes, you can do the same with rsync IF 
you have the storage to spare (my phone does not, many laptops with SSDs 
do not), IF you know about rsync and IETF's rsync service, IF you want 
to take the time to set it up, IF you have the bandwidth to spare to 
sync things.   In short, you can do this IF you make lots of prior 
arrangements and maybe IF you don't pay for bandwidth.

But rsync comes at a cost too.    Every software package that runs on a 
computer is something else that has to be installed and configured, 
something that can break, something that may need to be updated (and 
which can break in the process), something that needs to be monitored if 
it's to be available when needed, etc. In other words there is overhead 
associated with every software package.   For business and personal 
reasons, I run several different computers, and for each of them there 
is a list of things that "need" to be done - packages installed, 
updated, perhaps compiled, configured, tested, sometimes bugs fixed.  So 
every one of those items has an uncertain amount of time burden 
associated with it, time that generally isn't billable to a client, time 
that gets in the way of paying work.   Rsync is just another item on 
that list, another thing that takes an uncertain amount of time to get 
working, another thing that needs to be watched once in awhile so that 
the service it provides will actually be there when it's needed.

The same is true, I imagine, for IETF's running ftp - it's seen as a 
nuisance, as overhead, something else that can fail, something else that 
can be a security risk, maybe something else that the CDN would bill for 
if it were outsourced, etc.   But the "you don't need FTP because you 
can use rsync" is an argument that /everyone who needs file-level access 
to RFCs and I-Ds should have to separately incur the overhead/ of 
maintaining rsync so that IETF staff doesn't have to maintain FTP.   We 
don't know for sure how many "everyone" is, but it appears to be at 
least dozens of people, maybe more if you sample for more than 12 
days.   (I wouldn't expect everyone who uses FTP to use it once in 12 
days, far from it.)

IMO the correct posture for IETF should be "how can we help document 
authors, editors, reviewers work as effectively as possible?"   If 
there's any significant use of FTP - and dozens of users in 12 days 
relative to ~1000 regular participants (if judged by meeting attendance) 
/is/ significant - continued support for FTP should be seriously 
considered.   Several dozen document authors, editors, reviewers getting 
work done more easily should be considered a boon more than a burden.

And sure, maybe WebDAV would be a better choice - maybe it would 
facilitate ready access to RFCs and I-Ds for a larger number of users if 
Windows has built-in support for it.   So maybe a transition would make 
sense.   But if you're trying to help IETF participants effectively 
participate maybe a well-managed transition (perhaps even with overlap) 
would be the most helpful way of doing that.

> C-u C-M-! curl -s https://www.ietf.org/archive/id/draft-moore-exclusionary-language-00.txt'

Yes, but I'd have to remember and type that URL perfectly, which makes 
it a lot less likely to be an effective way of getting that document.  
(For better or worse, the naming scheme for I-Ds s not optimized for 
memorability.)

> I'm not so sure about FTP being unique here.  My personal experience is that the mobile app and OS feature set is very robust.  I have sent RFCs to print from my phone/tablet +and imported text int…

So everyone using FTP should have to change their toolset so that IETF 
can avoid supporting one server that helps at least several dozen 
participants?

Do you understand that that likely translates to a significant fraction 
of those several dozen people deciding that it's just too much trouble 
to work with IETF any more, because the organization is now imposing 
more and more arbitrary constraints on how the work gets done?

Keith

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 27 Nov 2020 11:06:57 +0000

Hi Keith,

I hope we can find a way to maintain our creativity and efficiency without using FTP.

Our goal is to produce high-quality specifications of protocols that get widely deployed in a secure way. I believe there are is still room for improvement on all fronts but I am less convinced that the protocols used for fetching the documents we read play a crucial part in that story.

Ciao
Hannes

-----Original Message-----
From: Keith Moore <[email-masked]>
Sent: Thursday, November 26, 2020 1:40 PM
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: Regarding "Call for Community Feedback: Retiring IETF FTP Service"

On 11/26/20 2:52 AM, Hannes Tschofenig wrote:

> I believe the real question is how do we manage change in this
> organization? In this specific case, how long are we going to support
> workflows of a smaller and smaller number of people? (I assume that
> your workstyle is less common than mine. Maybe a bold assumption.)

Yes it comes down to that.  But optimizing for the "common" workflow actually pessimizes against people who have more effective workflows, makes the organization less able to attract creative and experienced people to work for it, and makes the organization less adaptable overall.  I assert that this is exactly the wrong direction for IETF. IETF should not treat becoming more restrictive and less flexible at supporting people's workflows as a virtue.  It's bad enough when some company hampers its employees' productivity in that way, even worse when a volunteer organization does that.

IETF, of all organizations, should be trying to encourage its participants to try out new and varying ideas, not to coerce everyone into doing things the same way as everyone else.  IETF is not a factory that turns out huge numbers of identical goods.

Now granted there are always costs associated with maintaining multiple services, and at some point the usage of some service might not justify the cost.  But zero data has been presented to support this argument. Roman's data doesn't say anything about it because it's almost entirely about traffic volume, and I've seen zero assessment of the actual cost - just handwaving.

Really this is a textbook case for why "IT" shouldn't be allowed to make such decisions anywhere, but especially not in an organization that values creativity.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Nov 2020 09:51:44 -0500

> Our goal is to produce high-quality specifications of protocols that get widely deployed in a secure way. I believe there are is still room for improvement on all fronts but I am less convinced tha…

IMO, the effort to deny people tools that are useful for them, without 
actually providing any observable justification for doing so, does not 
bode well for IETF's creativity or efficiency.

Though I would miss FTP, it could certainly be replaced without loss of 
functionality IF IETF would support something that's equivalent (rsync 
doesn't seem to be, but WebDAV might), AND several dozen or maybe even 
hundreds of participants were willing to retool.   But disregarding the 
effort required on the part of participants to retool because it's 
Somebody Else's Problem does not reflect well on the organization's 
leadership.

More broadly it seems like many participants in this conversation 
believe that everyone should work and think like they do, and that 
everyone else should be considered obsolete.   That doesn't bode well 
for IETF's creativity or efficiency either.

And the evident bias against open standard solutions, among participants 
of an organization that has standardization as its purpose, seems like a 
Very Bad Sign.

Keith

---

From: Adam Roach <[email-masked]>
Date: Fri, 27 Nov 2020 18:06:41 -0600

> and surprise: it worked as major Web browsers support it.

That will change Really Soon Now.

https://groups.google.com/g/mozilla.dev.platform/c/FqCZUT9ay_o/m/jt4DLRDjAwAJ?pli=1

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 27 Nov 2020 18:22:02 -0600

> Up front -- there is no way to currently mount a remote filesystem from IETF services with anytime but FTP.

So, that's not *strictly* accurate. Someone's put a FUSE wrapper around 
the rsync commmand in a way that makes the remote rsync module mount as 
a local filesystem:

https://github.com/zaddach/fuse-rsync

I'm not sure this is the kind of solution people would be happy with, 
though.

/a

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Nov 2020 19:26:48 -0500

On 11/27/20 7:22 PM, Adam Roach wrote:

> So, that's not *strictly* accurate. Someone's put a FUSE wrapper 
> around the rsync commmand in a way that makes the remote rsync module 
> mount as a local filesystem:
>
It's certainly not a solution that everyone is likely to be able to use, 
but I'm nonetheless intrigued by it.   I'll give it a try, and thanks 
for mentioning it.

(still, python?  I love the language but am often appalled at how slow 
it is.)

Keith

---

From: Behcet Sarikaya <[email-masked]>
Date: Sun, 29 Nov 2020 14:49:57 -0600

Folks, I am OK with retiring ftp service.
Actually, I never said I am for it :)

Behcet

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 30 Nov 2020 14:12:43 +0000

Hi Adam!

> From: Adam Roach <[email-masked]>
> Sent: Friday, November 27, 2020 7:22 PM
> To: Roman Danyliw <[email-masked]>; Keith Moore <moore@network-
> heretics.com>; [email-masked]
> So, that's not *strictly* accurate. Someone's put a FUSE wrapper around the
> rsync commmand in a way that makes the remote rsync module mount as a
> local filesystem:
> 

I stand corrected.  This is really interesting solution.  Thanks for sharing.

You inspired me to look at other FUSE wrappers to mount IETF servers as a local file system.  I found these for mounting an HTTP directory listings from a webserver:

** rclone -- https://rclone.org/http/ -- a cross platform Linux/MacOS/Windows option

$ apt-get install rclone

$ cat rclone-ietf.conf
[ietf]
type = http
url = https://www.ietf.org/ietf-ftp/

$ rclone --config=rclone-ietf.conf mount ietf: /mnt/ietf-ftp/

$ ls -F /mnt/ietf-ftp/
charter/                         iana/           ietf-mail-archive/        rfc/             yang/
concluded-wg-ietf-mail-archive/  iana-timezone/  ietf-online-proceedings/  slides/
conflict-reviews/                ietf/           review/                   status-changes/

** HTTPDirFS -- https://github.com/fangfufu/httpdirfs -- Linux and FreeBSD only? (binaries in Debian and Arch flavors; FreeBSD ports) 

Regards,
Roman

> I'm not sure this is the kind of solution people would be happy with, though.
> 
> /a

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Nov 2020 09:26:06 -0500

> You inspired me to look at other FUSE wrappers to mount IETF servers as a local file system.  I found these for mounting an HTTP directory listings from a webserver:

FUSE is great, except when it isn't.   I had to reboot yesterday because 
sshfs/FUSE got wedged to the point that I basically couldn't get work 
done.   Something always gets lost when an unscheduled reboot becomes 
necessary.  (if nothing else, valuable context gets lost)

Also, I prefer to use tools that work by design rather than by 
accident.  With FTP I don't have to worry about the format of a web page 
changing.

Keith