On Thu, Mar 21, 2013 at 4:42 PM, Danny McPherson <da...@tcb.net> wrote: > On 2013-03-21 14:29, Chris Morrow wrote: > >> TODAY it reduces the number, yes. 100% agree. >> TOMORROW the number of repositories, even those which are 'hosted' will >> be split up by name and/or ip-address... >> >> I have a feeling these will be like DNS servers and likely ripe (ha!) >> points for attack by bad folks. So sharing fate for all customers just >> seems like a bad idea. >> >>> folks become unhappy with the repository management, but for now I think >>> it is reasonable to assume a much smaller number of repositories, which >>> is what Sriram and I did in our model. >> >> >> yup. but having the ability to increase the number of repositories in >> the model means we can say: "today with N repositories and M objects we >> see times of Y. Tomorrow when we have X repositories with Y objects we >> should see times of Z" > > > Agreed. > > Additionally, this perspective may well change when things like BGPSEC > router keys need to be published and then ingested by operational routers > for update signing, as the trust model is fairly different, methinks.
so, to me, this is just 'more objects with a tight(er) timeframe on delivery' right? meaning: today you have (for sake of the conversation) relatively static content in the repository, where data changes 1/2/3 objects/day, and it's important to get the data distributed, but (again, for the conversation) 24hrs is 'fine' as a timeline between: "publish object" and "rendered onto the router". but: tomorrow if you followed (for the sake of the conversation) Sriram's model of 'roll router keys hourly to ensure ttls on routes' (loosely paraphrased and with times I don't even think he put into his slides/discussions), you'd be talking about #-of-routers * 24 objects changing every day, and with a timescale for: "publish" to "render" on the order of 1hr. (likely less than 1hr, something closer to 5-10 minutes has been discussed previously). right? -chris _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
