[DBWG] stale route6 and domain objects for removed inet6num

[James]

Hello Frank,

We now have the child orphan monitoring tool in place and I can confirm
that all orphan objects have been cleaned up, now our focus turns to
getting the bug fixes implemented asap.

Regards,

James   

On 23/08/2020 20:27, Frank Habicht wrote:

> Great. Thanks.

> Frank

>

> On 23/08/2020 18:48, James wrote:

>> Hello  Frank,

>>

>> Indeed the plan is to get all the orphaned objects out of the database

>> and this will be done as soon as the monitoring tool is available, and

>> we expect this to be available as earliercommunicated.

>>

>> Regards,

>>

>> James   

>>

>> On 20/08/2020 19:04, Frank Habicht wrote:

>>> Thanks James.

>>>

>>> hoping that the general check, capture of orphans and clean up can be

>>> done by mid next week.

>>>

>>> Regards,

>>> Frank

>>>

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

>>>> 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

>>> _______________________________________________

>>> 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
____________________________