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

[Chris Caputo]

On Mon, 27 Jan 2020, Arnold Nipper wrote:
> On 27.01.2020 17:42, Chris Caputo wrote:
> > A core question for the task force: Does an IXP exporting IX-F JSON data 
> > have the right to prevent a network from publishing an assignment on the 
> > IXP's subnet?
> > 
> 
> The answer is "no" IMO
> 
> > I wrote #627 because I believe that right is a given, but apparently you 
> > disagree?  What do others believe?
> > 
> 
> I completely agree that the IX is the authoritative source. However, the
> IX-F JSON may be faulty. Hence any conflict should be escalated
> immediately to all parties involved and resolution be sought.
> 
> That's the reason we have the Data Ownership TF. We have found out that
> currently everything boils down to the netixlan object where both the
> net and the ix have a say.
> 
> In short. Without the ix having defined an ixpfx no network is able to
> create a netixlan record. The only one able to create and modify a
> netixlan record is a net (setting allow_ixp_update=yes only means that
> the net delegates this right to the ix).
> 
> Of course the net is able to delete a netixlan object. And with the old
> importer the ix was also able to delete a netixlan record. Even w/o
> permission of the net. And we have seen that this behaviour is
> unacceptable. Hence manual resolution is needed.
> 
> 
> Does that make sense?

It makes sense, but what I perceive you believe is that it is okay to 
publicize what may be incorrect data, rather than resolve the conflict 
first.

Just as IX-F JSON data can be wrong, so can Network-provided netixlan data 
be wrong.  I argue that when there is a difference, it is best to play it 
safe and not publicize until resolved.

If you are concerned about what was previously unconflicted data being 
pulled down by accident, then maybe the handling of previously published 
data should be different than the publishing of new data?  Could that be 
the solution we are looking for?  Ex:

if (data is in conflict)
{
  if (already published)
  {
    keep data up
    initiate resolution process
  }
  else
  {
    don't put data up
    initiate resolution process
  }
}

On Sat, 25 Jan 2020, Arnold Nipper wrote:
> Even though we consider data from IXP as authoritative, it might contain
> errors. According to your proposal data would disappear in the API. Booom!

I think the above avoids the "Booom!", if "Booom!" refers to 
unintentionally causing deprovisioning.

Thanks,
Chris