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

[Arnold Nipper]

On 25.01.2020 15:41, Chris Caputo wrote:
> 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.
> 

Given the situation that the IX-F import erroneously did not contain
information for ASN 64512, but ASN 64512 has a valid PDB entry. My
understanding is that your proposed solution would then immediately
withhold netixlan information for this ASN and this IX. Right? If so,
that would be completely unacceptable.


Arnold
-- 
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/20200127/4e3b890c/attachment.sig>