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

[Terry Sweetser]

Agreeing with Arnold here, it's the ISSUE.   Having data disappear is annoying some large players in the market and devaluing the PDB.

Regards,
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: Saturday, 25 January 2020 9:29 AM
To: DTF PeeringDB <dataownership-tf at lists.peeringdb.com>
Subject: Re: [PDB Data Ownership-TF] IXP assignment IP address (netixlan) ownership

On 24.01.2020 18:25, Chris Caputo wrote:

> On Fri, 24 Jan 2020, William Marantz wrote:
>
>> If they are getting netixlan via the API the conflicted IP data won't 
>> be there in this proposal. If they call a net object will the data be 
>> viewable in the netixlan_set data element in your proposal Chris? I'd 
>> assume yes if it will be available via the net web page. If the user 
>> is using netixlan calls as part of their provisioning process, I 
>> don't see how this proposal solves the problem. I'd suggest to 
>> clearly document the potentially conflicted view ( net ) and conflict 
>> free view ( netixlan ). Users can then code to whatever view meets 
>> the needs of their network.
> 
> No, it won't be visible in the /net/ result or other results as long 
> as it is conflicted.  The idea here is to prevent PeeringDB from 
> presenting (via web or API) any data that could be interpreted as 
> valid when it is not valid.  Conflicted data is not valid.  While that 
> conflict can be denoted in the web pages, so a network has a clue that 
> an issue has arisen, for API queries conflicted data would be withheld 
> to prevent accidental automation using conflicted data.
> 

I totally disagree. If data is conflicted we can't decide whether it is valid or not. Hence the conflict has to be resolved.

Interpreting conflicted data as invalid is the worth you can do IMO.
This might lead to deconfiguration of sessions as the netixlan object is not shown anymore via the API.

Instead conflicts must be resolved asap leaving the data intact until the conflict is resolved.



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