On Dec 20, 2012, at 11:30 AM, Randy Bush wrote: >>> bgpsec+rpki does not have the highly globally synced requirement. >> So, in bgpsec, you (as an RP) don't need to know ROAs a priori in >> order to validate routes as they arrive in updates? > > see "highly synched" above. as a rp, an hour or three loose synch is > fine.
No, you've got that wrong again. In order for the system that _you_ designed to meet the requirements of those who are using and operating the Internet, it must be able to perform faster than your design can realistically manage. That's a design flaw that came from ignoring requirements analysis. >> bgpsec (as currently outlined in the requirement-free draft) > > damn! and i thought i had writted a reqs draft, which does need > updating. Well, afaict, the requirements in your draft have not been accepted by the group, in general. Therefore, the fact that you have a reqs draft, does not mean the designs in the other drafts meet the group's requirements. You can't just write reqs and run away if you want people to take them seriously. ;) > let's try to limit the slinging. Gotcha... Stay focused on engineering. Ack... > and your problem is with origin validation as currntly implemented and > deployed. it ain't bgpsec. Umm... what? Right now, what's deployed ain't bgpsec... What implementation are you talking about? >> implicitly requires full replication of the rpki in order to make >> correct routing decisions. > > diff between loose time constraint and what is replicated. There is a requirement of data freshness. It is not realistic _in_your_design_. That makes your design a poor fit, and we need another approach. >> _That_ system has this flaw, but I don't claim to own it. ;) > > are you willing to rent it out? :) I'm confused... Are you ``slinging'' here? So, that's back on again? kewl... ;) > you have a product which places a currently unachievable time constrains > on pretty much any mechanism which provides prefix origination security. No no no... Sorry Randy, that's not how engineering works... You see, we have a requirement... If your suggested design cannot meet it, we need to go from _there_ (your design cannot meet a requirement). Your assumption that it is ``unachievable'' is silly. Have you explored the _entire_ solution space? Have you gotten consensus on what problem(s) we are even solving here? No, you haven't. As an engineer, ymbk... > randy, heading for more airports gtk, Eric _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
