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

[Filiz Yilmaz]

> 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