[gnso-rds-pdp-wg] Latest Revision to Possible Approach to Determining Consensus
Catalyst-Vaibhav Aggarwal
va at bladebrains.com
Tue Jul 12 09:42:03 UTC 2016
+1 MarkSV
From: <gnso-rds-pdp-wg-bounces at icann.org> on behalf of Greg Shatan
<gregshatanipc at gmail.com>
Date: Tuesday, July 12, 2016 at 7:37 AM
To: Mark Svancarek <marksv at microsoft.com>
Cc: "gnso-rds-pdp-wg at icann.org" <gnso-rds-pdp-wg at icann.org>
Subject: Re: [gnso-rds-pdp-wg] Latest Revision to Possible Approach to
Determining Consensus
Mark,
A cynic might also say that the objection to use cases is tactical, not
practical.
On Monday, July 11, 2016, Mark Svancarek <marksv at microsoft.com> wrote:
> I¹m puzzled by any objection to use casesŠ you really can¹t design software
> without use cases, and at the end of the day software is going to be built
> around these policies.
>
> I¹m sorry I missed the rationale in HelsinkiŠ Is the concern that there will
> be too many cases? The concern that ³illegitimate² use cases will be proposed
> and them become sacrosanct presumes bad faith on the part of the community and
> cynicism that we can¹t make appropriate compromises. What¹s more likely to
> happen is that false consensus will be achieved without a full set of use
> cases, causing us to back track later.
>
> I thought we had a draft list of use cases already createdŠ is that correct?
> Could you send me a link to them? Sorry for the new-guy questions.
>
> /marksv
>
> From: gnso-rds-pdp-wg-bounces at icann.org
> <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg-bounces at icann.org');>
> [mailto:gnso-rds-pdp-wg-bounces at icann.org
> <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg-bounces at icann.org');> ] On
> Behalf Of Greg Shatan
> Sent: Sunday, July 10, 2016 9:08 PM
> To: Gomes, Chuck <cgomes at verisign.com
> <javascript:_e(%7B%7D,'cvml','cgomes at verisign.com');> >
> Cc: gnso-rds-pdp-wg at icann.org
> <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg at icann.org');>
> Subject: Re: [gnso-rds-pdp-wg] Latest Revision to Possible Approach to
> Determining Consensus
>
>
> I support Chuck's view that we should continue with the direction as proposed.
> This direction is a result of compromises and should be viewed as such.
>
>
>
> For the reasons stated by Chuck, the idea of five preliminary reports is
> unworkable and ill-advised. Our ability to thoroughly and fairly consider the
> fundamental questions in our charter will only be hindered by disaggregating
> the interrelated issues before us. Considering each in isolation would remove
> context and produce results that would tend to be more academic than
> practical.
>
>
>
> The planned approach has a pause in Section 1.b, after deliberating only on
> the purpose, privacy and data elements. Critically, this plan allows to
> consider these three elements in conjunction, as well as in isolation,
> consistent with their interrelated nature. This wouldn't happen if we split
> this into five self-contained units. However, Ayden suggests that privacy be
> the first element and that this then be used as a limitation on all further
> discussions. This is suspiciously like a "privacy first" approach we have
> already debated and rejected at least once. It also sounds like a move away
> from finding consensus on our approach. As Ayden acknowledges, his objection
> to "use cases" is also making a return appearance, after being raised in
> Helsinki.
>
>
>
> If we are going to keep doubling back on ourselves, it will take forever to
> move forward. This is in part because each re-visitation means that all views
> need to be rehashed, for fear that a failure to re-state a view (even one that
> is widely held) will be misinterpreted as lack of support for that view. For
> instance, if Ayden resurfaces his objection to "use cases," do we all need to
> restate the reasons why use cases make good sense, or can we just refer back
> to earlier discussions on the topic? I'll hope that we can refer back to
> earlier discussions, but if not, we'll need to roll them all out again. I'll
> hold of on doing so, optimistic that it will not be necessary to re-enter that
> decision loop again.
>
>
>
> Finally, I would suggest there is no risk of us moving too quickly, and that
> we will have ample time to resolve all potential misunderstandings. As such,
> I think there is little risk that we would actually cause ICANN to implement
> recommendations that would "unintentionally upset the RDS landscape and impose
> significant costs on some stakeholders." We might do so intentionally, and
> that is a very valid concern -- but a different discussion for a different
> phase of our work.
>
>
>
> Greg
>
>
>
> On Sun, Jul 10, 2016 at 10:38 PM, Gomes, Chuck <cgomes at verisign.com
> <javascript:_e(%7B%7D,'cvml','cgomes at verisign.com');> > wrote:
>>
>> Ayden,
>>
>>
>>
>> We hnave discussed your input on the leadership list and the following points
>> were made that I think are worth noting:
>>
>>
>>
>> ". . . the board/GNSO group that developed the process framework explicitly
>> considered whether to split this PDP into multiple PDPs to separately address
>> more specific questions, and firmly decided upon a single PDP which required
>> (at minimum) all of the questions to be considered.
>>
>> "When reaching this decision, the board/GNSO group acknowledged that one
>> large PDP would be very complex and thus more difficult to resource and
>> manage. It did look at spinning off for example a PDP on privacy. However, it
>> was felt that the questions identified in the charter were so tightly
>> inter-related that they could not be effectively progressed independently,
>> and that reaching consensus would require striking a balance between the
>> interests of diverse groups with very different priorities. This is why the
>> charter's phase 1 requires all questions to be considered "simultaneously" by
>> a single group before making an initial recommendation. This is also why the
>> process framework enumerates a list of questions to be evaluated by the GNSO
>> council at key decision points. The intent was to help ensure that sufficient
>> progress is made in considering all questions and concerns, and that none be
>> pushed to the side or left behind for later consideration."
>>
>>
>>
>> "In addition to (the) insights on the process framework, from a practical
>> perspective an Initial Report comes with certain requirements of what needs
>> to be included and a minimum 40-day public comment period so five Initial
>> Reports would create a significant amount of work in addition to a minimum of
>> 200 days of public comment period, and in the end, all the recommendations
>> would need to be bundled up into one overall Initial Report anyway which
>> would also need to go out for public comment. From the process framework as
>> well as WG discussions, it (seems) clear that all these issues are
>> interlinked so it would likely be very difficult (for) the community (to)
>> able to comment on these standalone Initial Reports without having
>> information on how the other issues are addressed. (On a side point) it may
>> be helpful to move away from the term Initial Report as it comes with a
>> number of minimum requirements which may not be relevant for what the WG is
>> trying to achieve."
>>
>>
>>
>> Considering these points, I really believe that we should continue with the
>> direction as proposed but we will discuss this further in our WG meeting
>> Tuesday.
>>
>>
>>
>> Chuck
>>
>>
>>
>>
>> From: Ayden Férdeline [icann at ferdeline.com
>> <javascript:_e(%7B%7D,'cvml','icann at ferdeline.com');> ]
>> Sent: Saturday, July 09, 2016 3:44 PM
>> To: Gomes, Chuck
>> Cc: gnso-rds-pdp-wg at icann.org
>> <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg at icann.org');>
>> Subject: Re: [gnso-rds-pdp-wg] Latest Revision to Possible Approach to
>> Determining Consensus
>>
>> Hi, all-
>>
>>
>>
>> Thank you for sharing this document, Chuck. Having reflected on its contents,
>> I have two suggested revisions. Firstly, I would like to table the idea of
>> having five initial reports, and secondly I would like to re-state my
>> opposition to the inclusion of use cases.
>>
>>
>>
>> Five initial reports would allow us to more thoroughly and fairly consider
>> each of the fundamental questions set out in the working group charter. I
>> appreciate that on the surface this suggestion may sound radical, but I
>> believe a more incremental approach would be the most prudent means through
>> which we could fairly and justly address each of these important, initial
>> charter questions. As Sana noted a few weeks ago, different parts of our work
>> plan are inevitably going to weigh differently on the various stakeholders
>> involved in this working group, so proceeding in a slightly slower fashion
>> will allow us all to be fed new information, ideas, and perspectives. I worry
>> that if we move too quickly, possibly as a result of misunderstandings, we
>> may unintentionally upset the RDS landscape and impose significant costs on
>> some stakeholders.
>>
>>
>>
>> My suggestion is to consider one charter question per initial report,
>> followed by a public consultation exercise. This way, we can better
>> communicate to the wider ICANN community our progress and it will be much
>> easier for others to comment when we ask them to consider a small bite-sized
>> chunk of our work, rather than having to familiarise themselves with every
>> piece of the puzzle. I remember in Helsinki we spoke of wanting to have the
>> GAC involved sooner and more frequently this might be a helpful means of
>> doing just that.
>>
>>
>>
>> My suggested order for the five reports would be: privacy -> purpose -> data
>> elements -> accuracy -> gated access. I would like to suggest we consider
>> privacy first, because until such time as we have a privacy framework to work
>> within it will be difficult (if not impossible?) to define how limited the
>> RDS¹ purpose can or must be. And only once we know the purpose of the RDS can
>> we determine the data elements which need to be collected.
>>
>>
>>
>> Finally, in regards to point 3) c) iii) of version 13 of the work plan, I
>> would just like to have it on the record that I remain opposed - like I was
>> at our face-to-face meeting in Helsinki - to the consideration of use cases
>> in our deliberations. I am concerned that use cases may legitimise
>> illegitimate uses of the RDS because the burden of proof required to strike
>> one out is surely going to be high. If we go down this route of considering
>> use cases, however, I would like to respectfully suggest that we also
>> consider misuse cases they may help us identify negative scenarios that
>> could arise as a result of the RDS.
>>
>>
>>
>> Thank you for considering these two proposals.
>>
>>
>>
>> Best wishes,
>>
>>
>>
>> Ayden
>>
>>
>>
>> P.S. This is my first ICANN working group, so I am still learning about how
>> we initiate PDPs, develop work plans, consider issues, and ultimately reach
>> rough consensus. I say this because it is very possible I have misunderstood
>> something or do not appreciate the repercussions that could arise from my
>> suggested changes to the work plan. If that is the case, I am happy to be
>> corrected :-). However, I do think that there are capacity constraints. There
>> are only so many issues we can work on at once. The perception I have at the
>> moment, of the many emails I receive from this list, are that we are
>> frequently being reminded that we are ahead of ourselves. I have been guilty
>> of this too. Considering each charter question, one at a time, would give us
>> focus and direction.
>>
>>
>>
>> On 8 July 2016 at 18:04, Gomes, Chuck <cgomes at verisign.com
>> <javascript:_e(%7B%7D,'cvml','cgomes at verisign.com');> > wrote:
>>>
>>> Based on the results of our work in Helsinki, the Possible Approach to
>>> Determining Consensus was revised. Changes made since the last version are
>>> redlined to make them easy to find.
>>>
>>> If possible, please try to review the edits made before our WG call next
>>> Tuesday. It will be a main item on our agenda.
>>>
>>> Chuck
>>>
>>> _______________________________________________
>>> gnso-rds-pdp-wg mailing list
>>> gnso-rds-pdp-wg at icann.org
>>> <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg at icann.org');>
>>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmm.icann.o
>>> rg%2fmailman%2flistinfo%2fgnso-rds-pdp-wg&data=01%7c01%7cmarksv%40microsoft.
>>> com%7c22902e72410848bbc3b708d3a9411086%7c72f988bf86f141af91ab2d7cd011db47%7c
>>> 1&sdata=ijre%2bSTFYZNS42f9AmuLLKp0OJ%2bB89EuYBmGiZjL6Rc%3d>
>>
>>
>> _______________________________________________
>> gnso-rds-pdp-wg mailing list
>> gnso-rds-pdp-wg at icann.org
>> <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg at icann.org');>
>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmm.icann.or
>> g%2fmailman%2flistinfo%2fgnso-rds-pdp-wg&data=01%7c01%7cmarksv%40microsoft.co
>> m%7c22902e72410848bbc3b708d3a9411086%7c72f988bf86f141af91ab2d7cd011db47%7c1&s
>> data=ijre%2bSTFYZNS42f9AmuLLKp0OJ%2bB89EuYBmGiZjL6Rc%3d>
>
_______________________________________________ gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg at icann.org
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160712/6f03bdeb/attachment.html>
More information about the gnso-rds-pdp-wg
mailing list