Subject: Re: Call for Community Feedback: Retiring IETF FTP Service

From: tom petch <[email-masked]>
Date: Tue, 1 Dec 2020 12:33:27 +0000

On 30/11/2020 17:41, Julian Reschke wrote:
> Am 30.11.2020 um 18:27 schrieb tom petch:
>> ...
>> All the CSS preceding the text; well, that is what I got this morning
>> when prompted by Julian's post but tomorrow, well, tomorrow is another
>> day!
>> ...
>
> On what URL?

Julian

Apologies for a tardy response - I am on European time and so much of 
the discussion is when I am in bed.

A bigger apology.  I used the URL you gave of
https://www.rfc-editor.org/rfc/rfc7230.txt
except that, when I look at the History of my web usage yesterday, I 
omitted the final .txt.  Repeating it with the .txt I get just the text 
and no preceding CSS.  So that was a red herring, omit the .txt and 
'Save as' .txt saves all the CSS first; odd, but I know not to do that 
again. (The logic escapes me but then this is HTTP/HTML whose logic 
often does:-)

The loss of formatting when using HTTP/HTML is still an issue for me; I 
recall it being an issue many years ago but not one I see with ftp://
I access
https://www.ietf.org/ietf-ftp/rfc/rfc5347.txt
(a  URL most of which I took from an e-mail from Roman) and
Save target as
get a message that the download was successful (with .pdf I usually get 
an error message at this point) am invited to open it, do so and have 
lost the formatting, getting just a stream of characters.  I lack a hex 
editor at present (I am seeking to fix that) so do not know what is 
there but suspect it is the long standing issue of terminating lines 
with <CRLF> or something else.

I am sure that given time I will solve most of my problems, except, 
probably, the loss of the original date for an RFC (that date is part of 
my modus operandi).

The ongoing issue is, as others have commented on, I never know when and 
what I am going to encounter next with HTTP/HTML, as with my inability 
to signout the other day, or the Local Authority PC that insists that I 
have to stop what I am working on and look at the latest e-mail to 
arrive.  I see HTTP/HTML as not as stable as I want it to be as the 
basis for work, something I think I see at Enterprises where I work, 
where HTTP/HTML is always used, but for pushing out information and 
getting feedback, not for operational systems.

So thank your for taking an interest.

Tom Petch

> Best regards, Julian
> .

---

From: Julian Reschke <[email-masked]>
Date: Tue, 1 Dec 2020 14:05:26 +0100

> the discussion is when I am in bed.

So am I :-)

> again. (The logic escapes me but then this is HTTP/HTML whose logic

<https://www.rfc-editor.org/rfc/rfc7230> is an HTML resource (which just
happens to use a fixed space font). So you're asking IE to save an HTML
page as text file, and that's what it does in that case.

