[DBWG] stale route6 and domain objects for removed inet6num

[James]

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


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