--On Tuesday, April 07, 2015 05:56 -0400 Ray Pelletier <rpelletier@xxxxxxxx> wrote: >... > Since the information is already > available through other mechanisms (particularly rsync), the > folks studying the problem recommended discontinuing the > service, rather than investing in finding the least onerous > deamon and reconfiguring to it. Ray, This is the sort of statement that has made the discussion so confusing with so many irrelevant side-branches. So, putting HTTP aside for a moment given the above statement, let's try a really quick test of the "rsync as a substitute for FTP" hypothesis, including some of the assertions that have been made on-list and considering only the IETF I-D situation and not actual or hypothetical non-IETF uses.: (1) Rsync, in native form, is more secure and/or private than FTP. Both are, at base, cleartext transfer protocols that expose origins and destinations. One can argue for privacy by overwhelming an attacker by noise rather than fetching individual files that might be sensitive, but one can do that with either protocol (and whether it would work depends on the attackers and their attitudes and resources). So, no. (2) Rsync is more secure and/or private than FTP when run over assorted encryption tunnel (or equivalent) technology. Such technologies are available for both. The IETF isn't advertising (and probably not supporting) any of them. So, not an issue either. (3) Rsync is an appropriate client-side operational substitute for FTP. For people maintaining complete mirrors and possibly mirrors of all of the drafts associated with a particular WG (i.e., with draft-ietf-WGNAME-* names), probably so if only because it is good at not transferring files that are already present locally (although, because we maintain version numbers, it isn't hard to set some FTP clients up to not transfer files that are present locally -- the additional checks rsync maintains for file changes are not needed). For someone who is trying to fetch a single file with a known name, e.g., within an editor, FTP is _much_ easier to set up and use in most environments. (4) Ready availability: FTP wins hands-down here because clients are built-in to all major operating systems. For others, availability of rsync varies, but I note that installation of a client on Windows requires either installation of a Unix/Linux environment (a potentially large attack surface is installed by people who don't understand it and don't pay any attention to it) or an inexpensive, but not free or FOSS, client. Either may run into trouble with enterprise rules about what can be installed on organizational machines, so, while FTP clients are generally available, rsync clients may not be available at all. (5) The IETF should be using protocols standardized by the IETF, its predecessors or at least the elusive "recognized standards bodies". FTP is RFC 959, STD9 with updates) and the URI scheme was part of the base URI definition spec [RFC1738]. And now... Rsync has never been considered or documented in the IETF. There is a _provisional_ URI scheme registration [RFC5781], but it doesn't contain a normative reference to the protocol itself or even a stable informative reference. (6) Operational convenience on the server side: Your FTP server has rigid idea about tree structure and doesn't accommodate soft links. So you either need to find a better server or you need to create and maintain a compatible shadow tree (perhaps with rsync :-)). FWIW, if you don't maintain at least the appearance of a stable file structure configuration, rsync clients will either need to be continually maintained or won't work well either. Scorecard: (1) Security and privacy: No difference (2) Security and privacy 2: No difference (3) Client-side operational alternatives: Rsync is probably better for complete mirrors, ftp for fetching individual files. (4) Client availability: FTP, hands down. (5) Dogfood consumption: FTP. rsync isn't even a candidate (6) Server-side operational convenience. So, again considering FTP and rsync only, as your note suggests is appropriate, this is a tradeoff between open and convenient accessibility to our files and "incremental savings in maintenance and support burden, and complexity". I suggest that those savings would have to be fairly high to justify a risk of increasing unnecessary burdens on participants and consequent decreased IETF openness or participation. john