Subject: Re: [GROW] I-D Action: draft-ietf-grow-rpki-as-cones-00.txt

From: Andrei Robachevsky <[email-masked]>
Date: Fri, 15 Mar 2019 12:24:40 +0100

Hi,

A few comments on the draft.

> A policy definition contains a list the upstream and peering

I think 'of' is missing, but still the paragraph is not easy to parse.

>  2.  If there is no specific definition for the relationship, the
>            ASX:Default policy;

When you say ASX:Defaul, are you referring to the "The default behaviour
for a neighbour, if the relationship is not explicitly described in the
policy" mentioned before? To avoid ambiguity you may want to introduce
this notation there.

> 3.  Validating an AS-Cone

> If the validated cache does not contain the referenced object,
>        then the validation moves on to the next downstream ASN;

Meaning routes originated by this ASN will be rejected (or a filter
won't contain these routes)? Better to be explicit about this.

>  2.  If there is a reference to another AS-Cone, the validating
>            process should recursively process all the entries in that
>            AS-Cone first, with the same principles contained in this
>            list.

Here is a question. As I understand, the policy definition object is
intended to allow a customer to indicate to the upstream which AS-Cone
to use (and which prefixes to expect). The customer controls this
policy. However, the reference to an AS-Cone in another AS-Cone seems to
be done at will of a provider, based on some static decision, rather
than the analysis of a corresponding policy definition. Do you think
that can lead to inconsistencies?

Thanks,

Andrei