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

[Arnold Nipper]

Even though we consider data from IXP as authoritative, it might contain
errors. According to your proposal data would disappear in the API. Booom!

Again: if there is a conflict, data *must* stay intact and conflict
resolution has to happen asap with all parties involved.


Arnold

On 25.01.2020 00:37, Chris Caputo wrote:
> In practice, with #627, data would not disappear.  Rather, in cases where 
> an IXP is providing authoritative data, it won't be allowed to appear 
> prematurely in a way to be used for provisioning.  And then once agreement 
> happens, it will become available.
> 
> 
> Chris
> 
> On Fri, 24 Jan 2020, Terry Sweetser wrote:
>> 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
>>
>> -- 
>> DataOwnership-TF mailing list
>> DataOwnership-TF at lists.peeringdb.com
>> https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-tf


-- 
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/c7de98bf/attachment.sig>