> get a message that the download was successful (with .pdf I usually get

Plain text published by the RFC Editor does not have CRs in it (just
LFs), so you need to use a text editor that groks this format (Notepad
does this nowadays, and Wordpad has forever).

> lost the formatting, getting just a stream of characters.  I lack a hex

I just did a "save as" in IE with
<https://www.rfc-editor.org/rfc/pdfrfc/rfc7230.txt.pdf> and did not get
an error.

> So thank your for taking an interest.

Of all the issues you reported, the only thing I can reproduce is that
when saving text from the browser, the last modified time is indeed lost.

"curl" will allow you to keep it, for instance with

   curl --remote-time https://www.rfc-editor.org/rfc/rfc7230.txt -o foo.txt

So choose the right tool for the task, and there shouldn't be problem.

Best regards, Julian

---

From: Tim Chown <[email-masked]>
Date: Wed, 2 Dec 2020 13:55:45 +0000

And for what it’s worth, another +1.

Tim 

> On 10 Nov 2020, at 12:38, Stewart Bryant <[email-masked]> wrote:
> 
> +1
> 
> Stewart
> 
>> On 10 Nov 2020, at 11:55, Scott O. Bradner <[email-masked]> wrote:
>> 
>> is there a compelling reason to stop a service that some people are using
>> 
>> the pdf says : "The operational complexity of running this service "
>> 
>> just what complexity is there once the service was set up (years ago)?
>> 
>> i.e., just how much does this service cost to run?
>> 	(seems to me that it is likely that the effort to develop this plan was much more than just letting the service run)
>> 
>> yes, I run one of the scripts that use ftp to access IETF resources and it would be a significant pain to rewrite it
>> since it is complicated script and I do not know how to do some of its functions in other non-ftp ways
>> 
>> I do seriously want to know how much it costs the IETF to run the ftp service
>> 
>> Scott
>> 
>> 
>> 
>>> On Nov 9, 2020, at 9:23 PM, Roman Danyliw <[email-masked]> wrote:
>>> 
>>> Hi!
>>> 
>>> The Internet Engineering Steering Group (IESG) is seeking community input on retiring the IETF FTP service (ftp://ftp.ietf.org, ftp://ops.ietf.org, ftp://ietf.org).  A review of this service has found that FTP appears to serve a very small community and HTTP has become the access mechanism of choice.  Given this shift in community usage, reducing the operational complexity of the overall IETF infrastructure seems to outweigh the very limited community served with FTP.  
>>> 
>>> In reviewing the additional impacts of such a service retirement, the dependencies on FTP have been assessed.  Additionally, it has been confirmed that all information currently reachable through FTP will continue to be available through other services (HTTP, RSYNC, IMAP).
>>> 
>>> In consultation with the Tools team (Robert, Glen, Henrik, Russ, and Alexey), Communications team (Greg), affected SDO liaisons, IAB Chair, and LLC ED, a proposed retirement plan was developed and is available at:
>>> 
>>> https://www.ietf.org/media/documents/Retiring_IETF_FTP_Service.pdf
>>> 
>>> The IESG appreciates any input from the community on this proposal and will consider all input received by December 4, 2020 (to account for the upcoming IETF 109 and holidays).
>>> 
>>> Regards,
>>> Roman
>>> (as the IESG Tools Liaison)
>>> 
>> 
>

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 2 Dec 2020 09:52:31 -0500

On Thu, Nov 26, 2020 at 03:19:24PM -0500, Andrew Sullivan wrote:
> I think this FTP discussion and the above share something, which is a
> presumption that there are things that are just sitting around and that
> don't require any attention.  I think this is false, and I would like
> to suggest that just about everyone in this discussion knows that to
> be the case, but is forgetting it because the costs are externalized.
> This isn't meant to be a criticism, but just to draw to attention an
> important consideration about who decides.

This isn't my first day on the job.  I'm painfully aware of the costs
involved in running multiple (possibly overlapping) services, of
maintaining little-used/rarely-used/emergency-use infrastructure,
and so on, where costs may be measured via money, effort, complexity,
scheduling, and other metrics.  I say "painfully" because I've been
required to do it and I haven't always done it perfectly: hence, pain.

But I rather suspect that the aggregate effort expended in this very
discussion may well exceed that required to run the FTP service for
another decade or two. ;)  And if the ongoing/burst usage of the
service is relatively low -- which seems to be the case -- then surely
the computational resources required are minimal.

---rsk

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 2 Dec 2020 21:42:19 +0000

speaking as someone who does outsourced network / service operations as 
a full-time day job:

All services have a cost of delivery.  The cost is difficult to assess 
and it's usually more than people want it to be, but it is generally 
proportional to several things, including how complex the service is, 
how well-run you want to service to be.  There can also be other things, 
e.g. how large it needs to scale, what uptime you want to guarantee, etc.

Some of the things that might need to be taken into account for an 
itemised cost assessment could include:

- initial planning / design
- initial setup
- Hardware config / management
- Complexity of integration with the rest of the ecosystem
- Software management of service software
- Complexity / integration with the rest of the service ecosystem
- Backups
- DR
- Business overheads (light, wages, hvac, tax, offices, etc)
- Documentation
- Hosting and connectivity
- Monitoring
- Management knowledge communication
- Handling support issues
- Liability (what happens if the wrong data is served, etc)
- TCO of periodic forklift

This list isn't exhaustive, e.g. SLAs, process compliance, security 
management, and so forth. There's an endless of things that might or 
might not be important to either the service delivery provider or the 
consumer.  None of this comes for free because none of this is run on a 
charitable basis.  Nor is it run on a string-and-gum basis.

Even with a cost scoping exercise, where does that stop? E.g. if you're 
talking about a car, do you just include the cost of the petrol, or do 
you also include the annual service costs?  What about depreciation? 
One-off repairs?  Interest on loans? Crashes, insurance and 
consequential losses?  What about the costs of providing the underlying 
infrastructure - roads, bridges and traffic lights?  Environmental 
damage?  And so on.  I.e. reductionism isn't going to end you up with 
any more of an accurate answer for cars than it is for ftp servers, and 
there are more ways of assessing costs than you can shake a stick at.

Nick

---

From: Martin Duke <[email-masked]>
Date: Wed, 2 Dec 2020 18:31:35 -0800

So I'm hearing that the people actually running the FTP service believe it
to be a significant nuisance, and some subset of the community think that
it is obviously trivial. Would it be too much to ask one of the FTP
enthusiasts to volunteer to maintain it, so that those who have tired of it
can move to other things?

I'm sure we can migrate it to a URL that makes it clear it is
volunteer-driven.

On Wed, Nov 11, 2020 at 11:09 PM Loa Andersson <[email-masked]> wrote:

> All,
>
> That was my thought also, if we claim "operational complexity" we should
> maybe try to be explicit.
>
> /Loa
>
> On 10/11/2020 19:55, Scott O. Bradner wrote:
> >       (seems to me that it is likely that the effort to develop this
> plan was much more than just letting the service run)
> >
> > yes, I run one of the scripts that use ftp to access IETF resources and
> it would be a significant pain to rewrite it
> >> The Internet Engineering Steering Group (IESG) is seeking community
> input on retiring the IETF FTP service (ftp://ftp.ietf.org,
> ftp://ops.ietf.org, ftp://ietf.org).  A review of this service has found
> that FTP appears to serve a very small community and HTTP has become the
> access mechanism of choice.  Given this shift in community usage, reducing
> the operational complexity of the overall IETF infrastructure seems to
> outweigh the very limited community served with FTP.
> >>
> >> In reviewing the additional impacts of such a service retirement, the
> dependencies on FTP have been assessed.  Additionally, it has been
> confirmed that all information currently reachable through FTP will
> continue to be available through other services (HTTP, RSYNC, IMAP).
> >>
> >> In consultation with the Tools team (Robert, Glen, Henrik, Russ, and
> Alexey), Communications team (Greg), affected SDO liaisons, IAB Chair, and
> LLC ED, a proposed retirement plan was developed and is available at:
> >>
> >> The IESG appreciates any input from the community on this proposal and
> will consider all input received by December 4, 2020 (to account for the
> upcoming IETF 109 and holidays).
> >>
> >> Regards,
> >> Roman
> --
> Loa Andersson                        email: [email-masked]
> Senior MPLS Expert                          [email-masked]
> Bronze Dragon Consulting             phone: +46 739 81 21 64
>
>

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 Dec 2020 01:21:53 -0500

--On Wednesday, December 2, 2020 18:31 -0800 Martin Duke
<[email-masked]> wrote:

>  So I'm hearing that the people actually running the FTP
> service believe it to be a significant nuisance, and some
> subset of the community think that it is obviously trivial.
> Would it be too much to ask one of the FTP enthusiasts to
> volunteer to maintain it, so that those who have tired of it

Unfortunately, at least as I understood it, the claim/belief was
not [only] about its being a significant nuisance to maintain
but that it was also consuming other resources that the powers
that be didn't want to pay for any more.   Unless the latter has
changed --i.e., that the LLC would be happy to maintain the
service if someone volunteered to maintain the software and
tools -- having such volunteers would be of no help at all.

> I'm sure we can migrate it to a URL that makes it clear it is

There is also the question or whether the IETF tells people this
is an available option or whether it is a little secret among
the relevant volunteer and a few hundred or her closest friends.
If the former, the IETF and/or the IETF Administration LLC take
on some responsibility for keeping it available or providing
appropriate notice before it is shout down.

So, overall, I don't see that suggestion as helpful... much as I
would like to see this discussion end and stop consuming time
and bandwidth.

  john

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 3 Dec 2020 11:44:23 -0500

+1. It is time to move on and adapt.  I agree with Russ on the increased
security offered from HTTPS and the practicality points from both Russ and
Chris.

Best regards,
Kathleen

On Fri, Nov 20, 2020 at 11:39 AM Chris Inacio <[email-masked]> wrote:

> +1.
>
> FTP was great in its day.  I also really liked gopher.  Maybe more than
> the current web.  But let’s be real - that’s just not practical at this
> point, IMHO.  The Internet (at large) has moved on, possible even enabled
> by IETF, we should keep to that reality.
>
> Chris
>
>
> > On Nov 16, 2020, at 5:43 AM, Russ Housley <[email-masked]> wrote:
> >
> > I support turning off the FTP service at ietf.org. The FTP daemon
> places frustrating constraints on the file system structure.  HTTPS offers
> much greater security, and it does not impose constraints on the file
> system structure.
> >
> > Russ
> >

-- 

Best regards,
Kathleen

---

From: Adam Roach <[email-masked]>
Date: Thu, 3 Dec 2020 11:49:00 -0600

> the relevant volunteer and a few hundred or her closest friends.

For what it's worth, I think we're already in the second of these 
scenarios. I went looking for publicly visible information about the FTP 
server on the IETF web site, and cannot find it (aside from a single 
mention that the server *exists* without actually giving its name or 
address). The publicly-facing version of this information appears to 
have been lost at some point, and no one noticed.

/a

---

From: Keith Moore <[email-masked]>
Date: Thu, 3 Dec 2020 12:52:43 -0500

On 12/3/20 12:49 PM, Adam Roach wrote:

> scenarios. I went looking for publicly visible information about the 
> FTP server on the IETF web site, and cannot find it (aside from a 
> single mention that the server *exists* without actually giving its 
> name or address).

In general, the IETF web site is appallingly bad at helping people find 
the information they need, so there's nothing exceptional about the lack 
of FTP server information.

Keith

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 3 Dec 2020 15:17:16 -0500

Lets flip the question round.

I have developed a cryptographic format that is purpose designed to provide
a blockchain / CT like means of signing a series of documents. It could be
used to provide a standards based signature over the IETF document corpus
(something that Russ has already done using CMS technology but couldn't
have done using a standards based hash chain approach at the time because
of the Haber-Stornetta patent.

So what should be the criteria for deploying my new technology on the IETF
site and why should they be any different to insisting on continued support
for the old?

The obvious approach is to consider the costs and the benefits but we also
need to consider the alternatives to an IETF service.

Costs:

How much effort to perform initial installation?
How much effort is required to manage installation when transitioning
service to a new system?
What is the security impact? How much does this cost to monitor?
How often does the system require administrative intervention (e.g. recover
from crashes)?

Benefits:

What is the benefit to the IETF community?
What is the benefit to the IETF corporation?
What is the wider benefit?

Alternatives:

Can this service be provided by anyone else?
Is there a particular benefit to the IETF providing the service over any
other provider?

Now the reason to not deploy the Mesh right now is I haven't finished the
code. But assuming I had, it is a format that is purpose designed to
provide a forensic authentication of data added to a repository over time.
So it is something the IETF can only do for itself. FTP is not.

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 4 Dec 2020 15:18:59 +0000

Hi!

> -----Original Message-----
> From: Russ Housley <[email-masked]>
> Sent: Saturday, November 21, 2020 3:43 PM
> To: IETF <[email-masked]>
> Cc: Roman Danyliw <[email-masked]>
> Subject: Re: TLS access Re: Call for Community Feedback: Retiring IETF FTP
> Service
> 
> 
> 
> > On Nov 20, 2020, at 12:10 PM, Salz, Rich
> <rsalz=[email-masked]> wrote:
> >
> >> Separate question: we were told for the newcomers slides to use
> >> rfc-editor.org for official RFC references.  How do we resolve that difference
> of views?
> >
> >>   I'm not knowledgeable enough to be the authority on this.
> >
> > Fair enough.  Let's chase this down tho and figure out what it should be.
> "There  can be only one" definitive source.
> 
> The definitive source is rfc-editor.org.  The files are copied from there for
> serving by ietf.org.

To contextualize access to this non-authoritative data set via FTP, I've provided another chart to the "12 Days in the life of an IETF FTP server" at https://docs.google.com/document/d/1JAXspeaMWFl8ML3hSezFSM0VsJsHI4uyDlQ2dHip8jo/edit#

Access to RFCs is 27% of all FTP traffic and represents 37% of all unique IP addresses.

This new chart in the "What information are the users requesting?" section provides a distribution of requests and IP address across the top level directories.  A few highlights:
* 64% of all requests are for either an I-D or RFC (or 60% of all unique IP addresses, using no aggregation)
* the next most popular category (28%) is /ietf which contains historic charter and minute information of WGs; most of the usage is syncing the directory
* all other directories constitute < 8% of usage
* multiple top-level directories (4) had only a single IP address access it in the sample period

Regards,
Roman

---

From: Michael Richardson <[email-masked]>
Date: Fri, 04 Dec 2020 13:58:35 -0500

Thanks for the update.

    > This new chart in the "What information are the users requesting?"
    > section provides a distribution of requests and IP address across the
    > top level directories.  A few highlights:
    > * 64% of all requests are for either an I-D or RFC (or 60% of all
    > unique IP addresses, using no aggregation)

So basically a single user loading a single document?

    > * the next most popular category (28%) is /ietf which contains historic
    > charter and minute information of WGs; most of the usage is syncing the
    > directory

And the rest is doing mirroring, probably setup 10 years ago, and still
running.  Do we have any stats from rsync access?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 4 Dec 2020 19:50:03 +0000

Hi Michael!

> From: Michael Richardson <[email-masked]>
> Sent: Friday, December 4, 2020 1:59 PM
> To: Roman Danyliw <[email-masked]>
> Cc: Russ Housley <[email-masked]>; IETF <[email-masked]>
>     > To contextualize access to this non-authoritative data set via FTP, I've
> provided another chart to the "12 Days in the life of an IETF FTP server" at
> https://docs.google.com/document/d/1JAXspeaMWFl8ML3hSezFSM0VsJsHI4uy
> DlQ2dHip8jo/edit#
> 

77 unique IP addresses produced all of the I-D (29 IPs) or RFC (48 IPs) requests.  21 unique IPs requested exactly one I-D or RFC; there were a few that produced 2 requests for the identical file in rapid succession (some kind of client behavior?).  The rest I would primarily characterize as "syncing" or "polling" based on the access patterns.

It was a couple of the other directories (/slides, /review, /iesg, /iana-timezone) that had exactly one IP access each of them.

> And the rest is doing mirroring, probably setup 10 years ago, and still running.
> Do we have any stats from rsync access?

I don't have comparable stats beyond the FTP (thanks Glen) and the I-D/RFC traffic from tools.ietf (thanks Henrik) in that particular window.

Regards,
Roman

---

From: Keith Moore <[email-masked]>
Date: Sat, 5 Dec 2020 01:19:11 -0500

On 12/4/20 2:50 PM, Roman Danyliw wrote:

>   The rest I would primarily characterize as "syncing" or "polling" based on the access patterns.

Consider "searching for text or keywords" as another possible 
explanation for that access pattern.

(in other words, reading every file doesn't mean the client is mirroring 
the collection)

---

From: Keith Moore <[email-masked]>
Date: Sat, 5 Dec 2020 01:31:53 -0500

Again, I find this analysis flawed to the point that it's useless or 
nearly so.

The first rule in reporting stats, at least if you want them to be taken 
seriously, is to describe the methods and results separately, and 
separately from any conclusions.

The sampling period is far too short to be meaningful.   If there were 
only 91 unique users for a whole year, that's very different than only 
91 unique users over 12 days.   But 91 users (if they're  IETF 
participants) would be a significant fraction of active IETF participants.

Relationship between FTP and HTTP traffic volume seems irrelevant.  
Again, traffic volume is not an indicator of importance.   So why keep 
citing it?

The conclusions made e.g. "99% of all FTP traffic.." are almost 
certainly not warranted by the raw data, but the raw data aren't 
reported (not even anonymized, not even in summary form).

Keith

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 7 Dec 2020 00:30:20 +0000

Hi Keith!

> From: ietf <[email-masked]> On Behalf Of Keith Moore
> Sent: Saturday, December 5, 2020 1:32 AM
> To: [email-masked]
> Again, I find this analysis flawed to the point that it's useless or nearly so.
> 
> The first rule in reporting stats, at least if you want them to be taken seriously,
> is to describe the methods and results separately, and separately from any
> conclusions.

I have noted your concern and objection in the working summary.  See https://github.com/ietf/ftp-retirement-consult-2020/commit/3f96335fc213424288eafd212ff925dd809f790b

> The sampling period is far too short to be meaningful.   If there were only 91
> unique users for a whole year, that's very different than only
> Relationship between FTP and HTTP traffic volume seems irrelevant. Again,
> traffic volume is not an indicator of importance.   So why keep citing it?

I keep citing the HTTP numbers because they provide context to the FTP numbers.

I will say upfront that I don't know the entire population size of "active IETF participants".  However, if we say that all 91, or even 140, IP addresses seen in FTP (let's include the search engines) are active IETF users.  I see no reason why not to also count the >500,000 IP addresses that used HTTP as active IETF participants (see Section 2 of the "12 Days in the life ..." charts).  Comparing 140 to >500,000 doesn't seem to align with calling this number a "significant fraction" (as its 0.02%).

Regards,
Roman

> The conclusions made e.g. "99% of all FTP traffic.." are almost certainly not
> warranted by the raw data, but the raw data aren't reported (not even
> anonymized, not even in summary form).
> 
> Keith
>

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 7 Dec 2020 00:35:52 +0000

Hello!

The community feedback period on retiring the FTP service has come to close.  Thank you for all of input in the almost 400 messages across several threads.  The full history can be found in the mail archive (https://mailarchive.ietf.org/arch/msg/ietf/oTleIrHnjuvtEUKjpPXCt4Q31Qw/) and a running summary of key themes, positions and lines of discussion was also made (https://github.com/ietf/ftp-retirement-consult-2020/blob/main/status.md).

IESG will need some time to fully review all of the input, and we will return to the community on the topic in the coming weeks.

Regards,
Roman

> From: Roman Danyliw
> Sent: Friday, November 20, 2020 6:32 AM
> To: [email-masked]' <[email-masked]>
> Subject: RE: Call for Community Feedback: Retiring IETF FTP Service
> 
> Hi!
> 
> We are about half through the feedback period and helpful discussion has
> already occurred.  Thank you for the input.
> 
> To help focus further discussion and to help onboard those that have not
> weighed in yet, a summary of the thread to date can be found at
> https://github.com/ietf/ftp-retirement-consult-2020/blob/main/status.md
> 
> Regards,
> Roman
> 
> > From: Roman Danyliw
> > Sent: Monday, November 9, 2020 9:24 PM
> > To: [email-masked]' <[email-masked]>
> > Subject: Call for Community Feedback: Retiring IETF FTP Service
> >
> > Hi!
> >
> > input on retiring the IETF FTP service (ftp://ftp.ietf.org, ftp://ops.ietf.org,
> ftp://ietf.org).
> > A review of this service has found that FTP appears to serve a very
> > small community and HTTP has become the access mechanism of choice.
> > Given this shift in community usage, reducing the operational
> > complexity of the overall IETF infrastructure seems to outweigh the
> > very limited community served with FTP.
> >
> > Alexey), Communications team (Greg), affected SDO liaisons, IAB Chair,
> > and LLC ED, a proposed retirement plan was developed and is available at:
> >
> > will consider all input received by December 4, 2020 (to account for
> > the upcoming IETF 109 and holidays).
> >
> > Regards,
> > Roman

---

From: Keith Moore <[email-masked]>
Date: Sun, 6 Dec 2020 19:47:36 -0500

> I keep citing the HTTP numbers because they provide context to the FTP numbers.

I don't think they do, because IMO FTP and HTTP provide different 
services and probably for different user communities - FTP more for 
active IETF participants or "expert users" vs. HTTP for the whole world 
of RFC users.

To use an analogy, I wouldn't expect the traffic to the IETF tools pages 
to be of the same order of magnitude as to the HTTP pages serving RFCs 
either.   A significantly lower traffic volume for the tools pages 
wouldn't make the IETF tools pages seem any less useful, wouldn't be 
justification for deprecating them.

> I will say upfront that I don't know the entire population size of "active IETF participants".  However, if we say that all 91, or even 140, IP addresses seen in FTP (let's include the search engines) are active IETF users.

Just to clarify my concern about the sampling period, does 91 users in 
12 days imply only 91 users total, or is the number small because the 
sampling interval is so short?  Would the number of users in a year be 
closer to 91 total or more like 91 * (365/12) (around 2768), or 
somewhere in between?   While I think 91 total active users of the FTP 
site is probably enough to justify continuing to support it, in my mind 
2768 users in a year certainly does.

I assume that the IETF servers exist at least partially, even primarily, 
to facilitate the standards development work of IETF, and the people 
actively doing the work are relatively few.

>    I see no reason why not to also count the >500,000 IP addresses that used HTTP as active IETF participants (see Section 2 of the "12 Days in the life ..." charts).  Comparing 140 to >500,000 doesn't seem to align with calling this number a "significant fraction" (as its 0.02%).

IMO you are comparing dissimilar things because the two aren't 
equivalent services, and the FTP service supports useful operations that 
the HTTP service doesn't.

Keith

---

From: tom petch <[email-masked]>
Date: Wed, 9 Dec 2020 13:00:48 +0000

> Hi!
<snip>

Roman

I have belatedly accessed your Google document and query some of the 
interpretation.

It is unfortunate that it relates to August since I cannot recall what I 
was doing then and that is prime holiday season when not much happens. 
If you had chosen the week in July before the submission window closed 
for IETF108 you might have got much larger figures.

However, I wonder if I have been missed entirely (perhaps along with 
many others).  Being a small business I am behind an ISP-provided NAPT. 
  I could be sharing that NAPT with others.  I suspect that most often I 
get the same IPv4 IP address but perhaps a different port.  I am likely 
sharing the reverse DNS name with others, perhaps hundreds:-)  Thus I 
know that location tracking websites think that I am in Preston, UK, 
whereas in fact I am 50 miles away; IP-derived data can be plain wrong 
so when you conflate on the basis of reverse DNS, you could be missing a 
lot of small users and only counting the Microsoft or Cisco or such like 
and even then you could be missing a number of employees of such an 
organisation with a unique reverse DNS.

I do use the same ADSL modem for FTP for RFC and FTP for I-D (and HTTPS 
access to data-tracker) and will likely download an RFC or two most 
weeks and an I-D or two most working days, three or more days a week but 
I do use a different application for FTP RFC and FTP I-D.  So I am 
multiple download most working days from a UK ISP.  I struggle to see 
that in your data and suspect that you are missing many, perhaps most usage.

Tom Petch

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 11 Dec 2020 11:23:14 +0100

Sharing a little hilarity:

http://www.ams.org/publications/authors/tex/amsfonts

Click on “Download …”
➔
ftp://ftp.ams.org/pub/tex/amsfonts.zip
➔
This site can’t be reached

ftp.ams.org’s server IP address could not be found.

SCNR, apologies for rubbing salt in the wounds.

Grüße, Carsten

---

From: "John Levine" <[email-masked]>
Date: 11 Dec 2020 12:30:59 -0500

>ftp.ams.org’s server IP address could not be found.

I turned off my public FTP server last week.  Nobody noticed.

R's,
John