Hi, in my point of view - RIPE NCC will do nothing. They cannot do anything. RIPE NCC can only coordinate address space, which is NOT used. RIPE NCC has NO real force to cut these users and push these resources to other organisation - they can cut only record in their database, but this _really_ doesn't affect global routing. Many ISPs doesn't some filtering against RIPE (and similar) databases. RIPE NCC cannot assing this somewhere used prefix to new user. Just because this prefix will overlap with some other network - and cause problems... What I say was simply demonstrated on "youtube hijack". It's same case like PA space deaggregation. Global routing tablesare (stupidly) filled by deagregated PA addresses and RIPE NCC does really _nothing_. Maybe because this deaggregation is in many cases done by "large" RIPE members. Nobody cares about this problem, nobody really thinks about policies restricting this. And global (IPv4) table is stupidly growing. From RIPE NCC you receive almost the same argument - we (RIPE) haven't any force to avoid this. And same thing happens for PI/ANS... Daniel On 09/03/2009 08:01 PM, Max Tulyev wrote:

Hi All,

I have some misunderstanding with contractual relationship procedure is going on.

By 20th of September, I should provide information about my clients signed contracts with our company. These all objects will appear in our billing scheme in 2010.

If someone didn't sign it before this date, but will - for example, on October, 1st - what should I do with these clients?