Re: Call for Community Feedback: Retiring IETF FTP Service

[Marc Petit-Huguenin <[e-mail]>]

Transferring files that are not HyperText files using HTTP is in poor taste, much like eating salad with a fork that is not a salad fork.

On 11/10/20 9:19 AM, Roman Danyliw wrote:
> Hi John!
> 
>> -----Original Message-----
>> From: ietf <[e-mail]> On Behalf Of John C Klensin
>> Sent: Tuesday, November 10, 2020 8:02 AM
>> To: Scott O. Bradner <[e-mail]>; [e-mail]
>> Cc: [e-mail]
>> Subject: Re: Call for Community Feedback: Retiring IETF FTP Service
>>
>> +1
>>
>> And, while I suspect my scripts are less complicated than
>> Scott's, I do have them and am dependent on them.   So two
>> additional thoughts:
>>
>> (i) I know the conventional wisdom in the IETF is to obsolete HTTP in favor of
>> HTTPS.  However, if conversation is necessary, conversion from FTP to simple,
>> no negotiation HTTP is likely to be lots easier the conversation to HTTPS,
>> certificate handling, etc.  So, while the report seems to circle around this a bit,
>> if FTP is discontinued, will we be assured that plain HTTP access will be
>> available long-term rather than those who do convert waking up one day and
>> discovering that HTTP is being discontinued because HTTPS is more virtuous?
> 
> To be clear, the proposal is completely reductive -- spinning down FTP.  The posture of HTTP vs. HTTPs is outside the scope of this proposal and would be a separate community discussion to change that (and I'm not aware of this being under consideration).
> 
>> (ii) Can we start evaluating these changes, not just in terms of extra facilities
>> that have to be maintained (and I agree with Scott that, once the machinery is
>> set up, the marginal costs of maintaining FTP should be, well, marginal) but in
>> terms of costs to the community of discussing
> 
> There is a tension here.  The community has made a clear it wants to be consulted (and it seems very appropriate to asked when taking something away).  However, reviewing this consultation takes time and effort from the community.  I'm not sure how to reconcile this other than erring on the side of asking when the issue come up (as has been done here).
> 
>> and making the conversion.
> 
> I acknowledge that this conversion cost is real.  However, so is the cost migrating and managing the filesystem.  It's also not entirely clear on how to reconcile these costs.  All I believe we have is the usage data which suggests that most (but not all) of the community prefers HTTP.  This strongly suggests that the aggregate workflow for the overwhelming majority of the community is using HTTP and that continuing to run FTP is to support a small fraction of the community.  This call for feedback is a solicitation to the community to help reason about this threshold of usage for a service.
> 
>> Except for those who actually have unlimited time or would not be contributing
>> to the IETF's technical work anyway and In addition to the time taken up
>> creating plans and reports like this, please assume that every minute taking up
>> considering a plan like this, converting scripts (or even old habits), etc., is a
>> minute that IETF technical, standards-producing, work isn't getting done.  Is it
>> worth it for this case (or any particular other one that might arise next)?
> 
> Philosophically, this cuts both ways.  For every minute we are running a service that support n-users, we could be using that time to optimize a service that support 100n - 1000n-users.  That's the order of magnitude usage ratios were are talking about.  As noted in the proposal, this is likely undercounting HTTP usage since datatracker and cloudflare were not used.
> 
> Roman
> 
>>
>>       john
>>
>> --On Tuesday, November 10, 2020 06:55 -0500 "Scott O. Bradner"
>> <[e-mail]> 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 <[e-mail]>
>>>> 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_Servic
>>>> e.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)
>>>>
>>>
>>


-- 
Marc Petit-Huguenin
Email: [e-mail]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug