A
...
Relying parties already have to cope with inconsistencies due to parts
of the global database becoming unreachable (perhaps globally, perhaps
just for some relying parties). Transient inconsistencies introduced
during the publication process are just another form of inconsistency
that relying parties have to cope with.
Rob,
I think we moved beyond the notion getting an inconsistent set of
records a while ago. So, I'm confused. Are you saying that there is
no deterministic solution that allows an RP to detect that it has
fetched an inconsistent set of records. That's what i would like to
see. If the suggestion is to check the manifest, I would be
disappointed, as I think that makes it hard to distinguish between
attacks and sync problems. Also, as I noted in my reply to Tim, that
approach requires fairly invasive processing, i.e., looking into a
(verified?) manifest. My suggestion avoids that concern, although
perhaps at the cost of an additional rsync activity. (I'm still
interested in learning what Chris's parameterized rsync call does.)
I don't think we can go progress the repository doc without a better
description of the problem and recommended solution approaches.
Steve
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr