This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call
- Previous message (by thread): [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call
- Next message (by thread): [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Immo 'FaUl' Wehrenberg
immo.ripe at be.free.de
Tue May 3 19:47:56 CEST 2011
Martin wrote: > > In order to respond to [2] here (and following a short discussion i had > > with Geoff after his talk yesterday): > > as the ressources are given out by the by IANA and the RIRs and the LIRs, so introducing an hirarchial approach that shadows the real assigning is a logical and the only usefull approach IMO. > > Here I'd like to raise a minor, quite theoretical, objection. > The primary purpose of IANA, RIRs and LIRs, when it comes to IPv4/v6 > and AS numbers, is to organize resources globally so that there are no > collisions (uniqueness). WIth IPv4 and to some extent AS numbers, > there's an additional point of rationing them out, but that is mainly > a side-effect of them being varying degrees of finite resources. > IPv6 however, while not infinite, is certainly sufficient for every > person on the planet. And so it is conceivable that another, > distributed, system for uniqueness verification could exist. Whether > or not any change like what I'm describing has any chance to fly or > not, is a slightly different question. > That, and what routing it would require. While I agree with you at some point, i don't think we get any further when starting to discuss at this level here. > > In general, both approaches works poorly to say > > the least and giving away the power to some "trusted third partys" get > > us the mess we today have with traditional ssl certificates (where > > we have a system that is seriously broken beyond all repair). However, > > I'd like to take Randys point from his talk that the validatity of > > certificates should be long, but would even say that thay should not > > be only two to five years, but instead at least 20 years and > > no possible revocation in order to protect the RIRs from being smashed > > by political preassure. > The really-long-term validity is appealing, but nevertheless falls > short from personal preference since I don't see the actual need for > RPKI to begin with. Well, we had that Youtube incedent and there where a few more, so there are people demanding it. I don't think that denying that fact and just walk away would get us any further here again. In contrary, if people seriously start to demand it and we are going to say "well, we will not do something here" then they will start doing that in some other forum, which i would presume is much worse as we here can discuss and raise our concerns. Regards, Immo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: </ripe/mail/archives/address-policy-wg/attachments/20110503/ab7a2d86/attachment.sig>
- Previous message (by thread): [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call
- Next message (by thread): [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]