Re: [db-wg] Proposal to revert NWI-10

[Matthias Merkel via db-wg]

Hi Cynthia,

with all due respect, you did say "I see it as a policy that messes up data and 
wastes time for no real advantage." in your original email.

I think bringing this up with the RIPE NCC would be a good first step to get 
the implementation fixed.

Matthias Merkel
Staclar, Inc.

From: Cynthia Revström 
Sent: Monday, December 7, 2020 2:53 PM
To: Matthias Merkel 
Cc: DB-WG 
Subject: Re: [db-wg] Proposal to revert NWI-10

No I don't know what caused this, and if you read my original email you will 
see that I said "and how to implement it in a non-messy way." because yes ofc 
this is an implementation issue.
But also I don't see how this could be well implemented in a non-messy way.

- Cynthia


On Mon, Dec 7, 2020 at 2:51 PM Matthias Merkel 
mailto:matthias.mer...@staclar.com>> wrote:
Hi Cynthia,

do you have any idea what may have caused this? I'd say this is likely an issue 
with the implementation of the proposal, not with the proposal itself.

Matthias Merkel
Staclar, Inc.


From: Cynthia Revström mailto:m...@cynthia.re>>
Sent: Monday, December 7, 2020 2:49 PM
To: Matthias Merkel 
mailto:matthias.mer...@staclar.com>>
Cc: db-wg@ripe.net 
mailto:db-wg@ripe.net>>
Subject: Re: [db-wg] Proposal to revert NWI-10

This is not my point, yes I could easily ask them to fix my specific case.

My point is that I very much doubt I am the only one who has this issue, and I 
only noticed it as I was looking on bgp.he.net and noticed 
the GB flag.

- Cynthia


On Mon, Dec 7, 2020 at 2:48 PM Matthias Merkel 
mailto:matthias.mer...@staclar.com>> wrote:
Hi Cynthia,

ORG-ISSA10-RIPE is your LIR, right? It does indeed look like it should have a 
country attribute of Sweden. Did you ask the NCC about this already? Did they 
mention any reason for it being GB?

Matthias Merkel
Staclar, Inc.

From: Cynthia Revström mailto:m...@cynthia.re>>
Sent: Monday, December 7, 2020 2:40 PM
To: Matthias Merkel 
mailto:matthias.mer...@staclar.com>>
Cc: db-wg@ripe.net 
mailto:db-wg@ripe.net>>
Subject: Re: [db-wg] Proposal to revert NWI-10

Hi Matthias,

Well before NWI-10 there was no proper definition, but there is now a 
definition, and as a result the RIPE NCC updated the resources to GB whereas 
the LIR is quite obviously SE.

- Cynthia


On Mon, Dec 7, 2020 at 2:16 PM Matthias Merkel 
mailto:matthias.mer...@staclar.com>> wrote:

Hi Cynthia,



Could you please elaborate on why the data is now invalid (what you think it is 
supposed to be, what it is now and what situation is causing it to be this 
way)? My understanding is that there was never a “proper” definition of the 
country field.



Matthias Merkel

Staclar, Inc.



From: db-wg mailto:db-wg-boun...@ripe.net>> On Behalf 
Of Cynthia Revström via db-wg
Sent: Monday, 7 December 2020 14:04
To: DB-WG mailto:db-wg@ripe.net>>
Subject: Re: [db-wg] Proposal to revert NWI-10



To clarify, when I said "messed up the data on my resources" I meant that the 
delegated file now has invalid data.

And invalid data that is supposed to be correct is a lot worse than incorrect 
data that is just provided by the resource holder.


- Cynthia





On Mon, Dec 7, 2020 at 1:58 PM Cynthia Revström 
mailto:m...@cynthia.re>> wrote:

Apologies if this email is a bit impolite.



>From the start NWI-10 seemed like a pointless policy to me and just a policy 
>that was made because the db-wg wanted to make more policies.



But as it has already messed up the data on my resources, I see it as a policy 
that messes up data and wastes time for no real advantage.



