<div dir="ltr"><div>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. <br></div><div><br></div><div>Jacob Slater</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 21, 2019 at 10:33 AM Edward Shryane via db-wg <<a href="mailto:db-wg@ripe.net">db-wg@ripe.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Gert,<br>
<br>
> On 21 Oct 2019, at 15:48, Gert Doering <<a href="mailto:gert@space.net" target="_blank">gert@space.net</a>> wrote:<br>
> <br>
> Hi,<br>
> <br>
> On Mon, Oct 21, 2019 at 11:51:12AM +0200, Edward Shryane via db-wg wrote:<br>
>> as presented during the DB-WG session at RIPE 79, we wish to extend the "Default Maintainer" functionality for LIR organisations.<br>
> <br>
> I haven't seen that presentation, so forgive me if I haven't understood<br>
> things properly.<br>
> <br>
<br>
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.<br>
<br>
<br>
>> Secondly, to automatically (re-)set the Default Maintainer on a nightly basis, on *all* top-level resources:<br>
>> <br>
>> - Fix inconsistencies due to manual updates<br>
>> - Add the default maintainer (with an mnt-by: attribute), and remove other user maintainer(s)<br>
> <br>
> Why so? If a LIR puts something into the database, which is allowed by<br>
> business rules, I see no rationale for resetting it.<br>
> <br>
<br>
The Default Maintainer is (also) set by the user, in the LIR Portal, and is visible under "Account Details".<br>
<br>
This proposal is to make sure the maintainer in the RIPE database is aligned with the maintainer specified in the LIR Portal.<br>
<br>
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).<br>
<br>
> Now if we as a group decide that certain changes should not be allowed,<br>
> that's a different matter - but do not arbitrarily undo user changes unless <br>
> specifically asked for ("I have lost my maintainer password").<br>
> <br>
<br>
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).<br>
<br>
Should setting a Default Maintainer in the LIR Portal, preclude other mntners (as an mnt-by) on an LIR's top-level resources ?<br>
<br>
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) ?<br>
<br>
I welcome any feedback.<br>
<br>
<br>
> Gert Doering<br>
> -- NetMaster<br>
> -- <br>
> have you enabled IPv6 on something today...?<br>
> <br>
> SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer<br>
> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann<br>
> D-80807 Muenchen HRB: 136055 (AG Muenchen)<br>
> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279<br>
<br>
<br>
<br>
Regards<br>
Ed Shryane<br>
RIPE NCC<br>
<br>
<br>
</blockquote></div>