-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Can I delete aut-num object from RIPE DB if it registered by me (as LIR) for one of our customers and I have NO auth info refered by object's mnt-by field? In different way question may sound like: how can I return registered resources (PI/ASN) if my customer gone? What is BCP within LIRs for this case? Thanks for advices! P.S. If I choise wrong WG, don't hit me too much ;) :) - -- Dmitry Kiselev -----BEGIN PGP SIGNATURE----- iD8DBQFC8csaZaocAwQhSAQRAhg7AKChkv2sTl4qBoRcnFxAMqYGEQ5kCACbBacj KvojUT8PbYFXR/emNFga9EM= =IFJU -----END PGP SIGNATURE-----
Hi!
Can I delete aut-num object from RIPE DB if it registered by me (as LIR) for one of our customers and I have NO auth info refered by object's mnt-by field?
I think you can't. So if you need to keep control on objects - keep your mnt-by there. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
On Thu, Aug 04, 2005 at 12:51:29PM +0400, Max Tulyev wrote:
Can I delete aut-num object from RIPE DB if it registered by me (as LIR) for one of our customers and I have NO auth info refered by object's mnt-by field?
I think you can't.
So if you need to keep control on objects - keep your mnt-by there.
Even then the ASN/PI is assigned to his customer, not to him. Unless he's being authorized by the "gone customer" to delete that stuff (and tell RIPE about it, otherwise it's probably a "weird state"), he's doing something "illegal" (to the system). It's not his ASN/PI, it's the customer's. No matter thru which LIR the requests where tunneled. Can NCC folks confirm/correct this view? Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Hi, Daniel Roesen wrote: [...]
Can I delete aut-num object from RIPE DB if it registered by me (as LIR) for one of our customers and I have NO auth info refered by object's mnt-by field?
I think you can't.
So if you need to keep control on objects - keep your mnt-by there.
Even then the ASN/PI is assigned to his customer, not to him. Unless he's being authorized by the "gone customer" to delete that stuff (and tell RIPE about it, otherwise it's probably a "weird state"), he's doing something "illegal" (to the system). It's not his ASN/PI, it's the customer's. No matter thru which LIR the requests where tunneled.
Can NCC folks confirm/correct this view?
You're right in stating that AS Numbers and PI ranges are assigned to end users rather than to the LIRs that request them. If the end user no longer exists then we can clean up the database and make the unused resources available for assignment to another network - after a suitable quarantine period. If the LIR that requested a resource is making the report then contacting us in the ticket that was used in the request is useful. Otherwise, please contact us at <reg-review@ripe.net> and we'll do our best to help sort things out. Regards, -- leo vegoda RIPE NCC Registration Services Manager
If the end user no longer exists then we can clean up the database and make the unused resources available for assignment to another network - after a suitable quarantine period.
has this happened? randy
Randy Bush wrote:
If the end user no longer exists then we can clean up the database and make the unused resources available for assignment to another network - after a suitable quarantine period.
has this happened?
Yes, we have a couple of dozen AS Numbers in quarantine at the moment. Regards, -- leo vegoda RIPE NCC Registration Services Manager
If the end user no longer exists then we can clean up the database and make the unused resources available for assignment to another network - after a suitable quarantine period. has this happened? Yes, we have a couple of dozen AS Numbers in quarantine at the moment.
cool! do tell us if any space is actually recovered. we talk about recovery, but i worry that we actually gain so little. randy
Hi Randy, On Aug 4, 2005, at 7:03 pm, Randy Bush wrote:
If the end user no longer exists then we can clean up the database and make the unused resources available for assignment to another network - after a suitable quarantine period.
has this happened?
Yes, we have a couple of dozen AS Numbers in quarantine at the moment.
cool! do tell us if any space is actually recovered. we talk about recovery, but i worry that we actually gain so little.
We try to recover unused address space, too. We have small amounts coming back in, bit not a great deal. Regards, -- leo vegoda Registration Services Manager RIPE NCC
leo vegoda wrote:
Hi Randy,
On Aug 4, 2005, at 7:03 pm, Randy Bush wrote:
If the end user no longer exists then we can clean up the database and make the unused resources available for assignment to another network - after a suitable quarantine period.
has this happened?
Yes, we have a couple of dozen AS Numbers in quarantine at the moment.
cool! do tell us if any space is actually recovered. we talk about recovery, but i worry that we actually gain so little.
We try to recover unused address space, too. We have small amounts coming back in, bit not a great deal.
Indeed, just in process of returning two AS numbers and /22, /23, /24.... M
On Thu, 4 Aug 2005, leo vegoda wrote:
If the end user no longer exists then we can clean up the database and make the unused resources available for assignment to another network - after a suitable quarantine period.
What amounts to "suitable quarantine period"? How do you determine if the user "no longer exists"? What resources will fall under this system? Is such resource recovery covered by RIPE policies (if so which one)? -- William Leibzon Elan Networks william@elan.net
Hi, william(at)elan.net wrote:
If the end user no longer exists then we can clean up the database and make the unused resources available for assignment to another network - after a suitable quarantine period.
What amounts to "suitable quarantine period"?
It varies. Our concern is that the resource has not appeared in the RIPE Database or those route views we have access to for a few months.
How do you determine if the user "no longer exists"?
Most of the time we are contacted by the system or network administrators of companies that are closing, telling us that they can return resources because their are turning their networks off. Essentially, it's people voluntarily handing back resources that their networks no longer need. In other cases we follow a set of steps to determine whether the resource is no longer in use. The precise details of the process can vary depending on where the resources were used - there are a few dozen countries in our service region.
What resources will fall under this system?
Is such resource recovery covered by RIPE policies (if so which one)?
This system covers all the resources we are responsible for managing. In section 6.6 of the IPv4 policy it states: "All assignments are valid as long as the original criteria on which the assignment was based are still valid and the assignment is properly registered in the RIPE Database." In section 4.1 of the IPv6 policy it states: "The policies in this document are based upon the understanding that globally unique IPv6 unicast address space is licensed for use rather than owned. Specifically, IP addresses will be allocated and assigned on a license basis, with licenses subject to renewal on a periodic basis. The granting of a license is subject to specific conditions applied at the start or renewal of the license. RIRs will generally renew licenses automatically, provided requesting organisations are making a “good faith” effort at meeting the criteria under which they qualified for or were granted an allocation or assignment. However, in those cases where a requesting organisation is not using the address space as intended, or is showing bad faith in following through on the associated obligation, RIRs reserve the right to not renew the license." In section 1.8 of the AS Number policy it states: "If an organisation has an AS Number that is no longer in use, it can be returned to the public pool of AS Numbers by sending a message to <hostmaster@ripe.net>. It can then be reassigned to another Autonomous System by the RIPE NCC." I hope this is helpful. Regards, -- leo vegoda "Good enough is not good enough" RIPE NCC Axel Pawlik Registration Services Manager 3 June 2005
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! On Thu, Aug 04, 2005 at 12:51:29PM +0400, Max Tulyev wrote:
Can I delete aut-num object from RIPE DB if it registered by me (as LIR) for one of our customers and I have NO auth info refered by object's mnt-by field?
I think you can't.
I think too. RIPE-252, part 3.6.2 says: Only those mntners referenced by the "mnt-by:" attributes are authorised to modify or delete the object. For future delete I must keep my own mntner in all mnt-by fields for customer's objects. For inetnum it is not a big problem, its modification rarely needed (mnt-routes helps also). Completely different situation with aut-num object. Import/export fields are subject of frequent change and each customer want to do it by himself according to his routing policy. But he can't while LIR's mntner protect an ASN object. In other way, according to current IPv4 and ASN policies my customer can use resources while "original criteria are still valid". Neither LIR nor RIPE NCC can't free those resources. Any additional agreement between LIR and customer are subject of their country jurisdiction not RIPE. Even if there a contract with words "must return recources if gone" RIPE can't do anything with objects.
So if you need to keep control on objects - keep your mnt-by there.
In this case customer must ask LIR to do any changes in RIPE DB. It is not a best choise, I think. - -- Dmitry Kiselev -----BEGIN PGP SIGNATURE----- iD8DBQFC8fENZaocAwQhSAQRAiX0AJ94AzEa54WauVFyBwASPBzuOMM3vQCdH7r1 2LRuKKQBa7JbwVH2V/HxFEo= =qYo1 -----END PGP SIGNATURE-----
Hi!
So if you need to keep control on objects - keep your mnt-by there.
In this case customer must ask LIR to do any changes in RIPE DB. It is not a best choise, I think.
But it is only choise you have if you need to keep control, for example, to collect yearly payments for PI/AS as it usually is in RU/UA. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Max Tulyev wrote:
Hi!
So if you need to keep control on objects - keep your mnt-by there.
In this case customer must ask LIR to do any changes in RIPE DB. It is not a best choise, I think.
But it is only choise you have if you need to keep control, for example, to collect yearly payments for PI/AS as it usually is in RU/UA.
... another approach could be to link a resource object to more than 1 maintainer. As the access checks are performed on a "logical OR" basis, this allows modifications to be submitted by anyone holding a credential as listed in _any_ of the mntner: objects. We are doing that with some (legacy) objects of our customers. Works pretty well. Of course it assumes a collaborative environment, and/or some sort of incentive for the customer to not remove "your" maintainer (e.g. relying on your connectivity :-). It might work in your environment, and it might not be feasible. Whenever this approach is implemented, it is useful to properly configure notifications. This at least gets you a mail message if "something goes wrong" withthe collaboration.... Wilfried.
participants (8)
-
Daniel Roesen -
Dmitry Kiselev -
leo vegoda -
Matthew Smith -
Max Tulyev -
Randy Bush -
Wilfried Woeber, UniVie/ACOnet -
william(at)elan.net