[PDB Data Ownership-TF] draft "Data Ownership Policy Document"

[Darrell Budic]

Haha, I had specifically removed that comma because I didn’t think it was needed and I’m generally guilty of terrible comma splicing. How about making that line

+Similarly any new data, such as that from an IX-F Member Import or which is 
+entered by a Network, which conflicts with existing data, shall not be 

still a lot of commas, but reads better to me. Although I could live with your version if no one else has an issue with it.

> On Mar 17, 2020, at 4:15 PM, Chris Caputo <ccaputo at alt.net> wrote:
> 
> Good here.  I added a comma to your version (between 'data' and 'shall') 
> to end up with:
> 
>  @@ -677,7 +677,8 @@
>   done so by the Network or by a resolution process mediated by the Admin 
>   Committee.
> 
>  -Similarly, conflicted data which has not been published shall not be 
>  +Similarly, new data such as that from an IX-F Member Import or which is 
>  +entered by a Network which conflicts with existing data, shall not be 
>   published until a resolution process has been mediated by the Admin 
>   Committee and/or the conflict is resolved due to updated data from the 
>   Internet Exchange or the Network.
> 
> Please let me know if that works for you and then I'll work to clear it 
> with the prior approvers.
> 
> Thanks!
> 
> Chris
> 
> On Tue, 17 Mar 2020, Darrell Budic wrote:
>> Not quite there for me, what do you think of:
>> @@ -677,10 +677,11 @@
>>   done so by the Network or by a resolution process mediated by the Admin 
>>   Committee.
>> 
>>  -Similarly, conflicted data which has not been published shall not be 
>>  -published until a resolution process has been mediated by the Admin 
>>  -Committee and/or the conflict is resolved due to updated data from the 
>>  -Internet Exchange or the Network.
>>  +Similarly, new data such as that from an IX-F Member Import or which is 
>>  +entered by a Network which conflicts with existing data shall not be 
>>  +published until a resolution process has been mediated by the Admin 
>>  +Committee and/or the conflict is resolved due to updated data from the
>>  +Internet Exchange or the Network.
>> 
>> Going for wording changes to make it clearer that any newly entered data is subject to this policy, with minor capitalization and spelling (conflicts) fixes as well.
>> 
>> 
>>      On Mar 17, 2020, at 3:03 PM, Chris Caputo <ccaputo at alt.net> wrote:
>> 
>> Hi Darrell,
>> 
>> Thank you for the suggestion.  Does this work for you?
>> 
>> Chris
>> 
>> ---
>>  @@ -677,10 +677,11 @@
>>   done so by the Network or by a resolution process mediated by the Admin
>>   Committee.
>> 
>>  -Similarly, conflicted data which has not been published shall not be
>>  -published until a resolution process has been mediated by the Admin
>>  -Committee and/or the conflict is resolved due to updated data from the
>>  -Internet Exchange or the Network.
>>  +Similarly, new data such as that from an IX-F Member Import or a Network,
>>  +which conficts with existing data, shall not be published until a
>>  +resolution process has been mediated by the Admin Committee and/or the
>>  +conflict is resolved due to updated data from the Internet Exchange or the
>>  +Network.
>> 
>>   The Task Force recommends PeeringDB employ user interface methods and
>> 
>>   email notifications to encourage data harmony between a Network and an
>> 
>> On Tue, 17 Mar 2020, Darrell Budic wrote:
>>      Ah, that makes sense. And since it’s the second time I’ve had that question, I suggest the following change to 6.1:
>>      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.
>> 
>>      Or something similar that clarifies that this is newly entered data. With at that change or something similar, I support this plan.
>> 
>>         -Darrell
>> 
>>           On Mar 15, 2020, at 6:34 PM, Chris Caputo <ccaputo at alt.net> wrote:
>> 
>>      On Sun, 15 Mar 2020, Darrell Budic wrote:
>>           One nit pick:
>>           3.2:
>> 
>>           - Data is expected to be consistent and correct following good
>>             engineering.
>>           should probably be
>> 
>>           - Data is expected to be consistent and correct following good
>>             engineering practices.
>> 
>> 
>>      Hi Darrell,
>> 
>>      I like this change and put it up at:
>> 
>>       https://www.caputo.com/dotf/0.20200315.1-CC.txt
>> 
>>      Diff:
>> 
>>       https://www.caputo.com/dotf/0.20200307.1-CC-AN-WM-TS_0.20200315.1-CC.diff.txt
>> 
>>       --- 0.20200307.1-CC-AN-WM-TS.txt 2020-03-07 01:47:36.077354078 +0000
>>       +++ 0.20200315.1-CC.txt 2020-03-15 23:16:10.764210670 +0000
>>       @@ -1,7 +1,7 @@
>>        PeeringDB Data Ownership Policy Document
>> 
>>        Date: TBD
>>       -Version: 0.20200307.1-CC-AN-WM-TS
>>       +Version: 0.20200315.1-CC.txt
>> 
>>        1) Background
>> 
>>       @@ -62,7 +62,7 @@
>>        3.2) Expectations
>> 
>>         - Data is expected to be consistent and correct following good
>>       -   engineering.
>>       +   engineering practices.
>> 
>>         - Users are expected to keep their Organization's data current.
>> 
>>      Darrell and others, please let me know if you approve of this new version
>>      and want your initials added to it.  I will also reach out directly to the
>>      previous approvers.
>> 
>>           and one question. In 6.1, "Similarly, conflicted data which has not been
>>           published shall not be”. How can this occur? Is there an example someone
>>           can provide? Does peeringdb delay the publishing of new data in such a
>>           way as multiple entries could be made before publishing, causing such an
>>           unpublished conflict?
>> 
>> 
>>      At present PeeringDB does not prevent publication of netixlan data which
>>      is in conflict with an IX-F JSON export from an IX.  This recommendation
>>      from the task force would hopefully change that by resulting in an Issue
>>      or Issues on GitHub that act as feature requests for tracking the
>>      development of changes to the code base.
>> 
>>      A specific example would be if IX Foo exports an IX-F JSON that specifies
>>      that AS65512 has an assignment of 192.0.2.1 and Network AS65512 instead
>>      inputs an assignment of 192.0.2.2, the code would prevent the publication
>>      of 192.0.2.2 and instead result in:
>> 
>>       - "user interface methods and email notifications to encourage data
>>         harmony between a Network and an Internet Exchange, as a means of
>>         expediting resolution and decreasing the burdens on the Admin
>>         Committee."
>> 
>>      If anyone would like to see what an IX-F JSON dump looks like, check out:
>> 
>>       https://www.seattleix.net/autogen/participants.json
>> 
>>      Darrell, please let me know if this does not answer your questions?
>> 
>>      Thank you,
>>      Chris
>> 
>> 
>>