In hindsight, this has been a problematic decision. rsync is highly exploitable for DOS and unexpected outcomes. Pragmatically it got us somewhere. Its a bad fit for the CDN world we live in now. https://www.ietf.org/proceedings/89/slides/slides-89-sidr-6.pdf https://blog.apnic.net/2020/10/27/rpki-qa-the-trouble-with-rsync/ RPKI (sidrops) is trying to define a delta protocol up into more normative state, and a deprecate-rsync draft is in hypothesis. -G On Fri, Nov 27, 2020 at 9:03 PM tom petch <daedulus@xxxxxxxxxxxxx> wrote: > > On 26/11/2020 22:00, John C Klensin wrote: > > > > --On Thursday, November 26, 2020 14:11 -0500 Keith Moore > > <moore@xxxxxxxxxxxxxxxxxxxx> 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. > > Back in 2008, sidr chose rsync as the foundation of its protocol. It > referenced rsync.samba.org. See, for example, RFC6480. > > Tom Petch > > > > > > > > > > > > > john > > > > > > . > > >
