Latest Revision to Possible Approach to Determining Consensus
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
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@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
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@ferdeline.com] Sent: Saturday, July 09, 2016 3:44 PM To: Gomes, Chuck Cc: gnso-rds-pdp-wg@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@verisign.com<mailto:cgomes@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@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
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@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@ferdeline.com] *Sent:* Saturday, July 09, 2016 3:44 PM *To:* Gomes, Chuck *Cc:* gnso-rds-pdp-wg@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@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
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@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Greg Shatan Sent: Sunday, July 10, 2016 9:08 PM To: Gomes, Chuck <cgomes@verisign.com> Cc: gnso-rds-pdp-wg@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@verisign.com<mailto:cgomes@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@ferdeline.com<mailto:icann@ferdeline.com>] Sent: Saturday, July 09, 2016 3:44 PM To: Gomes, Chuck Cc: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@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@verisign.com<mailto:cgomes@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@icann.org<mailto:gnso-rds-pdp-wg@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@icann.org<mailto:gnso-rds-pdp-wg@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>
Mark, A cynic might also say that the objection to use cases is tactical, not practical. On Monday, July 11, 2016, Mark Svancarek <marksv@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@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg-bounces@icann.org');> [mailto:gnso-rds-pdp-wg-bounces@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg-bounces@icann.org');>] *On Behalf Of *Greg Shatan *Sent:* Sunday, July 10, 2016 9:08 PM *To:* Gomes, Chuck <cgomes@verisign.com <javascript:_e(%7B%7D,'cvml','cgomes@verisign.com');>> *Cc:* gnso-rds-pdp-wg@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg@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@verisign.com <javascript:_e(%7B%7D,'cvml','cgomes@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@ferdeline.com <javascript:_e(%7B%7D,'cvml','icann@ferdeline.com');>] *Sent:* Saturday, July 09, 2016 3:44 PM *To:* Gomes, Chuck *Cc:* gnso-rds-pdp-wg@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg@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@verisign.com <javascript:_e(%7B%7D,'cvml','cgomes@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@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg@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...>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg@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...>
+1 MarkSV From: <gnso-rds-pdp-wg-bounces@icann.org> on behalf of Greg Shatan <gregshatanipc@gmail.com> Date: Tuesday, July 12, 2016 at 7:37 AM To: Mark Svancarek <marksv@microsoft.com> Cc: "gnso-rds-pdp-wg@icann.org" <gnso-rds-pdp-wg@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@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@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg-bounces@icann.org');> [mailto:gnso-rds-pdp-wg-bounces@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg-bounces@icann.org');> ] On Behalf Of Greg Shatan Sent: Sunday, July 10, 2016 9:08 PM To: Gomes, Chuck <cgomes@verisign.com <javascript:_e(%7B%7D,'cvml','cgomes@verisign.com');> > Cc: gnso-rds-pdp-wg@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg@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@verisign.com <javascript:_e(%7B%7D,'cvml','cgomes@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@ferdeline.com <javascript:_e(%7B%7D,'cvml','icann@ferdeline.com');> ] Sent: Saturday, July 09, 2016 3:44 PM To: Gomes, Chuck Cc: gnso-rds-pdp-wg@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg@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@verisign.com <javascript:_e(%7B%7D,'cvml','cgomes@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@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg@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@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
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@microsoft.com <mailto:marksv@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@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg-bounces@icann.org');> [mailto:gnso-rds-pdp-wg-bounces@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg-bounces@icann.org');>] *On Behalf Of *Greg Shatan *Sent:* Sunday, July 10, 2016 9:08 PM *To:* Gomes, Chuck <cgomes@verisign.com <javascript:_e(%7B%7D,'cvml','cgomes@verisign.com');>> *Cc:* gnso-rds-pdp-wg@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg@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@verisign.com <javascript:_e(%7B%7D,'cvml','cgomes@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@ferdeline.com <javascript:_e(%7B%7D,'cvml','icann@ferdeline.com');>] *Sent:* Saturday, July 09, 2016 3:44 PM *To:* Gomes, Chuck *Cc:* gnso-rds-pdp-wg@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg@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@verisign.com <javascript:_e(%7B%7D,'cvml','cgomes@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@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg@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...>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org <javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg@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...>
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
We do not intend to examine all use cases. Also, we do not intend to examine controversial use cases. In our call today we are going to look at the example use case that was provided. In doing so, hopefully we can address any concerns and determine whether or not looking at additional use cases might be useful as we begin our deliberation. Let me also emphatically say that no-one's interests or rights will be ignored except for illegal ones. And let me say that we are not yet at the policy development phase, just getting ready to development requirements. Chuck From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Stephanie Perrin Sent: Tuesday, July 12, 2016 8:51 AM To: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Latest Revision to Possible Approach to Determining Consensus 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@microsoft.com<mailto:marksv@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@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org<javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg-bounces@icann.org');>] On Behalf Of Greg Shatan Sent: Sunday, July 10, 2016 9:08 PM To: Gomes, Chuck <cgomes@verisign.com<javascript:_e(%7B%7D,'cvml','cgomes@verisign.com');>> Cc: gnso-rds-pdp-wg@icann.org<javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg@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@verisign.com<javascript:_e(%7B%7D,'cvml','cgomes@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@ferdeline.com<mailto:icann@ferdeline.com>] Sent: Saturday, July 09, 2016 3:44 PM To: Gomes, Chuck Cc: gnso-rds-pdp-wg@icann.org<javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg@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@verisign.com<mailto:cgomes@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@icann.org<javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg@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@icann.org<javascript:_e(%7B%7D,'cvml','gnso-rds-pdp-wg@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@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
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, thedata portability right included in the European Union General Data ProtectionRegulation (GDPR) may significantly alter the relationship between datasubjects and data controllers by making it possible for individuals to managetheir data as a single set of information across different platforms.Forexample, the right might enable data subjects to take their transactionhistories with them when they switch to a new bank, or employees to carry theiremployment records when they move to a new job, even if that new job is inanother country. Theoverall 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 somecontrollers might lose out. Already the right for data subjects to access and receive theirdata already exists under the EU Data Protection Directive (95/46/EC). Article18 of the GDPR augments the data access right by requiring the data subject'spersonal data to be provided “in a structured and commonly used andmachine-readable format” so that it can be provided to an alternative datacontroller “without hindrance” from the original controller.Underthe GDPR, the data subject can also ask the controller to transmit his or herdata directly to an alternative controller “where technically feasible.” The right applies to personal data that is processedon 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@verisign.com> wrote: #yiv7801899585 P {MARGIN-BOTTOM:0px;MARGIN-TOP:0px;}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@ferdeline.com] Sent: Saturday, July 09, 2016 3:44 PM To: Gomes, Chuck Cc: gnso-rds-pdp-wg@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@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
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@yahoo.com] Sent: Monday, July 11, 2016 12:21 AM To: Gomes, Chuck Cc: gnso-rds-pdp-wg@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@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@ferdeline.com] Sent: Saturday, July 09, 2016 3:44 PM To: Gomes, Chuck Cc: gnso-rds-pdp-wg@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@verisign.com<mailto:cgomes@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@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Hi Le 11 juil. 2016 12:49, "Gomes, Chuck" <cgomes@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@yahoo.com] *Sent:* Monday, July 11, 2016 12:21 AM *To:* Gomes, Chuck *Cc:* gnso-rds-pdp-wg@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@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@ferdeline.com] *Sent:* Saturday, July 09, 2016 3:44 PM *To:* Gomes, Chuck *Cc:* gnso-rds-pdp-wg@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@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Thank you for discussing my proposal with the leadership team, Chuck, and for passing on this feedback. I would just like to add that considering the complexity of the issues at hand, I welcome as many opportunities for public input as possible. I do not consider the inclusion of three more brief comment periods to be an undue burden on the working group. This would also give different stakeholders more time to grasp each of the distinct issues we are discussing, while giving working group members an occasional pause during which time we can focus our energies on other projects we are involved in. - Ayden On Mon, Jul 11, 2016 3:38 AM, Gomes, Chuck cgomes@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@ferdeline.com] Sent: Saturday, July 09, 2016 3:44 PM To: Gomes, Chuck Cc: gnso-rds-pdp-wg@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@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg Ayden Férdeline Statement of Interest
Ayden, Broad and frequent community input is an essential part of PDPs but it is important to realize that there are multiple ways to obtain it. One of the basic ways is for members of WGs to serve as conduits for the groups and interests they represent on an ongoing basis. So don’t assume that public comment periods are the only ways to do that. Note that we have reached for input in two different ways already. Chuck From: Ayden Férdeline [mailto:icann@ferdeline.com] Sent: Tuesday, July 12, 2016 8:10 AM To: Gomes, Chuck Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Latest Revision to Possible Approach to Determining Consensus Thank you for discussing my proposal with the leadership team, Chuck, and for passing on this feedback. I would just like to add that considering the complexity of the issues at hand, I welcome as many opportunities for public input as possible. I do not consider the inclusion of three more brief comment periods to be an undue burden on the working group. This would also give different stakeholders more time to grasp each of the distinct issues we are discussing, while giving working group members an occasional during which time we can focus our energies on other projects we are involved in. - Ayden [https://app.mixmax.com/api/track/v2/g3X20EyxcASZdte9I/i02bj5SZulGblRmclZGQu5...] On Mon, Jul 11, 2016 3:38 AM, Gomes, Chuck cgomes@verisign.com<mailto:cgomes@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@ferdeline.com] Sent: Saturday, July 09, 2016 3:44 PM To: Gomes, Chuck Cc: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@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@verisign.com<mailto:cgomes@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@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg Ayden Férdeline Statement of Interest<https://community.icann.org/display/gnsosoi/Ayden+Férdeline+SOI>
Also, for your information, the current minimum time frame for a formal public comment period as set by the ICANN Board is 40 days. Best regards, Marika Marika Konings Senior Policy Director & Team Leader for the GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings@icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages<http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-e...>. From: <gnso-rds-pdp-wg-bounces@icann.org> on behalf of Chuck Gomes <cgomes@verisign.com> Date: Tuesday 12 July 2016 at 15:58 To: 'Ayden Férdeline' <icann@ferdeline.com> Cc: "gnso-rds-pdp-wg@icann.org" <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] Latest Revision to Possible Approach to Determining Consensus Ayden, Broad and frequent community input is an essential part of PDPs but it is important to realize that there are multiple ways to obtain it. One of the basic ways is for members of WGs to serve as conduits for the groups and interests they represent on an ongoing basis. So don’t assume that public comment periods are the only ways to do that. Note that we have reached for input in two different ways already. Chuck From: Ayden Férdeline [mailto:icann@ferdeline.com] Sent: Tuesday, July 12, 2016 8:10 AM To: Gomes, Chuck Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Latest Revision to Possible Approach to Determining Consensus Thank you for discussing my proposal with the leadership team, Chuck, and for passing on this feedback. I would just like to add that considering the complexity of the issues at hand, I welcome as many opportunities for public input as possible. I do not consider the inclusion of three more brief comment periods to be an undue burden on the working group. This would also give different stakeholders more time to grasp each of the distinct issues we are discussing, while giving working group members an occasional during which time we can focus our energies on other projects we are involved in. - Ayden On Mon, Jul 11, 2016 3:38 AM, Gomes, Chuck cgomes@verisign.com<mailto:cgomes@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@ferdeline.com] Sent: Saturday, July 09, 2016 3:44 PM To: Gomes, Chuck Cc: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@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@verisign.com<mailto:cgomes@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@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg Ayden Férdeline Statement of Interest<https://community.icann.org/display/gnsosoi/Ayden+Férdeline+SOI>
It is inevitable that we will be discussing uses for the data at some point. If the term "use cases" is too inflammatory, or if there is concern that discussing how data is used first is too provocative, I suppose we can defer to later. It certainly seems inefficient to me. As a policy-setting group, we'll be deciding which uses of data are necessary and appropriate, and which are not. In my experience, this starts with a broad list of uses which are whittled down during discussion until the core set have emerged. Even if that list contains only a single requirement (e.g. "Registrant data must be sufficiently accurate and complete to allow ICANN compliance team to perform their contractually obligated duties"), I think you will find that multiple potential "use cases" will emerge and need to be debated. Talk to you soon. /marksv ________________________________ From: gnso-rds-pdp-wg-bounces@icann.org <gnso-rds-pdp-wg-bounces@icann.org> on behalf of Marika Konings <marika.konings@icann.org> Sent: Tuesday, July 12, 2016 8:02:10 AM To: Gomes, Chuck; 'Ayden Férdeline' Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Latest Revision to Possible Approach to Determining Consensus Also, for your information, the current minimum time frame for a formal public comment period as set by the ICANN Board is 40 days. Best regards, Marika Marika Konings Senior Policy Director & Team Leader for the GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings@icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flearn.icann....> and visiting the GNSO Newcomer pages<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fgnso.icann.o...>. From: <gnso-rds-pdp-wg-bounces@icann.org> on behalf of Chuck Gomes <cgomes@verisign.com> Date: Tuesday 12 July 2016 at 15:58 To: 'Ayden Férdeline' <icann@ferdeline.com> Cc: "gnso-rds-pdp-wg@icann.org" <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] Latest Revision to Possible Approach to Determining Consensus Ayden, Broad and frequent community input is an essential part of PDPs but it is important to realize that there are multiple ways to obtain it. One of the basic ways is for members of WGs to serve as conduits for the groups and interests they represent on an ongoing basis. So don’t assume that public comment periods are the only ways to do that. Note that we have reached for input in two different ways already. Chuck From: Ayden Férdeline [mailto:icann@ferdeline.com] Sent: Tuesday, July 12, 2016 8:10 AM To: Gomes, Chuck Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Latest Revision to Possible Approach to Determining Consensus Thank you for discussing my proposal with the leadership team, Chuck, and for passing on this feedback. I would just like to add that considering the complexity of the issues at hand, I welcome as many opportunities for public input as possible. I do not consider the inclusion of three more brief comment periods to be an undue burden on the working group. This would also give different stakeholders more time to grasp each of the distinct issues we are discussing, while giving working group members an occasional during which time we can focus our energies on other projects we are involved in. - Ayden On Mon, Jul 11, 2016 3:38 AM, Gomes, Chuck cgomes@verisign.com<mailto:cgomes@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@ferdeline.com] Sent: Saturday, July 09, 2016 3:44 PM To: Gomes, Chuck Cc: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@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@verisign.com<mailto:cgomes@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@icann.org<mailto:gnso-rds-pdp-wg@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%7c2fb93af045b34c4f391d08d3aa65b2f8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=f4x9bVnGsKH3WoRp19CKVM9yWul9Jhh9oYrxGuKFGFo%3d> Ayden Férdeline Statement of Interest<https://na01.safelinks.protection.outlook.com/?url=https:%2f%2fcommunity.ica...>
Thanks Chuck. E-Meet you soon at the PDP Tuesday meeting. Best Regards --ff-- Mail sent from my mobile phone. Excuse for brievety. Le 8 juil. 2016 17:08, "Gomes, Chuck" <cgomes@verisign.com> a écrit :
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@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
participants (10)
-
Ayden Férdeline -
Catalyst-Vaibhav Aggarwal -
Farell Folly -
Gomes, Chuck -
Greg Shatan -
Marika Konings -
Mark Svancarek -
nathalie coupet -
Olévié Kouami -
Stephanie Perrin