Re: Call for Community Feedback: Retiring IETF FTP Service

[Keith Moore <[e-mail]>]

On 11/16/20 5:43 AM, Russ Housley wrote:

> I support turning off the FTP service at ietf.org. The FTP daemon places frustrating constraints on the file system structure.  HTTPS offers much greater security, and it does not impose constraints on the file system structure.

Perhaps you could elaborate on this a bit?   It seems to me that it's 
not the FTP daemon that's placing the constraints on the file system 
structure,  but rather, the expectation that RFCs will be available at 
well-known URLs derived from the RFC number, and I-Ds will be available 
at well-known URLs derived from the I-D identifier.   Sure, a typical 
HTTP server does allow more flexibility at mapping URLs to filenames 
than a typical FTP server does, but only at the cost of a certain amount 
of operational hassle - those mappings have to be maintained.

In practice it also seems that HTTP encourages the destabilizing of such 
interfaces over time, as there's a desire to conform to the latest 
fashion in user interfaces, creating pressure to rearrange the file 
system to suit current whims.

At any rate, there's no requirement to maintain the FTP backing store 
and the HTTP backing store on the same file systems.   As John Levine 
helpfully pointed out, the amount of storage required is fairly small.   
And I understand that there's also a commitment to maintain the file 
structure and make it available using rsync, so I don't think 
deprecating the FTP service is helpful in this regard.

As for the security issue, it seems like any risk resulting from 
exposure of FTP channels to eavesdroppers is entirely on the client, and 
clients are able to choose for themselves whether this is a significant 
enough risk to migrate to a more secure, but less stable, programming 
interface.

Keith