Skip to content
This repository has been archived by the owner on Dec 21, 2022. It is now read-only.

Latest commit

 

History

History
144 lines (103 loc) · 19.1 KB

status.md

File metadata and controls

144 lines (103 loc) · 19.1 KB
Raw

Working Summary of Community Discussion on Retiring FTP

(last updated per this message in the main thread; 2020-12-07)

(last updated per this message in a side thread; 2020-12-03)

The following is a summary of the feedback in the Call for Community Feedback: Retiring FTP Service thread and Regarding "Call for Community Feedback: Retiring IETF FTP Service" sub-thread on the IETF Discussion mailing list.

This summary aggregates common questions and concerns with the proposal, and associated responses with references. It is not a verbatim transcript of the discussions. Likewise, it does not synthesize discussions not directly related to the question of retiring the FTP service. The number of references per topic should not be interpreted as a measure of the volume of conversation. Rather, the references point to unique positions or descriptions (and repeats or duplicates of that position/idea/thought by the same or another party may not necessarily be linked).

As this thread consisted of many messages and interleaved ideas, if your position has been missed or misrepresented, please send corrections to the thread on ietf@ietf.org or privately to Roman Danyliw (IESG tool representative).

Explicitly Stated Positions

The following are pointers to explicitly stated positions (and rationales) on the retirement plan. No assumptions were made about the positions of parties who asked or endorsed a question, described a personal workflow, provided technical analysis/opinion, etc. See [190]. There were significantly more contributors to the mailing list discussion than suggested by the pointers to the positions noted below.

Oppose:

No objection, contingent on:

  • Turn off support in December 2021 [Richardson]
  • Continued operation of ftp.rfc-editor.org [Moore -new -old]

Support:

Questions

What is the "operational complexity" of running FTP? How much does it cost? [5] [6] [7] [19] [27]

  • Running each additional service takes operational effort [10]. In particular FTP requires a number of back-end scripts to make sure files are exported into the right directory [25].
  • Running services that are not use expose an unneeded attack surface [49] [62] [65]

How small is "small" referenced in the [retirement proposal] ?

Why was so much time invested in developing an FTP retirement plan if the community is just now being consulted? [19]

  • This is the second time the community is being asked about retiring the FTP service. This call for community feedback provided answers to the unaddressed questions posed in the 2015 calls up front [25].

Concerns

Traffic volumes are not a good indicator of the value of a service [29] [32]

IETF should not force participants into a particular workflow around tooling [1011] [189]

  • Supporting all work flows indefinitely leads to stagnation [292]

Cost exists to migrating existing scripts [5] [32]

  • Roman Danyliw and volunteers at Carnegie Mellon University have offered to help anyone with FTP script conversion [28] [128]
  • ... various discussion on who should (and when) incur the cost of the service -- technical debt [197] [204], fixed resources [[205]], different tolerance for changing worklow [292] ...

Calls for community feedback have a cost to the community as they need a response [8] [11]

  • The IESG feels that deprecating a service requires community consultion and will err on the side of asking rather than acting unilaterally [14] [15]

Browsers do not return documents in the correct formats or 'as the author intended' [246] and "are in constant state of flux" for a reliable download client [277]

  • ... long discusion highlighting the different URLs to download document and specific browser features (e.g., saving files in browsers); ... specific access issues could not be reproduced ...

FTP provides a unique interface (Use Cases)

The sections below describe unique properties of FTP access that the community feedback found important.

Irrespective of this proposal, FTP access to RFCs and I-Ds will continue at ftp.rfc-editor.org [207]. The rfc-editor is the authoritative source for RFCs.

FTP preserves unecrypted access [8] [67]

Not all clients can access encrypted content [19] [72] [125]

  • The usage data does not suggest that the current FTP are not in disavantaged enviroments 25 [122] 137
  • Unclear use case driving need for unencrypted access [68] 71 [81]

FTP is an alternative to strong TLS v1.3 ciphersuites [138]

  • All IETF web properties with content analogous to FTP (www.ietf.org, datatracker.ietf.org and tools.ietf.org) support TLS v1.0 - v1.2 [140] [170]

The small community that uses FTP might mirror access for users who can't access this content otherwise [19]

  • The usage data does not suggest this is occuring [25]

FTP provides a search-and-find access pattern [19] [98]

FTP provides a filesystem interface -- can be mounted as a file share [29] [58] [1008] and native notion of files and directories [1003]

  • <many posts around WebDAV was occured, but that is not service provided by the IETF>
  • Use a FUSE-file system wrapper for rsync [1016]
  • Use a FUSE-file system wrapper around web-server directory listings [1019]

FTP is widely supported in browsers [1001]

  • Chrome will disable support in 1Q2021 [1004]. So will Firefox [1015]

FTP is better for scripting and HTTP+HTML is complex (FTP is stable) [29]

  • Raw versions of IETF content (without HTML encoding) is availible over HTTPS transport [54]
  • Ability to mount FTP as a file share provides stability [58]
  • HTTP has been backward compatible [79]
  • ...significant general conversation about HTTP vs. FTP APIs and WebDAV as an interface...

FTP provides alternative access mechanism [101] [230]

  • Highly unlikely case [105] [106]
  • Additional access mechanism have cost [231]

FTP is simple tool [301]

With rsync as an alternative to sync

Rsync documentation is lacking and not widely supported [19] [30]

  • Guidance on using rysync to make a offline copy of IETF content exists [25].
  • rsync is availible on Unix, Mac, Windows and NetBSD [33] [324]
  • Three rsync servers exist for community use [60]

Rsync is not is not standardized [234]

  • IETF work has built upon rsync [236]

In other applications, there have been security issues [265]

Objection to the rigor of traffic statistics [342]

Transition Plan

The following suggestions were made on facilitating the retirement:

  • Fix pointers to FTP in embedded in the datatracker status page [35]
  • Retire FTP by having the service only serve a README that points to the locations of the content [19] [134] [139]
  • Retire FTP by having a CNAME from ftp.ietf.org to rfc.rfc-editor.org [209] [219]
  • Hand over operation of the FTP service to a community volunteer [332]
  • Consider building an "FTP-rsync" gateway [46]
    • Bespoke tools will add more complexity [48]
    • Custom tools are important to the IETF [50]
  • Move FTP and Gopher specifications to historic status [64] [75] [129]
  • Agree to retire now, but first announce a retirement date in the future [1007] [292]

Related Treads

The community discussion on this topic also spawned additional threads not directly germane to the specifics of this FTP retirement proposal.