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

From: Andrei Robachevsky <[email-masked]>
Date: Mon, 24 Jun 2019 10:46:53 +0200

Hi,

Is there still interest in the WG in progressing this work? I have not
seen any response to the comments raised so far.

Thanks,

Andrei

Andrei Robachevsky wrote on 15/03/2019 12:24:
> 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
>