On Tue, Apr 7, 2015 at 3:23 PM, manning bill <bmanning@xxxxxxx> wrote: > You are right. Lets just turn of FTP (an IETF standard) and run rsync (not an IETF standard)… Oh, come /on/ Bill -- that's not what I said, and I'm sure you know it; I expressed no preference for either keeping or discontinuing FTP[0]. > 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... Hey, that's also not what I said. Having AMS run a service for the IETF != IETF participants knowing how to run each protocol and especially how to run protocols as a mixture. W [0]: I actually happen to think we should keep it, unless the cost to run it is too high. And that knowing the cost (which only entered the conversation quite late in the game) is too high. > > /bill > PO Box 12317 > Marina del Rey, CA 90295 > 310.322.8102 > > On 7April2015Tuesday, at 12:10, Warren Kumari <warren@xxxxxxxxxx> wrote: > >> On Tue, Apr 7, 2015 at 11:07 AM, Dave Crocker <dhc@xxxxxxxxxxxx> wrote: >>> On 4/7/2015 2:56 AM, Ray Pelletier wrote: >>>>> On Apr 6, 2015, at 12:14 PM, Michael StJohns <mstjohns@xxxxxxxxxxx> 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 > -- 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