Adding to Andrei's comments, I think that some comments on the work of SIDR on resource certification maybe guaranteed. In fact, I know of at least two organizations that are looking into ways of interoperating IRRs and the information contained in the Resource PKI.
The comments on RIPE-NCC's policies seem out of place for this document IMO. A similar analysis for other IRR operators and maybe other RIR regions should be included if they are to be kept. I believe this is a good document, thank you ! regards, ~Carlos On Fri, Jul 5, 2013 at 5:39 AM, Andrei Robachevsky < [email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I think this is a useful document. Some suggestions below mostly > intended to make issues you bring up more clear. > > When you talk about the lack of resource certification (4.1), you make > two main points: > > - - there has existed no method for developing bindings of an IP prefix > to the originating Autonomous System (AS), and > - - there is the absence of a tangible tie between the resource and the > resource holder. > > To a certain extent RPSL (RFC2622) and RPSS (RFC2725) address these > issues - at least in the RIPE IRR a mntner object ties the resource to > the holder and RPSS provides mechanisms that require the consent of > both address space and ASN holders for the creation of route objects. > > So perhaps the deficiencies can be formulated in a slightly different way: > > - - existing IRR mechanisms do not provide ways for a relying party to > (cryptographically) verify the validity of an IRR object, and > - - generally there is no assurance of the validity of objects at their > creation time (except for a subset of the RIPE IRR where RPSS works - > for RIPE address holders and RIPE ASN holders). > > It'll also make this section more clear if you provide a definition of > "resource certification". > > I am also not sure you need to provide a detailed clarification > regarding the [RIPE2007-01] policy (btw, the correct reference for > this is http://www.ripe.net/ripe/docs/ripe-452). It is too specific > (it addresses PI/portable space holders), as far as I know other > regions address this issue, too, and is, indeed, a prerequisite for > resource certification, but doesn't directly address the IRR deficiencies. > > Finally it will be useful to look at the deficiencies with regards to > use cases. For example, throughout the document you seem to be > focusing on one use case - when as ISP builds an incoming policy for > its customer sessions. But for this case, as you note yourself in > 4.2., stale data is not necessarily a problem, since there are ways to > enforce (e.g. with an as-set) a specific subset of the IRR data to be > used. > > What other use cases so you have in mind? Perhaps that will > demonstrate the limitations of the IRR better and indicate new uses > of it should some of the deficiencies be fixed. > > Thanks, > > Andrei > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.14 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlHWhiYACgkQljz5tZmtij+NBwCcCjTsZVQsTQSREEHAPtoXIYUj > ZxsAoNdqX1sc7kub8wrxDYQeFFdrxaMI > =7KuZ > -----END PGP SIGNATURE----- > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow > -- -- ========================= Carlos M. Martinez-Cagnazzo h <http://cagnazzo.name>ttp://cagnazzo.me =========================
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
