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

[Darrell Budic]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.peeringdb.com/pipermail/dataownership-tf/attachments/20200317/ac70ba2c/attachment-0001.htm>