It looks to me like we have a fairly straightforward tradeoff here. The problem is actually that the IETF is using an FTP server that has a dubious security anti-feature (no symlinks ever) that causes operational issues. This is a real problem. One approach is to turn off FTP. This has costs to the IETF, find all of the ftp: URLs in the web site and other online materials (e.g., auto-generated e-mail and stuff you can get by FTP or rsync), identify other ways to access the material, and change the links. It also has costs to anyone using FTP who will at least have to change what they do and possibly find and install new software, e.g., Windows rsync. The other possibility is to make it someone's job to fix the FTP server. There is lots of free FTP server software -- I see about a dozen of them in the FreeBSD ports collection. I've used a few and found that they're generally not hard to configure, and symlinks are no problem (use chroot to limit accidental leakage.) Most provide RFC 4217 TLS support which makes FTP roughly as secure as https if your client supports it. In this case, the ftp: links keep working, and assuming reasonable file layout and use of symlinks on the server, it should be possible to keep existing URLs and paths valid indefinitely. So it seems to me this is really a question about money. Is it worth whatever the cost would be to upgrade and document the FTP service so it doesn't get in the way of other operations? I dunno, sounds like a job for the IAOC. R's, John PS: I have no sympathy for arguments that we should force people to use encrypted protocols. Can we please give our users the benefit of the doubt that they are able to understand their own security tradeoffs?