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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