Hence I suggest that we revert NWI-10 unless someone actually has a good reason 
for why the legal address needs to match the delegated file, and how to 
implement it in a non-messy way.



- Cynthia

Re: [db-wg] Proposal to revert NWI-10

[Matthias Merkel via db-wg]

Hi Cynthia,

do you have any idea what may have caused this? I'd say this is likely an issue 
with the implementation of the proposal, not with the proposal itself.

Matthias Merkel
Staclar, Inc.


From: Cynthia Revström 
Sent: Monday, December 7, 2020 2:49 PM
To: Matthias Merkel 
Cc: db-wg@ripe.net 
Subject: Re: [db-wg] Proposal to revert NWI-10

This is not my point, yes I could easily ask them to fix my specific case.

My point is that I very much doubt I am the only one who has this issue, and I 
only noticed it as I was looking on bgp.he.net and noticed 
the GB flag.

- Cynthia


On Mon, Dec 7, 2020 at 2:48 PM Matthias Merkel 
mailto:matthias.mer...@staclar.com>> wrote:
Hi Cynthia,

ORG-ISSA10-RIPE is your LIR, right? It does indeed look like it should have a 
country attribute of Sweden. Did you ask the NCC about this already? Did they 
mention any reason for it being GB?

Matthias Merkel
Staclar, Inc.

From: Cynthia Revström mailto:m...@cynthia.re>>
Sent: Monday, December 7, 2020 2:40 PM
To: Matthias Merkel 
mailto:matthias.mer...@staclar.com>>
Cc: db-wg@ripe.net 
mailto:db-wg@ripe.net>>
Subject: Re: [db-wg] Proposal to revert NWI-10

Hi Matthias,

Well before NWI-10 there was no proper definition, but there is now a 
definition, and as a result the RIPE NCC updated the resources to GB whereas 
the LIR is quite obviously SE.

- Cynthia


On Mon, Dec 7, 2020 at 2:16 PM Matthias Merkel 
mailto:matthias.mer...@staclar.com>> wrote:

Hi Cynthia,



Could you please elaborate on why the data is now invalid (what you think it is 
supposed to be, what it is now and what situation is causing it to be this 
way)? My understanding is that there was never a “proper” definition of the 
country field.



Matthias Merkel

Staclar, Inc.



From: db-wg mailto:db-wg-boun...@ripe.net>> On Behalf 
Of Cynthia Revström via db-wg
Sent: Monday, 7 December 2020 14:04
To: DB-WG mailto:db-wg@ripe.net>>
Subject: Re: [db-wg] Proposal to revert NWI-10



To clarify, when I said "messed up the data on my resources" I meant that the 
delegated file now has invalid data.

And invalid data that is supposed to be correct is a lot worse than incorrect 
data that is just provided by the resource holder.


- Cynthia





On Mon, Dec 7, 2020 at 1:58 PM Cynthia Revström 
mailto:m...@cynthia.re>> wrote:

Apologies if this email is a bit impolite.



>From the start NWI-10 seemed like a pointless policy to me and just a policy 
>that was made because the db-wg wanted to make more policies.



But as it has already messed up the data on my resources, I see it as a policy 
that messes up data and wastes time for no real advantage.



Hence I suggest that we revert NWI-10 unless someone actually has a good reason 
for why the legal address needs to match the delegated file, and how to 
implement it in a non-messy way.



- Cynthia

Re: [db-wg] Proposal to revert NWI-10

[Matthias Merkel via db-wg]

Hi Cynthia,

ORG-ISSA10-RIPE is your LIR, right? It does indeed look like it should have a 
country attribute of Sweden. Did you ask the NCC about this already? Did they 
mention any reason for it being GB?

Matthias Merkel
Staclar, Inc.

From: Cynthia Revström 
Sent: Monday, December 7, 2020 2:40 PM
To: Matthias Merkel 
Cc: db-wg@ripe.net 
Subject: Re: [db-wg] Proposal to revert NWI-10

Hi Matthias,

