<div dir="ltr">I support that "already published" modification to your proposal Chris. I totally forgot about that use case and great idea.<div><br></div><div>Best Regards</div><div><br></div><div>  -Bill</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 28, 2020 at 2:27 AM Arnold Nipper <<a href="mailto:arnold@peeringdb.com">arnold@peeringdb.com</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">On 27.01.2020 18:37, Chris Caputo wrote:<br>
> On Mon, 27 Jan 2020, Arnold Nipper wrote:<br>
>> On 27.01.2020 17:42, Chris Caputo wrote:<br>
>>> A core question for the task force: Does an IXP exporting IX-F JSON data <br>
>>> have the right to prevent a network from publishing an assignment on the <br>
>>> IXP's subnet?<br>
>>><br>
>><br>
>> The answer is "no" IMO<br>
>><br>
>>> I wrote #627 because I believe that right is a given, but apparently you <br>
>>> disagree?  What do others believe?<br>
>>><br>
>><br>
>> I completely agree that the IX is the authoritative source. However, the<br>
>> IX-F JSON may be faulty. Hence any conflict should be escalated<br>
>> immediately to all parties involved and resolution be sought.<br>
>><br>
>> That's the reason we have the Data Ownership TF. We have found out that<br>
>> currently everything boils down to the netixlan object where both the<br>
>> net and the ix have a say.<br>
>><br>
>> In short. Without the ix having defined an ixpfx no network is able to<br>
>> create a netixlan record. The only one able to create and modify a<br>
>> netixlan record is a net (setting allow_ixp_update=yes only means that<br>
>> the net delegates this right to the ix).<br>
>><br>
>> Of course the net is able to delete a netixlan object. And with the old<br>
>> importer the ix was also able to delete a netixlan record. Even w/o<br>
>> permission of the net. And we have seen that this behaviour is<br>
>> unacceptable. Hence manual resolution is needed.<br>
>><br>
>><br>
>> Does that make sense?<br>
> <br>
> It makes sense, but what I perceive you believe is that it is okay to <br>
> publicize what may be incorrect data, rather than resolve the conflict <br>
> first.<br>
> <br>
> Just as IX-F JSON data can be wrong, so can Network-provided netixlan data <br>
> be wrong.  I argue that when there is a difference, it is best to play it <br>
> safe and not publicize until resolved.<br>
> <br>
> If you are concerned about what was previously unconflicted data being <br>
> pulled down by accident, then maybe the handling of previously published <br>
> data should be different than the publishing of new data?  Could that be <br>
> 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 contain<br>
>> errors. According to your proposal data would disappear in the API. Booom!<br>
> <br>
> I think the above avoids the "Booom!", if "Booom!" refers to <br>
> unintentionally causing deprovisioning.<br>
> <br>
<br>
Now it starts to make sense to me as well. If you could also take #539<br>
into account we should have a made a huge step forward.<br>
<br>
<br>
Arnold<br>
-- <br>
Arnold Nipper<br>
email: <a href="mailto:arnold@peeringdb.com" target="_blank">arnold@peeringdb.com</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>