On 4/7/2015 2:56 AM, Ray Pelletier wrote:
On Apr 6, 2015, at 12:14 PM, Michael StJohns
<mstjohns(_at_)comcast(_dot_)net> wrote:
What is the cost of leaving FTP service in place? I would expect that the
cost was more in setting up FTP in the first place (e.g. adding it to
template emails, configuring the servers) than any real day to day cost, but
I could be wrong.
What is the cost of removing it? (e.g. besides simply shutting off the
servers, what else has to be done, who has to do it and what will it cost?).
...
There is no cost to turning it off.
There might be no cost to IETF ops, but there is cost to whomever is
still using the service.
There is also an indirect cost in the IETF's knowledge of its protocols.
As others have noted, we should be eating our own dog food. Knowing
how to run each protocol and especially how to run protocols as a
mixture, certainly should be an IETF goal.
The FTP server we are using (proftpd) places restrictions on how we
store files in the file sytem that are much more constraining than
the http and rsync daemons. Essentially, the files to be served must
be stored in a single tree (as hardlinks - symlinks won't work).
This is impeding work as we evolve. In particular, it affects how we
separate services to take advantage of cloud architectures. Other
servers have different limits, but still place significant
constraints on what we can do. 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.
The above should have been in the original announcement/request, along
with concrete details about current usage, as others have requested.
Further, the above could represent extremely significant operational
insight into the details of a multi-protocol service environment. It
should be thoroughly documented and considered for BCP.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net