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

[Chris Caputo]

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