On Sun, Nov 29, 2020 at 6:27 PM George Michaelson <ggm@xxxxxxxxxxxx> wrote: > > 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. arguably, CDN doesn't matter at all here, we are only shipping around some small number of small files per endpoint. CDN usage is really a micro-optimization which may be nice to have but isn't super relevant to operating the system as a whole. what matters is a transport where there are programming libraries (in the language(s) you choose to use for your system/tools) that report sane errors which can be handled programmatically. Shelling out to run your transport is ... hard to debug/think-about-programmatically/repair. :( Yes, rsync did and does provide a running system today. Yes, rsync is also painful in these systems because failures are 'impossible' to recover from (except by off/on-again) > 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 > > > > > > > > > . > > > > > >