Well before NWI-10 there was no proper definition, but there is now a 
definition, and as a result the RIPE NCC updated the resources to GB whereas 
the LIR is quite obviously SE.

- Cynthia


On Mon, Dec 7, 2020 at 2:16 PM Matthias Merkel 
mailto:matthias.mer...@staclar.com>> wrote:

Hi Cynthia,



Could you please elaborate on why the data is now invalid (what you think it is 
supposed to be, what it is now and what situation is causing it to be this 
way)? My understanding is that there was never a “proper” definition of the 
country field.



Matthias Merkel

Staclar, Inc.



From: db-wg mailto:db-wg-boun...@ripe.net>> On Behalf 
Of Cynthia Revström via db-wg
Sent: Monday, 7 December 2020 14:04
To: DB-WG mailto:db-wg@ripe.net>>
Subject: Re: [db-wg] Proposal to revert NWI-10



To clarify, when I said "messed up the data on my resources" I meant that the 
delegated file now has invalid data.

And invalid data that is supposed to be correct is a lot worse than incorrect 
data that is just provided by the resource holder.


- Cynthia





On Mon, Dec 7, 2020 at 1:58 PM Cynthia Revström 
mailto:m...@cynthia.re>> wrote:

Apologies if this email is a bit impolite.



>From the start NWI-10 seemed like a pointless policy to me and just a policy 
>that was made because the db-wg wanted to make more policies.



But as it has already messed up the data on my resources, I see it as a policy 
that messes up data and wastes time for no real advantage.



Hence I suggest that we revert NWI-10 unless someone actually has a good reason 
for why the legal address needs to match the delegated file, and how to 
implement it in a non-messy way.



- Cynthia

Re: [db-wg] Proposal to revert NWI-10

[Matthias Merkel via db-wg]

Hi Cynthia,

Could you please elaborate on why the data is now invalid (what you think it is 
supposed to be, what it is now and what situation is causing it to be this 
way)? My understanding is that there was never a “proper” definition of the 
country field.

Matthias Merkel
Staclar, Inc.

From: db-wg  On Behalf Of Cynthia Revström via db-wg
Sent: Monday, 7 December 2020 14:04
To: DB-WG 
Subject: Re: [db-wg] Proposal to revert NWI-10

To clarify, when I said "messed up the data on my resources" I meant that the 
delegated file now has invalid data.
And invalid data that is supposed to be correct is a lot worse than incorrect 
data that is just provided by the resource holder.

- Cynthia


On Mon, Dec 7, 2020 at 1:58 PM Cynthia Revström 
mailto:m...@cynthia.re>> wrote:
Apologies if this email is a bit impolite.

From the start NWI-10 seemed like a pointless policy to me and just a policy 
that was made because the db-wg wanted to make more policies.

But as it has already messed up the data on my resources, I see it as a policy 
that messes up data and wastes time for no real advantage.

Hence I suggest that we revert NWI-10 unless someone actually has a good reason 
for why the legal address needs to match the delegated file, and how to 
implement it in a non-messy way.

- Cynthia

Re: [db-wg] proposal: new attribute 'geofeed:'

[Matthias Merkel via db-wg]

A RIPE hosted geolocation feed may indeed provide some advantages, however in 
my opinion this should instead be based on data supplied by the LIR (or end 
user for PI assignments), as it would be using an external geolocation feed, 
instead of automatically via Atlas. There are various reasons for why a 
measurement approach may return bad data (i.e. routing inconsistencies).

Matthias Merkel
Executive Vice President
Staclar, Inc.
[cid:image001.png@01D69CED.A2E46E70]
+1-628-213-1141 | +49 15678 585608
[cid:image002.png@01D69CED.A2E46E70]
matthias.mer...@staclar.com
[cid:image007.png@01D69CED.A2F7F670]
staclar.com
[cid:image008.png@01D69CED.A2F7F670]
Munich, Germany
[cid:image009.png@01D69CED.A2F7F670]
[linkedin]


