<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Ah, that makes sense. And since it’s the second time I’ve had that question, I suggest the following change to 6.1:<div class=""><br class=""></div><div class=""><b class="">Similarly, if any newly entered data (via the UI or methods such as an IX-F upload) conflicts withe existing data, it shall not be published.</b></div><div class=""><br class=""></div><div class="">Or something similar that clarifies that this is newly entered data. With at that change or something similar, I support this plan.</div><div class=""><br class=""></div><div class=""> -Darrell<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 15, 2020, at 6:34 PM, Chris Caputo <<a href="mailto:ccaputo@alt.net" class="">ccaputo@alt.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Sun, 15 Mar 2020, Darrell Budic wrote:<br class=""><blockquote type="cite" class="">One nit pick:<br class="">3.2:<br class=""><br class=""> - Data is expected to be consistent and correct following good <br class=""> engineering.<br class="">should probably be<br class=""><br class=""> - Data is expected to be consistent and correct following good <br class=""> engineering practices.<br class=""></blockquote><br class="">Hi Darrell,<br class=""><br class="">I like this change and put it up at:<br class=""><br class=""> <a href="https://www.caputo.com/dotf/0.20200315.1-CC.txt" class="">https://www.caputo.com/dotf/0.20200315.1-CC.txt</a><br class=""><br class="">Diff:<br class=""><br class=""> <a href="https://www.caputo.com/dotf/0.20200307.1-CC-AN-WM-TS_0.20200315.1-CC.diff.txt" class="">https://www.caputo.com/dotf/0.20200307.1-CC-AN-WM-TS_0.20200315.1-CC.diff.txt</a><br class=""><br class=""> --- 0.20200307.1-CC-AN-WM-TS.txt<span class="Apple-tab-span" style="white-space:pre"> </span>2020-03-07 01:47:36.077354078 +0000<br class=""> +++ 0.20200315.1-CC.txt<span class="Apple-tab-span" style="white-space:pre"> </span>2020-03-15 23:16:10.764210670 +0000<br class=""> @@ -1,7 +1,7 @@<br class=""> PeeringDB Data Ownership Policy Document<br class=""><br class=""> Date: TBD<br class=""> -Version: 0.20200307.1-CC-AN-WM-TS<br class=""> +Version: 0.20200315.1-CC.txt<br class=""><br class=""> 1) Background<br class=""><br class=""> @@ -62,7 +62,7 @@<br class=""> 3.2) Expectations<br class=""><br class=""> - Data is expected to be consistent and correct following good <br class=""> - engineering.<br class=""> + engineering practices.<br class=""><br class=""> - Users are expected to keep their Organization's data current.<br class=""><br class="">Darrell and others, please let me know if you approve of this new version <br class="">and want your initials added to it. I will also reach out directly to the <br class="">previous approvers.<br class=""><br class=""><blockquote type="cite" class="">and one question. In 6.1, "Similarly, conflicted data which has not been <br class="">published shall not be”. How can this occur? Is there an example someone <br class="">can provide? Does peeringdb delay the publishing of new data in such a <br class="">way as multiple entries could be made before publishing, causing such an <br class="">unpublished conflict?<br class=""></blockquote><br class="">At present PeeringDB does not prevent publication of netixlan data which <br class="">is in conflict with an IX-F JSON export from an IX. This recommendation <br class="">from the task force would hopefully change that by resulting in an Issue <br class="">or Issues on GitHub that act as feature requests for tracking the <br class="">development of changes to the code base.<br class=""><br class="">A specific example would be if IX Foo exports an IX-F JSON that specifies <br class="">that AS65512 has an assignment of 192.0.2.1 and Network AS65512 instead <br class="">inputs an assignment of 192.0.2.2, the code would prevent the publication <br class="">of 192.0.2.2 and instead result in:<br class=""><br class=""> - "user interface methods and email notifications to encourage data <br class=""> harmony between a Network and an Internet Exchange, as a means of <br class=""> expediting resolution and decreasing the burdens on the Admin <br class=""> Committee."<br class=""><br class="">If anyone would like to see what an IX-F JSON dump looks like, check out:<br class=""><br class=""> <a href="https://www.seattleix.net/autogen/participants.json" class="">https://www.seattleix.net/autogen/participants.json</a><br class=""><br class="">Darrell, please let me know if this does not answer your questions?<br class=""><br class="">Thank you,<br class="">Chris</div></div></blockquote></div><br class=""></div></body></html>