Re: what is rsync, was Call for Community Feedback: Retiring IETF FTP Service

John C Klensin <john-ietf@jck.com> Thu, 26 November 2020 22:00 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 4B4753A10CB for <ietf@ietfa.amsl.com>; Thu, 26 Nov 2020 14:00:33 -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 dLQyKy23S2nR for <ietf@ietfa.amsl.com>; Thu, 26 Nov 2020 14:00:32 -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 07DF33A10C7 for <ietf@ietf.org>; Thu, 26 Nov 2020 14:00:31 -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 1kiPJW-0007xA-MX; Thu, 26 Nov 2020 17:00:30 -0500
Date: Thu, 26 Nov 2020 17:00:24 -0500
From: John C Klensin <john-ietf@jck.com>
To: Keith Moore <moore@network-heretics.com>, ietf@ietf.org
Subject: Re: what is rsync, was Call for Community Feedback: Retiring IETF FTP Service
Message-ID: <BBFBE169970BD46925028069@PSB>
In-Reply-To: <c34ed9df-0d12-cab0-551e-ec146bc949b7@network-heretics.com>
References: <20201126170826.F2FF8281C9C3@ary.qy> <c34ed9df-0d12-cab0-551e-ec146bc949b7@network-heretics.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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/EO3hvn0VnV07kVxE-VyZMkFUqaE>
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 22:00:33 -0000


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

> On 11/26/20 12:08 PM, John Levine wrote:
> 
>> If you're wondering if there's an RFC for it, nope. RFC 5781
>> specifies the rsync: URI but refers back
>> tohttp://rsync.samba.org/  for details on rsync.
>> 
>> I don't suppose anyone would object if we made an RFC out of
>> the spec but given that the tech report, thesis, and multiple
>> implementations are widely available without restriction
>> (other than GPL on some of the code) it doesn't seem worth a
>> lot of effort.
> 
> I remember when IETF cared about making standards and
> promoting broad interoperability.

Of course, there would be another way to do this, one that would
create an RFC but not a standard.  One could cobble a document
together that described what rsync was all about in the abstract
and introduction, include the references that have popped up in
this thread (and probably including a lot of text by reference),
and then hand it over to the ISE for publication of a
description of a protocol that is widely used in the community
for the information of the community.  If the IESG then wanted
to take such a document over and classify it as standards track,
I presume no one would object as long as they did not create a
working group that had the goal of either hanging bags on the
side of the thing or improving it enough that it was not
interoperable with deployed implementations. 

But there is not much evidence, in this case, that anyone cares
even enough to do that... and, if no one wants to invest even
that level of effort, then I think we need to agree with John
Levine's conclusion.

    john