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
