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

From: Andrei Robachevsky <[email-masked]>
Date: Fri, 05 Jul 2013 10:39:02 +0200

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