[DBWG] stale route6 and domain objects for removed inet6num

[Frank Habicht]

Thanks James.
Frank

On 24/09/2020 10:18, James wrote:

> Dear Frank,

> 

> Thank you for the follow up.

> 

> The fix has been developed and tested in dev-environment, we are

> expecting staging environment to be ready for testing by close of

> business tomorrow.

> 

> With an assumption that we won't experience any challenges on staging,

> production deployment should happen by end of next week.

> 

> In any case, a status update will be provided.

> 

> Regards,

> 

> James

> 

> 

> On 13/09/2020 22:56, Frank Habicht wrote:

>> Hi James,

>>

>> can we get some times lines for the bug fixes (if not completed

>> already), please?

>>

>> Thanks,

>> Frank

>>

>> On 25/08/2020 08:34, James wrote:

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

>> _______________________________________________

>> DBWG mailing list

>> DBWG at afrinic.net

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

>