Thanks Sandy, yours is actually the first in this very long and sometimes a bit... strange thread that actually provides an answer to my original question.
>From your email I identify a subtly different use case from the one that SIDR seems to be about. #1 - Certify the rightful holder of a prefix #2 - Help routers validate prefixes when deciding how to build their routing tables RFC 3779 validation rules are probably the best suited rules for #1. It seems clear now that whether RFC 3779 validation rules are adequate or well suited to #2 has not been discussed here in depth. It seems to me that this is a good time to do so. Have a great weekend. -Carlos On 8/8/14, 3:04 PM, Sandra Murphy wrote: > speaking as regular ol' member > > On Aug 8, 2014, at 11:39 AM, Andy Newton <a...@arin.net> wrote: > >> >> On Aug 6, 2014, at 11:44 AM, Stephen Kent <k...@bbn.com> wrote: >> >> >> The question was about why, in this effort, we are using 3779 validation >> rules, and the answer appears to be because a past, failed effort used them. >> Is there really no technical justification? >> \ > > and previously > > On Aug 5, 2014, at 1:49 PM, Carlos M. Martinez <carlosm3...@gmail.com> wrote: > >> Hello, >> >> I think what we need to discuss is which certificate validation rules >> apply to our problem domain, basically securing origin and/or securing path. >> >> Current specs refer that RFC 3779 validation rules should be applied to >> SIDR's problem domain. I couldn´t find any justification for this, other >> than 'RFC 3779 was already there by the time SIDR started'. > > > The RPKI was intended to certify the rightful holder of a prefix. So it was > designed to follow the current prefix allocation system. In the current > prefix allocation system, you can only allocate prefixes that you hold. So > the RPKI validation rules were designed to ensure that you can only certify > allocations from what you are certified to hold. > > 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. > > 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. > > > --Sandy, speaking as regular ol' member > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
