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

Patrick Gilmore patrick at peeringdb.com
Mon Mar 23 08:12:17 PDT 2020


As has been pointed out, the 11A Easter / 8A Pacific call today was moved to the 30th. I thought we were doing both.

Perhaps I am not qualified to comment since I cannot even read a calendar?

-- 
TTFN,
patrick

> On Mar 23, 2020, at 9:06 AM, Patrick Gilmore <patrick at peeringdb.com> wrote:
> 
> The call is in two hours, but to avoid confusion, I support the current draft. (I was being silent because I thought as a Board member AND a TF member, I thought I should reserve comment until the final call. But that was clearly a mistake.)
> 
> As for Job’s suggestion, I support allowing a final appeal to the Board. I did not bring it up before because, in my my, that is always an option. That said, I like the idea of having it explicitly called out in the doc.
> 
> -- 
> TTFN,
> patrick
> 
>> On Mar 22, 2020, at 8:00 AM, Filiz Yilmaz <filiz at peeringdb.com <mailto:filiz at peeringdb.com>> wrote:
>> 
>> Hi Chris, 
>> 
>> I feel we are saying very similar (or read not so orthogonal..) things but we seem also not communicating well. 
>> 
>> We are in the middle of an important discussion sparked with Job’s latest comment and I do not want derail attention from that. 
>> So short version:  Lets just stick to 29 March deadline for the end of Review Phase. 
>> Once we are there we can re-open the discussion what comes next. 
>>  
>> 
>> Longer-ish version for those who has the attentions-pan, to clarify my points: 
>> 
>> - I am not suggesting a pre-set date for a LAST CALL. But a Review Phase, assuming successfully finalized, should be followed with a LAST CALL. I hope we can agree on that for the reasons I had explained before. Timing of it can be set later on. 
>> 
>> - Up until Job’s comment and the discussion on how to handle a dispute resolution, previous edits comments did not require a new Review Phase to me and hence I suggested a LAST CALL yesterday.  Job’s comment that came afterwards changes this and I agree we need to discuss this further and secure support for it. 
>> 
>> - I strongly suggest all support/opposition are sent to this public mailing list. I am fine if you prefer to have private conversations to resolve detailed wording issues but overall support and/or objections should be transparently noted at this stage on the mailing list. Lets not create alternative channels and stick to the mailing list where everyone can see support and objection levels. 
>> 
>> - When it comes to calling for consensus; I am not keen on counting on voting on objection or supports by arbitrary numbers, especially per change. At this point we should be able to reach a reasonable consensus where all those who chose to speak up are comfortable enough with the wording of the resulting document. If something is crucially wrong, that can be raised and we can look for remedies all together too.  
>> 
>> 
>> Filiz
>> 
>> 
>> 
>> 
>>> On 22 Mar 2020, at 03:16, Chris Caputo <ccaputo at alt.net <mailto:ccaputo at alt.net>> wrote:
>>> 
>>> On Sun, 22 Mar 2020, Filiz Yilmaz wrote:
>>>>>> 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.
>>> 
>>> I am using an "approvers" list to specifically avoid the 
>>> silence-is-consent notion.
>>> 
>>>> 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.
>>> 
>>> I too encourage all to share their support or objections to the list, but 
>>> if someone expresses something privately, that puts me in a tough 
>>> position, given the norms of not sharing private email.  The purpose of 
>>> the adding of initials to the drafts is that it makes clear if support has 
>>> been expressed (even if privately) for a specific draft, while also 
>>> enabling the person to publicly rebut any mistaken inclusion of their 
>>> support.
>>> 
>>>>>> 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.
>>> 
>>> I mean that the 1 week clock resets after the most recent change.  Yes, 
>>> multiple changes can happen concurrently, with the clock starting after 
>>> the last change.
>>> 
>>> This is an idea in hopes of progress, avoiding the pressure of a premature 
>>> Last Call while the document is still alive.
>>> 
>>>> 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. 
>>> 
>>> It doesn't work for me.  :-)  I don't want a Last Call to happen unless 
>>> there has been a 1 week opportunity for any needed revisions to be 
>>> considered.  Thus we might be ready for Last Call even earlier, but I 
>>> don't want to say that it must start on the 29th, if it doesn't make sense 
>>> to do so come the 29th.
>>> 
>>>>> 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?
>>> 
>>> To help wind this down, I am proposing that new changes require the 
>>> support of 4 people before getting into a draft, and that the 1 week 
>>> Review Phase clock starts again if that happens.
>>> 
>>> If anyone objects, and they can find 3 or more people on the Task Force to 
>>> agree with their objection, they can submit a further revision to resolve 
>>> their objection.
>>> 
>>> And this process can continue as a path to consensus, since people tend to 
>>> prefer to work toward agreement rather than a stalemate.
>>> 
>>> There is current discussion about a change to the most recent draft.  My 
>>> intent it to help facilitate that discussion toward consensus.
>>> 
>>> Thanks,
>>> Chris
>> 
>> -- 
>> DataOwnership-TF mailing list
>> DataOwnership-TF at lists.peeringdb.com <mailto:DataOwnership-TF at lists.peeringdb.com>
>> https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-tf
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.peeringdb.com/pipermail/dataownership-tf/attachments/20200323/541411f4/attachment-0001.htm>


More information about the DataOwnership-TF mailing list