--On Friday, April 03, 2015 19:39 +0200 Eliot Lear
<lear(_at_)cisco(_dot_)com> wrote:
Ray,
On 4/3/15 7:31 PM, IETF Administrative Director wrote:
All;
The Technology Management Committee of the IAOC is considering
recommending to the IAOC ending support for FTP to retrieve
files from the IETF servers and would like to hear from the
community before the IAOC taking its decision. This does not
include rfc-editor.org.
...
Honestly I didn't even know that we were offering FTP service
for anything other than RFCs, and quite frankly I see no
reason to continue the service for RFCs either. FTP is
antiquated. In as much as we are encouraging everyone to
encrypt everything, most FTP clients and servers lack that
support.
Hmm.
First, my experience has been that Internet Drafts and other
files have been moved around enough to require rewriting macros
and functions that use FTP. That may have been worthwhile for
some mirrors (although I am not sure why) but I more or less
gave up after a couple of rounds of rewrites and started using
HTTP with, IMO, some reduction in productivity, especially since
I-D announcements eliminated links to the drafts themselves
(rather than an "HTMLized version" and a link to a page from
which one can get to the draft). There are certainly I-Ds I
haven't looked at because of those slow links and hidden
locations, especially when the announcements show up while I've
traveling in or two slow- or expensive-connection locations.
So, while I am unhappy about the reasons, I agree with your
announcement and with Eliot that, for most or all documents
other than the RFCs, the functionality is essentially gone
already except for mirrors that could be better served in other
ways.
The RFCs are a different matter: I'd be surprised if I'm the
only person who tends to fetch RFCs directly into an editor
environment, especially when I'm writing new or updated
documents. Those fetching operations are controlled by really
simple, and very fast and simple, macros -- the many features of
HTTP just make things more complex, slower, and involve more
bandwidth.
And, as to "encrypt everything" for RFC-like documents, I hope
we continue to be thoughtful about security measures and where
they are needed. It would be most unfortunate if we reduced the
openness of the network or our processes in the interest of
better protecting documents (or even access to them) that are
supposed to be completely public.
john