Subject: Re: FTP Service Discontinuance Under Consideration; Input Requested

From: Eliot Lear <[email-masked]>
Date: Fri, 03 Apr 2015 19:39:47 +0200

Ray,

On 4/3/15 7:31 PM, IETF Administrative Director wrote:
> All;
>
> The Technology Management Committee of the IAOC is considering
> recommending to the IAOC ending support for FTP to retrieve files
> from the IETF servers and would like to hear from the community
> before the IAOC taking its decision. This does not include
> rfc-editor.org.
>
> The use of FTP to retrieve files from the IETF servers has been
> declining steadily.
>
> The files made available with that protocol are also available using
> http and rsync. (See the modules exposed at rsync.ietf.org using
> "rsync rsync.ietf.org::")
>
> The majority of the current FTP traffic appears to be from mirror
> sites that would be better served using rsync.

Thanks for the opportunity to comment.

Honestly I didn't even know that we were offering FTP service for
anything other than RFCs, and quite frankly I see no reason to continue
the service for RFCs either.  FTP is antiquated.  In as much as we are
encouraging everyone to encrypt everything, most FTP clients and servers
lack that support.

Eliot

---

From: John C Klensin <[email-masked]>
Date: Fri, 03 Apr 2015 14:20:03 -0400

--On Friday, April 03, 2015 19:39 +0200 Eliot Lear
<[email-masked]> wrote:

>> recommending to the IAOC ending support for FTP to retrieve
>> files from the IETF servers and would like to hear from the
>> community before the IAOC taking its decision. This does not
>> include rfc-editor.org.
>...
> Honestly I didn't even know that we were offering FTP service
> for anything other than RFCs, and quite frankly I see no
> reason to continue the service for RFCs either.  FTP is
> antiquated.  In as much as we are encouraging everyone to
> encrypt everything, most FTP clients and servers lack that
> support.

Hmm.

First, my experience has been that Internet Drafts and other
files have been moved around enough to require rewriting macros
and functions that use FTP.  That may have been worthwhile for
some mirrors (although I am not sure why) but I more or less
gave up after a couple of rounds of rewrites and started using
HTTP with, IMO, some reduction in productivity, especially since
I-D announcements eliminated links to the drafts themselves
(rather than an "HTMLized version" and a link to a page from
which one can get to the draft).  There are certainly I-Ds I
haven't looked at because of those slow links and hidden
locations, especially when the announcements show up while I've
traveling in or two slow- or expensive-connection locations.

So, while I am unhappy about the reasons, I agree with your
announcement and with Eliot that, for most or all documents
other than the RFCs, the functionality is essentially gone
already except for mirrors that could be better served in other
ways.

The RFCs are a different matter: I'd be surprised if I'm the
only person who tends to fetch RFCs directly into an editor
environment, especially when I'm writing new or updated
documents.  Those fetching operations are controlled by really
simple, and very fast and simple, macros -- the many features of
HTTP just make things more complex, slower, and involve more
bandwidth.

And, as to "encrypt everything" for RFC-like documents, I hope
we continue to be thoughtful about security measures and where
they are needed.  It would be most unfortunate if we reduced the
openness of the network or our processes in the interest of
better protecting documents (or even access to them) that are
supposed to be completely public.

    john

---

From: "John Levine" <[email-masked]>
Date: 3 Apr 2015 18:42:36 -0000

>encouraging everyone to encrypt everything, most FTP clients and servers

Since it's anonymous retrieval of public information, I suppose a bad
guy could do traffic analysis, but if it's mostly mirrors, they'll be
fetching everything so it won't reveal much.

The main problem with turning FTP off is that stuff will mysteriously
stop working.  I wonder if it'd be possible to look at the FTP logs
and see if there are people we recognize, and if so contact them and
ask how hard it would be for them to use rsync instead, to limit the
mysteries.

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 03 Apr 2015 19:48:57 +0100

> fetching everything so it won't reveal much.

That sounds right to me.

> ask how hard it would be for them to use rsync instead, to limit the

I think maybe the thing to do is to turn if off but with a
willingness to turn it back on (perhaps temporarily) if it
turns out to break something badly. I'm fine with whoever
are the correct powers-that-be making those decisions. (But
very glad to see this checked with the community first.)

S.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 04 Apr 2015 07:50:38 +1300

On 04/04/2015 07:20, John C Klensin wrote:
...
> supposed to be completely public.

True. But on the other hand, imagine a person living in a country
with unpleasant laws who wished to obtain a copy of, say, RFC 1984
or RFC 2804 without revealing to the authorities that she is doing
so. So there needs to be provision for secure retrieval.

(That said, I have no use case for continued FTP access.)

   Brian

---

From: John C Klensin <[email-masked]>
Date: Fri, 03 Apr 2015 15:11:11 -0400

--On Saturday, April 04, 2015 07:50 +1300 Brian E Carpenter
<[email-masked]> wrote:

> True. But on the other hand, imagine a person living in a
> country with unpleasant laws who wished to obtain a copy of,
> say, RFC 1984 or RFC 2804 without revealing to the authorities
> that she is doing so. So there needs to be provision for
> secure retrieval.

Sure.  And preferably retrieval without identifying that one is
touching the hypothetically-evil IETF and its web sites at all.  
 
> (That said, I have no use case for continued FTP access.)

Noting that such a person would have even more difficulties if
he or she actually wanted to participate in IETF discussions and
that we don't, e.g., offer secure and untraceable methods for
posting to our mailing lists, let's just avoid making those of
us who don't have those constraints and who are participating
less productive in the interest of serving that hypothetical and
very limited case.

    john

---

From: Michael StJohns <[email-masked]>
Date: Fri, 03 Apr 2015 15:24:39 -0400

At 01:31 PM 4/3/2015, IETF Administrative Director wrote:
>Input received by 20 April will inform the decision.

I still use FTP occasionally for third party transfers (e.g. between two remote machines while controlling the transfer from a third).  I don't use FTP for RFC retrieval like that, but there may be others who do as that functionality isn't in HTTP or RSYNC.

There are also a few programs that use FTP to emulate a file system so you can do drags and drops.  Users may not even realize that its FTP under the hood.

That said - I don't have an objection to removing FTP from the list of retrieval methods.

But I don't think we should do it as Stephen suggests and just turn it off.  Comes under the heading of "conservative in what you send".   Announce it and take a while to see if folks start moving off or object strenuously.

Mike

>Thanks
>Ray

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 3 Apr 2015 14:00:58 -0700

This seems like a reasonable proposal. Both rysnc and common HTTP command line tools (wget and curl) handle "get me only the most recent changes" quite reliably.

--Paul Hoffman

---

From: Joe Touch <[email-masked]>
Date: Fri, 03 Apr 2015 17:09:50 -0700

On 4/3/2015 2:00 PM, Paul Hoffman wrote:
> This seems like a reasonable proposal. Both rysnc and common HTTP
> command line tools (wget and curl) handle "get me only the most recent
> changes" quite reliably.

Yes, but it's also important IMO to allow HTTP access and not require HTTPS.

I.e., the reason for the shift should not be to force use of a secure
connection. Some paths will drop anything they can't inspect, and
there's no reason to force that here for users who don't want it.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Fri, 3 Apr 2015 20:23:57 -0400 (EDT)

> there's no reason to force that here for users who don't want it.

I don't think I agree. And neither does RFC 7258.

If you are on a network that needs to MITM your HTTPS, it should run you
through their SOCKS / PROXY and install the right trust anchors on your
machine.

Paul

---

From: Joe Touch <[email-masked]>
Date: Fri, 03 Apr 2015 17:31:00 -0700

> I don't think I agree. And neither does RFC 7258.

So you'd rather I can't get the file?

That's NOT what that RFC says. The RFC actually has no 2119 language in
it anyway.

> through their SOCKS / PROXY and install the right trust anchors on your

So let's say that "network" is run by your government, and they don't
want to do that. You're OK with denying access?

I don't think that's appropriate. Our documents are not "only for those
who have non-monitored access".

Joe

---

From: Paul Wouters <[email-masked]>
Date: Fri, 3 Apr 2015 20:52:30 -0400 (EDT)

> want to do that. You're OK with denying access?

You realise the irony that a large part of this mess is because of
recently discovered government behaviour? :P

> who have non-monitored access".

I hope we are steadily moving moving towards a network that comes with
build-in privacy. I am not saying that the IETF needs to be the front
runner in that with their documents, although at some point in time
we should do what we preach.

But this has been an argument going back a decade and we won't get
agreement IETF-wide :)

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 04 Apr 2015 02:38:50 +0100

Frankly, I think you have both moved away from any discussion
of FTP access to IETF materials.

