Hi, thank you for responses.

I think there is a great need to highlight the information that is outdated or errorless. You can’t say: “We’re just keeping the data, the quality of data depends on community” because people make references not to AS holders but to RIPE DB or RIPE Stats. And most of end-users and even network engineers believe to this reference. As a result – stub networks becomes transnational, filtering networks are said to be distributed. And of course there is little opportunity to use such data for traffic flow prediction or AS design. RIPE DB makes people mistaken and this couldn’t be solved by updating RPSL.


2013/10/16 Rob Evans <rhe@nosc.ja.net>
Hi,

> Actually, having a *warning* if you send in an aut-num: object that
> declares import/export policies that do not match the corresponding
> "other AS's" aut-num: policies could useful.  Yes, it would create
> an impressive amount of warnings, but maybe that leads to sufficient
> peer pressure...

I wonder if this should be a keyword-driven thing to request the verification of policy rather than generating warnings on updates, as policies may start off right but what you really want is a quick way to check whether another ASN has changed their policy and you need to change your own policy to reflect that.

> Making it an *error* is a no-go, as the amount of non-matching policy
> documentation is too high (and you'd have an unsolvable conflict when
> trying to set up a new peering, as whoever tries to enter the policy
> first would be told "error: other end is not there").

Just a quick plug that towards the end of tomorrow's routing working group session Denis is going to present on import-via/export-via and following that is going to ask for some thoughts about new ways of showing peering relationships in RPSL...

Cheers,
Rob




--
| Alexander Azimov  | HLL l QRATOR
| tel.: +7 499 241 81 92
| mob.: +7 915 360 08 86
| skype: mitradir
| mailto: aa@highloadlab.com
| visit: www.qrator.net