RE: Call for Community Feedback: Retiring IETF FTP Service

[Roman Danyliw <[e-mail]>]

Hi Ned!

> -----Original Message-----
> From: Ned Freed <[e-mail]>
> Sent: Tuesday, November 17, 2020 9:53 AM
> To: Roman Danyliw <[e-mail]>
> Cc: [e-mail]; Keith Moore <moore@network-
> heretics.com>; [e-mail]
> Subject: RE: Call for Community Feedback: Retiring IETF FTP Service
> 
> > Hi Ned!
> 
> > Thanks for the feedback.
> 
> > > -----Original Message-----
> > > From: ietf <[e-mail]> On Behalf Of
> > > [e-mail]
> > > Sent: Tuesday, November 17, 2020 9:02 AM
> > > To: [e-mail]
> > > Cc: Keith Moore <[e-mail]>
> > > 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/