Not to detract from the paper Randy posted, in any way. For APRICOT 2021 I reported to the APNIC routing security sig as follows: As of Feb 2021 •1,009 total ASNs reading the APNIC RPKI data every day –902 distinct ASNs collecting using RRDP protocol (https) –927 distinct ASNs collecting via rsync -- So for us, they are mostly co-incident sets of ASNs. For APNIC's publication point, the scale of the issue is "almost everybody does both" Whats the size of the problem? The size of the problem is the likelihood of updating rsync state whilst its being fetched. There is a simple model to avoid this which has been noted: modify discrete directories, swing a symlink so the change from "old" to "new" state is as atomic as possible. rsync on UNIX is chroot() and the existing bound clients will drain from the old state. Then run some cleanup process. But, if you are caught behind a process which writes to the actively served rsync directory, the "size" of the subdirectory structure is an indication of the risk of a Manifest being written to, whilst being fetched. Yes, in absolute terms it could happen to a 1 ROA manifest, but it is more likely to happen in any manifest of size The "cost" of a non-atomic upate is higher, and I believe the risk is higher. The risk is computing the checksums and writing the Manifest and signing it, while some asynchronous update is happening, and whilst people are fetching the state. RIR host thousands of children, so we have at least one manifest each which is significantly larger over those certificated products and more likely to trigger a problem. ggm@host6 repository % !fi find . -type d | xargs -n 1 -I {} echo "ls {} | wc -l" | sh | sort | uniq -c 1 2 1 3 1 7 1 8 1 9 1 52 1 147 1 3352 ggm@host6 repository % Our hosted solution has this structure. Most children by far have less than 10 objects. ggm@host6 member_repository % find . -type d | xargs -n 1 -I {} echo "ls {} | wc -l" | sh | sort | uniq -c 2997 1 1697 2 2099 3 560 4 229 5 96 6 44 7 22 8 17 9 11 10 6 11 5 12 5 13 6 14 2 15 4 16 2 17 2 18 1 20 1 23 1 25 1 27 1 28 1 29 1 34 1 38 1 40 3 42 1 46 1 60 1 97 1 848 ggm@host6 member_repository %