Subject: Re: [GROW] Some comments on draft-ietf-grow-irr-routing-policy-considerations-01.txt

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Wed, 7 Aug 2013 18:15:13 -0300

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-masked]> 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-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

-- 
--
=========================
Carlos M. Martinez-Cagnazzo
h <http://cagnazzo.name>ttp://cagnazzo.me
=========================