Set Default Maintainer on all Top-level Resources
Dear Colleagues, as presented during the DB-WG session at RIPE 79, we wish to extend the "Default Maintainer" functionality for LIR organisations. Firstly, to set the Default Maintainer (with an mnt-by: attribute) on *all* top-level resources (where the org: reference is the LIR itself): - IPv4 and IPv6 allocations (the current behaviour) - ASNs - IPv4 and IPv6 assignments - IPv4 LEGACY resources Secondly, to automatically (re-)set the Default Maintainer on a nightly basis, on *all* top-level resources: - Fix inconsistencies due to manual updates - Add the default maintainer (with an mnt-by: attribute), and remove other user maintainer(s) Please let me know of any feedback or questions you may have. Regards Ed Shryane RIPE NCC
Hi, On Mon, Oct 21, 2019 at 11:51:12AM +0200, Edward Shryane via db-wg wrote:
as presented during the DB-WG session at RIPE 79, we wish to extend the "Default Maintainer" functionality for LIR organisations.
I haven't seen that presentation, so forgive me if I haven't understood things properly.
Secondly, to automatically (re-)set the Default Maintainer on a nightly basis, on *all* top-level resources:
- Fix inconsistencies due to manual updates - Add the default maintainer (with an mnt-by: attribute), and remove other user maintainer(s)
Why so? If a LIR puts something into the database, which is allowed by business rules, I see no rationale for resetting it. Now if we as a group decide that certain changes should not be allowed, that's a different matter - but do not arbitrarily undo user changes unless specifically asked for ("I have lost my maintainer password"). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi Gert,
On 21 Oct 2019, at 15:48, Gert Doering <gert@space.net> wrote:
Hi,
On Mon, Oct 21, 2019 at 11:51:12AM +0200, Edward Shryane via db-wg wrote:
as presented during the DB-WG session at RIPE 79, we wish to extend the "Default Maintainer" functionality for LIR organisations.
I haven't seen that presentation, so forgive me if I haven't understood things properly.
Thank you for your feedback, I also proposed these changes on the db-wg list so it wasn't necessary to sit through the presentation.
Secondly, to automatically (re-)set the Default Maintainer on a nightly basis, on *all* top-level resources:
- Fix inconsistencies due to manual updates - Add the default maintainer (with an mnt-by: attribute), and remove other user maintainer(s)
Why so? If a LIR puts something into the database, which is allowed by business rules, I see no rationale for resetting it.
The Default Maintainer is (also) set by the user, in the LIR Portal, and is visible under "Account Details". This proposal is to make sure the maintainer in the RIPE database is aligned with the maintainer specified in the LIR Portal. It could be confusing if the RIPE database doesn't match the LIR Portal, and also, any additional maintainer(s) in the RIPE database are not visible in the LIR Portal (so it's not clear who can update which objects).
Now if we as a group decide that certain changes should not be allowed, that's a different matter - but do not arbitrarily undo user changes unless specifically asked for ("I have lost my maintainer password").
This proposal aims to resolve differences in user changes in the LIR Portal (i.e. set Default Maintainer), and the RIPE database (i.e. the mnt-by on top-level resources). Should setting a Default Maintainer in the LIR Portal, preclude other mntners (as an mnt-by) on an LIR's top-level resources ? Should we require the Default Maintainer (as an mnt-by) on an LIR's top-level resources (i.e., don't allow it to be removed, as the user has set it in the LIR Portal) ? I welcome any feedback.
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Regards Ed Shryane RIPE NCC
If the goal is to ensure consistency between the LIR Portal and the RIPE database, why not simply make all mntner attributes on top-level resources managed by the NCC? If changes are made in the LIR portal, any changes could go live immediately. After an initial cleanup, there would be no need to constantly reset it. Jacob Slater On Mon, Oct 21, 2019 at 10:33 AM Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Hi Gert,
On 21 Oct 2019, at 15:48, Gert Doering <gert@space.net> wrote:
Hi,
On Mon, Oct 21, 2019 at 11:51:12AM +0200, Edward Shryane via db-wg wrote:
as presented during the DB-WG session at RIPE 79, we wish to extend the "Default Maintainer" functionality for LIR organisations.
I haven't seen that presentation, so forgive me if I haven't understood things properly.
Thank you for your feedback, I also proposed these changes on the db-wg list so it wasn't necessary to sit through the presentation.
Secondly, to automatically (re-)set the Default Maintainer on a nightly basis, on *all* top-level resources:
- Fix inconsistencies due to manual updates - Add the default maintainer (with an mnt-by: attribute), and remove other user maintainer(s)
Why so? If a LIR puts something into the database, which is allowed by business rules, I see no rationale for resetting it.
The Default Maintainer is (also) set by the user, in the LIR Portal, and is visible under "Account Details".
This proposal is to make sure the maintainer in the RIPE database is aligned with the maintainer specified in the LIR Portal.
It could be confusing if the RIPE database doesn't match the LIR Portal, and also, any additional maintainer(s) in the RIPE database are not visible in the LIR Portal (so it's not clear who can update which objects).
Now if we as a group decide that certain changes should not be allowed, that's a different matter - but do not arbitrarily undo user changes unless specifically asked for ("I have lost my maintainer password").
This proposal aims to resolve differences in user changes in the LIR Portal (i.e. set Default Maintainer), and the RIPE database (i.e. the mnt-by on top-level resources).
Should setting a Default Maintainer in the LIR Portal, preclude other mntners (as an mnt-by) on an LIR's top-level resources ?
Should we require the Default Maintainer (as an mnt-by) on an LIR's top-level resources (i.e., don't allow it to be removed, as the user has set it in the LIR Portal) ?
I welcome any feedback.
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Regards Ed Shryane RIPE NCC
Hi Jacob,
On 21 Oct 2019, at 16:57, Jacob Slater <jacob@rezero.org> wrote:
If the goal is to ensure consistency between the LIR Portal and the RIPE database, why not simply make all mntner attributes on top-level resources managed by the NCC? If changes are made in the LIR portal, any changes could go live immediately. After an initial cleanup, there would be no need to constantly reset it.
Jacob Slater
Yes, we could make the "mnt-by" attribute on top-level resources managed by the RIPE NCC (where a default maintainer is set), as an alternative to the nightly job. Should we allow additional user maintainers on top-level resources, where a default maintainer is also set? Regards Ed Shryane RIPE NCC
participants (3)
-
Edward Shryane -
Gert Doering -
Jacob Slater