Roman, Thank you. Sorry for note being more clear. A few other comments below (with a lot elided that does not seem to be worth pursuing further right now)... --On Tuesday, November 24, 2020 23:18 +0000 Roman Danyliw <rdd@xxxxxxxx> wrote: >... > 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. Seems completely reasonable and, again, I'm sorry for not being more clear. So, in the interest of further clarity, my instinct is to be opposed to this because it may lock people out or consume their time in ways that might better be spent on IETF technical standards work. Whether it is worth that tradeoff or not seems to me to depend on two things: whether dropping that service has enough value (or saves enough in costs of various types) to be worth it and whether the ancillary arguments hold water. For me, the actual cost arguments, at least so far, don't (and that is why I asked that question). It seems to me, as several others have suggested, that the big costs are in setting things up initially (done decades ago) and making sure that the scripts that keep moving copies to the right locations aren't screwed up. I obviously haven't looked at the systems and scripts that do that, but many years of experience suggests to me that, if keeping that working requires regular and extensive effort, we have far deeper problems than whether or not an FTP service continue to be offered. And, fwiw, I have far too high an opinion of the various people who have developed and maintained the IETF's scripts and databases over the years to consider that likely. >... >> 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 Yes, and you said earlier that I should not be concerned about HTTP service being cut off in favor of HTTPS-only because that was out of scope. I understand that now and understood it before. Probably I should have said so explicitly just as I should have said explicit "I am opposed to this, in part because I don't think the arguments for do it hold water" in the note about costs you referred to. But, as I suggested earlier, I've taken what I consider to be a lot of abuse in the last several months for posting long messages and, if I try to shorten them, I'm going to sometimes (maybe often) make the mistake of leaving things out. So, to be much more explicit, I am quite aware that neither the RFC Editor services nor a possible move to HTTPS access only are within the scope of _this effort_. However, whether one uses "slippery slope" on some other vocabulary, I am also painfully aware that, if we shut down FTP for I-Ds based on arguments that not enough relevant people are using it, that no morally acceptable person should be using it, or that it violates the IETF's norms about security and encryption, then it is a tiny step to some other effort arguing that the RFC Editor shouldn't be supporting it, using both the (unrefuted) arguments in part of this discussion and the evidence that FTP support was discontinued and no one died. And it would be an equally tiny step to say "HTTP access violates our principles so it should be shut down and we got rid of cleartext access with FTP and discontinuing HTTP should be ok too." I am _not_ suggesting that anyone has an explicit, multi-stage plan for either, only that these things happen and that, if those discussions come up a year or five from now, it is important to have the reasons why we are doing this absolutely clear and to not open those doors and leave them open. >... > I struggle to find text in the proposal > (https://www.ietf.org/media/documents/Retiring_IETF_FTP_Servic > e.pdf) or the usage analysis > (https://docs.google.com/document/d/1JAXspeaMWFl8ML3hSezFSM0Vs > JsHI4uyDlQ2dHip8jo/edit#) that suggests a position linking > morality and specific technologies. See above. I was not referring to anything you had written, only to some of the comments in the discussion that appeared to me rather strongly suggest that no one should be using FTP anyway because it is insecure and violates IETF policies/preferences in that area, that it is an unfortunate artifact of the time before we discovered The One True way with the web and should be abolished, etc. If my referring to those as moral arguments is an inappropriate exaggeration, I apologize, but I had hoped people would get the point. > To the question of companies/users who can't user encryption, > this was noted by [19] [72] and [125] >... > It was equally noted that from the data present, > there don't appear to be such disadvantaged users per [25] > [122] and [137] And, here, again, I'm trying to look ahead. Maybe we are going to dodge the bullet in the US, but there are clear international trends toward restrictions on encryption and/or requirements for law enforcement access, keys deposited with governments, etc. We have deliberately designed many of our protocols to make the latter hard (and I personally think that was exactly right). But suppose some country (to make this a concrete example, say France because they have done it before) bans encryption without explicit government permission/ license). Unless we are going to decide that we are not interested in input from, or access to files by, anyone living in France, we end up in a mad scramble, one that might be used to discredit everything we have done to push for more encryption and that gets us back to where we are today. Instead, I think we are better off if we take the position that these document are free and freely available, and that while, in line with our announced policies, we are making encrypted access available and recommend people use it, we consider it important to be sure those materials who are available to everyone, even in restricted regimes. YMMD. Because that situation has not arisen, yet and in the last decade or so, in France or elsewhere that we know about, the usage statistics are not going to show it. Similarly, I'm not a security expert or watching security issues, but I'm noticed that several enterprises and at least one vendor of enterprise firewalls/ security appliances have concluded that the solution to malware-over-HTTPS is to lie to servers about keys, get everything into cleartext on the firewall, and then pass it through. Depending on one's threat model (which the IETF recommendations have not, IMO, been explicit about), the protection being offered may be marginal to zero and, perhaps, everyone would be better off if the public information were retrieved and transmitted in the clear. However, even if we are fine with that situation, any measurements we make show users within those enterprises accessing the IETF servers via HTTPS. All of the above discussion about security and encryption should be irrelevant. Considering that IETF is already not offering a full and conforming FTP service, if the only thing at issue here is FTP and there is a plausible long-term guarantee of HTTP access as well as HTTPS, I don't see tremendous harm in dropping it. However, I am still concerned enough about the IETF, by its actions, endorsing the notion that, at the applications layer, everyone should be forced to do things that same way that I would prefer to be listed as opposed. >> 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_9b486x8x2io6d5d > Ab3FAgNng/) and #69 > (https://mailarchive.ietf.org/arch/msg/ietf/1lnlpXJDDl5ZSA4Xn9 > x4sQFPlvU/) already point to the IESG statement to maximize > encrypted access and IAB issued a Statement on Confidentiality > respectively as guiding principles. And, at the risk of repeating myself, I read the IAB and IESG statements as encouraging greater availability and user of encryption on the network. I don't see anything in either of them that can reasonably be interpreted as "if you don't agree with us, or if circumstances prevent your using encryption, than you should get off our network or at least not try to participate in the IETF". >... > To repeat again, the disposition of the RFC Editor's services > are out of scope of this proposal Understood but see above. I, again, would argue that this would set a precedent that could easily be misused (and probably would be) in a way that would impact those services. > > To the very specific philosophical point, as noted in message > #92 > (https://mailarchive.ietf.org/arch/msg/ietf/maUHi4gfaPAH_TfsU6 > XbqdYYM5Y/) and #122 > (https://mailarchive.ietf.org/arch/msg/ietf/b8BfvrcpLmvvjkhJ1M > W8DUEzmQ8/), 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/1JAXspeaMWFl8ML3hSezFSM0VsJ > sHI4uyDlQ2dHip8jo/edit#) First of all, to the extent to which the issue is "don't make IETF participants change their tools because the time would be better spent on IETF technical work", "you could replace FTP with foo" (whether 'foo' is rsync or something else) is not really helpful. If it is being used mostly for synchronization, then it would be an interesting (and very inexpensive) experiment to try to call the attention of those users to the fact (or at least our belief) that rsync would probably work better for them and then see if that produces any change in behavior. But, again, from my point of view, our goal should be encouraging use of IETF resources and participation in the IETF, not seeing what barriers we can erect because would-be participants could be doing things in other ways. And, fwiw, when I was still using FTP regularly for retrieving I-Ds, it was not to sync them, it was because the underlying FTP support was present in my favorite text editor, making it very easy to construct keyboard macros that incorporated the relevant pathnames and skeleton. Doing that in the editor is not just because I can but because that is where I typically want the file. Because there is not the same level of support for rsync, doing the same thing would require me to write code in ELL or a peculiar dialect of LISP rather than constructing a keyboard macro, a considerably larger (although obviously still feasible) task. best, john
