<div dir="ltr">I was engaged in a side conversation with Chris on this proposal to clarify some things and would like to bring the discussion to the list.<div><br></div><div>I'm going to wear two different hats when looking at this proposal.</div><div><br></div><div>1) From a data ownership perspective I like this proposal as it won't lead to full deletion of end user network specified IP data but will limit its visibility to others and indicate the IX-F conflict to the network.</div><div><br></div><div>2) From a poor coder and automated peering operator perspective I have some concerns with it depending on how the folks with reported issues use the API.</div><div>  a) does anyone know the access method and tables/objects the users who had data deletion issues used?  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 <span style="color:rgb(0,0,0);white-space:pre-wrap">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.</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">  b) Some networks are very slow at peer provisioning and IX port provisioning, so peers may have a strong desire to get provisioning started as soon as the IXP assigns the IPs but that may not yet be reflected in IX-F. This means a provisioning system would rely on the conflicting data if that system is built to only obtain IPs from peeringDB. As long as the caveats are documented, I'd like to support such functionality as I feel it would aid many operators.</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div><font color="#000000"><span style="white-space:pre-wrap">The provisioning code I wrote makes API calls to get netixlan but I'm happy to change it to make net calls if this proposal goes through.</span></font></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">Best Regards</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">  -Bill</span></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 24, 2020 at 9:25 AM Filiz Yilmaz <<a href="mailto:filiz@peeringdb.com">filiz@peeringdb.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><br></div><div>Dear all,</div><div><br></div><div>Bringing this to your attention again: </div><div><br></div><div><a href="https://github.com/peeringdb/peeringdb/issues/627" target="_blank">https://github.com/peeringdb/peeringdb/issues/627</a></div><div><br></div><div>There seems to be support from Product Com as well as some of the TF members for it. </div><div><br></div><div>Thoughts?</div><div><br></div><div>Filiz</div><div><br></div><br><div><blockquote type="cite"><div><div><br>---------- Forwarded message ----------<br>Date: Thu, 9 Jan 2020 19:18:13 +0000 (UTC)<br>From: Chris Caputo <<a href="mailto:ccaputo@alt.net" target="_blank">ccaputo@alt.net</a>><br>Reply-To: Chris Caputo <<a href="mailto:ccaputo-dated-1588965493.0ca23d@alt.net" target="_blank">ccaputo-dated-1588965493.0ca23d@alt.net</a>><br>To: DTF PeeringDB <<a href="mailto:dataownership-tf@lists.peeringdb.com" target="_blank">dataownership-tf@lists.peeringdb.com</a>><br>Subject: Re: [PDB Data Ownership-TF] IXP assignment IP address (netixlan)<br>    ownership (was: conditions for being listed in a facility)<br><br>On Thu, 9 Jan 2020, Arnold Nipper wrote:<br><blockquote type="cite">On 09.01.2020 19:02, Chris Caputo wrote:<br><blockquote type="cite">I believe the importer needs to perform an additional task:<br><br>  - populate/update a new database table, potentially known as <br>    netixlan_ixp, which represents the IXP viewpoint.<br><br>and once that is implemented, it can cease removing conflicted assignments <br>unless a network has opted for IX-F JSON automatic updates.<br></blockquote><br>There is no reason to do so. See #585 [0] which is ready for implementation.<br></blockquote>[...]<br><blockquote type="cite">[0] <a href="https://github.com/peeringdb/peeringdb/issues/585" target="_blank">https://github.com/peeringdb/peeringdb/issues/585</a><br></blockquote><br>Arnold, #585 has the word "Interim" in its very title.  I am proposing a <br>longer term solution that does not put the repeated burden of resolution <br>of ownership issues on the Admin Committee.  I shared my proposal with the <br>PC and got positive feedback, so I have now created an issue for it:<br><br>  <a href="https://github.com/peeringdb/peeringdb/issues/627" target="_blank">https://github.com/peeringdb/peeringdb/issues/627</a><br><br>Chris<br>-- <br>DataOwnership-TF mailing list<br><a href="mailto:DataOwnership-TF@lists.peeringdb.com" target="_blank">DataOwnership-TF@lists.peeringdb.com</a><br><a href="https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-tf" target="_blank">https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-tf</a><br></div></div></blockquote></div><br></div>-- <br>
DataOwnership-TF mailing list<br>
<a href="mailto:DataOwnership-TF@lists.peeringdb.com" target="_blank">DataOwnership-TF@lists.peeringdb.com</a><br>
<a href="https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-tf" rel="noreferrer" target="_blank">https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-tf</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><b>Bill Marantz</b><br>Principal Network Engineer</div><div dir="ltr">Backbone Engineering<br>Mobile: 848-404-4613<div>email: <a href="mailto:ihamilton@salesforce.com" style="color:rgb(17,85,204)" target="_blank">wmarantz@salesforce.com</a><br></div></div></div></div></div></div><br></div></div></div></div></div>