> o but we do not know the long term scaling characteristics of the > current rsync scheme.
While we may not know the scaling characteristics of the solution, do we at least know what would be a desirable objective target for sustainable deployment? > o we could get much better rsync performance with a trivial change at > the rids. Does "much better" accommodate our desired engineering targets for long-term? What are those? > o we are already playing with a bittorrent experiment for a number of > reasons, mainly because its model is so different. you have seen > the initial results. the code is open. Twitter may be more real-time (only half kidding :-) > o but we are suspicions and curious creatures, so folk are already > discussing mechanisms for v2, mechanism agility, ... to be deployed > in a year or three. Again, if we're engineering here for the future and stable standards then what are the desirable long-term system scale objectives for the RPKI? I think this is a pretty reasonable question - when this is fully deployed in n years, whatever the timeline is, what do you believe will be the number of objects (CRLs, EEs, ROAs, Manifests, size, etc..), RPs, frequency of updates, etc.., given the operational and design experience you have thus far? While I suspect some clever response here, I'm being sincere with these questions, particularly if we're baking this stuff into standards track protocols. Thanks, -danny _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