There are real issues to be considered about privacy for access
to public information, such as how to do it, when to do it, and
what to do if it fails. Personally, I'd prefer we not try to
decide such questions based on FTP access to RFCs. There are many
more interesting cases in which privacy is more obviously an
issue. And there are many more cases where the probability that
the user understands any of the issues is almost zero. It'd be
IMO foolish to try to draw a supposedly interesting conclusion
from cases where it doesn't matter and it's almost for sure that
the user knows the deal. It's kind of silly that it even came up
to be honest. So the effort devoted to this particular line of
argument is far better spent elsewhere. (And we needn't worry,
the subject will come up in a meaty manner I'm sure;-)

My suggestion is to forget about how 7258 might or might not
relate to the subject line here, and deal more with the subject
line itself. Let's save our energy for arguing about privacy
when accessing public information for discussing situations
where it matters much more and where users know less, both of
which are more typical and more important.

S.

---

From: Joe Touch <[email-masked]>
Date: Fri, 03 Apr 2015 18:12:14 -0700

> recently discovered government behaviour? :P

On one hand, we have governments that want to track the content.

On the other, we have governments that won't allow content they can't track.

(sometimes they put their hands together)

> we should do what we preach.

I don't disagree with "built in" privacy.

I disagree with "forced" privacy and I don't think that any "rough
consensus" document should force that upon any of us (especially one
with zero requirements language).

The key question here is simple:

	- does the RFC Editor have a reason to warrant
	mandatory privacy?

	- should mandatory privacy apply to the whole site,
	or should there be some content it doesn't care is tracked?

IMO, access to I-Ds and RFCs ought to be available even with tracking.

Joe

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 4 Apr 2015 05:07:38 +0000

> On Apr 3, 2015, at 11:50 AM, Brian E Carpenter <[email-masked]> wrote:
> 

S/he might try this:

https://tools.ietf.org/html/rfc1984
https://rfc-editor.org/rfc/rfc1984.txt

---

From: t.p. <[email-masked]>
Date: Sat, 4 Apr 2015 09:02:01 +0100

----- Original Message -----
From: "John Levine" <[email-masked]>
To: <[email-masked]>
Sent: Friday, April 03, 2015 7:42 PM
> ask how hard it would be for them to use rsync instead, to limit the

At least with the Microsoft software that I use, FTP preserves the date
of the file so that I can see at once how old a document is; HTTP
rewrites the date to be today, losing that information.

For I-Ds, not really an issue (but for RFC, that would be a serious
impairment).

Tom Petch

---

From: t.p. <[email-masked]>
Date: Sat, 4 Apr 2015 12:35:47 +0100

----- Original Message -----
From: "Fred Baker (fred)" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>
Cc: "John C Klensin" <[email-masked]>; <[email-masked]>
Sent: Saturday, April 04, 2015 6:07 AM

> https://tools.ietf.org/html/rfc1984

"Page cannot be displayed"

> https://rfc-editor.org/rfc/rfc1984.txt

[timeout]

 http://tools.ietf.org/html/rfc1984

" IAB and IESG Statement on Cryptographic Technology and the Internet"

http://rfc-editor.org/rfc/rfc1984.txt

" IAB and IESG Statement on Cryptographic Technology and the Internet"

Q.E.D.

Tom Petch

---

From: [email-masked]
Date: Sat, 04 Apr 2015 06:12:20 -0700 (PDT)

> IMO, access to I-Ds and RFCs ought to be available even with tracking.

I completely agree with all of this. The IETF has led the way in providing
fully open access to both its standards and standards-in-the-making, and
indeed, there are still plenty of other standards that are difficult
to access.

To me this is one of the IETF's core principles, and I don't think the
"privacy everywhere" priincple comes even close to trumping it.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Sat, 04 Apr 2015 09:43:24 -0400

--On Saturday, April 04, 2015 06:12 -0700
[email-masked] wrote:

> I completely agree with all of this. The IETF has led the way
> in providing fully open access to both its standards and
> standards-in-the-making, and indeed, there are still plenty of
> other standards that are difficult to access.
> 
> To me this is one of the IETF's core principles, and I don't
> think the "privacy everywhere" priincple comes even close to
> trumping it.

+1

That was the point I was trying to make.  Joe and Ned have made
it much better.

   john

---

From: [email-masked]
Date: Sat, 04 Apr 2015 07:51:40 -0700 (PDT)

> very glad to see this checked with the community first.)

I have no real opinion on whether or not the service should go, but assuming we
do decide to turn it off, this sounds like the way to do it.

				Ned

---

From: <[email-masked]>
Date: Sat, 4 Apr 2015 15:49:32 +0000

If privacy is so important to the IETF, why are we all posting to this list using our real names?

Lloyd Wood
http://about.me/lloydwood

can we call the IETF chair "Number One"?
________________________________________
From: ietf <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Sunday, 5 April 2015 12:12:20 AM
To: Joe Touch
Cc: Paul Wouters; [email-masked]
Subject: Re: FTP Service Discontinuance Under Consideration; Input Requested

                                Ned

---

From: Ted Lemon <[email-masked]>
Date: Sat, 4 Apr 2015 13:40:57 -0400

> If privacy is so important to the IETF, why are we all posting to this list using our real names?

We aren't all posting to this list, and we do not enforce a "real names" policy.

---

From: David Farmer <[email-masked]>
Date: Sat, 4 Apr 2015 12:42:27 -0500

This is not a contest, one is not more important than the other, it is a question of dependencies.  People's privacy on the Internet, yes hopefully built into the Internet's protocols, is dependent on a free, open, and accessible standards process.  In the name of privacy, you cannot lock up and  limit access to, what at the same time in the name of privacy must be open and accessible.

However, this is irrelevant to the announcement and request for community comment.  I think it is appropriate to retire support for FTP as announced.  There are newer more appropriate options supported and in dominant use, http and rsync.

Thanks.

> On Apr 4, 2015, at 10:49, <[email-masked]> <[email-masked]> wrote:
> 
> 

-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

---

From: Paul Wouters <[email-masked]>
Date: Sat, 4 Apr 2015 14:11:37 -0400 (EDT)

> However, this is irrelevant to the announcement and request for community comment.  I think it is appropriate to retire support for FTP as announced.  There are newer more appropriate options suppo…

Btw, I agree. ftp is still at times problematic with active ports and
firewall and it offers nothing that http cannot offer.

Paul

---

From: "John Levine" <[email-masked]>
Date: 4 Apr 2015 19:39:53 -0000

