RE: Call for Community Feedback: Retiring IETF FTP Service

John C Klensin <john-ietf@jck.com> Thu, 26 November 2020 17:25 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A577B3A152A for <ietf@ietfa.amsl.com>; Thu, 26 Nov 2020 09:25:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8SNPquvHcnN for <ietf@ietfa.amsl.com>; Thu, 26 Nov 2020 09:25:58 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA02F3A1527 for <ietf@ietf.org>; Thu, 26 Nov 2020 09:25:57 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1kiL1m-0006ki-Fa; Thu, 26 Nov 2020 12:25:54 -0500
Date: Thu, 26 Nov 2020 12:25:48 -0500
From: John C Klensin <john-ietf@jck.com>
To: Roman Danyliw <rdd@cert.org>, Keith Moore <moore@network-heretics.com>
cc: ietf@ietf.org
Subject: RE: Call for Community Feedback: Retiring IETF FTP Service
Message-ID: <2FA69B47CF816E0849FF411B@PSB>
In-Reply-To: <45d4a41f37e7434483cfbda549f44a84@cert.org>
References: <af6ab231024c478bbd28bbec0f9c69c9@cert.org> <b993def4eb0140698042781e0b790af0@cert.org> <50D6883540A39384617ABEBF@PSB> <725c1a373fbc77e5@orthanc.ca> <b2b172a2d793499bb4da094f1cceb105@cert.org> <36C92F732011DE95088B8427@PSB> <9ff7a889-2d9a-f0fc-f2bd-a3ea80f6ef1e@network-heretics.com> <45d4a41f37e7434483cfbda549f44a84@cert.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/M_c50I9DjgcU3MXxSWtp-HpHsRg>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Nov 2020 17:26:00 -0000

Roman, Keith,

Two small additions to parts of your recent comments...


--On Thursday, November 26, 2020 14:39 +0000 Roman Danyliw
<rdd@cert.org> wrote:
>...
> Unlike John, we had discussed a broad array of content, so I
> also want to point out that the ftp.rfc-editor.org site has
> different content that ftp.ietf.org -- RFCs and I-Ds are
> there.  However, for example, the mailing list archives and
> charters are NOT on the rfc-editor site.

I am personally not very concerned about FTP access to mailing
list archives (which are becoming less useful as some efforts
are shifted to github and similar "living" repositories) or
charters.  Personally, I'd be happier if we took "expired"
seriously such that, after some reasonable grace period, such
I-Ds were part of a separate repository and required
significantly more effort to get to than clicking on a link in
the datatracker that says "A copy of the expired Internet-Draft
can be found at...".   However, I'm quite sure after other
rounds of discussions that I'm in the rough about that.  I would
also be happier if there were a good mechanism (whether via
HTTP, rsync, or FTP that make it convenient to retrieve current
versions only (neither FTP --including LIST or NLST and local
grep-- nor rsync are good at that).  Consequently, if an FTP
repository consisted only of I-Ds that were current or that had
expired, without being replaced, more than, say, six months
previously, I'd be quite happy.  But I'm probably in the rough
about that too.

Keith's rather nice list of functionality available via FTP that
is not readily available through HTTP and the datatracker in
https://mailarchive.ietf.org/arch/msg/ietf/ukTEvRqPF-91riLLjyJEy20T2Q8
is relevant here.  But there is another tradeoff in that
situation.  For me (although I'm guessing not for Keith, Lyndon,
and some others), my need for FTP access to I-Ds would go down
another notch if, when I did a search in the datatracker and got
back a multiple-document list, it gave me checkboxes for format
preferences and to identify the documents I wanted and then
allowed me to click something to automagically retrieve/download
that collection of documents.  Today, I have to either pull up
the page for one document at a time, download or view it, and
then go back to the listing for the next document while, with
FTP, if some conditions are met, I can pull the lot in one
operation.  [1]

And...

--On Thursday, November 26, 2020 09:45 -0500 Keith Moore
<moore@network-heretics.com> wrote:

>...
> More broadly, this conversation has convinced me that IETF
> cannot be relied on to provide the tools that IETF
> participants need, and in fact that IETF management has become
> hostile to participation in IETF by some kinds of people.  
> So if IETF is going to continue to be a viable consensus-based
> standards-making organization, either the management needs to
> do a significant about-face in its attitude toward
> participation, or IETF participants need to take on the burden
> of providing those tools.

The problem with the latter is that, unless the participant is
part of an organization that is willing and able to provide a
long-term commitment, you end up with your archive, I end up
with my archive, Lyndon ends up with his, etc.  We might be
willing to share our archives with a few hundred of our closest
friends, but the arrangements are inherently unstable _and_
cause us, each the extra work and operational complexity "the
IETF" wants to shed.  That is why I asked the question long ago
about what the actual operational costs of the IETF running/
retaining the FTP service are (don't think I ever got an answer
that I could use):  If we had a number and it realistically
represented marginal costs, at least a few of us much be willing
to buy into it on a fee for service subscription basis,
considering such a service with long-term guarantees and an SLA
to be much cheaper (because of economies of scale if nothing
else) and more convenient than doing it ourselves.

More generally, people who believe the IETF has become hostile
to their participation have an option that you didn't mention.
That is to take the work they are interested in to other
organizations and standards bodies.  If those bodies consider it
in their interest (even if just to make their standards
relatively more credible), such people might help them identify
the perceived hostility of the IETF to other points of view or
ways of working and the consequent lack of broad perspective in
its standards-making activities.   I hope that, before getting
to point of taking such actions, the people who feel that way
have explained the problem to the Nomocm and that, if they did
not do so before the nominal cutoff at the end of the IETF week,
the Nomcom can be persuaded to listen.

best,
    john



[1]  It may or may not be relevant that ISO's TC eCommittee
mechanisms and the "livelink" mechanisms used by several
National Member Bodies as part of their secretariat functions
for TCs -- many of which would probably give a very blank look
it someone said "FTP" to them00 provide exactly that type of
functionality.  Speaking for myself only, I find it a tad
depressing that they are ahead of us.