Re: Call for Community Feedback: Retiring IETF FTP Service

[Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx>]

On 11/18/20 2:25 PM, Roman Danyliw wrote:

Hi Keith,

 

From: Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, November 18, 2020 7:06 AM
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 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.)

I don't think rsync is an acceptable substitute for FTP (valuable though rsync is) for several reasons:

[Roman] I wasn’t suggesting that rsync is a substitute of FTP.  Rsync + https can cover FTP use cases (unless using encryption in the https is the problem; however, I’m still unclear on why using https rather than http presents a problem when accessing IETF assets).

    no, rsync + https does not cover FTP use cases.

(a) it's not that widely known and mostly known in the Unix/Linux worlds;

[Roman] So the belief is that most FTP users are coming from Windows?  Rsync across all platform strikes me a niche.

    Yes, I think rsync is a niche...that is the point I was making.

(b) people looking for a way to access individual files may not stumble on rsync because it's generally a mirroring solution;

[Roman] Agreed.  However, as discussed with Toerless [1] there is little evidence that “stumbling” or as he called it “search/find” is actually happening via FTP.  If this use case of interest, “https://www.ietf.org/ietf-ftp/” provides a very accessible “stumbling” all with a tool (browser) built into all end-user operating systems.

I wasn't referring to finding IETF content via stumbling, I was instead asking: how does a user or service who needs a better solution than https find out about rsync access?

>  You’ve noted that “traffic volume isn’t
>         importance” but without relying on usage data of how the system
>         is used now we’re reduced to conjuncture and speculation of who
>         our users are and might be.
      
      The same is true when "relying on usage data" alone, there's a lot
      of conjecture and speculation about what that usage data means,
      especially for the usage data that doesn't easily cluster.

(c) it's not really designed to permit single file access even though it can be used that way;

[Roman] Agreed.  It would be awkward to use rsync for that.  However, HTTPS seems ideal.

    How many times do I have to keep pointing out that a web browser is
    a really lousy tool for trying to access multiple RFCs or drafts at
    the same time?   I can't tell you how many hours I've wasted trying
    to deal with web interfaces to document that required me to
    individually click on each one, download each one, specify a
    destination for each one, and keep track of which ones actually got
    downloaded, all before I could do anything with that set of
    documents... and wondered "why can't I just ftp this stuff in one
    command?"   Web browsers suck for file downloading, and http
    (without WebDAV) doesn't provide enough protocol hooks to build a
    decent client that would support that.   (Yes this is still
    "individual file access" as compared to syncing the whole server.)

(d) a lot of people don't know that rsync access to IETF documents even exists or how to use it, and (given that http access is already cut off) may have no way of discovering it;

[Roman] Well, they could look at https://www.ietf.org/standards/ids/internet-draft-mirror-sites/ or  https://tools.ietf.org/. 

    How are they going to find those if they can't use https?

(e) support for rsync is not integrated into browsers (though if browser vendors are also crippling ftp and http URLs that point may be moot).

[Roman] Right, but browsers could use HTTPS to get absolutely everything that is currently in FTP.

Arrgh.   I give up.  Clearly you've never actually had to do this kind of thing.   But the idea that "everybody should use the Internet like I do" seems out of place for IETF.

Keith