>For I-Ds, not really an issue (but for RFC, that would be a serious

You might enyoy switching to rsync, which both preserves the date, and
is a lot faster since it knows how to skip the ones you already have.

The usual version for Windwowsseems to be cwrsync:
https://www.itefix.net/cwrsync

R's,
John

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 4 Apr 2015 14:32:24 -0700

> rewrites the date to be today, losing that information.

Please.  In both cases, preserving the date is a client feature that
uses whatever date is provided by either protocol. See "curl -R" or "wget -N".

....Roy

---

From: John C Klensin <[email-masked]>
Date: Sat, 04 Apr 2015 18:14:10 -0400

> https://www.itefix.net/cwrsync

FWIW, I've had good success of late with acrosync
(https://acrosync.com/), which runs natively under Windows and
does not require the Cygwin environment.  There are apparently
Mac and mobile/iOS versions as well.  Of course, if one is
running a Cygwin environment over Windows for other purposes, it
becomes a matter of taste, and Acrosync is not free.

   john

---

From: John C Klensin <[email-masked]>
Date: Sat, 04 Apr 2015 18:26:17 -0400

> firewall and it offers nothing that http cannot offer.

You mean like the well-known HTTP "TYPE" and "STRU" verbs?  

It is likely that neither is an issue for IETF materials as long
as they stay plain text.. at least with the possible exception
of those who complain bitterly about difficulties in displaying
I-Ds and RFC that use CRLF newline conventions, but it would
probably be good to avoid sweeping generalizations like "nothing
that http cannot offer".

    john

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 5 Apr 2015 10:03:11 -0400

> If privacy is so important to the IETF, why are we all posting to this list using our real names?

How do you know if we do or not?

---

From: Hector Santos <[email-masked]>
Date: Sun, 05 Apr 2015 10:27:58 -0400

+1

You know, I will venture that most people who still have FTP as part 
of their business or whatever, are not paying attention to this noise 
of "getting rid of it."   It would be a disservice if the IETF did 
something that would begin changing things unbeknowst to them.

 From a business standpoint, I have quite a major 
enterprises/corporations, companies of all sizes who still use FTP for 
their mission critical operations and it will one of those things that 
"no one" is going to get rid of or replace with anything else.  I have 
two product lines that include FTP components is a big part of a 
virtual file/data I/O framework.  Legacy or not, it is pretty solid, 
especially for advanced FTP systems that may include "intelligent" 
(programmable) FTP clients.

As far the IETF "getting rid" of their own FTP server/service/access 
to files... well, for many years I have used my 1997 iFTP (intelligent 
FTP) console client to get the RFC documents.  It has DOS-like 
Move/Copy commands and options to save the file date (it might be 
default).  I use it all the time, on the fly, while I am reading a 
text doc via my console editor. When I see a reference to RFCXXXX of 
interest, I spawn a "GETRFC RFCxxxx.txt" job, etc.     I suppose I can 
change it to a web-based fetch/get, but the date will be lost too, 
which is OK, download date is fine for chronological timing of data.

Overall,  I suppose there are IETF FTP log files to show the level of 
activity. I am sure it would not be much but there is still activity. 
  We are making a big decision here, pretty quickly, and I hope that 
it doesn't get down to a situation where there are many folks who 
don't hang around here much, if ever, who are still using it in some 
fashion, but the IETF powers doesn't think much of that and shuts it 
down.   There are other tools, but that generally isn't the issue -- 
its changing something that people have been doing for a long time and 
don't need to change.  Those making the decision are most likely not 
using FTP anymore.  They would not feel the impact and it would be 
very easy to say that a "few people" still using it doesn't justify 
keeping it around.

Personally, I don't see why it needs to go. What is it hurting?  Is 
their an IETF cost savings here?  Shut down a PC?

My two pennies on the matter.  I would like to see the FTP server kept 
around.

-- 
HLS

---

From: Randy Bush <[email-masked]>
Date: Sun, 05 Apr 2015 08:23:57 -0700

though it is highly unusual on this list, the discussion seems to have
drifted far afield from the question.  what would dropping ftp access
break in a way for which there is no viable alternative?

for me, nothing; but i have been an rsync addict for some years.

    #!/bin/sh

    RSY="/usr/bin/rsync -vaHx --delete"

    $RSY rfc-editor.org::rfcs-text-only $HOME/rfcs
    $RSY ietf.org::internet-drafts $HOME/ids
    # old + new, though i really want only old
    $RSY rsync.tools.ietf.org::tools.id $HOME/ids.old
    # for xml2rfc
    $RSY rsync.tools.ietf.org::xml2rfc.bibxml/bibxml $HOME/refs/rfc
    $RSY rsync.tools.ietf.org::xml2rfc.bibxml/bibxml3 $HOME/refs/id

randy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 5 Apr 2015 11:38:40 -0400

On Sun, Apr 5, 2015 at 10:27 AM, Hector Santos <[email-masked]> wrote:

> You know, I will venture that most people who still have FTP as part of
> their business or whatever, are not paying attention to this noise of
> "getting rid of it."   It would be a disservice if the IETF did something
> that would begin changing things unbeknowst to them.

They probably aren't aware that they have FTP at all.

Which is exactly the sort of feature that turns into a security hole.

---

From: John C Klensin <[email-masked]>
Date: Sun, 05 Apr 2015 14:37:20 -0400

--On Sunday, April 05, 2015 11:38 -0400 Phillip Hallam-Baker
<[email-masked]> wrote:

>> You know, I will venture that most people who still have FTP
>> as part of their business or whatever, are not paying
>> attention to this noise of "getting rid of it."   It would be
>> a disservice if the IETF did something that would begin
>> changing things unbeknowst to them.
> 

It seems to me that the topic was "should the IETF turn off its
FTP Server for I-Ds and other non-RFC documents".  Some of us
have said "why not as long as you don't mess up the RFCs".
Others have said "possible problems for IETF participant users
(or lurkers whom we might hope to turn into participants) whom
we might rather have spending energy on participation rather
than tuning their systems.   In all cases, the documents
involved are completely public, there are more secure and
private methods available for those who want them, and no one is
being forced to use FTP.  

So your threat model for the cases covered by the question is?
Now, of course, if you were just offering free advice to Hector
about how he should run his business or advise his customers,
that is anything matter.

    john

p.s. I think the IETF has done the Internet community a
disservice by not examining FTP carefully and updating it in
several areas, including making it more security-, shared
server, and IPv6-friendly.  I also think that the model of
separate and asynchronous control and data connections could be
used to good advantage (even including improvements to security
and privacy if carefully thought out) in a number of
applications including situations involving controlled streaming
large amounts of data.  And, fwiw, the number of times I've been
saved from various bits of nastiness by running an email client
that won't follow links or execute scripts from HTML messages
are such that I wince every time someone tells me how secure the
web --especially a web that is secured by poorly-regulated
certificates-- is relation to assorted other protocols.  But
none of that has anything to do with the question that Ray and
the IAOC asked.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 06 Apr 2015 10:29:02 +0200

Hi,

> which are more typical and more important.

It seems that we're conflating two issues: privacy and protection
against pervasive surveillance.  What we have discussed in the past, and
in fact it was part of what Bruce presented in Vancouver, was that in
order to mitigate a pervasive surveillance attack, *all *information –
not just that which we might consider sensitive – should be encrypted. 
This is especially the case when multiple services run on the same
infrastructure.

Going further, the IAB has said that communications should be
encrypted.[1]  If we as a community wish others to encrypt their
traffic, we should of course do what we can to encrypt our own.  In the
alternative, let's have a deeper exploration of encryption and
confidentiality and the tradeoffs so that more specific advice can be
given to the broader community that we ourselves can follow.

Eliot
[1]
https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Apr 2015 15:19:59 +0100

On 06/04/15 09:29, Eliot Lear wrote:
> against pervasive surveillance.  

That was not my point. Mine was that we're conflating the
question asked (about FTP) with privacy issues in a really
non-productive manner. Debate about how and whether and why
to encrypt IETF materials would be far better done considering
all materials, and not a corner case like FTP.

Start a separate discussion for that if you think it's timely,
but one cannot base any sensible general conclusions on the FTP
question. Personally I don't think it's likely to be so useful
to have that debate now, since we had most of it during the last
call for 7258 and afaics most points and positions are just being
repeated here again. OTOH, maybe we'd come up with some good
ideas that'd help so it could be worth trying again, but if so,
please let's do that in a general way.

S.

PS: One idea; mirror all IETF public stuff in clear below some
other domain name (notprivate.ietf.org say;-) and migrate all our
other services to encrypted as we go.

> What we have discussed in the past, and
> order to mitigate a pervasive surveillance attack, *all *information â€“
> not just that which we might consider sensitive â€“ should be encrypted.

---

From: [email-masked]
Date: Mon, 06 Apr 2015 07:36:27 -0700 (PDT)

> This is especially the case when multiple services run on the same

Maybe Stephen is conflating things, but I'm not, and I don't think most other
people on this thread are.

And I was aware of Phil Zimmerman's  postcards versus letters line of reasoning
long before Bruce reiterated it in Vancouver.

My point was, and is, that there are competing interests here. (Or, if you like
the way Bruce puts things, "Security is always a tradeoff.") And it's my
position that in this case the need for people - including those who for one
reason or another don't have access to ubquituous security - to be able to
access the information is vastly more important than protection pervasive
surveillance, or privacy, or always using envelopes, or whatever you want to
call it.

Again, this isn't because I don't understand the concern you're raising. I
understand the concern quite well. I just don't think it wins out in this case.

> given to the broader community that we ourselves can follow.

Doing what we can != forcing things onto people that limit access. This is very
weak tea indeed.

				Ned

---

From: manning bill <[email-masked]>
Date: Mon, 6 Apr 2015 08:16:54 -0700

On the other hand, if the IAB/IESG is hell-bent on encrypting everything (eating their own dogfood) then perhaps
we should not stand in the way.   I am sure that other, open, fora will emerge to take the place of the IETF.

/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: manning bill <[email-masked]>
Date: Sat, 4 Apr 2015 12:55:02 -0700

Has FTP stopped working?  Is it time to deprecate FTP as an Internet Protocol?
Is it so costly to run an FTP service that it is cost prohibitive?

A core, perhaps the core of the IETF value has been in its open, freely available standards,
available over a wide variety of transport options. Indeed this is a valuable crosscheck against
tampering.  Too many copies exist.

Arguably some methods are better than others, those value propositions change over time.

The recent zeal for “security” seems, to these jaded eyes, to be reactionary at best.

"We cannot sprinkle magic security pixie dust over what you have built. It cannot be secured at any price. 
We have to get you to change the way you do security because the way you've been doing it was asking for trouble.” 

There is no good reason to shut this down.  

/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: IETF Administrative Director <[email-masked]>
Date: Fri, 03 Apr 2015 10:31:22 -0700

All;

Thanks

Ray

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 6 Apr 2015 15:25:44 +0000

> On Apr 4, 2015, at 1:02 AM, t.p. <[email-masked]> wrote:
> 

rsync preserves the date.

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 06 Apr 2015 11:47:33 -0400

> Input received by 20 April will inform the decision.

It seems to me that FTP should be maintained as much out of tradition as 
for any other reason.

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

---

From: Michael StJohns <[email-masked]>
Date: Mon, 06 Apr 2015 12:14:19 -0400

>The use of FTP to retrieve files from the IETF servers has been

Hi Ray - 

What is the cost of leaving FTP service in place?  I would expect that the cost was more in setting up FTP in the first place (e.g. adding it to template emails, configuring the servers) than any real day to day cost, but I could be wrong.

What is the cost of removing it?  (e.g. besides simply shutting off the servers, what else has to be done, who has to do it and what will it cost?).

Is there an impact on the IETF budget either way short term?  Long term?

Thanks - Mike

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Apr 2015 18:12:20 +0100

> people on this thread are.

Actually, I think you and others are, as per my previous post. If you
want to debate privacy issues I think you ought start another thread
on that. This one is about FTP where we mostly seem to agree that
turning it off carefully might be right. I'd also note that those who
prefer that the FTP service not be turned off may be being drowned out
by the unstructured privacy side-show.

My point is only that if we want to debate the appropriate mechanisms
to put in place to protect the privacy of access to public IETF
information, then let's not do that based on the FTP corner case, but
by considering the general question.

And regardless of what those who don't read the words written might
think or imply, I have not argued here or ever for requiring all
accesses to IETF information to be encrypted. But the pattern of
seeing exaggerated claims as to what the "other" side is saying is
one that we also saw in the 7258 last call. I just think repeating
those canards again is pointless.

S.

---

From: [email-masked]
Date: Mon, 06 Apr 2015 10:45:49 -0700 (PDT)

> Actually, I think you and others are, as per my previous post.

Nonsense. The post I originally responded to was specific on the topic of
driving things towards encryption everywhere. And since discontinuance of FTP
as an access mechanism can be seen in furtherance of that goal, it's quite
clear there's substantial overlap.

> If you want to debate privacy issues I think you ought start another thread
> on that.

If I thought that was the right thing to do I would have done it.

> This one is about FTP where we mostly seem to agree that
> turning it off carefully might be right.

I never said that. What I did say is that I presently have no opinion on the
matter. And that's because I do not have sufficient data to evaluate the cost
and benefits of phasing out the service.

> I'd also note that those who

> by considering the general question.

And I quite simply disagree with this approach. I think FTP provides an
interesting test case and context under which to consider the more
general question.

> accesses to IETF information to be encrypted.

I never said you had.

> But the pattern of

You might want to reread what you wrote here and think for a minute about just
how dismissive and condesending it sounds to someone who was on the "other"
side of that debate.

				Ned

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Apr 2015 19:22:53 +0100

> interesting test case and context under which to consider the more

Really? I honestly don't get why FTP is at all "interesting" from
the privacy of access POV. Can you explain?

In my head, how to appropriately setup privacy friendly defaults for
http is much more interesting (and by "appropriate" I do include maybe
keeping some form of cleartext access, perhaps no longer as default,
but that'd have to be figured out).

> how dismissive and condesending it sounds to someone who was on the "other"

I guess it might. If so, sorry. But actually I was including those on
my "side" of the argument too - so far I've only seen repeat  arguments
here from all perspectives. But maybe I'm missing something specific to
FTP and your answer to the question above will help,

Cheers,
S.

---

From: [email-masked]
Date: Mon, 06 Apr 2015 11:41:46 -0700 (PDT)

> the privacy of access POV. Can you explain?

It's interesting precisely because it's one of the services we use to provide
access to our content and it's one that is intrisicly hostile to privacy.

Even more interesting is how its presence cuts both ways: As long as we have FTP
access, we cannot claim to have secure-only access (which makes some people
happy and others unhappy). But at the same time this can be used as an argument
justifying tightening up or even eliminating non-secure access via other
protocols.

> but that'd have to be figured out).

Having spent not-inconsiderable time on implementing scripts for performing
automatic operations on various web site content, my assessment is that this
general area is a complete mess that includes conspicuous shortcomings in
protocols, best practice recommendations, implementations, libraries,
distributions, and deployments. As a bonus, it even drags in certificate
validation, revokation, and expiration issues.

Of course this doesn't mean that the IETF has to deal with the entire mess as
part of its web site policies. But just to provide an example of how deep even
the IETF's part of the rabbit hole goes: I use a stylesheet that sucks in the
RFC index in XML from the RFC Editor via http (not https), and uses it to
correctly present the statuses of various RFCs in our generated documentation.

Now suppose the RFC Editor were to switch to https-only access. Or suppose we
were to extend this to handle references to Interent Drafts. Whatever. The
issues this very simple application would face include:

(1) Does the application software even include https support as an option?
(2) Does the packaged version we're using have that support compiled in? If
    not, are we able to rebuild it or find an alternative?
(3) Does the change create issues for proxies or proxy configuration?
(4) Are there SSL/TLS compatibility issues?
(5) What happens if the IETF screws up their certificate handling? Can we
    turn off cerificate validation?

And this is a very straightforward case. Things get even messier if you're
writing applications that access web data using libraries in PHP, Perl, Python,
etc. If you think all of this stuff just works seamlessly and effortlessly, you
need get out more.

I note in passing that I have on a couple of occasions found FTP to actually be
the better alternative to HTTP for this sort of thing. (But admittedly never
when proxies are involved.) And so we come full circle.

One way to look at all this is that the IETF and friends have for better or
worse create a lot of what people have come to regard as public, stable
identifiers for accessing various resources. We mess with those at our peril.
Perhaps including those that begin with "ftp:".

				Ned

---

From: heasley <[email-masked]>
Date: Mon, 6 Apr 2015 20:25:18 +0000

> access to our content and it's one that is intrisicly hostile to privacy.

you, the proverbial you - as the user, are free to choose a different
service - others are provided.  i dont care if whomever may know that I
downloaded some rfc.  others may.  find less interest in forcing your
religion^Wchoice upon potential users and more in delivering choice and
content.

> justifying tightening up or even eliminating non-secure access via other

for most users, it does not require secure access.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 06 Apr 2015 16:27:28 -0400

>>>>> "Ned" == ietf  <ned> writes:

    >> >> My point is only that if we want to debate the appropriate
    >> mechanisms >> to put in place to protect the privacy of access to
    >> public IETF >> information, then let's not do that based on the
    >> FTP corner case, but >> by considering the general question.
    >> >
    >> > And I quite simply disagree with this approach. I think FTP
    >> provides an > interesting test case and context under which to
    >> consider the more > general question.

    >> the privacy of access POV. Can you explain?

    Ned> It's interesting precisely because it's one of the services we
    Ned> use to provide access to our content and it's one that is
    Ned> intrisicly hostile to privacy.

So, I find this flawed for two reasons:

* ftp has multiple security layers including GSS-API and TLS.  I'm
  certainly aware of servers and clients that implement this.

so, we absolutely could have secure ftp.
This is even more true if you include sftp.

* Rsync, which we seem to be favoring over ftp has the same security
  properties as ftp.  That is, while there are secure channels over
  which you run rsync, the most common deployments of anonymous rsync
  are insecure in exactly the same way as ftp and I suspect have similar
  client deployment issues: secure rsync is available but for anonymous
  access secure rsync is a bit harder to set up.

Note that authenticated rsync is an entirely different situation; there
security is expected.

So, to me it sounds like we're replacing one cleartext technology with
another.
I am failing to see the pervasive monitoring implications for this
transition.

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 06 Apr 2015 16:50:00 -0400

>>> interesting test case and context under which to consider the more

Somehow, privacy + publicly accessible documents seems like a corner 
case all of its own.  Obviously, we're not talking about keeping the 
document itself secure, and ftp supports anonymous access.

Plus, there's SFTP and FTPS if we really want secure access coupled with 
FTP.

So what, exactly is the privacy consideration here?

Miles Fidelman

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Mon, 06 Apr 2015 18:29:54 -0300

Having a service online that no-one uses becomes a liability in terms of
security, even it it´s one of those things that 'just works' without
anyone even looking at it.

Don't say you haven't seen things like servers with multi-year uptimes
and whose sysadmin no one knows, I won't believe you :-)

So yes, I agree with the position that FTP support should be phased out.

Cheers!

-Carlos

---

From: Ted Hardie <[email-masked]>
Date: Mon, 6 Apr 2015 14:48:50 -0700

On Mon, Apr 6, 2015 at 1:50 PM, Miles Fidelman <[email-masked]>
wrote:

> Somehow, privacy + publicly accessible documents seems like a corner case
> all of its own.  Obviously, we're not talking about keeping the document
> itself secure, and ftp supports anonymous access.
>

In general, the privacy implications of revealing access to publicly
accessible documents​ can be very significant.  There's a lot you can
determine about a subject with just their access to publicly accessible
documents like news articles reviewed, blogs visited, etc.  Under the
current threat model, this information can be determined by correlating
observations taken at many points in the network topology, rather than by
targeted observation.

Please be careful about making broad generalizations on this topic based on
the smaller question of  "FTP access to RFCs".  It may be a very poor
stand-in for the general threat.

regards,

Ted

---

From: [email-masked]
Date: Mon, 06 Apr 2015 14:30:36 -0700 (PDT)

>   certainly aware of servers and clients that implement this.

Do the servers the IETF has deployed at present support it? AFAIK they
do not. And if they don't, it's only relevant if there's a proposal to
move in the direction of using it.

> This is even more true if you include sftp.

Why would we? It's a completely different protocol.

>   access secure rsync is a bit harder to set up.

I'm skeptical the security properties are the same, but let's assume for the
moment they are. That doesn't mean the operational characteristics are the
same. Is rsync commonly used by individuals as a means of fetching specific
documents? Is rsync commonly used by applications to access web data?

AFAIK the answer to both those questions is "no".

> So, to me it sounds like we're replacing one cleartext technology with

Whereas it sounds to me like we're eliminating one cleartext technology and
not replacing it with anything. And that's a significant change to the
landscape.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Mon, 06 Apr 2015 18:11:47 -0400

--On Monday, April 06, 2015 19:22 +0100 Stephen Farrell
<[email-masked]> wrote:

>> provides an interesting test case and context under which to
>> consider the more general question.
> 
> Really? I honestly don't get why FTP is at all "interesting"
> from the privacy of access POV. Can you explain?

I don't know what Ned's answer to that is, but I addressed it in
my earlier note on the subject.  

Observing again that what I'm about to say is very nearly
irrelevant to the question of whether IETF should eliminate a
particular FTP service...

Unless we have reached the point that the only way that we can
think about privacy is in terms of simple end to end connections
and encrypted tunnels (and I don't think we have), then FTP's
model of separate (and potentially asynchronous) command and
data connections, the ability to select data ports from either
end, and the possibility of third-party transfers would seem to
pose some interesting security and privacy opportunities as well
as challenges.

To the extent that our privacy concerns extend to not wanting to
leak information from the relationship between a single client
and a single server, forcing both connection channels into the
same pipe (however encrypted) casts off several opportunities.
I'm not sure whether they are worth exploiting, but not
examining them and discarding or deprecating FTP on the grounds
that it is an ancient protocol doesn't seem like good
engineering to me.

    john

---

From: Joe Touch <[email-masked]>
Date: Mon, 06 Apr 2015 16:33:41 -0700

IMO, the IETF should support as many protocols as possible. The IETF
site represents the Internet to the world, and just as the IETF itself
"let's a thousand flowers bloom", our site should support as many
protocols as are economically available.

I certainly appreciate the desire to do all of the following:

	- omit deprecated protocols
		(e.g., NETBLT)

	- avoid security vulnerabilities
		(e.g., RCP)

	- encourage efficient protocols
		(e.g., RSYNC for bulk coordination)

	- encourage best-practices
		(e.g., privacy preservation)

Only the first two of these involves disabling services. All other
"behavior engineering" should be accomplished through education (e.g.,
informational web pages explaining the pros and cons of different methods).

However, we should always try to support as many access methods as
economically possible and I see no good reason to disable this service
at this time.

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 6 Apr 2015 18:18:00 -0700 (PDT)

I frequently use FTP to retrieve the mailing list archves.  I am 
unable to divine how to use HTTP to retreive the mail archive files 
at ftp://ftp.ietf.org/ietf-mail-archive/ (meaning the ones in mbox 
format).  If there is a way to do so I would be happy to do so using 
wget.  I should note in passing that there are numerous links to 
ftp://ftp.ietf.org/ietf-mail-archive/ and its subfolders on the IETF 
web site; if the FTP service is discontinued those will need to be 
fixed.

//cmh

---

From: Larry Masinter <[email-masked]>
Date: Tue, 7 Apr 2015 03:35:14 +0000

these sound like good reasons to keep ftp service.

What was the motivation for raising this? Surely the cost is low.
There’s been a lot of (to-be-expected) discussion time if there
isn’t really a problem, while making the change causes some.

Larry
—
http://larry.masinter.net

---

From: Eliot Lear <[email-masked]>
Date: Tue, 07 Apr 2015 07:59:08 +0200

Hi,

Sam's right.  We should do better than simply replacing one insecure
service with another.

Eliot

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 7 Apr 2015 08:20:26 +0000

> The use of FTP to retrieve files from the IETF servers has been

Could you share the access numbers so we can have an idea of what they are and at what rate they have been declining? (Maybe also contrast them to the HTTP numbers for comparison.)

Thanks,
Lars

---

From: Randy Bush <[email-masked]>
Date: Tue, 07 Apr 2015 17:52:50 +0900

> Has FTP stopped working?

no.  neither has uucp or the post.

if god had meant us to ride in planes she would not have given us
trains.

i maintain an ftp server.  it is a pita.  i also maintain uucp service.
i recommend neither.  but i have very good reasons to run them.  i am
still not getting the very good reason for the secretariat to continue
to run ftp.

randy

---

From: Ray Pelletier <[email-masked]>
Date: Tue, 7 Apr 2015 05:56:58 -0400

Michael,

> On Apr 6, 2015, at 12:14 PM, Michael StJohns <[email-masked]> wrote:
> 

There is no cost to turning it off.

There is an incremental savings in maintenance and support burden,
and complexity.

The FTP server we are using (proftpd) places restrictions on how we
store files in the file sytem that are much more constraining than
the http and rsync daemons. Essentially, the files to be served must
be stored in a single tree (as hardlinks - symlinks won't work).
This is impeding work as we evolve. In particular, it affects how we
separate services to take advantage of cloud architectures.  Other
servers have different limits, but still place significant
constraints on what we can do. Since the information is already
available through other mechanisms (particularly rsync), the folks
studying the problem recommended discontinuing the service, rather
than investing in finding the least onerous deamon and reconfiguring
to it.

Ray

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Apr 2015 07:52:51 -0400

> still not getting the very good reason for the secretariat to continue

Yup.  I killed off ftp on my servers about four or five years ago because the code was too old and brittle to feel trustworthy, and I didn't need it.   The idea that there is no cost to continuing to run a service that is already working fails to take into account the issue of stale code with few friendly eyes upon it.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 07 Apr 2015 08:48:55 -0400

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> Hi, Sam's right.  We should do better than simply replacing
    Eliot> one insecure service with another.

Hi.
I was quite frustrated reading this message and would like to be heard
differently.
I was arguing that removing ftp from the IETF does not seem to be about
privacy and does not seem to change the privacy scape one way or the
other.
I did not take a position on whether we should work more to discourage
cleartext access to our documents.

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Apr 2015 09:17:22 -0400

--On Tuesday, April 07, 2015 05:56 -0400 Ray Pelletier
<[email-masked]> wrote:

>...
> Since the information is already
> available through other mechanisms (particularly rsync), the
> folks studying the problem recommended discontinuing the
> service, rather than investing in finding the least onerous
> deamon and reconfiguring to it.

Ray,

This is the sort of statement that has made the discussion so
confusing with so many irrelevant side-branches.

So, putting HTTP aside for a moment given the above statement,
let's try a really quick test of the "rsync as a substitute for
FTP" hypothesis, including some of the assertions that have been
made on-list and considering only the IETF I-D situation and not
actual or hypothetical non-IETF uses.:

(1) Rsync, in native form, is more secure and/or private than
FTP.  Both are, at base, cleartext transfer protocols that
expose origins and destinations.   One can argue for privacy by
overwhelming an attacker by noise rather than fetching
individual files that might be sensitive, but one can do that
with either protocol (and whether it would work depends on the
attackers and their attitudes and resources).   So, no.

(2) Rsync is more secure and/or private than FTP when run over
assorted encryption tunnel (or equivalent) technology.  Such
technologies are available for both.  The IETF isn't advertising
(and probably not supporting) any of them.   So, not an issue
either.

(3) Rsync is an appropriate client-side operational substitute
for FTP.  For people maintaining complete mirrors and possibly
mirrors of all of the drafts associated with a particular WG
(i.e., with draft-ietf-WGNAME-* names), probably so if only
because it is good at not transferring files that are already
present locally (although, because we maintain version numbers,
it isn't hard to set some FTP clients up to not transfer files
that are present locally -- the additional checks rsync
maintains for file changes are not needed).  For someone who is
trying to fetch a single file with a known name, e.g., within an
editor, FTP is _much_ easier to set up and use in most
environments.

(4) Ready availability: FTP wins hands-down here because clients
are built-in to all major operating systems.  For others,
availability of rsync varies, but I note that installation of a
client on Windows requires either installation of a Unix/Linux
environment (a potentially large attack surface is installed by
people who don't understand it and don't pay any attention to
it) or an inexpensive, but not free or FOSS, client.  Either may
run into trouble with enterprise rules about what can be
installed on organizational machines, so, while FTP clients are
generally available, rsync clients may not be available at all.

(5) The IETF should be using protocols standardized by the IETF,
its predecessors or at least the elusive "recognized standards
bodies".  FTP is RFC 959, STD9 with updates) and the URI scheme
was part of the base URI definition spec [RFC1738]. And now...
Rsync has never been considered or documented in the IETF.
There is a _provisional_ URI scheme registration [RFC5781], but
it doesn't contain a normative reference to the protocol itself
or even a stable informative reference.

(6) Operational convenience on the server side: Your FTP server
has rigid idea about tree structure and doesn't accommodate soft
links.  So you either need to find a better server or you need
to create and maintain a compatible shadow tree (perhaps with
rsync :-)).  FWIW, if you don't maintain at least the appearance
of a stable file structure configuration, rsync clients will
either need to be continually maintained or won't work well
either.

Scorecard:
 (1) Security and privacy: No difference
 (2) Security and privacy 2: No difference
 (3)  Client-side operational alternatives: Rsync is
	probably better for complete mirrors, ftp for fetching
	individual files.
 (4) Client availability: FTP, hands down.
 (5) Dogfood consumption: FTP.  rsync isn't even a
	candidate
(6) Server-side operational convenience.   

So, again considering FTP and rsync only, as your note suggests
is appropriate, this is a tradeoff between open and convenient
accessibility to our files and "incremental savings in
maintenance and support burden,
and complexity".   I suggest that those savings would have to be
fairly high to justify a risk of increasing unnecessary burdens
on participants and consequent decreased IETF openness or
participation.

    john

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Apr 2015 14:26:30 +0100

Hiya,

> justifying tightening up or even eliminating non-secure access via other

So I'm with Sam on this one, having read and thought a bit about
the above, I just don't think this is an interesting case.

> Perhaps including those that begin with "ftp:".

I fully agree that identifier stability is a good thing and one to
not break without good reason.

On tooling - I do think that has improved a lot over the last 4-5
years, and if you think it hasn't you need to get out more:-)
But, yes, "--no-check-certificate" and similar are still far too
commonly needed in general, though hopefully not with the IETF
or RFC editor sites. (I've not played about, but I've also not
noticed an IETF/RFC editor cert expiry glitch for a couple of
years, and I used see 'em now and then before.) And I have some
hope that the acme work [1] we're likely to charter might help
there too, but I'd not blame someone for being more skeptical
given our previous failures in terms of making security things
work well and easily for admins.

So I'd agree that we're not now at a stage where we could credibly
ask to turn off cleartext access to all IETF materials even if we
all agreed we wanted that. (Which we clearly do not.) However, I
do think we ought be trying to migrate towards the defaults being
more privacy friendly and I also do think that we can make real
progress in that respect.

Lastly, there are a few interesting questions to consider if/when
we get to the point where we could possibly operate in some kind
of ciphertext only mode. It's not the same thing at all, but I
like the example of the mozilla download server that has to keep
loads of old/crap crypto options [1] so that it can update a FF
that still uses the old/crap stuff. That I think is a much more
interesting corner-case than FTP access and I bet if/when someone
really gets to properly work on the issue of privacy for access
to public IETF materials, then they will discover other equally
interesting things.

S.

[1]
https://www.ssllabs.com/ssltest/analyze.html?d=download.mozilla.org&s=63.245.217.36

[1] https://www.ietf.org/mailman/listinfo/acme

---

From: Dave Crocker <[email-masked]>
Date: Tue, 07 Apr 2015 08:07:49 -0700

...
> There is no cost to turning it off.

There might be no cost to IETF ops, but there is cost to whomever is
still using the service.

There is also an indirect cost in the IETF's knowledge of its protocols.
 As others have noted, we should be eating our own dog food.  Knowing
how to run each protocol and especially how to run protocols as a
mixture, certainly should be an IETF goal.

> than investing in finding the least onerous deamon and reconfiguring

The above should have been in the original announcement/request, along
with concrete details about current usage, as others have requested.

Further, the above could represent extremely significant operational
insight into the details of a multi-protocol service environment.  It
should be thoroughly documented and considered for BCP.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Warren Kumari <[email-masked]>
Date: Tue, 7 Apr 2015 15:10:13 -0400

> mixture, certainly should be an IETF goal.

Known by whom? Glen? Matt? The other AMS folk?

This sounds like motherhood and apple pie -- "We, the IETF, should
know how to run each protocol and especially how to run protocols as a
mixture. And we should floss daily and always call our granny on her
birthday..."

But, before this thread, how many people here even knew we were
running proftpd? How many people on this list are operationally
involved in running the ietf.org mail / dns / ftp / rsync / web / etc?
Who has root on these boxes?
Quick, name the box that mailman runs on. What version of apache run
www.ietf.org?[0]

I've been trying to stay out of this thread, but now that I've started
commenting...
Perhaps we should also consider the human time cost of this whole
discussion -- so far there have been 65+ emails on this topic - each
of these have taken a non-insignificant amount of time to write, and
many many people have spent time reading them. Payscale.com claims the
median pay for a Snr Network Engineer in the US is $91,226 per year,
or ~$45 per hour[1] - how much has this whole conversation cost
us?![2]

W
[0]: Yup, this is a trick question - but I'm guessing a fair number of
people don't know why...
[1]: This was the quickest / easiest number to find - I'm betting most
people on the list earn significantly more than that...
[2]: I'm choosing to a: make the issue worse by bringing this up,
which will no doubt prolong the thread....and b: I refuse to let
people use the same argument when I start talking about something that
I happen to find interesting or entertaining. Like hypocrisy... or the
writings of Jerome K Jerome... or cats...  or the changing
distribution of colors in paintings over time (
http://www.washingtonpost.com/blogs/wonkblog/wp/2015/04/06/the-colors-of-94526-paintings-since-1800-charted/?tid=sm_fb
).

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Joe Touch <[email-masked]>
Date: Tue, 07 Apr 2015 12:43:47 -0700

> be stored in a single tree (as hardlinks - symlinks won't work).

http://www.proftpd.org/docs/howto/Chroot.html

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 7 Apr 2015 13:12:18 -0700 (PDT)

> There is no cost to turning it off.

The must be SOME cost associated with fixing the links 
to FTP URLs on the IETF web site.  Surely the intent is 
not simply to turn off the service and leave broken links 
such as ftp://ftp.ietf.org/ietf-mail-archive/ietf in 
http://www.ietf.org/list/discussion.html or 
ftp://ftp.ietf.org/ietf-mail-archive/wgchairs in 
http://www.ietf.org/wg/chairs-page.html (among others).

//cmh

---

From: Dave Crocker <[email-masked]>
Date: Tue, 07 Apr 2015 14:19:27 -0700

On 4/7/2015 12:10 PM, Warren Kumari wrote:
>>>> What is the cost of removing it? 
>> ...
...
> mixture. And we should floss daily and always call our granny on her

(The freedom to publicly speak so condescendingly and dismissively of
others' views and suggestions remains a true hallmark of the IETF, as
does the anticipated reaction against my noting the rudeness... Thank
you for that.  It's curious that we object more to the noting of
rudeness than to its generation.)

Had you chosen to solicit clarification, I'd have observed that while
AMS does indeed have the primary hands-on, others in the IETF also deal
with such configuration and monitoring experience, starting with the
IAOC and propagating out to others.

That is, operations problems get reported up the chain, beyond AMS.

And the more ops wrinkles are shared with the community -- such as is
happening now -- the more the community learns from that experience.
That is the reason I said that Ray should have supplied more information
in the original query.

And, of course, many of us are /users/ of these mechanism, which imparts
some other experiences.

> running proftpd?

How is that, or the rest of the questions you ask in that paragraph,
relevant?

d/

---

From: Warren Kumari <[email-masked]>
Date: Tue, 7 Apr 2015 17:24:14 -0400

On Tue, Apr 7, 2015 at 3:23 PM, manning bill <[email-masked]> wrote:
> You are right.   Lets just turn of FTP (an IETF standard) and run rsync (not an IETF standard)…

Oh, come /on/ Bill -- that's not what I said, and I'm sure you know
it; I expressed no preference for either keeping or discontinuing
FTP[0].

> And while your at it, please deprecate FTP as a legacy, insecure protocol.
> Nobody else beside the AMS folks know or care about a busted implementation of an IETF  standard after all...

Hey, that's also not what I said. Having AMS run a service for the
IETF != IETF participants knowing how to run each protocol and
especially how to run protocols as a mixture.

W

[0]: I actually happen to think we should keep it, unless the cost to
run it is too high. And that knowing the cost (which only entered the
conversation quite late in the game) is too high.

>
> /bill
> PO Box 12317
> Marina del Rey, CA 90295
> 310.322.8102
>
> On 7April2015Tuesday, at 12:10, Warren Kumari <[email-masked]> wrote:
>

---

From: Warren Kumari <[email-masked]>
Date: Tue, 7 Apr 2015 17:37:14 -0400

> rudeness than to its generation.)

I apologize. I hadn't intended the tone to come out the way it did.

I'm often frustrated by how far from operations IETF participants have
strayed, and how dismissive of the views of operators much of the IETF
has become (which is why I helped man the IETF Helpdesk at NANOG,
asked  Chris Grundermann to present at IEPG / OpsAWG
(http://www.iepg.org/2015-03-22-ietf92/IETF-HelpDesk-Update_IETF92.pdf),
the Synergy list (
http://snozzages.com/cgi-bin/mailman/listinfo/synergy), etc).

My frustration leaked out, but it wasn't (intended to be) directed at
you - it was more general, undirected frustration...

> That is the reason I said that Ray should have supplied more information

Yup, I fully agree -- we've been having long discussions on whether or
not to buy a loaf of bread - with no idea of how much the bread costs.

> How is that, or the rest of the questions you ask in that paragraph,

I guess it's not -- it was more of my frustration leaking out...

W

---

From: Warren Kumari <[email-masked]>
Date: Tue, 7 Apr 2015 17:42:25 -0400

[ Top post, replying to my own mail ]

I suspect that I should just apologize again and then stay out of this
conversation.

Me being frustrated and grumpy doesn't benefit anyone.
Apologies to Dave and Bill for my pissyness.

W

---

From: Dave Crocker <[email-masked]>
Date: Tue, 07 Apr 2015 17:53:58 -0700

> strayed, and how dismissive of the views of operators much of the IETF

Warren,

Thank you for the rapid response and its content.  I'll in turn
apologize for choosing you to single out; there's some separate recent
history of rudeness -- IMO far worse than what you indulged in -- on a
different list going without accountability.

But in this case, it's worth noting that, now that you've clarified your
point, it seems an entirely relevant one to me.  Casting it in my own
terms:

     We should be paying attention to our own operations, since it moves
things from abstractions to immediate reality.

The wgs I'm around don't dismiss ops issues; mostly I'd say we ignore
them.  They don't get raised enough to have a track record of being
dismissed.

Besides the question of professionalism, one of the other damages of our
permitting casual roughness in postings is that we wind up missing
relevant issues to consider.

d/

---

From: Michael StJohns <[email-masked]>
Date: Tue, 07 Apr 2015 21:00:35 -0400

Hi Ray - 

Thanks for the response.  See a few comments below.

>There is no cost to turning it off.

As someone else noted, there are a number of ftp:// links scattered throughout the IETF database.  There will be a cost to go through and re-write the templates or even re-do documents.  Probably not a great amount, but those costs will exist.

>than investing in finding the least onerous deamon and reconfiguring

That makes a reasonable amount of sense.  Sort of.   I think elsewhere you stated that the traffic towards FTP is decreasing and we're not talking about adding new types of data to the set so maybe leaving this as a legacy system with no improvements planned for a couple more years might make sense.

I don't actually have any strong preferences one way or the other - except that I'd prefer a measured and long phase out rather than an abrupt turn off if that's where we end up going.

Later, Mike

---

From: Larry Masinter <[email-masked]>
Date: Wed, 8 Apr 2015 03:47:25 +0000

>than investing in finding the least onerous deamon and reconfiguring

Surely you could leave a FTP server whose copies of the files
are just pulled out of the cloud server and put the right proftpd form,
and now you can continue to offer legacy ftp access for the cases
where there are old ftp: URLs. 

Then you can reconfigure your CDN multi-homed redundant cloud
services as much as you want, and not risk making more IETF
URLs uncool because you don’t think URL stability is important
enough.

I don’t see how doing this would “impede work” or affect how
you plan to separate services (you know, by separating the
ftp server) or place any significant constraints on what you
can do (except please don’t break http: URLs either).

Larry
—

---

From: Larry Masinter <[email-masked]>
Date: Wed, 8 Apr 2015 04:02:35 +0000

>and not risk making more IETF

Some background: http://www.w3.org/Provider/Style/URI.html 
“Cool URIs don’t change”.

So I propose that the IAOC take as an operational requirement, not to be broken without explicit community review, that .ietf.org URLs never change in the sense they never go 404, never reused for a different purpose.

W3C has struggled with this policy but mainly has succeeded, and I think it’s an important topic that would also determine this single instance of turning off resolution for for ftp://ietf.org URLs.

Larry
—

---

From: manning bill <[email-masked]>
Date: Tue, 7 Apr 2015 12:23:12 -0700

You are right.   Lets just turn of FTP (an IETF standard) and run rsync (not an IETF standard)… And while your at it, please deprecate FTP as a legacy, insecure protocol.
Nobody else beside the AMS folks know or care about a busted implementation of an IETF  standard after all...

/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: "John Levine" <[email-masked]>
Date: 8 Apr 2015 16:15:29 -0000

It looks to me like we have a fairly straightforward tradeoff here.

The problem is actually that the IETF is using an FTP server that has
a dubious security anti-feature (no symlinks ever) that causes
operational issues.  This is a real problem.

One approach is to turn off FTP.  This has costs to the IETF, find all
of the ftp: URLs in the web site and other online materials (e.g.,
auto-generated e-mail and stuff you can get by FTP or rsync), identify
other ways to access the material, and change the links.  It also has
costs to anyone using FTP who will at least have to change what they
do and possibly find and install new software, e.g., Windows rsync.

The other possibility is to make it someone's job to fix the FTP
server.  There is lots of free FTP server software -- I see about a
dozen of them in the FreeBSD ports collection.  I've used a few and
found that they're generally not hard to configure, and symlinks are
no problem (use chroot to limit accidental leakage.)  Most provide RFC
4217 TLS support which makes FTP roughly as secure as https if your
client supports it.  In this case, the ftp: links keep working, and
assuming reasonable file layout and use of symlinks on the server, it
should be possible to keep existing URLs and paths valid indefinitely.

So it seems to me this is really a question about money.  Is it worth
whatever the cost would be to upgrade and document the FTP service so
it doesn't get in the way of other operations?  I dunno, sounds like
a job for the IAOC.

R's,
John

PS: I have no sympathy for arguments that we should force people to
use encrypted protocols.  Can we please give our users the benefit of
the doubt that they are able to understand their own security
tradeoffs?

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Apr 2015 13:17:18 +1200

> web site; if the FTP service is discontinued those will need to be 

Also, what will be done about the RFCs that contain direct references to
ftp sources; just in the ones hanging around on my laptop I found these:

rfc2418.txt:         located at ftp://ftp.ietf.org/ietf-mail-archive.  For
rfc3160.txt:   ftp://ftp.ietf.org/ietf-mail-archive/.  If you don't find the list
rfc3160.txt:      ftp://ftp.ietf.org/ietf/1id-guidelines.txt
rfc3356.txt:      ftp://ftp.ietf.org/rfc/rfc-index.txt
rfc3356.txt:      ftp://ftp.ietf.org/internet-drafts/1id-abstracts.txt
rfc4677.txt:   at ftp://ftp.ietf.org/ietf-mail-archive/ or they are in a web-based

Not quite zero cost, since we never change RFC text.

BTW there is mention in the SOW for the IETF website revamp of a directory
/ietf-ftp/. However, there is no mention in the SOW of any URLs like
ftp://ftp.ietf.org/* needing to be preserved, and that seems to be a bug in
the SOW. At the least, it seems that the question of the FTP service needs
to considered as part and parcel of the website revamp, not as if it was
a stand-alone issue, which it clearly isn't. We, for some value of "we",
should have spotted that more than a year ago.

   Brian

---

From: Larry Masinter <[email-masked]>
Date: Thu, 9 Apr 2015 17:19:09 +0000

The technical requirements for the ftp service
are different from the other ietf.org protocol 
service requirements, though.

The service requirements are minimal — ftp is only for legacy, 
anonymous, read-only access to mainly write-once data (never updated 
after creation).  Traffic and load should continue to decrease.
Scalability isn’t a requirement. 

There is no need to move to different ftp server or 
reconfigure to deal with a different directory structure,
continue to run a single instance ftp server which
serves data from it’s own chroot copies.

Maybe that was the thinking behind the SoW allusion to the
ftp directories.

Larry
—

---

From: "John Levine" <[email-masked]>
Date: 9 Apr 2015 19:28:10 -0000

>serves data from it’s own chroot copies.

The problem appears to be that they want to set up the FTP server so
its directories or maybe files are symlinked to files in other
directories arranged in other ways.  There are new files available for
FTP every day since it's one of the ways to retrieve RFCs and IDs.

I have to say that no symlinks at all strikes me as the kind of design
you get from security amateurs ("someone might use this useful feature
wrong, so we won't let anyone use it.")  There are perfectly good FTP
servers without that problem, which would involve a one time switching
cost that I doubt would be very great.

If we are going to continue to support FTP, it would be reasonable to
use a server that can do FTP over TLS, since it that is something
actually defined in RFCs and implemented in clients.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Thu, 09 Apr 2015 15:42:43 -0400

IMO, it would be a tremendous disservice to the community to discontinue 
support for FTP.   Even if the vast majority of traffic is from mirrors, 
those mirrors are still presumably being used.

HTTP (without extensions) is not a good alternative because it does not 
reliably facilitate mirroring.   rsync is not a standard protocol and is 
somewhat specific to UNIX-like systems.

Keith

---

From: Hector Santos <[email-masked]>
Date: Thu, 09 Apr 2015 16:16:41 -0400

+1

On 4/9/2015 3:42 PM, Keith Moore wrote:
> IMO, it would be a tremendous disservice to the community to
> discontinue support for FTP.   Even if the vast majority of traffic is
> from mirrors, those mirrors are still presumably being used.
>
> HTTP (without extensions) is not a good alternative because it does
> not reliably facilitate mirroring.   rsync is not a standard protocol
> and is somewhat specific to UNIX-like systems.
>
> Keith

-- 
HLS

---

From: David Morris <[email-masked]>
Date: Thu, 9 Apr 2015 13:20:27 -0700 (PDT)

My concern has been mentioned in more comprehensive responses, but I think
as a concern it has been lost from the discussion.

Since FTP has been offered as an access method for IETF documents since
almost the beginning of time there exist many many documents in private
repositories which include FTP references for retrieval of related
material.

It would be irresponsible to break a long-time commitment to the stability
of these references. And it would make the organization look incompetent.
I can imagine that there are situations where access to specific documents
by explicit reference would traverse a firewall that wouldn't allow the
generic searches needed to locate the alternative access method.

If the FTP server product which refuses to follow SYMLINKs must be used
for some operational reason, creating a clone of the tree full of SYMLINKs
with fully resolved file copies isn't rocket science. rsync for example
will perform that function with the proper flags.

- Dave Morris

---

From: Doug Royer <[email-masked]>
Date: Thu, 09 Apr 2015 16:13:55 -0600

On 04/09/2015 01:28 PM, John Levine wrote (in part):
> actually defined in RFCs and implemented in clients. R's, John 

Why would anyone care if public documents are transfered encrypted?

When this tread started, I switched to rsync in case FTP went away. I 
had no issues.
rsync is not secure. You can run it through TLS, but again - why?

-- 

Doug Royer - (http://K7DMR.us / http://DougRoyer.US)
[email-masked]
714-989-6135

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Apr 2015 11:53:37 +1200

On 10/04/2015 10:13, Doug Royer wrote:
>> If we are going to continue to support FTP, it would be reasonable to use a server that can do FTP over TLS, since it that is
>> something actually defined in RFCs and implemented in clients. R's, John 
> 
> When this tread started, I switched to rsync in case FTP went away. I had no issues.

If you don't want your government to know that you're taking an unhealthy
interest in Avian Carriers, you might prefer to fetch the RFCs over an
encrypted connection.

    Brian

---

From: Dave Crocker <[email-masked]>
Date: Thu, 09 Apr 2015 16:55:22 -0700

> interest in Avian Carriers, you might prefer to fetch the RFCs over an

And indeed, interoperable bird flew is dangerous.

d/

---

From: Larry Masinter <[email-masked]>
Date: Fri, 10 Apr 2015 04:14:43 +0000

Use the Force:

proftpd has many features and the ftp.ietf.org server turns on many of them. If you look at http://www.proftpd.org/features.html it’s likely many are turned on and used. Switching to something else

I suggest looking for volunteers:

(a) get some volunteers to replicate the current ftp.ietf.org service configuration on  chroot whose content isn’t a shared file system with the http / rsync servers, but rather it’s own copies populated by rsync or wget plus some scripting to copy/move/link things into place.
(b) to host the results of (a), monitor/manage.

Outsourcing ftp to some (monitored) volunteers is very different from discontinuing. 

A hackathon project could get pretty far.  Anyone using ftp.ietf.org is motivated to help or test.

Larry
—

---

From: [email-masked]
Date: Fri, 10 Apr 2015 06:31:15 -0700 (PDT)

> generic searches needed to locate the alternative access method.

I have to say I find this argument extremely compelling.

> will perform that function with the proper flags.

Exactly what I thought when I first heard of the issue.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Fri, 10 Apr 2015 10:39:41 -0400

As David says, this pair of observations have been made before
but may have gotten lost in longer messages.    +1 -- I really
think that stability issue is the bottom line.

    john

--On Friday, April 10, 2015 06:31 -0700
[email-masked] wrote:

>> It would be irresponsible to break a long-time commitment to
>> the stability of these references. And it would make the
>> organization look incompetent. I can imagine that there are
>> situations where access to specific documents by explicit
>> reference would traverse a firewall that wouldn't allow the
>> If the FTP server product which refuses to follow SYMLINKs
>> must be used for some operational reason, creating a clone of
>> the tree full of SYMLINKs with fully resolved file copies
>> isn't rocket science. rsync for example will perform that
>> function with the proper flags.
>

---

From: Tim Bray <[email-masked]>
Date: Sat, 11 Apr 2015 10:29:00 -0700

The same why-we-don’t-need-privacy-in-this-case arguments keep coming up
over and over whenever the p-word rears its head.  Sufficiently so that I
was motivated to post an I-D addressing them one-by one:
http://tools.ietf.org/html/draft-bray-privacy-choices-01 - which has
received a bit of interest over in perpass.

>From which I quote:

This document attempts to establish the following:

1. Whether or not information is considered "public" is not a good
criterion for choosing whether or not to deploy privacy technologies for
its users.
2. Privacy choices are difficult and context-dependent, so it's
inappropriate to ask users to make them.
3. Privacy techologies offer benefits to users of data services even when
those technologies are imperfect.
4. Cost should not be a significant factor while considering the deployment
of privacy technologies.

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: David Farmer <[email-masked]>
Date: Sat, 11 Apr 2015 15:13:07 -0500

> On Apr 11, 2015, at 12:29, Tim Bray <[email-masked]> wrote:
> 
> The same why-we-don’t-need-privacy-in-this-case arguments keep coming up over and over whenever the p-word rears its head.  Sufficiently so that I was motivated to post an I-D addressing them one-by one: http://tools.ietf.org/html/draft-bray-privacy-choices-01 - which has received a bit of interest over in perpass.
> 
> From which I quote:
> 
> 1. Whether or not information is considered "public" is not a good criterion for choosing whether or not to deploy privacy technologies for its users.
> 2. Privacy choices are difficult and context-dependent, so it's inappropriate to ask users to make them.
> 3. Privacy techologies offer benefits to users of data services even when those technologies are imperfect.
> 4. Cost should not be a significant factor while considering the deployment of privacy technologies.

Tim,

I find it ironic that in a document titled Privacy Choices, you seem to conclude that users should have privacy forced upon them, and that they are not equipped to make any choices for themselves.  I actually agree with much of your thesis, even that opt-in is not an appropriate mode for privacy even for Public Information in most situations.  However, you seem to deliberately ignore another obvious possible mode for privacy that would still allow users a choice, opt-out.

Additionally, while you make it clear privacy is important, which I agree it is very important.  However, you do not seem recognize that privacy is not universally more important than every other consideration.  For me as an individual other considerations might be more important, at least in some situations. I'll raise just one example here, what about accessibility, in an ideal would no one should have to trade privacy for there basic right to access information in a form that they can consume it.  However, in the real world these kinds of trade-offs unfortunately are forced on individuals.  You think society ignores privacy, take a look at the world from the view of a person with disabilities, and you will see how much society can really ignore an issue.

So, while privacy is very important, please make room for the idea that it is not always the most important issue, at least in every situation or for every individual.  I think if you gave serious consideration to opt-out privacy model at least in some situations, I could possibly support a document along these lines.  In so many ways we don't live is a one size fits all world, even for something as important as privacy.

Thanks.

> 
> -- 
> - Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray)

---

From: [email-masked]
Date: Sat, 11 Apr 2015 20:30:54 -0700 (PDT)

> over and over whenever the p-word rears its head.

Except the arguments aren't always the same. And there are plenty of cases
where there's broad agreement in favor of "the p-word" when it has been brought
up.

> Sufficiently so that I

> 4. Cost should not be a significant factor while considering the deployment

I have to say I fail to see the relevance of any of this. Your document talks
about objections to the deployment of privacy technology. To the best of my
knowledge the deployment of privacy technology is not at issue; indeed, several
people have argued for additional privacy options in access to IETF
documents.

				Ned

---

From: Michael StJohns <[email-masked]>
Date: Sun, 12 Apr 2015 01:01:49 -0400

I'm detecting that a consensus might have been reached on this topic to wit:

Removal of the FTP service should probably not go forward at this time.  The primary reason for retention of FTP is due to the desire to maintain the stability of the various ftp:// references embedded throughout the web sites and document series. 

There are other less widely held/expressed reasons for retaining the service, but none of those appear to outweigh the general goal of simplifying the service infrastructure.

There are also other less widely held/expressed reasons for eliminating the service past those stated in the original request for input, but none of them appear to trump the reference stability issue.

Is the above a fair summary of the main point and conclusions?

Mike

---

From: Tim Bray <[email-masked]>
Date: Sat, 11 Apr 2015 22:38:49 -0700

I think that’s fair.

On Sat, Apr 11, 2015 at 10:01 PM, Michael StJohns <[email-masked]>
wrote:

> Removal of the FTP service should probably not go forward at this time.
> The primary reason for retention of FTP is due to the desire to maintain
> the stability of the various ftp:// references embedded throughout the
> web sites and document series.
>
> There are other less widely held/expressed reasons for retaining the
> service, but none of those appear to outweigh the general goal of
> simplifying the service infrastructure.
>
> There are also other less widely held/expressed reasons for eliminating
> the service past those stated in the original request for input, but none
> of them appear to trump the reference stability issue.
>
>

---

From: [email-masked]
Date: Sun, 12 Apr 2015 11:56:34 +0000

> Is the above a fair summary of the main point and conclusions?

I think it is. While it wasn't formally  an ietf consensus call, and earlier discussion seemed more ok with turning it off, later discussion did convince me that that folks seem to want to keep the ftp option.

S.