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? 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/
