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

[Arnold Nipper]

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

-------------- 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/20200125/962486ba/attachment.sig>