Re: Call for Community Feedback: Retiring IETF FTP Service

Keith Moore <moore@network-heretics.com> Thu, 26 November 2020 14:29 UTC

Return-Path: <moore@network-heretics.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 A47C73A11F7 for <ietf@ietfa.amsl.com>; Thu, 26 Nov 2020 06:29:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
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 7pcHnoCfuhbe for <ietf@ietfa.amsl.com>; Thu, 26 Nov 2020 06:29:04 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26C7B3A11F5 for <ietf@ietf.org>; Thu, 26 Nov 2020 06:29:04 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 70A395C0193 for <ietf@ietf.org>; Thu, 26 Nov 2020 09:29:03 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 26 Nov 2020 09:29:03 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=8jnN32M2p2c8BWKW66YhaqZq66Ajl69LlyIH6oIew Zo=; b=mA271G4Q/1ZBJbPwAD3yPemvi7e1ZSsCfeDbGIN+8PuO/RzTyL+81wtYd EQs7y/BrSU4noWDSKR+HktYYsP8vYKRi2ypR2Nd0nmwEUXYWBwEafKu3zAyv7PiS iE0bH3YL7OQrVGdxBZmWgfQL9n0eKI/YLkmy7V602DYjlq+eIxbShuDwHr5X/xHo IeH3oqpQ2HW0jRWAw3tHahmitbsesdTIvuv0ldZZ+wPwXkY26tga+Tu06BPJbnAG TPl9aD7ys8Vu6suLJ6OG6B2anBYcDU7RhwqI6INSY97xvJMUF2gDx+zGraMW4GoE e4JwhuVqKj+1PimMhJM/tXtjofHBg==
X-ME-Sender: <xms:rru_X-t-5mxjCH_82dxnGquRzzAC4TyPFPMqw_6HGOclN6FTJMldkg> <xme:rru_XzdIxYYP8NCkg-l-Knff9WUYERnao4jVz-KB2cHFDbRp4d6wrMDuk_lKK_Y7i FcB0fFGnVuHYA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudehvddgieehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeegffejhfegve etleeukedufedviedvkeeuhfdtieekvdekteejvdetvdfhieefkeenucffohhmrghinhep ihgvthhfrdhorhhgnecukfhppedutdekrddvvddurddukedtrdduheenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomh
X-ME-Proxy: <xmx:r7u_X5yB9dxwicMX3DP2ub_OdpaNdn3mpgL6ZmoWaTlnFLZUh6dPKg> <xmx:r7u_X5PDra-ugkWgzdNOH_rlzEtldwVGt9r0IkimsQo3V3Cq7A9MrQ> <xmx:r7u_X-8beuw-k7Mu5GT4v5_jm0e8WygBmDONEjabHUiAqfomqPfbcA> <xmx:r7u_X4c0jiMNzVzmGJD2hGNdirUsKhkrzzZsP-qu-9FEcyqS48Mz6w>
Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id C21F63064AB2 for <ietf@ietf.org>; Thu, 26 Nov 2020 09:29:02 -0500 (EST)
Subject: Re: Call for Community Feedback: Retiring IETF FTP Service
To: ietf@ietf.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> <c0f34e88c3ee46ec9e6f168cf79d44be@cert.org>
From: Keith Moore <moore@network-heretics.com>
Message-ID: <073df5a5-8eff-ef7a-0a1d-21d18bdaa249@network-heretics.com>
Date: Thu, 26 Nov 2020 09:29:01 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <c0f34e88c3ee46ec9e6f168cf79d44be@cert.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/VM9-gQbKtncPTpibdsH3vCx8qc8>
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 14:29:06 -0000

On 11/26/20 6:23 AM, Roman Danyliw wrote:

>   What isn't working for you?  Have you reported it so it can be improved?
>
> If you are specifically referencing the timeout first mentioned inhttps://mailarchive.ietf.org/arch/msg/ietf/uaCQP0VPcLWzDe7hRkLiFAx4MLU/  (FTP timeout after 20 seconds), I consulted with the Tools team who tells me this configuration has been in place for over a decade.  In my quick check on ietf@ and their checking in issue reporting in recent years, this is the first time this issue has been raised.

I noticed many years ago that the ietf ftp server was "fussy", and 
noticed this again after testing the server in the context of this 
conversation.  I just never had time to figure out why.

But knowing that the control connection times out after 20 seconds, it's 
pretty obvious that that's going to be annoying for interactive users 
(there are lots of interruptions that take more than 20 seconds).

It should also be obvious that it's going to probably break some 
non-interactive programs.  (think about it, if a program is transferring 
files one-at-a-time, and any file takes longer than 20 seconds to 
transfer, the program is going to have to either explicitly recover from 
the closing of the control connection, or simply fail).

What I saw the other day when trying to do "grep 'judgment' 
/rfc/rfc*.txt" was a lot of "no such file or directory" errors that 
should not have happened because the files were actually there.   I 
don't know if this was because of the control connection timeout, but 
it's certainly plausible.

Keith