On Tue, Nov 24, 2020 at 05:05:07PM -0500, John C Klensin wrote: > > > 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. I think this sentiment bears reiterating, so +1. Thank you for putting it to words. > [1] The reasons are mostly unrelated to this discussion but are > due to IESG refusal to enforce naming conventions: When naming Could you remind me of which deviations from draft-(ietf|lastname)-wgname-slug are problematic for your workflow? I don't recall a particular IESG discussion on "let's not enforce naming conventions" (and do recall some discussion about preserving some namespace prefixes), but perhaps my memory needs a jolt to get in gear. Thanks again, Ben > 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." >