From: db-wg  On Behalf Of Elad Cohen via db-wg
Sent: Wednesday, 7 October 2020 17:01
To: Horváth Ágoston János ; Job Snijders 

Cc: db-wg@ripe.net >> Database WG 
Subject: Re: [db-wg] proposal: new attribute 'geofeed:'

+1

and I would like to suggest an adjustment:

Not everyone will add the "geofeed" value and the geolocations in the csv will 
not validated by a 3rd party and may also be not up to date.

I suggest to make the csv creation (of each INETNUM object) automatic and 
hosted by RIPE NCC, RIPE NCC can use all the current ATLAS Probes in order to 
check the physical location of each ip (using latencies from many probes to 
each ip, and using latencies from many probes to each router in the routing 
path to each ip, other ICMP queries can be used as well to query the routers in 
the routing path for physical information such as timezone as additional 
measures, etc). Algorithem will be efficient meaning at first only small number 
of probes will check each ip and then more probes physically near the first 
probe with the smallest latency.

Kind Regards,
Elad

From: db-wg mailto:db-wg-boun...@ripe.net>> on behalf 
of Job Snijders via db-wg mailto:db-wg@ripe.net>>
Sent: Wednesday, October 7, 2020 5:19 PM
To: Horváth Ágoston János 
mailto:horvath.agos...@gmail.com>>
Cc: db-wg@ripe.net >> Database WG 
mailto:db-wg@ripe.net>>
Subject: Re: [db-wg] proposal: new attribute 'geofeed:'

On Wed, Oct 07, 2020 at 03:43:33PM +0200, Horváth Ágoston János wrote:
> An interesting proposal, but merging an external data set with RIPE
> Database arises some questions:
>
> - RIPE Database is set up to contain hierarchical data already. With this
> proposal, we would take some of this data outside the database in a manner
> that does not guarantee consistency with the database itself.

I don't think that is what is happening, this is more analogous to
"abuse-mailbox:". The value contains an email address (which is an
entrypoint outside the database, and interacting with the entrypoint is
outside the scope of this working group).

The "geofeed:" attribute is a pointer to elsewhere, and what a data
consumer wants to do with that information is up to them.

Kind regards,

Job

Re: [db-wg] proposal: new attribute 'geofeed:'

[Matthias Merkel via db-wg]

+1

Matthias Merkel
Executive Vice President
Staclar, Inc.
[cid:image001.png@01D69CB4.4D061960]
+1-628-213-1141 | +49 15678 585608
[cid:image002.png@01D69CB4.4D061960]
matthias.mer...@staclar.com
[cid:image007.png@01D69CB4.4D0EA4E0]
staclar.com
[cid:image008.png@01D69CB4.4D0EA4E0]
Munich, Germany
[cid:image009.png@01D69CB4.4D0EA4E0]
[linkedin]


From: db-wg  On Behalf Of Cynthia Revström via db-wg
Sent: Wednesday, 7 October 2020 14:14
To: Job Snijders 
Cc: DB-WG 
Subject: Re: [db-wg] proposal: new attribute 'geofeed:'

+1 this is a much more reasonable solution than remarks imo

- Cynthia

On Tue, 6 Oct 2020, 18:29 Job Snijders via db-wg, 
mailto:db-wg@ripe.net>> wrote:
Dear DB-WG,

Some colleagues are working to address the never-ending-story of 'where
the heck are IPs geographically?'. This problem space has been brought
up numerous times in the Database Working Group, but we never managed to
solve it. As with all compsci problems adding a layer of indirection can
help ;-)

This current draft suggests overloading the RPSL 'remarks:' field with a
structured attribute value, however I suspect we would do ourselves a
disservice to overload a 'remarks:' field.

Instead it would be better to add a 'geofeed:' attribute to the RPSL
inetnum/inetnum6 class dictionary, which as value contains a URL with
http or https scheme.

The draft: https://tools.ietf.org/html/draft-ymbk-opsawg-finding-geofeeds

The value of the attribute could be validated using something like
"org.apache.commons.validator.UrlValidator", the attribute would look
like this, only valid in the inetnum/inet6num:

"geofeed:   [optional]   [single] [ ]"

Example object:

inetnum:192.0.2.0 - 192.0.2.255
netname:EXAMPLE
country:NL
geofeed:https://example.com/geofeed.csv
... snip ...
source: RIPE

What do others think?

Kind regards,

Job

ps. In IRRd v4.2 support for the 'geofeed:' attribute will be added
https://github.com/irrdnet/irrd/issues/396

Re: [db-wg] mntner with misleading primary key

[Matthias Merkel via db-wg]

Hi,

if we consider this issue tho we should consider completely disallowing objects 
with names of existing objects. I'm personally not a big fan of mandatory -MNT 
because there seems to be a larger amount of people using other formats.

Matthias Merkel

Vice President

Staclar, Inc.

[https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/phone-icon-2x.png]
+1-302-291-1141 | +49 15678 585608
[https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/email-icon-2x.png]
matthias.mer...@staclar.com
[https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/link-icon-2x.png]
staclar.com
[https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/address-icon-2x.png]
Munich, Germany
[https://staclar.com/images/logo.png]
[linkedin]



From: db-wg on behalf of Gert Doering via db-wg
Sent: Wednesday, July 1, 2020 8:52 PM
To: Cynthia Revström
Cc: DB-WG
Subject: Re: [db-wg] mntner with misleading primary key

Hi,

On Wed, Jul 01, 2020 at 07:36:53PM +0200, Cynthia Revström via db-wg wrote:
> I am not sure how feasible the mandatory "-mnt" would be at this point tbh.
> I can easily think of at least 2 maintainers that are actually used that I
> see quite often that wouldn't fit that pattern.

It would annoy me a bit, because all our stuff is under SPACENET-N and
SPACENET-P ("networks and person objects").  And all tools.

Of course it is doable, but... why?  Convince me :-)

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Re: [db-wg] mntner with misleading primary key

[Matthias Merkel via db-wg]

An alternative approach might be to make an authentication check (user has to 
have access to a maintainer of the ASN), however given the small amount of 
maintainers actually being named this way this would likely not be justifiable.

Matthias Merkel

Vice President

Staclar, Inc.

[https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/phone-icon-2x.png]
+1-302-291-1141 | +49 15678 585608
[https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/email-icon-2x.png]
matthias.mer...@staclar.com
[https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/link-icon-2x.png]
staclar.com
[https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/address-icon-2x.png]
Munich, Germany
[https://staclar.com/images/logo.png]
[linkedin]



From: db-wg on behalf of Gert Doering via db-wg
Sent: Wednesday, July 1, 2020 8:52 PM
To: Cynthia Revström
Cc: DB-WG
Subject: Re: [db-wg] mntner with misleading primary key

Hi,

On Wed, Jul 01, 2020 at 07:36:53PM +0200, Cynthia Revström via db-wg wrote:
> I am not sure how feasible the mandatory "-mnt" would be at this point tbh.
> I can easily think of at least 2 maintainers that are actually used that I
> see quite often that wouldn't fit that pattern.

It would annoy me a bit, because all our stuff is under SPACENET-N and
SPACENET-P ("networks and person objects").  And all tools.

Of course it is doable, but... why?  Convince me :-)

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Re: [db-wg] mntner with misleading primary key

[Matthias Merkel via db-wg]

Apologies, I was actually counting the objects twice (once the mntner attribute 
and once the mnt-by attribute). Here are the objects in question:

AS327833
AS58224
AS42910
AS37527
AS8362
AS202723
as2856
AS12400
AS427313
AS397268
AS12655
AS30956
AS49717

Given the small number of objects, I don't think implementing a filter would 
have any significant impact (negative or positive) and may not be worth the 
effort.


Matthias Merkel

Vice President

Staclar, Inc.

