[PDB Data Ownership-TF] IXP assignment IP address (netixlan) ownership

[Terry Sweetser]

I like this process!

if (data is in conflict) {
	if (already published) {
		keep data up
		initiate resolution process
	} else {
		don't put data up
		initiate resolution process
	}
}

Regards,
Terry Sweetser
General Manager, IX Australia
Terry.Sweetser at ix.asn.au
Mobile/WhatsApp: +61455067119



-----Original Message-----
From: DataOwnership-TF <dataownership-tf-bounces at lists.peeringdb.com> On Behalf Of Arnold Nipper
Sent: Wednesday, 29 January 2020 6:28 PM
To: Chris Caputo <ccaputo-dated-1590636781.72278b at alt.net>; DTF PeeringDB <dataownership-tf at lists.peeringdb.com>
Subject: Re: [PDB Data Ownership-TF] IXP assignment IP address (netixlan) ownership


On 29.01.2020 04:33, Chris Caputo wrote:
> On Tue, 28 Jan 2020, William Marantz wrote:
>> On Tue, Jan 28, 2020 at 2:27 AM Arnold Nipper <arnold at peeringdb.com> wrote:
>>> On 27.01.2020 18:37, Chris Caputo wrote:
>>>> [...] what I perceive you believe is that it is okay to publicize 
>>>> what may be incorrect data, rather than resolve the conflict first.
>>>>
>>>> Just as IX-F JSON data can be wrong, so can Network-provided 
>>>> netixlan data be wrong.  I argue that when there is a difference, 
>>>> it is best to play it safe and not publicize until resolved.
>>>>
>>>> If you are concerned about what was previously unconflicted data 
>>>> being pulled down by accident, then maybe the handling of 
>>>> previously published data should be different than the publishing of new data?
>>>> Could that be the solution we are looking for?  Ex:
>>>>
>>>> if (data is in conflict)
>>>> {
>>>>    if (already published)
>>>>    {
>>>>      keep data up
>>>>      initiate resolution process
>>>>    }
>>>>    else
>>>>    {
>>>>      don't put data up
>>>>      initiate resolution process
>>>>    }
>>>> }
>>>>
>>>> On Sat, 25 Jan 2020, Arnold Nipper wrote:
>>>>> Even though we consider data from IXP as authoritative, it might 
>>>>> contain errors. According to your proposal data would disappear in 
>>>>> the API. Booom!
>>>>
>>>> I think the above avoids the "Booom!", if "Booom!" refers to 
>>>> unintentionally causing deprovisioning.
>>>
>>> Now it starts to make sense to me as well. If you could also take 
>>> #539 into account we should have a made a huge step forward.
>>
>> I support that "already published" modification to your proposal Chris. 
>> I totally forgot about that use case and great idea.
> 
> Excellent!  Ok, I spent a bunch of time today trying to pull #539, 
> #585, and #627 together in some coherent way.  Please review the below 
> and let me know of mistakes.  Maybe we can beat this around into something useful.
> 

Looks very elaborated to me, Chris. Very well done! Thank you for your time and effort. I don't have the time to go through the pseudocode in detail, but I didn't find obvious flaws.

How to proceed? Open a new issue with the pseudocode? As this is very well specced out it could be implemented right away. I would love to see it happening with the next release!


Cheers
Arnold
--
Arnold Nipper
email: arnold at nipper.de
mobile: +49 172 2650958