--On Tuesday, April 07, 2015 05:56 -0400 Ray Pelletier
<rpelletier(_at_)isoc(_dot_)org> 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