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

Arnold Nipper 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.
> 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>

More information about the DataOwnership-TF mailing list