a) I don't think that "small community" is a sufficient analysis to justify retirement of ftp. If this small community for example would be significant mirrors or give access to the content to users who for whatever reasons can not access the content differently, i am sure that would influence the decision making. b) I don't know what "operational complexity" is supposed to mean. Cost of operations would be a more useful measure to weigh against the benefit, especially when its hard to quantify the benefit, given how (see a) the benefit is not necessarily equal to the percentage of utilization - and the cost likely is very small. c) The PDF and your email is not really honest, because it says "http", but in reality every http URL is immediately redirected to https, aka: retiring ftp would further strengthen the policy USER MUST USE END TO END ENCRYPTION WHETHER THEY WANT TO OR NOT. I understand that this is the implied policy by security advocacy in the IETF, but i think it is not the right policy for all content. I think end-to-end encryption should be a choice. Of course, a content provider like IETF could make that choice and force it upon users, but for example for bulk download of public data it often is a quite performance reducing choice. Aka: https downloads are slower than ftp/rsync (rsync without ssh!). Encrypted download might also not be permitted by users operating from secured environments where all actions need to be logged. Aka: I think IETF should have the option for unencrypted access to its data for all popular protocols and leave the choice to the users. Of course, this would be less a question of protocol if IETF would not have forced MUST ENCRYPT onto TLS 1.3, because no-encrypt,authenticate-only would be a perfect option for these type of use-cases when accessing public data without requring privacy. Oh well... d) HTTP/HTTPS are not protocols that actually allow to search/find content, like FTP is with its ability to list directories. For repositories like what was/is on ftp, HTTP/HTTPS are severely inferior protocols. Directory listing through per-client implemented screen scrping of directory listing output format of few well-known web-server directory listing formats. And IETF seems to be endorsing this. Give me a break. Where is INT area when you need it ? ;-)) Do we even specify a standard format for IETF HTTP/HTTP directory listing format, or do all mirroring script clients need to be updated when/if the IETF web server would some time decide to change implementations and use a different directory listing output format ? WebDAV ? Have not seen this in operation on any browser to give me better, FTP like experience on web file stores... e) rsync would survive as the only viable bulk update mechanism, and for that one may argue its better than FTP. I am a fan. But not sure that means it can replace ftp in all use-cases. The IETF documentation for rsync is quite lacking. I would stroongly suggest to put better documentation, on a https://rsync.tools.ietf.org page so users for whom https is not the best choice can quickly get up to speed. Also: before removing ftp.ietf.org, i would STRONGLY suggest to simply remove all content, but keep the web service alive with a forward pointer, (README) e.g.: to http://rsync.tools.ietf.org - and let that run for at least one year (or longer). That way, all owners of scripts could inf the forward information. f) Q: Was this type of question raised before investing all the effort into the analysis of the situation and what looks like almost finished decision making ? i can't remember and earlier Q to the community... Cheers Toerless On Tue, Nov 10, 2020 at 02:23:58AM +0000, 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) -- --- tte@xxxxxxxxx
