--On Friday, November 20, 2020 11:31 +0000 Roman Danyliw <rdd@xxxxxxxx> wrote: > Hi! > > We are about half through the feedback period and helpful > discussion has already occurred. Thank you for the input. > > To help focus further discussion and to help onboard those > that have not weighed in yet, a summary of the thread to date > can be found at > https://github.com/ietf/ftp-retirement-consult-2020/blob/main/ > status.md Roman, Thank you for your note and the pointer to the summary. I largely agree with Keith's comments today in https://mailarchive.ietf.org/arch/msg/ietf/ZnI-i5sB-d9eq7KDfkFB3Gb5ZPc but want to add a few things. First, it may be a trivial detail, but you undercounted those who objected. I'm certainly on that list unless the criterion for being counted is posting mostly-redundant arguments over and over again. That, however, leads to the non-trivial part and one of those "everything is connected to everything else" problems. I have gone back and checked through my tools and I have been using FTP access to I-Ds very little in the last few years [1]. I do use FTP to access RFCs, but I do so on the RFC Editor site, not the IETF one, both because some of my tools are old enough that the IETF was not maintaining an RFC repository and because the IETF does not seem to understand the importance of stable locations or links. So, in addition to not showing up in the summary list of those who objected, I don't show up if you are monitoring use of FTP access to IETF materials. But I am opposed to making this change nonetheless. So I would like to take a step back from most of the details of the discussion and talk about where it seems to come from. Keith wrote: 'And "let's be real" sounds like an argument for a certain kind of prejudice - it could be rephrased as "let's force everybody to conform to some completely arbitrary fashion".' I see the comments about encryption in the summary under "FTP provides a unique interface (Use Cases)" in the summary (and a great deal of traffic in this thread) as being about that same problem. So, again, let's take a step back, noting that this gets back to my comments about a slippery slope between "drop FTP access" and "ban everything but HTTPS". Am I in favor of making encrypted access to Internet resources available and having them work well from the user's standpoint as well as securely? Absolutely. Am I in favor of educating users as to why encryption is good for them and they should prefer it when they have the option? Yes again, although I'm not sure that is the IETF's job. But neither of those imply a stance that feels equivalent to "if you want to use unencrypted communications (or some particular protocol or resource), you are an outdated and/or immoral person whom we don't want in the IETF and who maybe doesn't deserve to be on the Internet"... especially if someone lives in a country or works for a company that is nervous about encrypted communications. The Internet I've been working to build for well over 30 years is one that is open and flexible, not only to connectivity from all over the world, but to allowing people to work the way they want to rather than being victims of an "our way or you lose" approach. That needs to apply to the IETF. It is entirely reasonable for the IETF to adopt rules about how people work and interact with others and we have done a lot of that in recent years. But, at least IMO, we need to remember that much of our strength and credibility depends on diversity --not just demographic diversity but on diversity of technical experience, perspectives, and work habits. Each time we say "do it this way from now on or you might as well go away and leave the IETF to people who work and think the way we do", we need to assume that some people will say "ok, enough" and go away. I can't predict how many of them will be valuable contributors, but "we" had best assume that some will be. And, for whatever it is worth --because I see this as a symptom of a much broader set of attitudes and problems-- I think the same principle applies to the assorted nastygrams and threats I (and probably others) who prefer to try to think through things, do careful analyses, and then write infrequent notes that tend to be long as a result, get from those who seem to believe that the only righteous way to work in the IETF involves a much larger and more frequent number of very short messages. I will consider the input and try to write shorter messages when I can but if the intent is to push everyone into expressing themselves in one particular way or not at all, well, sooner or later I (and maybe others) will conclude that the IETF doesn't want our input (a couple of those messages very nearly said that) and walk away. That would cost the IETF a certain amount of experience and perspective but perhaps the reality is that it is inconvenient and unwanted. As far as FTP access to I-Ds is concerned, I guess that I don't care from the standpoint of my own tools and work habits, although I do care (and am opposed to removing it) in principle. But many of the same arguments that have been made against keeping FTP access to those IETF materials could be made about the RFC Editor's repository and against retaining unencrypted access to the web-based repository. And then I would care a great deal (as I tried to say some weeks ago). best, john [1] The reasons are mostly unrelated to this discussion but are due to IESG refusal to enforce naming conventions: When naming conventions are predictable, a decent interface to FTP that includes what is commonly called "mget" (really a combination of NLST, a client-end selection process, and RETR) works well and requires a minimum number of user steps. When they are not, a search function like that of the datatracker gets much more easy. So, to a certain extent, while I trust it was not intentional, where we are now might as well have been a sequence of "let's make FTP access less useful so it drives people off; then let's notice that people, having been driven off, are not using it any more; then we notice that it is getting little use so should discontinue it."
