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

[Arnold Nipper]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.peeringdb.com/pipermail/dataownership-tf/attachments/20200129/31362304/attachment.sig>