[PDB Data Ownership-TF] draft "Data Ownership Policy Document"
Chris Caputo
ccaputo at alt.net
Tue Mar 17 16:00:36 PDT 2020
Darrell and I worked this out off the list and we came up with this:
Similarly, new data 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.
Diff from 0.20200315.3-CC-TS-WM-AN.txt:
-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 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.
New version up at:
https://www.caputo.com/dotf/0.20200317.3-CC-DB.txt
Thanks,
Chris
On Tue, 17 Mar 2020, Darrell Budic wrote:
> 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
> >>
> >>
> >>
>
More information about the DataOwnership-TF
mailing list