From cio at spamhaus.org Sun Nov 4 17:50:12 2007
From: cio at spamhaus.org (Richard Cox)
Date: Sun, 04 Nov 2007 16:50:12 +0000
Subject: [dp-tf] Re: 91.198.71.0 - 91.198.71.255
In-Reply-To: <90CBBE18-BF6F-4FC8-B9BB-1065F529B1B8@ripe.net>
References: <90CBBE18-BF6F-4FC8-B9BB-1065F529B1B8@ripe.net>
Message-ID:
(Copied to APWG-Chairs and DP-TF in view of the policy implications)
On 02/11/2007 16:36:35, Alex Le Heux wrote:
> As it turns out, we had already noticed the change in registration
> data a few weeks ago and are currently in contact with the LIR.
> We have established procedures that are designed to track changes
> like this, and this case is already under investigation.
There appear to be seven other ranges and ASNs, similarly acquired.
193.33.128.0/23 AS42672 194.110.69.0/24 AS42811
91.193.40.0/22 AS42662 91.193.56.0/22 AS42672
91.194.140.0/23 AS43188 91.195.116.0/23 AS43702
91.196.232.0/22 AS43259 91.198.71.0/24 AS43603
> We have audited the request and our policies and procedures
> were correctly applied when this range was assigned.
That's obviously very worrying - because it implies that any similar
new application now would also be granted, and the claims that RIPE
still has three years to go before IP4 exhaustion would then be seen
as having been highly optimistic!
I note your earlier comment about the data having been recently changed:
so are you saying that the original application was valid just because
it had an address in the RIPE region - even though that address may have
been meaningless? If so, are you able to remind us what that address
originally was (as at the time it would have been "public" data)?
As you may know, the entity believed to be using these IP assignments is
the notorious "Russian Business Network" about which much has recently
been written: and http://en.wikipedia.org/wiki/Russian_Business_Network
provides a convenient index to the more significant of those articles.
The RIPE NCC cannot, of course, be concerned with any criminal activity
that uses IP addresses it assigns, but I believe the RIPE NCC does need
to be concerned about the obtaining by dishonest means of resources that
are owned by the community and entrusted to the stewardship of RIPE NCC.
During RIPE 55 I mentioned the earlier cases of shell companies set up
apparently by a "Boris Mizhen" to apply for IP resources for spamming
purposes (ie to avoid filters) and I understand that the LIR handling
those applications (Merezha) has previously been linked to questionable
assignments. For the record, the IP ranges and ASNs involved with that
series of incidents, were as follows:
91.193.152.0/22 AS42719 91.193.192.0/22 AS42719
91.193.216.0/22 AS42719 91.193.88.0/22 AS42719
91.200.124.0/22 AS42719 91.200.132.0/22 AS42719
91.200.164.0/22 AS42719 91.200.176.0/22 AS42719
91.200.56.0/22 AS43791 91.200.60.0/22 AS43791
91.200.72.0/22 AS43799 91.200.80.0/22 AS43799
I (and others) mentioned at the Address Policy WG the probability of an
imminent IPv4 landgrab - these two recent incidents seem to suggest that
it has started. How well can RIPE policies stand up to such deliberate
and abusive attacks? In particular, how protected would the community
be against an LIR that intentionally submits applications which rely on
data the LIR knows is bogus? The LIR is not identified on the WHOIS
output - but if the only policing of the application is done by the LIRs
(as I'm told that RIPE hostmasters are not allowed to question details
supporting an application for resources) perhaps the identity of the LIR
should be displayed against the IP range, so that patterns of dishonesty
can quickly become visible?
> We do sometimes assign resources to organisations for use outside our
> region, although it rarely happens, and such requests are handled very
> carefully as they are rather unusual.
I'd welcome some clarification on the policies involved there: is that
just to entities ("organisations") located, at least nominally, within
the RIPE service region: with operations outside that region - or would
entities/organisations within other regions qualify? I ask because the
other questionable incident that came to our attention recently was the
use of 85.255.112.0/20 in California USA, when it was shown in the RIPE
database as unassigned space: and we discovered that an assignment was,
mysteriously, made of that space by the RIPE Hostmaster to "Inhoster" on
the very day I pointed out the inappropriate use, and that assignment
has also recently had its data changed: showing it as now being assigned
to a "UkrTeleGroup". But still it is used - solely - in California USA.
> It is a normal occurrence that a request is denied by one of the RIRs.
> If the reason for the denial is related to the location of the network,
> the end-user is then referred to the correct RIR. This is normally
> nothing to be suspicious about as there are many legitimate
> organisations that have operations in multiple RIR regions.
Given the (apparent) disparity in policy implementation between RIPE
and the other RIRs - most of whose hostmasters are empowered to (and
indeed do) check for and reject abusive applications it seems RIPE
may soon be regularly targeted by organisations worldwide who cannot,
for whatever reason, get resource assignments from their local RIR.
> Could you tell us a little about the circumstances that brought
> this range to your attention? Any information might help us with
> our investigation.
We have been tracking the "Russian Business Network" and also "Boris
Mizhen" for some time now, and we have been monitoring routing and
other changes which tell us their traffic has moved to new routes.
It is, however, unlikely that their actual location has changed, as
traceroutes to IP addresses in the new ranges are indicative of the
use of a "traceroute simulator" rather than of a real network path.
Best regards
--
Richard D G Cox
CIO, The Spamhaus Project
http://www.spamhaus.org
From alexlh at ripe.net Wed Nov 7 16:05:30 2007
From: alexlh at ripe.net (Alex Le Heux)
Date: Wed, 7 Nov 2007 16:05:30 +0100
Subject: [dp-tf] Re: 91.198.71.0 - 91.198.71.255
In-Reply-To:
References: <90CBBE18-BF6F-4FC8-B9BB-1065F529B1B8@ripe.net>
Message-ID: <655EB3B1-7E0C-4B41-8780-FBA14FD6BF37@ripe.net>
Dear Richard,
Thank you for providing us with a list of specific resources that
might be associated with this event. We will add them to our
investigation. You can be sure that if we find fraudulent
registrations, we will take appropriate action. Unfortunately neither
the RIPE Policies nor our legal framework enables us to pursue action
against any other type of abuse.
All requests that we receive are treated equally, and where needed, we
verify the identity of the requester to the best of our abilities. We
also monitor the RIPE Database for unauthorised changes and take
action where required. Usually these cases turn out to be legitimate
company name changes or changes of ownership. Some of the changes in
the RIPE Database that you have noticed are such cases.
We do not however monitor the BGP routing table, as our mandate
specifically does not extend to policing routing.
It has been suggested several times over the past years that we should
police routing. However, there has never been consensus in the
community that we should actually do this. If you wish to open a
discussion on this issue, the Address Policy Working Group is probably
the best venue.
A possible "land grab" for the remaining IPv4 address space is of
course something that we keep a close watch on. So far, there have
been no indications that one is ongoing. It is also highly unlikely
that such a land grab would take the shape of a relatively small
number of small PI assignments. The grand total of PI space that we
assign is less than 2% of the total space that we assign and allocate,
so such an event would be extremely noticeable. Also, as we publish
our assignment and allocation data daily, there are more eyes than
just ours watching, so a sudden change in these patterns would be very
obvious to many people.
Resources that the RIPE NCC allocates and assigns are, in principle,
for use in the RIPE region. Our policies do no define precisely what
"use in the RIPE region" means. Over the years the RIRs have developed
a procedural framework for dealing with cross-region requests:
- When the network is physically located in our region, even though
connectivity might not go through our region, that network is eligible
to receive resources from the RIPE NCC.
- When a network is physically located outside our region but the
routing originates inside our region it is also eligible.
- When the request comes through a RIPE region LIR who is also the
connectivity provider, it is also eligible.
Note that these are guidelines, as by their nature these requests
cover a large variety of situations. When needed, there is
communication between the different RIRs about such requests.
If you have noticed a disparity between the different RIRs that does
not come from differences in the regional policies, I would be very
interested to hear about this.
I have also discussed your request for historical data with our legal
team, and any data not currently available to the public requires a
court order for the RIPE NCC to release it. This applies even to data
that was published in the past, but is no longer publicly available.
Finally, your suggestion to include the identity of the LIR in PI/AS
assignment objects is an interesting one. If you wish to pursue it, it
should be made to the Database and/or Address Policy Working Groups.
Best Regards,
Alex Le Heux
RIPE NCC
On Nov 4, 2007, at 17:50, Richard Cox wrote:
> (Copied to APWG-Chairs and DP-TF in view of the policy implications)
>
> On 02/11/2007 16:36:35, Alex Le Heux wrote:
>
>> As it turns out, we had already noticed the change in registration
>> data a few weeks ago and are currently in contact with the LIR.
>> We have established procedures that are designed to track changes
>> like this, and this case is already under investigation.
>
> There appear to be seven other ranges and ASNs, similarly acquired.
>
> 193.33.128.0/23 AS42672 194.110.69.0/24 AS42811
> 91.193.40.0/22 AS42662 91.193.56.0/22 AS42672
> 91.194.140.0/23 AS43188 91.195.116.0/23 AS43702
> 91.196.232.0/22 AS43259 91.198.71.0/24 AS43603
>
>> We have audited the request and our policies and procedures
>> were correctly applied when this range was assigned.
>
> That's obviously very worrying - because it implies that any similar
> new application now would also be granted, and the claims that RIPE
> still has three years to go before IP4 exhaustion would then be seen
> as having been highly optimistic!
>
> I note your earlier comment about the data having been recently
> changed:
> so are you saying that the original application was valid just because
> it had an address in the RIPE region - even though that address may
> have
> been meaningless? If so, are you able to remind us what that address
> originally was (as at the time it would have been "public" data)?
>
> As you may know, the entity believed to be using these IP
> assignments is
> the notorious "Russian Business Network" about which much has recently
> been written: and http://en.wikipedia.org/wiki/
> Russian_Business_Network
> provides a convenient index to the more significant of those articles.
>
> The RIPE NCC cannot, of course, be concerned with any criminal
> activity
> that uses IP addresses it assigns, but I believe the RIPE NCC does
> need
> to be concerned about the obtaining by dishonest means of resources
> that
> are owned by the community and entrusted to the stewardship of RIPE
> NCC.
>
> During RIPE 55 I mentioned the earlier cases of shell companies set up
> apparently by a "Boris Mizhen" to apply for IP resources for spamming
> purposes (ie to avoid filters) and I understand that the LIR handling
> those applications (Merezha) has previously been linked to
> questionable
> assignments. For the record, the IP ranges and ASNs involved with
> that
> series of incidents, were as follows:
>
> 91.193.152.0/22 AS42719 91.193.192.0/22 AS42719
> 91.193.216.0/22 AS42719 91.193.88.0/22 AS42719
> 91.200.124.0/22 AS42719 91.200.132.0/22 AS42719
> 91.200.164.0/22 AS42719 91.200.176.0/22 AS42719
> 91.200.56.0/22 AS43791 91.200.60.0/22 AS43791
> 91.200.72.0/22 AS43799 91.200.80.0/22 AS43799
>
> I (and others) mentioned at the Address Policy WG the probability of
> an
> imminent IPv4 landgrab - these two recent incidents seem to suggest
> that
> it has started. How well can RIPE policies stand up to such
> deliberate
> and abusive attacks? In particular, how protected would the community
> be against an LIR that intentionally submits applications which rely
> on
> data the LIR knows is bogus? The LIR is not identified on the WHOIS
> output - but if the only policing of the application is done by the
> LIRs
> (as I'm told that RIPE hostmasters are not allowed to question details
> supporting an application for resources) perhaps the identity of the
> LIR
> should be displayed against the IP range, so that patterns of
> dishonesty
> can quickly become visible?
>
>> We do sometimes assign resources to organisations for use outside our
>> region, although it rarely happens, and such requests are handled
>> very
>> carefully as they are rather unusual.
>
> I'd welcome some clarification on the policies involved there: is that
> just to entities ("organisations") located, at least nominally, within
> the RIPE service region: with operations outside that region - or
> would
> entities/organisations within other regions qualify? I ask because
> the
> other questionable incident that came to our attention recently was
> the
> use of 85.255.112.0/20 in California USA, when it was shown in the
> RIPE
> database as unassigned space: and we discovered that an assignment
> was,
> mysteriously, made of that space by the RIPE Hostmaster to
> "Inhoster" on
> the very day I pointed out the inappropriate use, and that assignment
> has also recently had its data changed: showing it as now being
> assigned
> to a "UkrTeleGroup". But still it is used - solely - in California
> USA.
>
>> It is a normal occurrence that a request is denied by one of the
>> RIRs.
>> If the reason for the denial is related to the location of the
>> network,
>> the end-user is then referred to the correct RIR. This is normally
>> nothing to be suspicious about as there are many legitimate
>> organisations that have operations in multiple RIR regions.
>
> Given the (apparent) disparity in policy implementation between RIPE
> and the other RIRs - most of whose hostmasters are empowered to (and
> indeed do) check for and reject abusive applications it seems RIPE
> may soon be regularly targeted by organisations worldwide who cannot,
> for whatever reason, get resource assignments from their local RIR.
>
>> Could you tell us a little about the circumstances that brought
>> this range to your attention? Any information might help us with
>> our investigation.
>
> We have been tracking the "Russian Business Network" and also "Boris
> Mizhen" for some time now, and we have been monitoring routing and
> other changes which tell us their traffic has moved to new routes.
> It is, however, unlikely that their actual location has changed, as
> traceroutes to IP addresses in the new ranges are indicative of the
> use of a "traceroute simulator" rather than of a real network path.
>
> Best regards
>
> --
> Richard D G Cox
> CIO, The Spamhaus Project
> http://www.spamhaus.org
>
Best regards,
Alex Le Heux
RIPE NCC IP Resource Analyst
From gert at space.net Thu Nov 8 17:57:59 2007
From: gert at space.net (Gert Doering)
Date: Thu, 8 Nov 2007 17:57:59 +0100
Subject: [dp-tf] Re: [apwg-chairs] Re: 91.198.71.0 - 91.198.71.255
In-Reply-To: <655EB3B1-7E0C-4B41-8780-FBA14FD6BF37@ripe.net>
References: <90CBBE18-BF6F-4FC8-B9BB-1065F529B1B8@ripe.net> <655EB3B1-7E0C-4B41-8780-FBA14FD6BF37@ripe.net>
Message-ID: <20071108165759.GR69215@Space.Net>
Hi,
On Wed, Nov 07, 2007 at 04:05:30PM +0100, Alex Le Heux wrote:
> Finally, your suggestion to include the identity of the LIR in PI/AS
> assignment objects is an interesting one. If you wish to pursue it, it
> should be made to the Database and/or Address Policy Working Groups.
Actually I think that this wouldn't be easy today (given that PI
stands for "independent"), but with the new contract framework, we
*do* have the instruments to tag PI/AS objects to "who is the
currently-responsible LIR for this"?
Whether we want (or even are allowed to) to publish this information is
a different matter, and I'm not in a position to give a good answer on
this.
Gert Doering
-- APWG chair
--
Total number of prefixes smaller than registry allocations: 122119
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
From leo.vegoda at icann.org Fri Nov 9 18:52:29 2007
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Fri, 9 Nov 2007 18:52:29 +0100
Subject: [dp-tf] Re: [apwg-chairs] Re: 91.198.71.0 - 91.198.71.255
In-Reply-To: <20071108165759.GR69215@Space.Net>
References: <90CBBE18-BF6F-4FC8-B9BB-1065F529B1B8@ripe.net> <655EB3B1-7E0C-4B41-8780-FBA14FD6BF37@ripe.net> <20071108165759.GR69215@Space.Net>
Message-ID: <0F2B4597-B8D2-4E48-BC75-5CF2FE462BB2@icann.org>
On 8 Nov 2007, at 17:57, Gert Doering wrote:
[...]
>> Finally, your suggestion to include the identity of the LIR in PI/AS
>> assignment objects is an interesting one. If you wish to pursue it,
>> it
>> should be made to the Database and/or Address Policy Working Groups.
>
> Actually I think that this wouldn't be easy today (given that PI
> stands for "independent"), but with the new contract framework, we
> *do* have the instruments to tag PI/AS objects to "who is the
> currently-responsible LIR for this"?
Why would we care which LIR sent in a request for a PI assignment and
why would we want to require "independent" networks to maintain a
contractual relationship with an LIR?
I can't speak for anyone else but I don't care who sends in the
request. I care who is operating the network and how to contact them.
Anything that diverts us from maintaining operationally relevant
contact information is unhelpful.
Identifying LIRs strikes me as a mechanism to label LIRs as either
"good" or "bad" and doing this is at best likely to besmirch innocent
customers who are unrelated to any abuse. At worst it is likely to
cause them problems operating their networks. "Guilty by association"
is something we should try to avoid.
Regards,
Leo Vegoda
From gert at space.net Tue Nov 20 12:34:44 2007
From: gert at space.net (Gert Doering)
Date: Tue, 20 Nov 2007 12:34:44 +0100
Subject: [dp-tf] Re: [apwg-chairs] Re: 91.198.71.0 - 91.198.71.255
In-Reply-To: <0F2B4597-B8D2-4E48-BC75-5CF2FE462BB2@icann.org>
References: <90CBBE18-BF6F-4FC8-B9BB-1065F529B1B8@ripe.net> <655EB3B1-7E0C-4B41-8780-FBA14FD6BF37@ripe.net> <20071108165759.GR69215@Space.Net> <0F2B4597-B8D2-4E48-BC75-5CF2FE462BB2@icann.org>
Message-ID: <20071120113444.GT69215@Space.Net>
Hi,
just some more food for thought:
On Fri, Nov 09, 2007 at 06:52:29PM +0100, Leo Vegoda wrote:
> >Actually I think that this wouldn't be easy today (given that PI
> >stands for "independent"), but with the new contract framework, we
> >*do* have the instruments to tag PI/AS objects to "who is the
> >currently-responsible LIR for this"?
>
> Why would we care which LIR sent in a request for a PI assignment and
> why would we want to require "independent" networks to maintain a
> contractual relationship with an LIR?
Because the RIR wants to know how to reach the PI holder. Either they
have a direct relation - or if not, they need to go through a LIR.
(At least that seems to be what the RIPE community and the NCC agrees
to be the way forward).
Whether or not this relationship should be made publically viewable is
a completely different discussion, of course.
[..]
> Identifying LIRs strikes me as a mechanism to label LIRs as either
> "good" or "bad" and doing this is at best likely to besmirch innocent
> customers who are unrelated to any abuse. At worst it is likely to
> cause them problems operating their networks. "Guilty by association"
> is something we should try to avoid.
Actually it goes along with the responsibility thing of address
distribution. If the LIR doesn't do a proper job in maintaining contact
data for the end user, the blame falls back onto the LIR, and I think
that this is actually not such a bad thing.
Gert Doering
-- NetMaster
--
Total number of prefixes smaller than registry allocations: 110584
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL:
From leo.vegoda at icann.org Tue Nov 20 23:53:00 2007
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Tue, 20 Nov 2007 23:53:00 +0100
Subject: [dp-tf] Re: [apwg-chairs] Re: 91.198.71.0 - 91.198.71.255
In-Reply-To: <20071120113444.GT69215@Space.Net>
References: <90CBBE18-BF6F-4FC8-B9BB-1065F529B1B8@ripe.net> <655EB3B1-7E0C-4B41-8780-FBA14FD6BF37@ripe.net> <20071108165759.GR69215@Space.Net> <0F2B4597-B8D2-4E48-BC75-5CF2FE462BB2@icann.org> <20071120113444.GT69215@Space.Net>
Message-ID: <118FED7B-AD74-40DA-AF95-1DA3DA4A4172@icann.org>
Hi Gert,
On 20 Nov 2007, at 12:34, Gert Doering wrote:
[...]
>>> Actually I think that this wouldn't be easy today (given that PI
>>> stands for "independent"), but with the new contract framework, we
>>> *do* have the instruments to tag PI/AS objects to "who is the
>>> currently-responsible LIR for this"?
>>
>> Why would we care which LIR sent in a request for a PI assignment and
>> why would we want to require "independent" networks to maintain a
>> contractual relationship with an LIR?
>
> Because the RIR wants to know how to reach the PI holder. Either they
> have a direct relation - or if not, they need to go through a LIR.
>
> (At least that seems to be what the RIPE community and the NCC agrees
> to be the way forward).
>
> Whether or not this relationship should be made publically viewable is
> a completely different discussion, of course.
The RIPE NCC has always maintained records of which LIR sent in a
request for a PI assignments. I assume that this would continue. I
have doubts about whether publishing this information is appropriate.
>> Identifying LIRs strikes me as a mechanism to label LIRs as either
>> "good" or "bad" and doing this is at best likely to besmirch innocent
>> customers who are unrelated to any abuse. At worst it is likely to
>> cause them problems operating their networks. "Guilty by association"
>> is something we should try to avoid.
>
> Actually it goes along with the responsibility thing of address
> distribution. If the LIR doesn't do a proper job in maintaining
> contact
> data for the end user, the blame falls back onto the LIR, and I think
> that this is actually not such a bad thing.
I doubt that most LIRs are in a position to maintain the end users's
contact information as well as the end user. I understand that the
RIPE NCC encourages PI holders to have their own maintainer on the
inetnum for their address space. The current training material
mentions this on slide 72:
http://www.ripe.net/training/lir/material/lir_training_oct07-1.pdf
I expect a very well designed web based tool to allow end users to
manage their contact information would have a far more beneficial
effect that a contractual requirement for the LIR to do it for the end
user.
Regards,
Leo
From gert at space.net Wed Nov 21 08:21:37 2007
From: gert at space.net (Gert Doering)
Date: Wed, 21 Nov 2007 08:21:37 +0100
Subject: [dp-tf] Re: [apwg-chairs] Re: 91.198.71.0 - 91.198.71.255
In-Reply-To: <118FED7B-AD74-40DA-AF95-1DA3DA4A4172@icann.org>
References: <90CBBE18-BF6F-4FC8-B9BB-1065F529B1B8@ripe.net> <655EB3B1-7E0C-4B41-8780-FBA14FD6BF37@ripe.net> <20071108165759.GR69215@Space.Net> <0F2B4597-B8D2-4E48-BC75-5CF2FE462BB2@icann.org> <20071120113444.GT69215@Space.Net> <118FED7B-AD74-40DA-AF95-1DA3DA4A4172@icann.org>
Message-ID: <20071121072137.GN69215@Space.Net>
Hi,
On Tue, Nov 20, 2007 at 11:53:00PM +0100, Leo Vegoda wrote:
> I expect a very well designed web based tool to allow end users to
> manage their contact information would have a far more beneficial
> effect that a contractual requirement for the LIR to do it for the end
> user.
All nice and shiny. But what are you going to do if the end user does
*not* properly maintain their contact information?
Having requirements without a way to apply pressure if the requirements
are not met is not overly effective.
Gert Doering
-- NetMaster
--
Total number of prefixes smaller than registry allocations: 110584
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL:
From denis at ripe.net Thu Nov 22 19:47:53 2007
From: denis at ripe.net (Denis Walker)
Date: Thu, 22 Nov 2007 19:47:53 +0100
Subject: [dp-tf] unreferenced person/role object stats
Message-ID: <4745CED9.2060003@ripe.net>
HI
The RIPE NCC was asked to investigate the increasing number of
unreferenced person and role objects in the RIPE Database. This is
personal data that is not relevant to the purpose of the RIPE Database.
We have now done this investigation covering the last 5 years. The
results were surprising.
We found that one organisation is responsible for most of the
unreferenced person and role objects created in the RIPE Database this
year. They are also responsible for a large percentage of the
unreferenced person and role objects created in the RIPE Database over
the last 5 years.
These are the actual figures:
organisation X unreferenced person/role objects created compared with
total unreferenced person/role objects created for each year.
year X Total
2007 109031 134986 81% (Till October 31)
2006 13188 51393 26%
2005 13139 56006 24%
2004 12841 78204 16%
2003 98 38656 0.25% (from June 1)
Total 148297 359245 41%
Current total unreferenced person/role objects is 553572
of these 26.8% are from organisation X
We have contacted this member organisation for an explanation and asked
for permission to delete all these objects in one step.
Regards
Denis Walker
RIPE NCC
From mis at wari.net Sat Nov 24 17:59:18 2007
From: mis at wari.net (Manfredo Miserocchi)
Date: Sat, 24 Nov 2007 17:59:18 +0100
Subject: [dp-tf] unreferenced person/role object stats
In-Reply-To: <4745CED9.2060003@ripe.net>
References: <4745CED9.2060003@ripe.net>
Message-ID:
-----Original Message-----
From: Denis Walker
To: dp-tf at ripe.net
Date: Thu, 22 Nov 2007 19:47:53 +0100
Subject: [dp-tf] unreferenced person/role object stats
Great job Denis !!
>
> year X Total
> 2007 109031 134986 81% (Till October 31)
WOW !!
>
> Current total unreferenced person/role objects is 553572
> of these 26.8% are from organisation X
>
> We have contacted this member organisation for an explanation
Do you mean that the organization is a LIR ??
Cheers/Manfredo
Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il presente messaggio Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo ed a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie.
You are hereby informed that this message contains confidential informations intended for the addressee's use only. If yu're not the addressee and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you.
From denis at ripe.net Sun Nov 25 22:49:20 2007
From: denis at ripe.net (Denis Walker)
Date: Sun, 25 Nov 2007 22:49:20 +0100
Subject: [dp-tf] unreferenced person/role object stats
In-Reply-To:
References: <4745CED9.2060003@ripe.net>
Message-ID: <4749EDE0.1060308@ripe.net>
Manfredo Miserocchi wrote:
> -----Original Message-----
> From: Denis Walker
> To: dp-tf at ripe.net
> Date: Thu, 22 Nov 2007 19:47:53 +0100
> Subject: [dp-tf] unreferenced person/role object stats
>
>
> Great job Denis !!
>
>
>> year X Total
>> 2007 109031 134986 81% (Till October 31)
>>
>
> WOW !!
>
>
>> Current total unreferenced person/role objects is 553572
>> of these 26.8% are from organisation X
>>
>> We have contacted this member organisation for an explanation
>>
>
> Do you mean that the organization is a LIR ??
>
Yes, but I don't want to name them publicly. They responded to my mail
very quickly and will work with us to sort this out.
cheers
denis
>
> Cheers/Manfredo
>
>
> Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il presente messaggio Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo ed a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie.
>
> You are hereby informed that this message contains confidential informations intended for the addressee's use only. If yu're not the addressee and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you.
>
>
>
From mis at wari.net Tue Nov 27 10:39:37 2007
From: mis at wari.net (Manfredo Miserocchi)
Date: Tue, 27 Nov 2007 10:39:37 +0100
Subject: [dp-tf] unreferenced person/role object stats
In-Reply-To: <4749EDE0.1060308@ripe.net>
References: <4745CED9.2060003@ripe.net> <4749EDE0.1060308@ripe.net>
Message-ID:
-----Original Message-----
From: Denis Walker
To: mis at wari.net
Cc: dp-tf at ripe.net
Date: Sun, 25 Nov 2007 22:49:20 +0100
Subject: Re: [dp-tf] unreferenced person/role object stats
> > Do you mean that the organization is a LIR ??
> >
>
> Yes, but I don't want to name them publicly. They responded to my mail
> very quickly and will work with us to sort this out.
Denis, I understood the why....only I was expected to have this from an
anonymous....
Let us informed
Cheers/Manfredo
Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il presente messaggio Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo ed a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie.
You are hereby informed that this message contains confidential informations intended for the addressee's use only. If yu're not the addressee and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you.