<div dir="ltr">sorry for the delay, I finally have a clear enough head to dig in.<div><br></div><div>I support this proposal! Thanks so much for the hard work Chris!<div><br></div><div>Best Regards</div><div><br></div><div>  -Bill</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 29, 2020 at 5:27 PM Terry Sweetser <<a href="mailto:Terry.Sweetser@ix.asn.au">Terry.Sweetser@ix.asn.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I like this process!<br>
<br>
if (data is in conflict) {<br>
        if (already published) {<br>
                keep data up<br>
                initiate resolution process<br>
        } else {<br>
                don't put data up<br>
                initiate resolution process<br>
        }<br>
}<br>
<br>
Regards,<br>
Terry Sweetser<br>
General Manager, IX Australia<br>
<a href="mailto:Terry.Sweetser@ix.asn.au" target="_blank">Terry.Sweetser@ix.asn.au</a><br>
Mobile/WhatsApp: +61455067119<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: DataOwnership-TF <<a href="mailto:dataownership-tf-bounces@lists.peeringdb.com" target="_blank">dataownership-tf-bounces@lists.peeringdb.com</a>> On Behalf Of Arnold Nipper<br>
Sent: Wednesday, 29 January 2020 6:28 PM<br>
To: Chris Caputo <<a href="mailto:ccaputo-dated-1590636781.72278b@alt.net" target="_blank">ccaputo-dated-1590636781.72278b@alt.net</a>>; DTF PeeringDB <<a href="mailto:dataownership-tf@lists.peeringdb.com" target="_blank">dataownership-tf@lists.peeringdb.com</a>><br>
Subject: Re: [PDB Data Ownership-TF] IXP assignment IP address (netixlan) ownership<br>
<br>
<br>
On 29.01.2020 04:33, Chris Caputo wrote:<br>
> On Tue, 28 Jan 2020, William Marantz wrote:<br>
>> On Tue, Jan 28, 2020 at 2:27 AM Arnold Nipper <<a href="mailto:arnold@peeringdb.com" target="_blank">arnold@peeringdb.com</a>> wrote:<br>
>>> On 27.01.2020 18:37, Chris Caputo wrote:<br>
>>>> [...] what I perceive you believe is that it is okay to publicize <br>
>>>> what may be incorrect data, rather than resolve the conflict first.<br>
>>>><br>
>>>> Just as IX-F JSON data can be wrong, so can Network-provided <br>
>>>> netixlan data be wrong.  I argue that when there is a difference, <br>
>>>> it is best to play it safe and not publicize until resolved.<br>
>>>><br>
>>>> If you are concerned about what was previously unconflicted data <br>
>>>> being pulled down by accident, then maybe the handling of <br>
>>>> previously published data should be different than the publishing of new data?<br>
>>>> Could that be the solution we are looking for?  Ex:<br>
>>>><br>
>>>> if (data is in conflict)<br>
>>>> {<br>
>>>>    if (already published)<br>
>>>>    {<br>
>>>>      keep data up<br>
>>>>      initiate resolution process<br>
>>>>    }<br>
>>>>    else<br>
>>>>    {<br>
>>>>      don't put data up<br>
>>>>      initiate resolution process<br>
>>>>    }<br>
>>>> }<br>
>>>><br>
>>>> On Sat, 25 Jan 2020, Arnold Nipper wrote:<br>
>>>>> Even though we consider data from IXP as authoritative, it might <br>
>>>>> contain errors. According to your proposal data would disappear in <br>
>>>>> the API. Booom!<br>
>>>><br>
>>>> I think the above avoids the "Booom!", if "Booom!" refers to <br>
>>>> unintentionally causing deprovisioning.<br>
>>><br>
>>> Now it starts to make sense to me as well. If you could also take <br>
>>> #539 into account we should have a made a huge step forward.<br>
>><br>
>> I support that "already published" modification to your proposal Chris. <br>
>> I totally forgot about that use case and great idea.<br>
> <br>
> Excellent!  Ok, I spent a bunch of time today trying to pull #539, <br>
> #585, and #627 together in some coherent way.  Please review the below <br>
> and let me know of mistakes.  Maybe we can beat this around into something useful.<br>
> <br>
<br>
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.<br>
<br>
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!<br>
<br>
<br>
Cheers<br>
Arnold<br>
--<br>
Arnold Nipper<br>
email: <a href="mailto:arnold@nipper.de" target="_blank">arnold@nipper.de</a><br>
mobile: +49 172 2650958<br>
<br>
-- <br>
DataOwnership-TF mailing list<br>
<a href="mailto:DataOwnership-TF@lists.peeringdb.com" target="_blank">DataOwnership-TF@lists.peeringdb.com</a><br>
<a href="https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-tf" rel="noreferrer" target="_blank">https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-tf</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><b>Bill Marantz</b><br>Principal Network Engineer</div><div dir="ltr">Backbone Engineering<br>Mobile: 848-404-4613<div>email: <a href="mailto:ihamilton@salesforce.com" style="color:rgb(17,85,204)" target="_blank">wmarantz@salesforce.com</a><br></div></div></div></div></div></div><br></div></div></div></div></div>