On Aug 8, 2014, at 3:17 PM, Andy Newton <a...@arin.net> wrote: > > On Aug 8, 2014, at 2:04 PM, Sandra Murphy <sa...@tislabs.com> wrote: > >> RFC3779 was also intended to follow the current prefix allocation system. >> No surprise, its validation rules ensure that you can only certify >> allocations from what you hold. That made RFC3779 useful for the purposes >> of providing a RPKI certification of prefix allocation. Reuse of existing >> technology that provides the features you want is generally considered >> wisdom. > > Since we are talking about wisdom, knowing why you are doing something is > wise. Doing something just because it was done in the past is following > tradition.
You mischaracterize the motivation. I indicated that the desired features of the RPKI design matched the features provided by an existing technology. That is decidedly not just following tradition. For example, the RPKI also uses CMS, because it provides the features the RPKI needs. That is not just following tradition. > >> This prefix allocation system is encapsulated in the RPSL authorization >> model that is used in some RIRs. In those systems, you can only create an >> inetnum if you hold the rights to a parent inetnum. >> >> That's the authorization model people have been using in some regions for >> decades. I have always found the fact that the RPKI authorization model >> was a good match to the IRR authorization model in long use to be >> reassuring. It meant the RPKI followed what people had already long >> accepted, and it meant that operators should find the semantics familiar. > > Well, not all IRRs are tied to RIR registrations. In fact, most are not. I mentioned those used in some RIRs. I did not address all IRRs. Yes, most do not. Those that do not are subject to unauthorized registrations. As has happened. I am not sure why you are bringing up systems which provide no security in discussing the design of a secure system. As an example of what to avoid? > > Reverse DNS might be a better parallel. However, if a particular delegation > is lame, the DNS does not consider all delegations of the network holder to > be lame. > I do not follow the parallel at all. --Sandy
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
