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

Terry Sweetser Terry.Sweetser at ix.asn.au
Wed Jan 29 14:27:20 PST 2020

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

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!

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

More information about the DataOwnership-TF mailing list