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

Mon Jul 11 17:01:40 UTC 2016

Hi
Le 11 juil. 2016 12:49, "Gomes, Chuck" <cgomes at verisign.com> a écrit :

> Nathalie,
>
>
>
> Security & stability will be assumptions in everything we do.  And as you
> know, privacy will be addressed in the first three questions we cover.
>
>
>
> I do have a little concern though when you say "ICANN cannot tell people
> how to implement their software".  Unless it relates to ICANN's mission, I
> think it is correct that ICANN cannot tell people how to implement their
> software; except for gTLD registries & registrars, ICANN has no vehicle for
> doing that.
>
>
>
> Chuck
>
> ------------------------------
>
> *From:* nathalie coupet [nathaliecoupet at yahoo.com]
> *Sent:* Monday, July 11, 2016 12:21 AM
> *To:* Gomes, Chuck
> *Cc:* gnso-rds-pdp-wg at icann.org
> *Subject:* Re: [gnso-rds-pdp-wg] Latest Revision to Possible Approach to
> Determining Consensus
>
> Chuck,
>
> After listening to the Helsinki WG recorded session, I would like to
> express my concern that data security or system integrity, i.e.
> unintentional leaks are being treated only in the implementation phase, and
> according to some, should not even be included in our deliberations.
> I believe data security and privacy to be the two main concerns of simple
> end-users who represent the overwhelming majority of Internet users.
> RDAP/Next-Gen RDS is an opportunity to build trust, in some cases, to
> restore it, for millions of people who use the Internet as an appliance,
> and whose faith in this medium continue to erode, will erode or will never
> materialize, unless concrete steps are taken, at every turn, to secure the
> loopholes that leave them feeling vulnerable.
> When designing a new system or tweaking an old one, shouldn't security and
> integrity be at the heart of our activity? As far as I am concerned, data
> security is a deal breaker and the privacy of PIIs behind gated access a
> thin consolation for the risk that is not being properly addressed, within
> the context of heightened responsibilities on the part of those who benefit
> from the Internet and harvest personally identifying information.
> If ICANN cannot tell people how to implement their software, who will?
> Involuntary data breaches a mere section in the third and last part of our
> work...this doesn't address evolving realities on the ground.  If PIIs have
> value, people will know it, and it's only a matter of time until they
> demand more measures be taken to protect what they have no choice - for the
> time being - but to entrust others with. It is later then we think,
> especially for Europeans, and their legislators seem to be listening - amid
> increasing alarm over U.S. hegemony, especially with social media
> companies. Why not catch the wave ahead of a proliferation of national laws
> aiming at securing the grasp of data subjects over their PIIs and make
> positive steps to patch the fort?
>
> For example, the data portability right included in the European Union
> General Data Protection Regulation (GDPR) may significantly alter the
> relationship between data subjects and data controllers by making it
> possible for individuals to manage their data as a single set of
> information across different platforms.
> For example, the right might enable data subjects to take their
> transaction histories with them when they switch to a new bank, or
> employees to carry their employment records when they move to a new job,
> even if that new job is in another country.
> The overall effect may weaken the hold data controllers have over personal
> data, and to force controllers to work with one another, even in cases in
> which some controllers might lose out. Already the right for data
> subjects to access and receive their data already exists under the EU Data
> Protection Directive (95/46/EC). Article 18 of the GDPR augments the data
> access right by requiring the data subject's personal data to be provided
> “in a structured and commonly used and machine-readable format” so that it
> can be provided to an alternative data controller “without hindrance” from
> the original controller.
> Under the GDPR, the data subject can also ask the controller to transmit
> his or her data directly to an alternative controller “where technically
> feasible.”The right applies to personal data that is processed on the
> basis of the data subject's consent or to fulfill a contract.
> In the future, data subjects might be able to make demands when it comes
> to data security and system integrity, permissible uses (liability of
> controllers in case of loss, leak, selling or re-purposing of their PIIs
> even?). It's only a matter of time. As the value of personal data continues
> to grow, data subject will be awarded greater ownership rights on their
> data and greater control over them. So, will it be business as usual, or
> can we adopt a more forward-looking attitude?
>
> Nathalie
>
>
> On Sunday, July 10, 2016 10:39 PM, "Gomes, Chuck" <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]
> *Sent:* Saturday, July 09, 2016 3:44 PM
> *To:* Gomes, Chuck
> *Cc:* 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> 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
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
>
>
> _______________________________________________
> 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/20160711/7a2d15d9/attachment.html>