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

Chris Caputo ccaputo at alt.net
Sun Mar 15 16:34:19 PDT 2020


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


More information about the DataOwnership-TF mailing list