Subject: [Sidr] rsync discussion history

From: Sandra Murphy <[email-masked]>
Date: Wed, 12 Mar 2008 15:47:04 -0400 (Eastern Daylight Time)

Here's my promised message about the rsync discussions in and outside the 
working group.

The sidr mailing list shows exchanges about rsync around Oct 30-31, 2006 
with Joe Abley expressing concerns about interop of different 
implementations, and 28-31 Mar 07 starting with William Leibzon expressing 
concerns about IESG/IETF process.  Those message also include messages 
describing the features that are needed and how rsync satisfies those.

That's about it.

But the discussion during meetings and in private exchnages has 
snowballed:

(1) rsync is not a URI

OK, we'll get it registered based on the RFC

(2) rsync is not an rfc and the author is not interested in making it one

OK, we'll do a third party registration based on the spec

(3) there is no stable spec for rsync (aka "the code is the spec")

OK, we'll register the URI based on ... the code? (if we can)

(4) there are (a few) wg concerns about non-interoperability of 
independent implementations, due to lack of spec

OK, we'll presume that everyone uses the open-source implementation.

(5) rsync has gone through some non-backward-compatible version changes in 
the past.

OK, we'll hope the rsync project doesn't do that again, else new versions 
of rsync with non-backward compatible features would require a flag day.

You may recall a mention in Monday's meeting of license difficulties for 
commercial implementations.

At this point in the history, I discovered that the rsync open source 
project used a license that forbid charging for any code that included 
their code.  That would have made commercial implementations problematic.

However, I just discovered that with the announcement of rsync 3.0 on 
March 1, 2008 they have moved from GPL version 2 to GPL version 3:
http://www.samba.org/rsync/GPL.html

From a first glance through, I can not find similar text that would 
prohibit charging for code that includes their code.  People who are used 
to reading these GPL licences should take a look to see if you see limits 
on commercial use of the rsync code.

So the difficulty about commercial implementations could be OBE.

--Sandy
_______________________________________________
Sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Florian Weimer <[email-masked]>
Date: Thu, 13 Mar 2008 19:59:02 +0100

> OK, we'll register the URI based on ... the code? (if we can)

I wonder if rsync is the right protocol anyway.  To me, this looks more
like an application of zsync or WebDAV (with VCDIFF, RFC 3284, for
transmitting delta updates).  zsync is similar to rsync, but doesn't
need special server support.  It should also be easier to standardize.

It's not clear to me if you need rsync's capability for transmitting
collections of files.  In that case, neither approach willl help you,
but you should be aware that the current rsync implementation binds
significant resources on the server side, particularly for large
directory trees.  To a lesser extent, this also applies to the
single-file mode.

> http://www.samba.org/rsync/GPL.html

The charging scheme (you may create derivative works if you give
downstream users the same permissions as we gave to you) hasn't changed,
so this will not make a difference.
_______________________________________________
Sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 14 Mar 2008 09:38:03 -0400

Florian,

On Thu, Mar 13, 2008 at 07:59:02PM +0100, Florian Weimer wrote:
> collections of files.

This is the major advantage of using rsync.  When you must sync a large
number of files, it is *very* efficient.

For our purposes, we just care that we can gather all of the necessary
files.  This can be as simple as downloading the latest manifest and
then fetching all changed files within the manifest.  This was one of
the reasons I had suggested a "last updated" value for the items in the
manifest at the microphone at the SIDR meeting.

-- Jeff

---

From: Terry Manderson <[email-masked]>
Date: Sat, 15 Mar 2008 06:13:32 +1000

I'm not going to go back through the process of discussing the merits  
and downfalls of RSYNC or any other competing protocol or service that  
might be used as the fetch mechanism. Looking at the draft:

section 3.9.7
"Other access method URIs that reference the same location MAY also be  
included in the value sequence of this extension. The ordering of URIs  
in this sequence reflect the subject's relative preferences for access  
methods, with the first method in the sequence being the most  
preferred."

