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

[Darrell Budic]

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/530d1553/attachment.htm>