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

[Arnold Nipper]

On 27.01.2020 18:37, Chris Caputo wrote:
> On Mon, 27 Jan 2020, Arnold Nipper wrote:
>> On 27.01.2020 17:42, Chris Caputo wrote:
>>> A core question for the task force: Does an IXP exporting IX-F JSON data 
>>> have the right to prevent a network from publishing an assignment on the 
>>> IXP's subnet?
>>>
>>
>> The answer is "no" IMO
>>
>>> I wrote #627 because I believe that right is a given, but apparently you 
>>> disagree?  What do others believe?
>>>
>>
>> I completely agree that the IX is the authoritative source. However, the
>> IX-F JSON may be faulty. Hence any conflict should be escalated
>> immediately to all parties involved and resolution be sought.
>>
>> That's the reason we have the Data Ownership TF. We have found out that
>> currently everything boils down to the netixlan object where both the
>> net and the ix have a say.
>>
>> In short. Without the ix having defined an ixpfx no network is able to
>> create a netixlan record. The only one able to create and modify a
>> netixlan record is a net (setting allow_ixp_update=yes only means that
>> the net delegates this right to the ix).
>>
>> Of course the net is able to delete a netixlan object. And with the old
>> importer the ix was also able to delete a netixlan record. Even w/o
>> permission of the net. And we have seen that this behaviour is
>> unacceptable. Hence manual resolution is needed.
>>
>>
>> Does that make sense?
> 
> It makes sense, but 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.


Arnold
-- 
Arnold Nipper
email: arnold at peeringdb.com
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/20200128/540cdb86/attachment.sig>