[gnso-rds-pdp-wg] Latest Revision to Possible Approach to Determining Consensus

Greg Shatan gregshatanipc at gmail.com
Tue Jul 12 02:07:41 UTC 2016 

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.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>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160711/df7a79c8/attachment.html>

More information about the gnso-rds-pdp-wg mailing list