RE: Call for Community Feedback: Retiring IETF FTP Service

[John C Klensin <[e-mail]>]

Roman,

Thanks.  Inline below.

--On Thursday, November 26, 2020 14:19 +0000 Roman Danyliw
<[e-mail]> wrote:

>...

>> I didn't know about that and, at least for me, that
>> completely changes the equation.  If there is at least one
>> IETF (or IETF LLC)-supported site that is kept synchronized
>> with the IETF I-D collection and offers FTP, I don't see any
>> strong reason why there needs to be access to the IETF
>> repository on the IETF site. Even for those who need to
>> change scripts, changing one site and path for another
>> (either in human memory or in a
>> script) should not be a big deal and, IIR, IETF has moved
>> things around often enough that most FTP users have had to do
>> that once or twice already.
 
> Since we talked exchanged notes on being clear on positions
> (see:
> https://mailarchive.ietf.org/arch/msg/ietf/GXzI5CRCVLhfKzFR4s5
> BwKmjhio/), am I correct in interpreting that you have moved
> from "opposed" to "no objection contingent on continued
> operations of an alternative ftp source such as
> ftp://ftp.rfc-editor.org"?

"only weak objections contingent..." would be a tad better, but
let me comment on a few things below and then explain the
difference.

>> On the other hand, if the LLC has to support, or fund AMS to
>> support, FTP access to a repository on the RFC Editor
>> site/path, it seems that the case that there are significant
>> marginal costs for maintaining FTP access to the IETF
>> repository just got a little more dubious.
> 
> I'm speaking for the IESG, so I (we) have no purview over
> contract.  With that caveat and being completely on the
> outside, I will repeat what was mentioned earlier that
> operational complexity get reduced with fewer services to run.
> It also reduced attack surface (perhaps one was a little
> behind in updates or had a misconfiguration).

Understood.  However, whatever niceties we might have about the
boundaries among decisions made by the IESG, decisions made by
whomever or whatever makes decisions for the RFC Editor
Function, and decisions/contracts managed by the IETF LLC, those
distinctions are fairly invisible from a distance.  That is
important for two reasons.  First, if this is really just an
operational matter, even one of operational complexity, then it
should not be the IESG's problem at all -- the LLC should be
discussing it as an operational matter and consulting the
community.   No, I don't think starting over would be at all
helpful but if you (and presumably the rest of the IESG are
"completely on the outside", then I'm not sure why you
(severally) have started this discussion.   Second, your
statement takes us into the uncomfortable territory of plausible
deniability.  Suppose the IETF drops the FTP service because
almost no one is using it (an argument made several times in
this discussion) and because it adds operational complexity and
increases security risks.  Then (especially in the absence of an
RSE or successor function with authority) the LLC wakes up some
morning in the near future and says "The IETF has concluded,
after an extensive community discussion, that an FTP service is
unnecessary, unused, adds operational complexity, and increases
risks.  Certainly the same arguments apply to the RFC Editor's
FTP service(s), so let's tell AMS to shut it down."   Absolutely
nothing would prevent them from doing that and, if we are really
treating these things as complete separate entities which are
"completely on the outside" with respect to each other, then "no
objection contingent..." turns back into a strong objection
unless whoever or whatever makes the decision for the IETF
repository (I'm presuming the IESG is taking on that authority)
makes a firm commitment that, if the RFC Editor FTP
functionality is shut down and not replaced by some other FTP
availability of I-Ds (and RFCs if they are involved) under the
general IETF-RFC Editor-IETF LLC-ISOC umbrella, the IETF service
will be immediately turned back on.

Put into a sentence you can put in the summary, I have no
objection to the IETF dropping its FTP service if there is a
firm commitment that those documents and and resources will
continue to be available from some site within the general IETF
family.  If that assurance cannot be given, then I am back onto
the strong objection list.

In addition, I don't know if this is worth belaboring, but a
number of the arguments that have been made, particularly those
that imply that FTP service should be shut down because people
who want to use it are, e.g., just horribly backward and/or
should join the current century, seem to be to be spurious
and/or insulting.  I would hope they would not be included in
any future summary  of why discontinuing FTP service or, better,
explicitly disclaimed.  For example and because of my concerns
about actions others (including the LLC and/or RFC Editor
Function) might decide to take based on an IETF/IESG decision,
it seems to me to be very important that "our" reasons for
whatever decisions we made be very clear and that the implied
insults of those arguments should have no part of them.

    best,
     john