[db-wg] source: field for non RIPE address space

On 14 Nov 2014, at 10:26, Nigel Titley <nigel at titley.com> wrote:

>> I'm sorry, I don't understand what you mean with less "secure" routing
>> table in this context. Can you elaborate? Or maybe give an
>> (hypothetical) example?
>> 
> I'm not sure but this sounds like Kaveh thinks that ISPs perform negative filtering whereas, at least in my experience they perform positive filtering, which will be made *more* secure.

Hello,

Sorry for not being clear. 

To my understanding, these are the three scenarios where most operators make their routing decision:

1- Route is seen and is in the IRR: Provider accepts it.
2- Route is seen but differs from IRR: Except if the received route is a subset of IRR object, it is rejected.
3- Route is seen and is absent in IRR: Provider rejects if the route is coming from a downstream provider, accepts it otherwise.

So, if we change the RIPE Database default behaviour to return "%ERROR:101: no entries found” when they run their trustworthy scripts, they will get less route objects, which will in practice downgrade some of the cases which would have caught by strategy (2) and rejected to the category (3) and accepted. This is where if we only make this change on the server side, we have made the system less useful.

As I have written to routing-wg, I just wanted to point out that these kinds of changes should accompany provider behaviour and toolset changes as well. 
Without them, they will have no effect, if not negative. If we have the commitment in the operator space and toolset provider space, this can be a very positive change towards better data quality.

All the best,
Kaveh.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20141114/958d0c1e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/db-wg/attachments/20141114/958d0c1e/attachment.sig>