<div dir="ltr"><div>Hi, thank you for responses.</div><div><br></div><div>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.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/10/16 Rob Evans <span dir="ltr"><<a href="mailto:rhe@nosc.ja.net" target="_blank">rhe@nosc.ja.net</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<div class="im"><br>
> Actually, having a *warning* if you send in an aut-num: object that<br>
> declares import/export policies that do not match the corresponding<br>
> "other AS's" aut-num: policies could useful.  Yes, it would create<br>
> an impressive amount of warnings, but maybe that leads to sufficient<br>
> peer pressure...<br>
<br>
</div>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.<br>

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

<br>
Cheers,<br>
Rob<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div style="font-family:Helvetica;font-size:12px;background-color:rgb(255,255,255);border-collapse:collapse"><font color="#999999">| Alexander Azimov  | HLL l QRATOR</font></div>
<div style="font-family:Helvetica;font-size:12px;background-color:rgb(255,255,255);border-collapse:collapse"><font color="#999999">| tel.: +7 499 241 81 92</font></div><div style="font-family:Helvetica;font-size:12px;background-color:rgb(255,255,255);border-collapse:collapse">
<font color="#999999">| mob.: +7 915 360 08 86</font></div><div style="font-family:Helvetica;font-size:12px;background-color:rgb(255,255,255);border-collapse:collapse"><font color="#999999">| skype: mitradir</font></div><div style="font-family:Helvetica;font-size:12px;background-color:rgb(255,255,255);border-collapse:collapse">
<font color="#999999">| mailto: <a href="mailto:aa@highloadlab.com" target="_blank">aa@highloadlab.com</a></font></div><div style="font-family:Helvetica;font-size:12px;background-color:rgb(255,255,255);border-collapse:collapse">
<font color="#999999">| visit: <a href="http://www.qrator.net/" target="_blank">www.qrator.net</a></font></div>
</div>