On 11/18/20 6:00 AM, Roman Danyliw wrote:
Hi Ned!
-----Original Message-----
From: Ned Freed <ned.freed@xxxxxxxxxxx>
Sent: Tuesday, November 17, 2020 9:53 AM
To: Roman Danyliw <rdd@xxxxxxxx>
Cc: ned+ietf@xxxxxxxxxxxxxxxxx; Keith Moore <moore@network-
heretics.com>; ietf@xxxxxxxx
Subject: RE: Call for Community Feedback: Retiring IETF FTP Service
Hi Ned!
Thanks for the feedback.
-----Original Message-----
From: ietf <ietf-bounces@xxxxxxxx> On Behalf Of
ned+ietf@xxxxxxxxxxxxxxxxx
Sent: Tuesday, November 17, 2020 9:02 AM
To: ietf@xxxxxxxx
Cc: Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx>
Subject: Re: Call for Community Feedback: Retiring IETF FTP Service
The discussion of FTP service retirement has actually been
surprisinginly informative. Things I've learned include:
(1) The IETF no longer provides HTTP access, leaving FTP as the only
access mechanism that doesn't require a crypto layer. With FTP gone,
crypto becomes a requirement for access.
Could you help me better understand which way your concern leans.
Let's abstract away HTTP and FTP, and just consider a communications
channel. Do you have a use case where access to IETF artifacts need
to happen over unencrypted channels (i.e., getting the same artifacts
over an encrypted channels breaks the use case)?
For myself, I routinely use devices that are incapable of supporting a crypto
stack that would work with an IETF HTTPS server. I haven't had the need to
access IETF resources recently from such hardware, which is why I hadn't
noticed this change. But that's happenstance, nothing more.
Thanks for clarifying. This access must not have had happened in several years. HTTP has been turned off since 2015 per https://www.ietf.org/about/groups/iesg/statements/maximizing-encrypted-access/.
However, the case that worries me much more is how this may affect access
from places where crypto use is problematic.
We haven't been serving over HTTP in 5 years. As I understand it, the concern is that FTP is one of the last ways to access IETF information unencrypted. Do I have it wrong?
rsync is unencrypted.
As I responded to Toerless [1], the primary users of FTP (by volume) don't appear to be disadvantaged:
==[ snip from [1] ]==
>From the data we have [1], it doesn't seem like many users are operating in a restricted environment. I'm making assumptions here, but the biggest users of FTP, constituting 85% of the traffic, all seem very capable of consuming encrypted content.
** a dynamic IP address in a German ISP
** the proxy of a Fortune 100 company
** a Canadian IT services company
** a large US search engine company
** a leading Japanese research university
** website of a not-so-popular programming language
** a small Swedish software product company
** a small, several person US consulting company
==[ snip ]==
Hence, from what we see from actual usage, those disadvantaged users appear largely hypothetical.
Furthermore, >99% of requests are syncing the entire or parts of the repository which can be done with rsync. As pointed out by Bob [2], rsync can be used over rsh (unencrypted):
==[ snip ]==
$ rsync rsh rsync.ietf.org::
everything-ftp - The entire IETF FTP Archive
internet-drafts - The Internet Draft Repository (currently active drafts)
id-archive - The Internet Draft Archive (both active and expired drafts)
iesg-minutes - IESG Minutes
proceedings - Repository of Proceedings
xml2rfc.bibxml The xml2rfc citation libraries
charter - Repository of WG Charters
concluded-wg-ietf-mail-archive - Older list text archives
conflict-reviews - Repository of Conflict Review documents
iana - IANA assignments
iana-timezone - IANA Time Zone Datatbase (see also http://www.iana.org/time-zones)
legacy-files - Legacy material supporting long-lived URLs
mailman-archive - Repository of Mailing List Text Archives
rfc - Repository of RFCs
slides - Repository of Slide Documents
status-changes - Repository of Status Change Documents
==[ snip ]==
Roman
[1] https://mailarchive.ietf.org/arch/msg/ietf/py_9b486x8x2io6d5dAb3FAgNng/
[2] https://mailarchive.ietf.org/arch/msg/ietf/maUHi4gfaPAH_TfsU6XbqdYYM5Y/
