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

[Chris Caputo]

On Sat, 25 Jan 2020, Arnold Nipper wrote:
> Chris/team
> 
> On 25.01.2020 02:30, Chris Caputo wrote:
> 
> > On 25.01.2020 01:31, Arnold Nipper wrote:
> > 
> >> Again: if there is a conflict, data *must* stay intact and conflict
> >> resolution has to happen asap with all parties involved.
> > 
> > Network-provided data stays intact in the netixlan table, but it is 
> > disputable (hence this discussion) that it should be public in such as way 
> > as to inform provisioning.  I believe the IXP should have the option of 
> > having a say in that matter, since it is their address space, and their 
> > fabric which can be affected.
> > 
> 
> IMO we are running in circles somehow.
> 
> We want to have the IX-F importer, but also want to make it safe in the
> sense that data is not deleted/gets invisible in case of an error on
> either side.
> 
> As we are not able to resolve a conflict automatically w/o causing
> interruption of services, the conflict has to be brought to attention
> immediately by notifying each party involved and then get resolved.
> 
> AC will do this resolution. And I fully agree that the IXP should be the
> authoritative source of information regarding (asn, ipv4, ipv6).
> 
> If there is anything we can do to minimize the work of AC w/o violating
> above mentioned principles we should implement it.

Hi Arnold,

Maybe the way to reach consensus here is to revise part of #627's initial 
proposal:

  - "Issue #585 could then be adjusted to only generate tickets for 
    conflicts that are older than a certain amount of time, ideally 
    exceeding the amount of time a conflict may exist as part of normal 
    IXP/network provisioning."

to rather be:

  - "At the same time as #627 (netixlan conflict resolution idea)  
    withholds general API and /ix/ HTML page publication of conflicted 
    data to avoid premature and/or accidental provisioning, and produces a 
    conflict notification on the Network's /net/ HTML page, the resolution 
    methods of #585 (Interim IX-F JSON importer) are also triggered.  
    This enables the Admin Committee to exercise discretion and/or brings 
    parties together toward agreement, resulting in either a correction or 
    override of the IX-F JSON export from the IXP and/or a change in the 
    data provided by the Network, as needed to aide in resolution of the 
    conflict.  To facilitate an override, a netixlan_override table is 
    envisioned, to accompany the netixlan table and new netixlan_ixp 
    table.  The Admin Committee also has the discretion to disable the 
    IXP's IX-F JSON import if it is apparent new data is in error, thus 
    minimizing the duration of accidental censoring of valid data."

?  Does that work for you?

Then after implementation and experience is gained, if the trigger delay 
for invoking #585 turns out to be too low at zero seconds, it could be 
increased over time, such as to an hour or more, if it makes sense to do 
so in the judgment of the Admin Committee.

Thanks,
Chris