From: Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, November 18, 2020 2:53 PM
To: Roman Danyliw <rdd@xxxxxxxx>; Ned Freed <ned.freed@xxxxxxxxxxx>
Cc: ned+ietf@xxxxxxxxxxxxxxxxx; ietf@xxxxxxxx
Subject: Re: Call for Community Feedback: Retiring IETF FTP Service
On 11/18/20 2:25 PM, Roman Danyliw wrote:
Hi Keith,
On 11/18/20 6:00 AM, Roman Danyliw wrote:
As I responded to Toerless [1], the primary users of FTP (by volume) don't appear to be disadvantaged:
The issue is not about the "primary" users (by volume). (Remember, traffic volume is not an indicator of importance.) This is an accessibility issue. Would you consider it acceptable to deny access to IETF documents to sight- or hearing-impaired
persons because "the primary users... don't appear to be disadvantaged"? If not, why is it acceptable to deny access to those who cannot use crypto?
[Roman] The IETF should definitely try to ensure that there is pervasive access to its information. Toerless asked the same question [1]. He was wondering if current FTP access was bridging access to other communities.
==[ snip ]==
Per the usage data [1], the 85th percentile of traffic comes from entities that don't strongly suggest they would mirror for unique access:
It's not the 85th percentile of traffic that you should be looking at. It's the remaining 15 percent; the odd uses cases that aren't easily characterized.
[Roman] I’m no expert in accessibility technology, but what’s the basis to link the “sight- or hearing-impaired persons” population with FTP usage.
The "accessibility" issue I was referring to was also one that Ned was concerned about - are there people who cannot access RFCs and I-Ds because they can't use https and therefore crypto? I don't think rsync suffices because it's designed for mirroring
rather than file access. (Accessibility isn't just about people with physical impairments.)
The reference to sight- or hearing-impaired persons was an analogy. If you don't think they should be prevented from accessing RFCs and I-Ds, should those in countries that block https be prevented? (For instance, some countries are currently blocking
TLS 1.3 when using ESNI because they can't monitor what sites the browsers are talking to.)
[Roman] In case there is concern about the TLS configuration on
www.ietf.org, it is quite permissive to ensure flexibility . See
https://www.ssllabs.com/ssltest/analyze.html?d=www.ietf.org&s=104.16.45.99&hideResults=on. TLS v1.0 – 1.3 is supported. Likewise, the ciphersuites are extremely generous.
Roman
