Proposed change 2003.3: "reclaim:"-like functionality
Colleagues, This is one of a number of proposed changes to the way the RIPE Database works. These are changes that are intended to make the database work more consistently, as well as provide an increased level of security and control to users. Please have a look, and discuss it here. [2003.3] Implementation of "reclaim:"-like functionality -------------------------------------------------------- Proposal: Any maintainer that would have been able to authorise the creation of an object can authorise the deletion of the same object. If creation of an object requires authorisation from multiple maintainers (e.g. route objects that require authorisation from an aut-num and an inetnum), then any of those maintainers may authorise the deletion. Motivation: The maintainer of an object is responsible for insuring that the data in the object is accurate. For hierarchical objects the maintainer can delegate responsibility for a subset. However, under the current implementation, there is no way for the maintainer to delete objects created and delegated to maintainers who should not or will not have access to the resources represented by these objects any more. For example, if the holder of portable address space changes ISP, then the address space will be advertised from a different AS. This means that the old route object is invalid and should be deleted. However, if the old ISP maintains the object, then the holder of the space has no way to delete the old object. This old route object will prevent the creation of a new route object that represents the new arrangement. The "reclaim:" attribute defined in RPSS allows for very similar functionality, but it may not be added to space that already has objects. This means that any existing more-specific objects cannot be deleted by the maintainers of the less-specific objects. For the case of old objects - the ones most likely to need such deletion - this means that the "reclaim:" attribute does not help. The "reclaim:" attribute also has a different syntax, depending on the specific object type that it is present in. This complicates parsing of objects. -- Shane Kerr RIPE NCC
Hi, On Tue, Mar 04, 2003 at 03:54:56PM +0100, Shane Kerr wrote:
Proposal:
Any maintainer that would have been able to authorise the creation of an object can authorise the deletion of the same object.
If creation of an object requires authorisation from multiple maintainers (e.g. route objects that require authorisation from an aut-num and an inetnum), then any of those maintainers may authorise the deletion.
I like this. It gives reclaim: functionality without having to add all the additional code & checks. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57021 (57147) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hi, Are we going to introduce a new attribute for this, or just change the database behavior to allow deletion by 'creator' maintainers? Cheers, Sanjaya
-----Original Message----- From: db-wg-admin@ripe.net [mailto:db-wg-admin@ripe.net] On Behalf Of Shane Kerr Sent: Wednesday, 5 March 2003 12:55 AM To: db-wg@ripe.net Subject: [db-wg] Proposed change 2003.3: "reclaim:"-like functionality
Colleagues,
This is one of a number of proposed changes to the way the RIPE Database works. These are changes that are intended to make the database work more consistently, as well as provide an increased level of security and control to users.
Please have a look, and discuss it here.
[2003.3] Implementation of "reclaim:"-like functionality --------------------------------------------------------
Proposal:
Any maintainer that would have been able to authorise the creation of an object can authorise the deletion of the same object.
If creation of an object requires authorisation from multiple maintainers (e.g. route objects that require authorisation from an aut-num and an inetnum), then any of those maintainers may authorise the deletion.
Motivation:
The maintainer of an object is responsible for insuring that the data in the object is accurate. For hierarchical objects the maintainer can delegate responsibility for a subset. However, under the current implementation, there is no way for the maintainer to delete objects created and delegated to maintainers who should not or will not have access to the resources represented by these objects any more.
For example, if the holder of portable address space changes ISP, then the address space will be advertised from a different AS. This means that the old route object is invalid and should be deleted. However, if the old ISP maintains the object, then the holder of the space has no way to delete the old object. This old route object will prevent the creation of a new route object that represents the new arrangement.
The "reclaim:" attribute defined in RPSS allows for very similar functionality, but it may not be added to space that already has objects. This means that any existing more-specific objects cannot be deleted by the maintainers of the less-specific objects. For the case of old objects - the ones most likely to need such deletion - this means that the "reclaim:" attribute does not help.
The "reclaim:" attribute also has a different syntax, depending on the specific object type that it is present in. This complicates parsing of objects.
-- Shane Kerr RIPE NCC
On 2003-03-10 15:53:53 +1000, Sanjaya wrote:
Are we going to introduce a new attribute for this, or just change the database behavior to allow deletion by 'creator' maintainers?
My idea was to change the behaviour without adding a new attribute. Adding a new attribute that allows this would be an unnecessary extra step, I think. -- Shane Kerr RIPE NCC
participants (3)
-
Gert Doering -
Sanjaya -
Shane Kerr