Re: Cost was Re: FTP Service Discontinuance Under Consideration; Input R

You are right.   Lets just turn of FTP (an IETF standard) and run rsync (not an 
IETF standard)… And while your at it, please deprecate FTP as a legacy, 
insecure protocol.
Nobody else beside the AMS folks know or care about a busted implementation of 
an IETF  standard after all...

/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

On 7April2015Tuesday, at 12:10, Warren Kumari <warren(_at_)kumari(_dot_)net> 
wrote:

> On Tue, Apr 7, 2015 at 11:07 AM, Dave Crocker <dhc(_at_)dcrocker(_dot_)net> 
> wrote:
> > 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.
> Known by whom? Glen? Matt? The other AMS folk?
>
> This sounds like motherhood and apple pie -- "We, the IETF, should
> know how to run each protocol and especially how to run protocols as a
> mixture. And we should floss daily and always call our granny on her
> birthday..."
>
> But, before this thread, how many people here even knew we were
> running proftpd? How many people on this list are operationally
> involved in running the ietf.org mail / dns / ftp / rsync / web / etc?
> Who has root on these boxes?
> Quick, name the box that mailman runs on. What version of apache run
> www.ietf.org?[0]
>
> I've been trying to stay out of this thread, but now that I've started
> commenting...
> Perhaps we should also consider the human time cost of this whole
> discussion -- so far there have been 65+ emails on this topic - each
> of these have taken a non-insignificant amount of time to write, and
> many many people have spent time reading them. Payscale.com claims the
> median pay for a Snr Network Engineer in the US is $91,226 per year,
> or ~$45 per hour[1] - how much has this whole conversation cost
> us?![2]
>
> W
> [0]: Yup, this is a trick question - but I'm guessing a fair number of
> people don't know why...
> [1]: This was the quickest / easiest number to find - I'm betting most
> people on the list earn significantly more than that...
> [2]: I'm choosing to a: make the issue worse by bringing this up,
> which will no doubt prolong the thread....and b: I refuse to let
> people use the same argument when I start talking about something that
> I happen to find interesting or entertaining. Like hypocrisy... or the
> writings of Jerome K Jerome... or cats...  or the changing
> distribution of colors in paintings over time (
> http://www.washingtonpost.com/blogs/wonkblog/wp/2015/04/06/the-colors-of-94526-paintings-since-1800-charted/?tid=sm_fb
> ).
>
> > > 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
>
>
> -- 
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>   ---maf