[gnso-rds-pdp-wg] Latest Revision to Possible Approach to Determining Consensus
Stephanie Perrin
stephanie.perrin at mail.utoronto.ca
Tue Jul 12 12:51:03 UTC 2016
I am not sure it is helpful to describe the objections to use cases
being discussed as "tactical", Greg. Those of us who have objected to
exploring use cases prior to deciding on the purpose of the RDS, may be
objecting on various grounds. I objected to the same strategy during
the EWG, with the identical effect, and I must say as a greenhorn at
ICANN I had no concept of tactics at that time. In response to Mark's
question, which is a good one, we are not designing software here, we
are deciding policy. Determining the overall purposes of such a policy
before starting to work on the nuts and bolts, is pretty normal. You
could characterize the discussion of use cases as an environmental scan,
(if you were drafting new legislation, for instance) but because of the
inherently heterogeneous nature of our group, and the differences in
policy formation practices which our various countries follow, it is
doubtful that everyone would understand the limitations of that exercise.
In case you really wanted to hear my reasons for not starting with use
cases again, here they are:
* We are supposed to be developing a policy for the new RDS, if indeed
we decide we need a new RDS
* Many of the current practices surrounding the RDS reflect certain
dominant interests that have had a normative effect on the RDS as it
has emerged over the years
* The Internet has changed considerably during that 18 year period,
and it is time to recalibrate the balance of interests, which we are
doing via this long-awaited policy
* The interests and rights of end-users (ie the registrants, not the
many data users who have been harvesting data) have been largely
ignored and need to be discussed in terms of the actual purpose of
the registry; that purpose has not been defined but should be
limited and closely associated with the ICANN goal of ensuring the
security and stability of the INternet
* The officials who are charged with defending privacy rights and
enforcing data protection laws have been largely ignored, and their
demands for establishing respect for the basic rule of law in the
matter of data collection, use disclosure and retention should be
respected.
* Examining all use cases, including ones which are excessive, have
been the result of business tradeoffs, or do not reflect ICANN's
accountability goals, risk muddying the waters for any logical
discussion of policy
Someone recently remarked that people are repeating themselves. This
will be inevitable during this process. I think we should get used to
this idea.
Stephanie Perrin
On 2016-07-11 22:07, Greg Shatan wrote:
> 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
> <mailto: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.org%2fmailman%2flistinfo%2fgnso-rds-pdp-wg&data=01%7c01%7cmarksv%40microsoft.com%7c22902e72410848bbc3b708d3a9411086%7c72f988bf86f141af91ab2d7cd011db47%7c1&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.org%2fmailman%2flistinfo%2fgnso-rds-pdp-wg&data=01%7c01%7cmarksv%40microsoft.com%7c22902e72410848bbc3b708d3a9411086%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=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/bc7fe0b5/attachment.html>
More information about the gnso-rds-pdp-wg
mailing list