On Aug 8, 2014, at 4:23 PM, Sandra Murphy <[email protected]> wrote:
> > On Aug 8, 2014, at 3:17 PM, Andy Newton <[email protected]> wrote: > >> >> On Aug 8, 2014, at 2:04 PM, Sandra Murphy <[email protected]> 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. I’m fine with not characterizing motives and historical context. Just following your lead. :) > For example, the RPKI also uses CMS, because it provides the features the > RPKI needs. That is not just following tradition. CMS is used in many deployed systems. As has been asked but has been left unanswered, in what other deployed systems is 3779 used? The grounds for changing the 3779 rules has been described as “wobbly” but how is that accusation made if we cannot put our fingers on the reasons for the 3779 rules in the first place? >>> 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? Again, I was following your lead by addressing the example you gave. >> >> 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. If you are looking for a system that follows the address allocation hierarchy, reverse DNS is one such system. However, I get the feeling you and I are talking past each other. If that was not the characteristic you were describing or I have done a poor job explaining my point, please let me know. -andy _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