[https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/phone-icon-2x.png]
+1-302-291-1141 | +49 15678 585608
[https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/email-icon-2x.png]
matthias.mer...@staclar.com
[https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/link-icon-2x.png]
staclar.com
[https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/address-icon-2x.png]
Munich, Germany
[https://staclar.com/images/logo.png]
[linkedin]



From: db-wg on behalf of Gert Doering via db-wg
Sent: Wednesday, July 1, 2020 8:52 PM
To: Cynthia Revström
Cc: DB-WG
Subject: Re: [db-wg] mntner with misleading primary key

Hi,

On Wed, Jul 01, 2020 at 07:36:53PM +0200, Cynthia Revström via db-wg wrote:
> I am not sure how feasible the mandatory "-mnt" would be at this point tbh.
> I can easily think of at least 2 maintainers that are actually used that I
> see quite often that wouldn't fit that pattern.

It would annoy me a bit, because all our stuff is under SPACENET-N and
SPACENET-P ("networks and person objects").  And all tools.

Of course it is doable, but... why?  Convince me :-)

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Re: [db-wg] mntner with misleading primary key

[Matthias Merkel via db-wg]

I fully agree with Cynthia here, we use the maintainer STACLAR for example.

I have looked through the database files and there seem to be exactly 26 
maintainer objects that are named as an ASN (without any prefixes or suffixes). 
I think the best solution would be to just block the creation of new objects 
like this and manually check through the existing ones to find potentially 
fraudulent ones.

Matthias Merkel

Vice President

Staclar, Inc.

[https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/phone-icon-2x.png]
+1-302-291-1141 | +49 15678 585608
[https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/email-icon-2x.png]
matthias.mer...@staclar.com
[https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/link-icon-2x.png]
staclar.com
[https://cdn2.hubspot.net/hubfs/53/tools/email-signature-generator/icons/address-icon-2x.png]
Munich, Germany
[https://staclar.com/images/logo.png]
[linkedin]


From: db-wg  on behalf of Cynthia Revström via db-wg 

Sent: Wednesday, July 1, 2020 7:36 PM
To: Job Snijders 
Cc: DB-WG 
Subject: Re: [db-wg] mntner with misleading primary key

I am not sure how feasible the mandatory "-mnt" would be at this point tbh.
I can easily think of at least 2 maintainers that are actually used that I see 
quite often that wouldn't fit that pattern.
There are probably a considerable amount of maintainers that do not follow this 
pattern in fact...

$ grep -P 
'mntner:\s+(?:(?!mnt\-|MNT\-|MAINT\-|maint\-).(?!\-MNT|\-mnt|\-maint|\-MAINT))+$'
 ripe.db.mntner | wc -l
6990

$ grep -P 'mntner:\s+' ripe.db.mntner | wc -l
56524

I don't think we can make 12% of people change their maintainer for this 
purpose.

- Cynthia

On Wed, Jul 1, 2020 at 6:28 PM Job Snijders via db-wg 
mailto:db-wg@ripe.net>> wrote:
Dear Tom,

On Wed, Jul 1, 2020, at 16:16, Tom Hill via db-wg wrote:
> Unless of course, parsing/filtering before insertion (thus augmenting
> the database's table natural design restrictions) is not something Good
> To Do. Database design definitely isn't my primary skill.
>
> Saying that, I have long been idly frustrated by the way that mntners
> seemingly have a reversible, unwritten standard of 'MNT-[random]' or
> '[random]-MNT'. I can't be the only one.

It is possible to change this, but it'll take some time: extensive research to 
figure out a path which causes the least disruption to the fewest amount of 
people. Ideally only a handful of people have to change their "mntner:" primary 
key.

I think a mandatory "-MNT" or "MNT-" or "-MAINT" is helpful because the 
maintainers primary key string does pop up from time to time without any 
context, and this can lead to confusion. See 
https://seclists.org/nanog/2020/Jan/650 for a fun story about how one person's 
email error code is another person's BGP autonomous system reference. :-)

It starts with a volunteer who does some digging in the data to see if a 
migration path can be constructed or not. A conclusion may be that it is too 
hard, but we don't know yet. Are you up for it? :)

Kind regards,

Job