RE: Call for Community Feedback: Retiring IETF FTP Service

[Roman Danyliw <[e-mail]>]

Hi John!

> -----Original Message-----
> From: John C Klensin <[e-mail]>
> Sent: Tuesday, November 24, 2020 5:05 PM
> To: Roman Danyliw <[e-mail]>
> Cc: [e-mail]
> Subject: RE: Call for Community Feedback: Retiring IETF FTP Service
> 
> 
> 
> --On Friday, November 20, 2020 11:31 +0000 Roman Danyliw <[e-mail]>
> 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.  

Respectfully, I disagree. Parties were attributed as supporting or opposing the proposal only if they explicitly said they had a position.  If someone contributed to the conversation or posed a question, I made no assumptions of their positions.  Links to these explicit statement were provided as a short-cut into the specifics of what parties are thinking.

For example, you "+1-ed" a question on wanting details on what it costs to run the FTP service (https://mailarchive.ietf.org/arch/msg/ietf/7ImbzRpyhUmTfgcqb-hya8xU7GU/).  I made no assumptions on whether your support for wanting more details was equivalent to support or opposition of the proposal.

Based on your clarification above, I added a link for your opposition (see: https://github.com/ietf/ftp-retirement-consult-2020/commit/478c004856120501f1a1e6bdb10e28537b6574f0).  Thanks for the correction.

To everyone who has provided input, repeating the text in the summary -- "[a]s this thread consistent of many messages and interleaved ideas, if your position has been missed or misrepresented, please send corrections to the thread on [e-mail] or privately to Roman Danyliw (IESG tool representative)." 

> 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.

Thanks for that clarification.  To be clear on scope, the disposition of the RFC Editor's services are out of scope of this proposal

> 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.   

I struggle to find text in the proposal (https://www.ietf.org/media/documents/Retiring_IETF_FTP_Service.pdf) or the usage analysis (https://docs.google.com/document/d/1JAXspeaMWFl8ML3hSezFSM0VsJsHI4uyDlQ2dHip8jo/edit#) that suggests a position linking morality and specific technologies.

To the question of companies/users who can't user encryption, this was noted by [19] (https://mailarchive.ietf.org/arch/msg/ietf/XFJOyi9a8KsrF4vmBAghb0Zo3mo/), [72] (https://mailarchive.ietf.org/arch/msg/ietf/a0U1ofyDlbxS72MTmDGNY2YBpiI/) and [125] (https://mailarchive.ietf.org/arch/msg/ietf/Da4mZ1cC0pQ8IelsdCFjCBLXyO4/).  It was equally noted that from the data present, there don't appear to be such disadvantaged users per [25] (https://mailarchive.ietf.org/arch/msg/ietf/py_9b486x8x2io6d5dAb3FAgNng/), [122](https://mailarchive.ietf.org/arch/msg/ietf/b8BfvrcpLmvvjkhJ1MW8DUEzmQ8/) and  [137] (https://mailarchive.ietf.org/arch/msg/ietf/7rWVjpu1h3M3mR4OT5NqdTkSrSU/)

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.  

In this case, there are published principles.  At the risk of rehashing messages already on the thread, message #25 (https://mailarchive.ietf.org/arch/msg/ietf/py_9b486x8x2io6d5dAb3FAgNng/) and  #69 (https://mailarchive.ietf.org/arch/msg/ietf/1lnlpXJDDl5ZSA4Xn9x4sQFPlvU/) already point to the IESG statement to maximize encrypted access and IAB issued a Statement on Confidentiality respectively as guiding principles.

> 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).

To repeat again, the disposition of the RFC Editor's services are out of scope of this proposal

To the very specific philosophical point, as noted in message #92 (https://mailarchive.ietf.org/arch/msg/ietf/maUHi4gfaPAH_TfsU6XbqdYYM5Y/) and #122 (https://mailarchive.ietf.org/arch/msg/ietf/b8BfvrcpLmvvjkhJ1MW8DUEzmQ8/), rysnc still provides unencrypted access if COMSEC properties are the driver to use FTP (realizing of course the rsync and FTP are not equivalent, but most of the usage for FTP appears to be syncing file which can be satisfied by FTP as noted by https://docs.google.com/document/d/1JAXspeaMWFl8ML3hSezFSM0VsJsHI4uyDlQ2dHip8jo/edit#)

Roman

> 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."