[PDB Data Ownership-TF] IXP assignment IP address (netixlan) ownership
arnold at nipper.de
Fri Jan 24 16:31:11 PST 2020
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.
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.
> 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.
>> 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 Nipper
>> email: arnold at nipper.de
>> mobile: +49 172 2650958
>> DataOwnership-TF mailing list
>> DataOwnership-TF at lists.peeringdb.com
email: arnold at nipper.de
mobile: +49 172 2650958
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 261 bytes
Desc: OpenPGP digital signature
More information about the DataOwnership-TF