The last sentence is important, I'll not regurgitate the various  
discussions I had with the authors to get that in play, instead simply  
to point out:
1) You need an initial and effective service to code to, and to allow  
a base common denominator for development and deployment.
2) Where and how you collect the information is by far a secondary  
concern to the realisation that the information simply needs to exist  
and at least accessible by 1)
So to clarify, you can indeed assert another URI to put in play, and  
preference it over RSYNC, but still have RSYNC as the lowest common  
denominator for base level interoperability.
Terry

--
Terry Manderson                         email:      [email-masked]
Network Operations Manager, APNIC       sip:    [email-masked]
http://www.apnic.net                    phone:      +61 7 3858 3100

---

From: Robert Loomans <[email-masked]>
Date: Tue, 18 Mar 2008 11:07:49 +1000

> You may recall a mention in Monday's meeting of license difficulties
> for commercial implementations.
> 
>  project used a license that forbid charging for any code that
> included their code.  That would have made commercial implementations
> problematic.

[Disclaimer: INAL, etc.]

Not quite. "Included" is the loaded word here.

I haven't examined the GPL v3 in depth, but I have looked very carefully
at v2.

The GPL v2 tries to make the distinction between derived works (ie,
modified versions of the licensed program) and "mere aggregation" for
the purposes of distribution. Note: the GPL does not try to dictate what
you do in the privacy of your own home/office.

Typically this distinction is represented by looking at whether a
program links to the GPL licensed code or not. If it does link to it,
the linked code must be GPL for it to be distributed.

In this case, if the rsync program is executed by proprietary software
as a command line tool, and qualifies as "mere aggregation" then the
only addition requirement on that software would be that it package the
source to rsync along with the binary.

> prohibit charging for code that includes their code.  People who are
> used to reading these GPL licences should take a look to see if you
> see limits on commercial use of the rsync code.
> 

GPL v3 appears to make a similar distinction 
http://www.gnu.org/licenses/gpl.html section 5:

 > A compilation of a covered work with other separate and independent
 > works, which are not by their nature extensions of the covered work,
 > and which are not combined with it such as to form a larger program,
 > in or on a volume of a storage or distribution medium, is called an
 > “aggregate” if the compilation and its resulting copyright are not
 > used to limit the access or legal rights of the compilation's users
 > beyond what the individual works permit. Inclusion of a covered work
 > in an aggregate does not cause this License to apply to the other
 > parts of the aggregate.

Rob
-- 
Robert Loomans                                  Email: [email-masked]
Senior Software Engineer, APNIC                 Phone:   +61 7 3858 3100
http://www.apnic.net                              Fax:   +61 7 3858 3199

---

From: Robert Loomans <[email-masked]>
Date: Tue, 18 Mar 2008 13:50:02 +1000

>> It's not clear to me if you need rsync's capability for transmitting

It is needed.

For the major use case, relying parties will need to get all published 
products of each CA, by walking the certificate hierarchy from the top down.

In each case, the SIA extension of each certificate will point to a 
repository directory where the certificate's products are published. The 
relying party needs to retrieve all of those, and repeat...

> number of files, it is *very* efficient.

What's more it's very efficient over high latency links, and it recovers 
gracefully if you have to restart because of connection failures, etc.

> manifest at the microphone at the SIDR meeting.

That's certainly possible.... assuming the manifest is there. Currently 
the manifests are optional.

Rob

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 18 Mar 2008 10:47:16 -0400

Terry,

On Sat, Mar 15, 2008 at 06:13:32AM +1000, Terry Manderson wrote:
> might be used as the fetch mechanism.

> > manifest at the microphone at the SIDR meeting.

The presence of a last updated field in the manifest means that you
don't require remote file system last-time-touched state to determine what 
files you may need to fetch.  rsync handles those details beautifully.
In the absence of rsync, you need additional information to do this
efficiently.

-- Jeff

---

From: Terry Manderson <[email-masked]>
Date: Wed, 19 Mar 2008 02:44:39 +1000

Hi Jeff,

> And this was not my original point.  I said:

I top posted my reply as I wasn't actually picking on you or  
challenging your point, I felt it worthwhile simply to highlight that  
there are options at that junction of the thread, so in some way we  
can have our cake and eat it too. :-)

> In the absence of rsync, you need additional information to do this

I don't disagree there..

Terry