This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
[db-wg] restrict usage of RIPE-NCC-RPSL-MNT
- Previous message (by thread): [db-wg] restrict usage of RIPE-NCC-RPSL-MNT
- Next message (by thread): [db-wg] restrict usage of RIPE-NCC-RPSL-MNT
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Job Snijders
job at instituut.net
Thu Nov 20 14:16:01 CET 2014
On Sat, Nov 15, 2014 at 10:33:12PM +0400, Alex Semenyaka wrote: > I would say it depends on the [future] AfriNIC procedure. I mean if the > objects will be transferred not all at once but gradually there may be a > situation when some objects still have to be kept in RIPE DB, and other > (transferred ones) should live in AFRINIC DB. Obviously transferred objects > are subject to future change, so they will have to be synchronized or > removed from RIPE DB. In this scenario the object immunity can cause > needless trouble. > > Isn't it reasonable just to change the maintainer to the another one, with > the unknown password? RIPE NCC can work with affected parties which _only_ have "mnt-by: RIPE-NCC-RPSL-MNT" on a route object to get them to add another maintainer object. For all objects where there are multiple "mnt-by" lines, we just need to delete the "mnt-by: RIPE-NCC-RPSL-MNT" line and the object will be better secured. Kind regards, Job
- Previous message (by thread): [db-wg] restrict usage of RIPE-NCC-RPSL-MNT
- Next message (by thread): [db-wg] restrict usage of RIPE-NCC-RPSL-MNT
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]