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

[Filiz Yilmaz]

Hello,

> On 21 Mar 2020, at 22:24, Chris Caputo <ccaputo at alt.net> wrote:
> 
> 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.


Sure. 

I understand Review Phase as the period where a text gets reviewed and word-smithed, after basic ideas had been formulated. 

In RIPE Policy Development Process it comes after some Initial Discussion phase. 
We did not name such an initial discussion phase as per se in our case, but I believe we can count the initial discussions we had until your document emerged under that category too. . 

Last Call is a period just in case someone missed all of the previous discussions and process AND has a strong objection to the document that has gone through the Review Phase. 
 
It is also a note just like boarding a plane, if you dont say anything now, we will go ahead.
In our case that is publishing the document. 

If someone speaks up during Last Call and say they cannot live with some part of the document, natural thing to do would be to put the document with their suggested new text to Review Phase for others to re-evaluate. 

In normal circumstances if people followed what happened during Review Phase we should not have any problems in the Last Call. 



>  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.
> 

My comment was for those who already participated so far, whom you called “approvers” in your initial mail. 

Either way, I would in fact feel more comfortable if all support or objections are sent to this list, so everyone can see them, for transparency reasons. 



>> 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?
> 

If the changes are not conflicting with each other I do not think we need linear processing of calling for multiple Review Phases after each change request. 
We should be able to resolve them altogether for a coherent final document.
If change requests are conflicting and people cannot agree, then we have another problem and that needs to be resolved with a discussion first.

I am fine though having 29 March set as the new Review Phase, after which we can set a week of Last Call, if that works for you. 



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


If someone has an objection to a new change, they need to speak up within the given period. 
Otherwise what is the point of setting these dates?

Either way, I think we have enough supporters for the document. 
Once people explicitly note their feedback on the mailing list and the document goes through Last Call we should be fine, imo.

Having said that we can hear from even more hopefully within the next two weeks. 
That would help, I agree. 


Filiz


> 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