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

[William Marantz]

sorry for the delay, I finally have a clear enough head to dig in.

I support this proposal! Thanks so much for the hard work Chris!

Best Regards

  -Bill

On Wed, Jan 29, 2020 at 5:27 PM Terry Sweetser <Terry.Sweetser at ix.asn.au>
wrote:

> I like this process!
>
> if (data is in conflict) {
>         if (already published) {
>                 keep data up
>                 initiate resolution process
>         } else {
>                 don't put data up
>                 initiate resolution process
>         }
> }
>
> 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: Wednesday, 29 January 2020 6:28 PM
> To: Chris Caputo <ccaputo-dated-1590636781.72278b at alt.net>; DTF PeeringDB
> <dataownership-tf at lists.peeringdb.com>
> Subject: Re: [PDB Data Ownership-TF] IXP assignment IP address (netixlan)
> ownership
>
>
> On 29.01.2020 04:33, Chris Caputo wrote:
> > On Tue, 28 Jan 2020, William Marantz wrote:
> >> On Tue, Jan 28, 2020 at 2:27 AM Arnold Nipper <arnold at peeringdb.com>
> wrote:
> >>> On 27.01.2020 18:37, Chris Caputo wrote:
> >>>> [...] 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.
> >>>
> >>> Now it starts to make sense to me as well. If you could also take
> >>> #539 into account we should have a made a huge step forward.
> >>
> >> I support that "already published" modification to your proposal Chris.
> >> I totally forgot about that use case and great idea.
> >
> > Excellent!  Ok, I spent a bunch of time today trying to pull #539,
> > #585, and #627 together in some coherent way.  Please review the below
> > and let me know of mistakes.  Maybe we can beat this around into
> something useful.
> >
>
> Looks very elaborated to me, Chris. Very well done! Thank you for your
> time and effort. I don't have the time to go through the pseudocode in
> detail, but I didn't find obvious flaws.
>
> How to proceed? Open a new issue with the pseudocode? As this is very well
> specced out it could be implemented right away. I would love to see it
> happening with the next release!
>
>
> Cheers
> 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
>


-- 
*Bill Marantz*
Principal Network Engineer
Backbone Engineering
Mobile: 848-404-4613
email: wmarantz at salesforce.com <ihamilton at salesforce.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.peeringdb.com/pipermail/dataownership-tf/attachments/20200204/4296bfd4/attachment.htm>