Folks,
At the IETF meeting in Maastricht I mentioned that we might need to
augment the repository structure doc (that I briefed on Geoff's
behalf) with some sort of lock capability. My concern is that if RP
softwre visits a publication point (file system directory) while the
directory is being modified, the RP software has no easy way to know
that rsync has returned an inconsistent set of records.
Yes, the manifest will indicate a mismatch in this case, but the
manifest was designed to enable an RP to detect malicious
modification of a directory. If we try to use a manifest to detect
inconsistency due to benign directory maintenance, I fear this will
lead to a lot of complexity. Also, if one downloads signed objects
and later processes them against the manifest (itself a signed
object) detecting an inconsistency may be late in the process, long
after the directory was visited, making it harder (and slower) to
respond.
I think it would be clearer if we had a separate object dedicated to
this function. The mechanism should be easy to check quickly,
enabling RP software to detect that a directory is being modified, so
that the RP can discard the (changed) files that it is retrieving,
and schedule a revisit to the directory in a little while, when the
directory update is complete.
I have no specific proposal for the lock object, or the details of
how RP software interpret it. I'l looking for suggestions, or an
alternative way to address the problem.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
