speaking as someone who does outsourced network / service operations as
a full-time day job:
All services have a cost of delivery. The cost is difficult to assess
and it's usually more than people want it to be, but it is generally
proportional to several things, including how complex the service is,
how well-run you want to service to be. There can also be other things,
e.g. how large it needs to scale, what uptime you want to guarantee, etc.
Some of the things that might need to be taken into account for an
itemised cost assessment could include:
- initial planning / design
- initial setup
- Hardware config / management
- Complexity of integration with the rest of the ecosystem
- Software management of service software
- Complexity / integration with the rest of the service ecosystem
- Backups
- DR
- Business overheads (light, wages, hvac, tax, offices, etc)
- Documentation
- Hosting and connectivity
- Monitoring
- Management knowledge communication
- Handling support issues
- Liability (what happens if the wrong data is served, etc)
- TCO of periodic forklift
This list isn't exhaustive, e.g. SLAs, process compliance, security
management, and so forth. There's an endless of things that might or
might not be important to either the service delivery provider or the
consumer. None of this comes for free because none of this is run on a
charitable basis. Nor is it run on a string-and-gum basis.
Even with a cost scoping exercise, where does that stop? E.g. if you're
talking about a car, do you just include the cost of the petrol, or do
you also include the annual service costs? What about depreciation?
One-off repairs? Interest on loans? Crashes, insurance and
consequential losses? What about the costs of providing the underlying
infrastructure - roads, bridges and traffic lights? Environmental
damage? And so on. I.e. reductionism isn't going to end you up with
any more of an accurate answer for cars than it is for ftp servers, and
there are more ways of assessing costs than you can shake a stick at.
Nick
Tim Chown wrote on 02/12/2020 13:55:
And for what it’s worth, another +1.
Tim
On 10 Nov 2020, at 12:38, Stewart Bryant <stewart.bryant@xxxxxxxxx> wrote:
+1
Stewart
On 10 Nov 2020, at 11:55, Scott O. Bradner <sob@xxxxxxxxx> wrote:
is there a compelling reason to stop a service that some people are using
the pdf says : "The operational complexity of running this service "
just what complexity is there once the service was set up (years ago)?
i.e., just how much does this service cost to run?
(seems to me that it is likely that the effort to develop this plan was much more than just letting the service run)
yes, I run one of the scripts that use ftp to access IETF resources and it would be a significant pain to rewrite it
since it is complicated script and I do not know how to do some of its functions in other non-ftp ways
I do seriously want to know how much it costs the IETF to run the ftp service
Scott
On Nov 9, 2020, at 9:23 PM, Roman Danyliw <rdd@xxxxxxxx> wrote:
Hi!
The Internet Engineering Steering Group (IESG) is seeking community input on retiring the IETF FTP service (ftp://ftp.ietf.org, ftp://ops.ietf.org, ftp://ietf.org). A review of this service has found that FTP appears to serve a very small community and HTTP has become the access mechanism of choice. Given this shift in community usage, reducing the operational complexity of the overall IETF infrastructure seems to outweigh the very limited community served with FTP.
In reviewing the additional impacts of such a service retirement, the dependencies on FTP have been assessed. Additionally, it has been confirmed that all information currently reachable through FTP will continue to be available through other services (HTTP, RSYNC, IMAP).
In consultation with the Tools team (Robert, Glen, Henrik, Russ, and Alexey), Communications team (Greg), affected SDO liaisons, IAB Chair, and LLC ED, a proposed retirement plan was developed and is available at:
https://www.ietf.org/media/documents/Retiring_IETF_FTP_Service.pdf
The IESG appreciates any input from the community on this proposal and will consider all input received by December 4, 2020 (to account for the upcoming IETF 109 and holidays).
Regards,
Roman
(as the IESG Tools Liaison)
