> On 07 Sep 2016, at 16:42, Christopher Morrow <morrowc.li...@gmail.com> wrote: > > > > On Wed, Sep 7, 2016 at 12:07 AM, Rob Austein <s...@hactrn.net > <mailto:s...@hactrn.net>> wrote: > At Tue, 6 Sep 2016 22:48:07 -0400, Christopher Morrow wrote: > > > > (note, I do not care for this message about politics) > > Understood, with the caveat that since it's the politics which are > pushing the wrong technical solution here, any technical discussion > will loop back to politics as soon as one asks "why?" > > > totally agree/understand. > > > we're here because, I think, from the top down to the RIR there isn't a > > hierarchy being created, right? the RIR folk are saying: "Ok, you all want > > this thing, but upstairs hasn't created the root, so we're going to do the > > best we can with making a root each that allows us to xfer between RIRs. > > This is how it's being done, so you have some docs about the mechanics > > involved and can build/guide from there" > > > > is that not the case? (again, I don't care about the politics) > > I'm ignoring "upstairs", because that is also political. > > > yes, sorry I was trying to not point fingers at particular people/things :( > > Stripped of the politics, we're having this conversation because the > RIRs are proposing to operate five roots instead of one, with each > root allowed to claim ownership over the known universe, because > actually coordinating with each other is Too Hard. Or maybe it's more > than five, some of the RIRs have extra roots just for fun, but let's > take it as given for now that they'll collapse back down to five. > > > ok > > The problem with multiple global RPKI roots, as KC Claffy put it > rather neatly many years ago, is that it pushes responsibility for > fixing RIR coordination mistakes (which the RIRs apparently believe > are a serious issue, as evidenced by the draft under discussion) onto > the relying parties rather than forcing the RIRs to fix those issues > on the CA side. This is technically broken. > > > I think it means that since there is no single root coming 'soon', the RIR's > are taking a step to move forward with rpki despite the 'no single root' > existing. Ideally they would have a method to keep from being out of sync in > their processing of requests/changes. Ideally that process would be outlined > in the document here so we'd be able to say: "Ok, as the rpki lives on, how > does X and Y and Z get done? what happens at X step 3 when Carlos decides to > take a very long lunch? how does the process move along? what checks/balances > are there?" > > That's the part that you're referring to as KC's comment, I think? > > Generating a single RPKI root is not hard. It can be done by a cron > job. I ran one for years, for experimental purposes, entirely from > data already available to the RIRs. The only real issue is which > database to believe when they disagree -- which is exactly the problem > the RIRs are trying to push onto the RPs with this document. > > > I don't disagree that running a CA is 'simple'... I think though that if the > RIRs are in a position where there won't be a single root above them 'for a > while' (it's been ~10 yrs at this point) but they feel they need to move > forward with something, is this direction acceptable? is it better to > document that decision and it's gotchas than to not move forward at all? or > to 'continue waiting for the single root' to arrive?
Chris, fully agree, the intent is to provide unity and transparency on how the RIRs handle their respective trust anchors at this stage Andrew > > Which brings us back to bad technical decisions and political reasons. > Sorry. > > yup. > > > _______________________________________________ > sidr mailing list > sidr@ietf.org <mailto:sidr@ietf.org> > https://www.ietf.org/mailman/listinfo/sidr > <https://www.ietf.org/mailman/listinfo/sidr> > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
