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

Sat Mar 21 12:24:34 PDT 2020

Filiz,

> >> As this change came really on the last day of the Review Phase we 
> >> previously announced, best thing to do will be to give ample time to 
> >> everyone to review it properly and have the opportunity to object to it 
> >> if that is the case.

It may be helpful to define the terms "Review Phase" and "Last Call", and 
what is allowed/expected during those phases.  We all come from different 
backgrounds and experience or lack thereof.  My intent has been to give 
the group time to review & make suggestions & improvements.  Clearly I did 
not understand "Review Phase" to mean something akin to "no more edits", 
and I am not sure it does.  Arnold brought up an issue that he felt 
important enough to add and I concurred as part of building consensus.

> Good. Then we can assume silence is consent from those listed above.

I'm not so sure about that and have now directly emailed the draft to 
people on the task force that we haven't heard from about it, in hopes of 
getting their feedback on the latest draft.  Sometimes list emails just 
get lost in the depths of people's inboxes.

> Otherwise they can speak up until 29 March as well as others.

I recommend this not be rushed.

How about a review period of 1 week since each last change, repeatable, 
with a last call week only happening after a review week with no changes?

And how about, no changes from this point onward unless there are at least 
4 supporters of a given change?

We have plenty of task force members we have not heard from and this was 
only recently shared with the Admin & Product committees for 
feedback/objections.

Thanks,
Chris

On Sat, 21 Mar 2020, Filiz Yilmaz wrote:
> > On 21 Mar 2020, at 21:35, Chris Caputo <ccaputo at alt.net> wrote:
> > 
> > Hi.  4 of the 5 previous approvers have approved this new version.  
> > (Arnold, William, Darrel, and myself.  Waiting on Terry.)
> > 
> 
> Good. Then we can assume silence is consent from those listed above.
> 
> Otherwise they can speak up until 29 March as well as others.
> 
> >  https://www.caputo.com/dotf/0.20200320.2-CC-AN-WM-DB.txt
> > 
> > I am not comfortable setting the version number to 1.0 until all is said 
> > and done.  Doing so would defeat the purpose of the versioning system 
> > which also tracks approvers.  The document finally approved by the task 
> > force, whatever and whenever that is, should be set to be 1.0, but we are 
> > not there yet.
> 
> 
> That’s what my intention was if what I said was not clear: the document 
> that goes to Last Call and which will be the final document will have 
> version 1.0, ie the final public facing document.
> 
> Filiz
> 
> > 
> > Chris
> > 
> >> On Sat, 21 Mar 2020, Filiz Yilmaz wrote:
> >> Chris, all,
> >> 
> >> As this change came really on the last day of the Review Phase we 
> >> previously announced, best thing to do will be to give ample time to 
> >> everyone to review it properly and have the opportunity to object to it 
> >> if that is the case.
> >> 
> >> But I also think we can do that during the Last Call, that we planned 
> >> previously. I would be happy to take silence as consent but since the 
> >> change came rather last minute and since you asked for support or 
> >> feedback in your previous mail I think it will be good to see the 
> >> support notes transparently on the list during this period too.
> >> 
> >> My only comment is rather cosmetic and towards the look of the final 
> >> document: While the version of the document to the TF makes sense, the 
> >> final and public facing document should go out with version 1.0.
> >> Can you pls change that? 
> >> 
> >> With all this, lets set the end of Last Call to 29 March. 
> >> 
> >> Pls send support or objections to the list until this date.
> >> 
> >> 
> >> Assuming there is support for change as well as no objections to any 
> >> other parts of the document, after 29 March, we announce consensus on 
> >> it, seal the document and announce it.
> >> 
> >> Kind regards
> >> 
> >> Filiz
> >> 
> >>      On 20 Mar 2020, at 19:40, Chris Caputo <ccaputo at alt.net> wrote:
> >> 
> >>      Arnold reached out to me about an issue with respect to embargoed
> >>      information at an IX.  Ie., a Network who has requested to not yet be
> >>      listed in the IX-F JSON export, but who then updates PeeringDB prior to
> >>      informing the IX the embargo can be listed.
> >> 
> >>      Please see the below diff and provide feedback and/or support.  I will
> >>      also reach out directly to previous approvers.
> >> 
> >>      The change indicates that data will remain unpublished until the
> >>      resolution is made by the IX ending the embargo so that its data begins to
> >>      match that provided by the Network.  Then when that happens, the data can
> >>      become published.  (An IX would end an embargo when a network reaches out
> >>      to it and says its connection is no longer confidential.)
> >> 
> >>      Thanks,
> >>      Chris
> >> 
> >>      ---
> >> 
> >>      New draft: https://www.caputo.com/dotf/0.20200320.1-CC-AN.txt
> >>      Diff here at and at: https://www.caputo.com/dotf/0.20200317.4-CC-DB-TS-AN-WM_0.20200320.1-CC-AN.diff.txt
> >> 
> >>      --- 0.20200317.4-CC-DB-TS-AN-WM.txt    2020-03-17 23:30:20.401784614 +0000
> >>      +++ 0.20200320.1-CC-AN.txt    2020-03-20 16:37:33.379968769 +0000
> >>      @@ -1,7 +1,7 @@
> >>      PeeringDB Data Ownership Policy Document
> >> 
> >>      Date: TBD
> >>      -Version: 0.20200317.4-CC-DB-TS-AN-WM
> >>      +Version: 0.20200320.1-CC-AN
> >> 
> >>      1) Background
> >> 
> >>      @@ -688,6 +688,11 @@
> >>      Internet Exchange, as a means of expediting resolution and decreasing the
> >>      burdens on the Admin Committee.
> >> 
> >>      +It is understood that an IX-F Member Import may be incomplete, such as due
> >>      +to an information embargo requirement. If a conflict arises due to new
> >>      +data provided by a Network, the above conflict resolution recommendations
> >>      +are appropriate.
> >>      +
> >>      6.2) ixfac & netfac
> >> 
> >>      A conflict may arise in which a Facility with an actual owner disputes the
> >>      --
> >>      DataOwnership-TF mailing list
> >>      DataOwnership-TF at lists.peeringdb.com
> >>      https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-tf
> 