I am concerned with the current draft's reliance on RSYNC as a base
line (read required) protocol for transport of the certificate
information and the CRL.
I think I had two concerns about the the way that rsync was specified:
1. Why specify (with MUSTs and SHOULDs) a particular protocol at all?
2. Given the need for a base protocol, why choose rsync?
[...]
Point 2 still bothers me slightly, since it seems to me that the rsync
protocol is not documented in a sufficiently stable form for it to be
used as a base protocol for work such as this. Unless I'm mistaken, the
rsync protocol/algorithm are products of a single talented individual
and are documented in ad-hoc web pages. This seems to present risks
(e.g. of future IPR claims, or modifications to the protocol which break
interop with other rsync implementations).
These might be real concerns, I don't know.
It seems to me that the answer to question 1 lends itself to the choice
of a protocol which is widely implemented, for which interoperability
has been well-demonstrated, and whose specification is stable. Given
these goals, HTTP seems like a better choice than rsync.
If you look at the expected use cases (especially parties synchronising
between repositories), you end up with a number of requirements against the
protocol that is going to be used in the distribution of these certificates:
1. It should be able to handle access to individual files (e.g. download
issuer certificate or CRL).
2. It should be able to handle access to a large set files (download all
objects from one or more repositories), out of which only relatively few are
new (because you don't want to transfer data you already have)
3. The previous need to be supported throughout multiple directories, which
are potentially nested
4. It should have some method for marking/deleting the objects that no
longer exist on the "server".
5. It should work bidirectionally, i.e. should support sync between "A" and
"B", not only update "B" from the repository "A".
rsync does all that, pretty effectively. Number (1) is easy with HTTP, but
starting from (2) you need to have some common listing format, a directory
traversal (probably with multiple requests), etc. Yes, it could be done, but
if you specify everything for all that functionality, you pretty much invent
"rsync over HTTP" :-)
Perhaps this is a non-issue, but it seems to me that it ought to be
discussed.
I'm not saying rsync is the only solution here, but from the usage point of
view it is a very good tool.
Regards,
Robert
Joe
_______________________________________________
Sidr mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sidr
_______________________________________________
Sidr mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sidr
