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

[Chris Caputo]

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