[DBWG] stale route6 and domain objects for removed inet6num

[James]

Dear Frank,

Thanks for the inquiry.

The mechanism being referred to is implemented within the WHOIS  and the
bug has been reported with our software team. As soon as I have an ETA
you shall be kept in the loop.

Before removing the objects you highlighted, we are running a general
check to establish the extent of the issue and ensure we capture any
other orphan objects that may exist so that the clean up is done at
once. Furthermore, the proactive monitory tool in this regard was
something already requested internally and is under development with an
ETA of Monday.

My previous update was in the interest of keeping you updated as the
team works in the background to resolve the issue.

Regards,

James

On 19/08/2020 22:14, Frank Habicht wrote:

> Dear James,

>

> Thanks for your email.

>

> I want to respond as an AfriNIC member, *not* as DBWG co-chair.

> Also, I'm known to be sometimes a bit too blunt, and i'm currently not

> sure if i can avoid this here. Apologies in advance.

>

> We (non-staff outsiders) probably don't need to know all the internals,

> but in this case i think it would comfort me if we had some indication

> that internal details are being looked at (critically) and this and more

> bug(s) get fixed. with intention of pro-activeness.

> We don't know whether the 'mechanisms that checks for child objects' is

> a script for a human to follow and a passage should be more highlighted,

> or whether that's a script for a machine where a '6?' is missing in a

> regular expression right after 'route' .

>

> And we shouldn't be involved in this. I just want to express that it

> would be very comforting if we could get to see - by results, of course

> - that this is taken seriously and being looked at.

>

> Maybe there should or could be some incentives to find issues. and to

> fix them. Anything i can think of can probably be "gamed", and i

> shouldn't get into details.

> [I included Arthur for that. he had asked me ages ago for feedback, took

> me long to give some;-)]

>

> So I wanted also to mention:

> If I found an embarrassing bug or mistake in my database, I would really

> try hard to fix it, if not before sending the response email, then at

> least immediately after.

>

> If not done 2.5 hours after the email is sent, a troublesome outsider

> (named Frank) could already think the issue gets neglected or forgotten.

>

> the route6 object is still there:

> $ whois -h whois.afrinic.net -- -T route6 2c0f:f370::/32 | egrep -A 4

> '^rout'

> route6:         2c0f:f370::/32

> descr:          Auvionics-v6

> origin:         AS328097

> mnt-by:         AA96-MNT

> source:         AFRINIC # Filtered

>

> Since the bug existed when the inet6num was deleted, the route6 wasn't

> deleted during inet6num deletion, I would believe that manual

> intervention is required.

>

> And it seems to me that it still wasn't done.

>

> I simply don't want to do the same check for the domain object for the

> same prefix - I leave that to staff. [maybe I can ask Arthur to drop me

> a note when both are removed]

>

>

> Now about an idea for a way forward:

> [and I hope that's obvious, but i request forgiveness that I don't want

> to assume too much]

> Someone could volunteer to find additional objects that were orphaned

> through the same process as the objects in this case i discovered.

>

> - go through all existing domain objects ending in 'ip6.arpa' and see if

>   the covering (or equal) inet6num objects exist -

>        and are *not* equal to ("2c00::/12" or "2001:4200::/23")

> - go through all existing route6 objects, and do the same test.

>

> I strongly believe that we shouldn't look for a volunteer from the

> community for this - AfriNIC staff is just much better equipped (and

> paid) to do that.

>

>

> Finally I want to mention a word about impact.

>

> [we can't thank Job enough for some of the great tools he's

> contributing, nevertheless: Thank you, Job Snijders!!!]

>

> http://irrexplorer.nlnog.net/search/328097

> currently shows 3 AS-SETs in RIPE and one AS-SET in AfriNIC that include

> AS328097, which means that real operators are putting 2c0f:f370::/32

> into real filters, eating up resources ...

> <sarcasm>...and leading to earlier upgrade requirements, spending money

> that we all would rather spend on AfriNIC fees...... </sarcasm>

>

> Now I'm co-guilty; and I will fix 2 of these AS-SETs within 15 minutes

> after sending this email, and make an email to someone to fix the 3rd

> within 30 minutes....

>

> So maybe http://irrexplorer.nlnog.net/search/328097 will already look

> better by the time you guys check.

>

> Thanks,

> Frank

>

>

> On 19/08/2020 17:52, James wrote:

>> Dear Frank,

>>

>> Thank you for bringing this forward.

>>

>> When resources are being de-registered by staff, we have mechanisms that

>> checks for child objects and prevents the deletion where any still exist.

>>

>> However, based on the issue you have raised, we have noted that there is

>> a bug in the implementation and this bug led to the issues observed.

>>

>> We will be  taking this up with our software team to fix the issue and

>> also look for better monitoring.

>>

>> Regards,

>>

>> James

>>

>>

>> On 18/08/2020 08:53, Frank Habicht wrote:

>>> On 17/08/2020 22:02, Nishal Goburdhan wrote:

>>>> On 17 Aug 2020, at 16:31, Frank Habicht wrote:

>>>>

>>>>

>>>>> Sure: *these* were created by the member, not by AfriNIC.

>>>>> But should these not have been removed whilst removing the inet6num ?

>>>> assume for a minute that the member did not pay their fees.  afrinic

>>>> themselves, would have happily removed the domain objects as part of

>>>> “suspending the resources”  (heh!)  even though they were “created by

>>>> the member”.

>>> didn't know. good to know. so deleting the domain objects is part of

>>> that process.

>>>

>>>> so, i’m not sure why you felt it necessary to say:  “ *these* were

>>>> created by the member”.  as if that confers some sort of special power

>>>> onto them?

>>> wanted to get confirmation that they're not that special.

>>>

>>>

>>>>> I believe the process of deleting an inet6num is rarely happening, but

>>>>> a) it sure did and b) it should include taking care of these "dependant"

>>>>> objects....... right?

>>>> yes.

>>> thanks.

>>>

>>>

>>>> i seem to remember that there a policy that helps with this .. like

>>>> “lame delegation” something-or-the-other that’s meant to deal with

>>>> long-term occurrences of this.  so, even if the db-admin, for reasons

>>>> unknown, deigned to remove the domain objects, said objects _should_

>>>> have been reported, and acted on.  iirc, the details were left to

>>>> afrinic to implement, but i stand to correction.

>>> there's no lameness (yet). domain in question is served by my ($dayjob)

>>> servers. And I was looking to clean that up and that got me to this case.

>>>

>>>

>>> I wish we could get a confirmation (from AfriNIC staff) that deleting

>>> the domain and route objects is (or will from now on be) part of the

>>> process of de-registering any inetnum / inet6num object.

>>>

>>>

>>> Frank

>>>

>>>

>>> _______________________________________________

>>> DBWG mailing list

>>> DBWG at afrinic.net

>>> https://lists.afrinic.net/mailman/listinfo/dbwg

> _______________________________________________

> DBWG mailing list

> DBWG at afrinic.net

> https://lists.afrinic.net/mailman/listinfo/dbwg


-- 
James Chirwa
Acting Manager, Member Services Department,
AFRINIC Ltd.
t: +230 403 51 00 | f: +230 466 6758 |
tt: @afrinic | w: www.afrinic.net
SM: facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia
____________________________