Hello All, I have given the potential ePDP much thought over the last two days. To effectively do this work at the speed that it will require we need to focus the ePDP. As you all know this is a tremendous amount of work. We need to address the following: Including at the very least the GAC and SSAC in this ePDP will be critical. The members of the team should be limited to 5-6 members of each SG/AC. Each member must agree to accept the fast paced extensive work load, participating on calls, subgroups and drafting when necessary. Understand that their work is representational of the community they are affiliated with and will receive endorsement to express views. Create a leadership team with extensive knowledge and time to focus on this work. Select a Chair that will have the time and skills to effectively manage the ePDP. Include a Board member for oversight and check ins on the team. This ePDP should focus on the critical needs identified in the Annex of the Temporary Spec. first as these issues are of critical importance. (copied below for ease of reference) Annex: Important Issues for Further Community Action The purpose of this Annex is to set forth implementation issues raised during the course of development of this Temporary Specification for which the ICANN Board encourages the community to continue discussing so that they may be resolved as quickly as possible after the effective date of the Temporary Specification. This Annex does not create new or modified requirements for Registrar or Registry Operator, nor is it intended to direct the scope of the Policy Development Process, which will be initiated as a result of the Board’s adoption of thisTemporary Specification. 1. Pursuant to Section 4.4, continuing community work to develop an accreditation and access model that complies with GDPR, while recognizing the need to obtain additional guidance from Article 29 Working Party/European Data Protection Board. 2. Addressing the feasibility of requiring unique contacts to have a uniform anonymized email address across domain name registrations at a given Registrar, while ensuring security/stability and meeting the requirements of Section 2.5.1 of Appendix A. 3. Developing methods to provide potential URS and UDRP complainants with sufficient access to Registration Data to support good-faith filings of complaints. 4. Consistent process for continued access to Registration Data, including non- public data, for users with a legitimate purpose, until the time when a final accreditation and access mechanism is fully operational, on a mandatory basis for all contracted parties. 5. Distinguishing between legal and natural persons to allow for public access to the Registration Data of legal persons, which are not in the remit of the GDPR. 6. Limitations in terms of query volume envisaged under an accreditation program balanced against realistic investigatory cross-referencing needs. 7. Confidentiality of queries for Registration Data by law enforcement authorities. Looking forward to discussing further tonight. Susan Kawaguchi BC Councilor.
Susan, Responses inline.
On 23 May 2018, at 21:26, Susan Kawaguchi <susankpolicy@gmail.com <mailto:susankpolicy@gmail.com>> wrote:
Hello All,
I have given the potential ePDP much thought over the last two days.
To effectively do this work at the speed that it will require we need to focus the ePDP. As you all know this is a tremendous amount of work.
We need to address the following:
Including at the very least the GAC and SSAC in this ePDP will be critical.
While this is still a GNSO ePDP, the fact that we will likely not run an open WG means that we should invite ACs, but I don't see why some ACs would be critical and others would not.
The members of the team should be limited to 5-6 members of each SG/AC.
I'm more inclined to a lesser number of members per SG, and even less from ACs, perhaps one each per AC.
Each member must agree to accept the fast paced extensive work load, participating on calls, subgroups and drafting when necessary.
And to be willing to come to common grounds... which is the only way for this effort to not fail like all others before them have.
Understand that their work is representational of the community they are affiliated with and will receive endorsement to express views.
I'm not sure of that; while I understand that idea, and this is how Council representation works for 3 of the 4 GNSO SGs, I'm afraid it could be not practical and hamper productivity, but I'm not ready yet to offer an alternative.
Create a leadership team with extensive knowledge and time to focus on this work.
Select a Chair that will have the time and skills to effectively manage the ePDP.
Yeap.
Include a Board member for oversight and check ins on the team.
I believe Board liaison(s) would be helpful in not causing a delay by drafting a policy Board wouldn't be able to accept, but I wouldn't call them members.
This ePDP should focus on the critical needs identified in the Annex of the Temporary Spec. first as these issues are of critical importance. (copied below for ease of reference)
But if the main topics are not dealt with by the ePDP, temp spec will expire and lose effect... so I would rather see the opposite: taking first the items already included in the spec, bake all the uncontroversial ones into policy and begin implementation of them ASAP. Only after that first report, deal with controversial and further community action ones. Having parallel PDP/IRT teams also seem to be needed to achieve the ambitious timeframe imposed by the temp spec framework. Rubens
Annex: Important Issues for Further Community Action
The purpose of this Annex is to set forth implementation issues raised during the course of development of this Temporary Specification for which the ICANN Board encourages the community to continue discussing so that they may be resolved as quickly as possible after the effective date of the Temporary Specification. This Annex does not create new or modified requirements for Registrar or Registry Operator, nor is it intended to direct the scope of the Policy Development Process, which will be initiated as a result of the Board’s adoption of thisTemporary Specification.
Pursuant to Section 4.4, continuing community work to develop an accreditation and access model that complies with GDPR, while recognizing the need to obtain additional guidance from Article 29 Working Party/European Data Protection Board.
Addressing the feasibility of requiring unique contacts to have a uniform anonymized email address across domain name registrations at a given Registrar, while ensuring security/stability and meeting the requirements of Section 2.5.1 of Appendix A.
Developing methods to provide potential URS and UDRP complainants with sufficient access to Registration Data to support good-faith filings of complaints.
Consistent process for continued access to Registration Data, including non- public data, for users with a legitimate purpose, until the time when a final accreditation and access mechanism is fully operational, on a mandatory basis for all contracted parties.
Distinguishing between legal and natural persons to allow for public access to the Registration Data of legal persons, which are not in the remit of the GDPR.
Limitations in terms of query volume envisaged under an accreditation program balanced against realistic investigatory cross-referencing needs.
Confidentiality of queries for Registration Data by law enforcement authorities.
Looking forward to discussing further tonight.
Susan Kawaguchi
BC Councilor.
_______________________________________________ council mailing list council@gnso.icann.org <mailto:council@gnso.icann.org> https://mm.icann.org/mailman/listinfo/council
Agree with Rubens that no one SO/AC is more important than another. Is Susan’s suggestion 5-6 per SO/AC or SG/C? I’m confused. From: council <council-bounces@gnso.icann.org> on behalf of Rubens Kuhl <rubensk@nic.br> Date: Wednesday, May 23, 2018 at 9:16 PM To: Susan Kawaguchi <susankpolicy@gmail.com> Cc: GNSO Council List <council@gnso.icann.org> Subject: Re: [council] ePDP Susan, Responses inline. On 23 May 2018, at 21:26, Susan Kawaguchi <susankpolicy@gmail.com> wrote: Hello All, I have given the potential ePDP much thought over the last two days. To effectively do this work at the speed that it will require we need to focus the ePDP. As you all know this is a tremendous amount of work. We need to address the following: Including at the very least the GAC and SSAC in this ePDP will be critical. While this is still a GNSO ePDP, the fact that we will likely not run an open WG means that we should invite ACs, but I don't see why some ACs would be critical and others would not. The members of the team should be limited to 5-6 members of each SG/AC. I'm more inclined to a lesser number of members per SG, and even less from ACs, perhaps one each per AC. Each member must agree to accept the fast paced extensive work load, participating on calls, subgroups and drafting when necessary. And to be willing to come to common grounds... which is the only way for this effort to not fail like all others before them have. Understand that their work is representational of the community they are affiliated with and will receive endorsement to express views. I'm not sure of that; while I understand that idea, and this is how Council representation works for 3 of the 4 GNSO SGs, I'm afraid it could be not practical and hamper productivity, but I'm not ready yet to offer an alternative. Create a leadership team with extensive knowledge and time to focus on this work. Select a Chair that will have the time and skills to effectively manage the ePDP. Yeap. Include a Board member for oversight and check ins on the team. I believe Board liaison(s) would be helpful in not causing a delay by drafting a policy Board wouldn't be able to accept, but I wouldn't call them members. This ePDP should focus on the critical needs identified in the Annex of the Temporary Spec. first as these issues are of critical importance. (copied below for ease of reference) But if the main topics are not dealt with by the ePDP, temp spec will expire and lose effect... so I would rather see the opposite: taking first the items already included in the spec, bake all the uncontroversial ones into policy and begin implementation of them ASAP. Only after that first report, deal with controversial and further community action ones. Having parallel PDP/IRT teams also seem to be needed to achieve the ambitious timeframe imposed by the temp spec framework. Rubens Annex: Important Issues for Further Community Action The purpose of this Annex is to set forth implementation issues raised during the course of development of this Temporary Specification for which the ICANN Board encourages the community to continue discussing so that they may be resolved as quickly as possible after the effective date of the Temporary Specification. This Annex does not create new or modified requirements for Registrar or Registry Operator, nor is it intended to direct the scope of the Policy Development Process, which will be initiated as a result of the Board’s adoption of thisTemporary Specification. Pursuant to Section 4.4, continuing community work to develop an accreditation and access model that complies with GDPR, while recognizing the need to obtain additional guidance from Article 29 Working Party/European Data Protection Board. Addressing the feasibility of requiring unique contacts to have a uniform anonymized email address across domain name registrations at a given Registrar, while ensuring security/stability and meeting the requirements of Section 2.5.1 of Appendix A. Developing methods to provide potential URS and UDRP complainants with sufficient access to Registration Data to support good-faith filings of complaints. Consistent process for continued access to Registration Data, including non- public data, for users with a legitimate purpose, until the time when a final accreditation and access mechanism is fully operational, on a mandatory basis for all contracted parties. Distinguishing between legal and natural persons to allow for public access to the Registration Data of legal persons, which are not in the remit of the GDPR. Limitations in terms of query volume envisaged under an accreditation program balanced against realistic investigatory cross-referencing needs. Confidentiality of queries for Registration Data by law enforcement authorities. Looking forward to discussing further tonight. Susan Kawaguchi BC Councilor. _______________________________________________ council mailing list council@gnso.icann.org https://mm.icann.org/mailman/listinfo/council _______________________________________________ council mailing list council@gnso.icann.org https://mm.icann.org/mailman/listinfo/council
Also we need to remember that the ePDP needs to focus on the temporary spec NOT on “fixing” whois. To that end it needs to be focussed on the various policies etc., that are impacted by the temporary spec and are now out of sync. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com https://blacknight.blog / http://ceo.hosting/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow, R93 X265 ,Ireland Company No.: 370845 From: council <council-bounces@gnso.icann.org> on behalf of Darcy Southwell <darcy.southwell@endurance.com> Date: Thursday 24 May 2018 at 02:21 To: Rubens Kuhl <rubensk@nic.br>, Susan Kawaguchi <susankpolicy@gmail.com> Cc: GNSO Council List <council@gnso.icann.org> Subject: Re: [council] ePDP Agree with Rubens that no one SO/AC is more important than another. Is Susan’s suggestion 5-6 per SO/AC or SG/C? I’m confused. From: council <council-bounces@gnso.icann.org> on behalf of Rubens Kuhl <rubensk@nic.br> Date: Wednesday, May 23, 2018 at 9:16 PM To: Susan Kawaguchi <susankpolicy@gmail.com> Cc: GNSO Council List <council@gnso.icann.org> Subject: Re: [council] ePDP Susan, Responses inline. On 23 May 2018, at 21:26, Susan Kawaguchi <susankpolicy@gmail.com<mailto:susankpolicy@gmail.com>> wrote: Hello All, I have given the potential ePDP much thought over the last two days. To effectively do this work at the speed that it will require we need to focus the ePDP. As you all know this is a tremendous amount of work. We need to address the following: Including at the very least the GAC and SSAC in this ePDP will be critical. While this is still a GNSO ePDP, the fact that we will likely not run an open WG means that we should invite ACs, but I don't see why some ACs would be critical and others would not. The members of the team should be limited to 5-6 members of each SG/AC. I'm more inclined to a lesser number of members per SG, and even less from ACs, perhaps one each per AC. Each member must agree to accept the fast paced extensive work load, participating on calls, subgroups and drafting when necessary. And to be willing to come to common grounds... which is the only way for this effort to not fail like all others before them have. Understand that their work is representational of the community they are affiliated with and will receive endorsement to express views. I'm not sure of that; while I understand that idea, and this is how Council representation works for 3 of the 4 GNSO SGs, I'm afraid it could be not practical and hamper productivity, but I'm not ready yet to offer an alternative. Create a leadership team with extensive knowledge and time to focus on this work. Select a Chair that will have the time and skills to effectively manage the ePDP. Yeap. Include a Board member for oversight and check ins on the team. I believe Board liaison(s) would be helpful in not causing a delay by drafting a policy Board wouldn't be able to accept, but I wouldn't call them members. This ePDP should focus on the critical needs identified in the Annex of the Temporary Spec. first as these issues are of critical importance. (copied below for ease of reference) But if the main topics are not dealt with by the ePDP, temp spec will expire and lose effect... so I would rather see the opposite: taking first the items already included in the spec, bake all the uncontroversial ones into policy and begin implementation of them ASAP. Only after that first report, deal with controversial and further community action ones. Having parallel PDP/IRT teams also seem to be needed to achieve the ambitious timeframe imposed by the temp spec framework. Rubens Annex: Important Issues for Further Community Action The purpose of this Annex is to set forth implementation issues raised during the course of development of this Temporary Specification for which the ICANN Board encourages the community to continue discussing so that they may be resolved as quickly as possible after the effective date of the Temporary Specification. This Annex does not create new or modified requirements for Registrar or Registry Operator, nor is it intended to direct the scope of the Policy Development Process, which will be initiated as a result of the Board’s adoption of thisTemporary Specification. 1. Pursuant to Section 4.4, continuing community work to develop an accreditation and access model that complies with GDPR, while recognizing the need to obtain additional guidance from Article 29 Working Party/European Data Protection Board. 2. Addressing the feasibility of requiring unique contacts to have a uniform anonymized email address across domain name registrations at a given Registrar, while ensuring security/stability and meeting the requirements of Section 2.5.1 of Appendix A. 3. Developing methods to provide potential URS and UDRP complainants with sufficient access to Registration Data to support good-faith filings of complaints. 4. Consistent process for continued access to Registration Data, including non- public data, for users with a legitimate purpose, until the time when a final accreditation and access mechanism is fully operational, on a mandatory basis for all contracted parties. 5. Distinguishing between legal and natural persons to allow for public access to the Registration Data of legal persons, which are not in the remit of the GDPR. 6. Limitations in terms of query volume envisaged under an accreditation program balanced against realistic investigatory cross-referencing needs. 7. Confidentiality of queries for Registration Data by law enforcement authorities. Looking forward to discussing further tonight. Susan Kawaguchi BC Councilor. _______________________________________________ council mailing list council@gnso.icann.org<mailto:council@gnso.icann.org> https://mm.icann.org/mailman/listinfo/council _______________________________________________ council mailing list council@gnso.icann.org https://mm.icann.org/mailman/listinfo/council
And, as a GNSO PDP, it must respect the picket fence. Not all issues in the Temporary Specification are eligible for a PDP. This is going to be one of the important scoping questions for the Council’s attention. Regards, Keith From: council <council-bounces@gnso.icann.org> On Behalf Of Michele Neylon - Blacknight Sent: Thursday, May 24, 2018 12:35 AM To: Darcy Southwell <darcy.southwell@endurance.com>; Rubens Kuhl <rubensk@nic.br>; Susan Kawaguchi <susankpolicy@gmail.com> Cc: GNSO Council List <council@gnso.icann.org> Subject: [EXTERNAL] Re: [council] ePDP Also we need to remember that the ePDP needs to focus on the temporary spec NOT on “fixing” whois. To that end it needs to be focussed on the various policies etc., that are impacted by the temporary spec and are now out of sync. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com https://blacknight.blog / http://ceo.hosting/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow, R93 X265 ,Ireland Company No.: 370845 From: council <council-bounces@gnso.icann.org<mailto:council-bounces@gnso.icann.org>> on behalf of Darcy Southwell <darcy.southwell@endurance.com<mailto:darcy.southwell@endurance.com>> Date: Thursday 24 May 2018 at 02:21 To: Rubens Kuhl <rubensk@nic.br<mailto:rubensk@nic.br>>, Susan Kawaguchi <susankpolicy@gmail.com<mailto:susankpolicy@gmail.com>> Cc: GNSO Council List <council@gnso.icann.org<mailto:council@gnso.icann.org>> Subject: Re: [council] ePDP Agree with Rubens that no one SO/AC is more important than another. Is Susan’s suggestion 5-6 per SO/AC or SG/C? I’m confused. From: council <council-bounces@gnso.icann.org<mailto:council-bounces@gnso.icann.org>> on behalf of Rubens Kuhl <rubensk@nic.br<mailto:rubensk@nic.br>> Date: Wednesday, May 23, 2018 at 9:16 PM To: Susan Kawaguchi <susankpolicy@gmail.com<mailto:susankpolicy@gmail.com>> Cc: GNSO Council List <council@gnso.icann.org<mailto:council@gnso.icann.org>> Subject: Re: [council] ePDP Susan, Responses inline. On 23 May 2018, at 21:26, Susan Kawaguchi <susankpolicy@gmail.com<mailto:susankpolicy@gmail.com>> wrote: Hello All, I have given the potential ePDP much thought over the last two days. To effectively do this work at the speed that it will require we need to focus the ePDP. As you all know this is a tremendous amount of work. We need to address the following: Including at the very least the GAC and SSAC in this ePDP will be critical. While this is still a GNSO ePDP, the fact that we will likely not run an open WG means that we should invite ACs, but I don't see why some ACs would be critical and others would not. The members of the team should be limited to 5-6 members of each SG/AC. I'm more inclined to a lesser number of members per SG, and even less from ACs, perhaps one each per AC. Each member must agree to accept the fast paced extensive work load, participating on calls, subgroups and drafting when necessary. And to be willing to come to common grounds... which is the only way for this effort to not fail like all others before them have. Understand that their work is representational of the community they are affiliated with and will receive endorsement to express views. I'm not sure of that; while I understand that idea, and this is how Council representation works for 3 of the 4 GNSO SGs, I'm afraid it could be not practical and hamper productivity, but I'm not ready yet to offer an alternative. Create a leadership team with extensive knowledge and time to focus on this work. Select a Chair that will have the time and skills to effectively manage the ePDP. Yeap. Include a Board member for oversight and check ins on the team. I believe Board liaison(s) would be helpful in not causing a delay by drafting a policy Board wouldn't be able to accept, but I wouldn't call them members. This ePDP should focus on the critical needs identified in the Annex of the Temporary Spec. first as these issues are of critical importance. (copied below for ease of reference) But if the main topics are not dealt with by the ePDP, temp spec will expire and lose effect... so I would rather see the opposite: taking first the items already included in the spec, bake all the uncontroversial ones into policy and begin implementation of them ASAP. Only after that first report, deal with controversial and further community action ones. Having parallel PDP/IRT teams also seem to be needed to achieve the ambitious timeframe imposed by the temp spec framework. Rubens Annex: Important Issues for Further Community Action The purpose of this Annex is to set forth implementation issues raised during the course of development of this Temporary Specification for which the ICANN Board encourages the community to continue discussing so that they may be resolved as quickly as possible after the effective date of the Temporary Specification. This Annex does not create new or modified requirements for Registrar or Registry Operator, nor is it intended to direct the scope of the Policy Development Process, which will be initiated as a result of the Board’s adoption of thisTemporary Specification. 1. Pursuant to Section 4.4, continuing community work to develop an accreditation and access model that complies with GDPR, while recognizing the need to obtain additional guidance from Article 29 Working Party/European Data Protection Board. 2. Addressing the feasibility of requiring unique contacts to have a uniform anonymized email address across domain name registrations at a given Registrar, while ensuring security/stability and meeting the requirements of Section 2.5.1 of Appendix A. 3. Developing methods to provide potential URS and UDRP complainants with sufficient access to Registration Data to support good-faith filings of complaints. 4. Consistent process for continued access to Registration Data, including non- public data, for users with a legitimate purpose, until the time when a final accreditation and access mechanism is fully operational, on a mandatory basis for all contracted parties. 5. Distinguishing between legal and natural persons to allow for public access to the Registration Data of legal persons, which are not in the remit of the GDPR. 6. Limitations in terms of query volume envisaged under an accreditation program balanced against realistic investigatory cross-referencing needs. 7. Confidentiality of queries for Registration Data by law enforcement authorities. Looking forward to discussing further tonight. Susan Kawaguchi BC Councilor. _______________________________________________ council mailing list council@gnso.icann.org<mailto:council@gnso.icann.org> https://mm.icann.org/mailman/listinfo/council _______________________________________________ council mailing list council@gnso.icann.org<mailto:council@gnso.icann.org> https://mm.icann.org/mailman/listinfo/council
Hi Keith, It appears to me that all policy is within the picket fence so will be interesting to see a document with your view point on what the RySG views as outside the picket fence. Considering, that this is a new process to all I think we will be learning as we go. Best, Susan On Wed, May 23, 2018 at 9:46 PM, Drazek, Keith <kdrazek@verisign.com> wrote:
And, as a GNSO PDP, it must respect the picket fence. Not all issues in the Temporary Specification are eligible for a PDP. This is going to be one of the important scoping questions for the Council’s attention.
Regards,
Keith
*From:* council <council-bounces@gnso.icann.org> *On Behalf Of *Michele Neylon - Blacknight *Sent:* Thursday, May 24, 2018 12:35 AM *To:* Darcy Southwell <darcy.southwell@endurance.com>; Rubens Kuhl < rubensk@nic.br>; Susan Kawaguchi <susankpolicy@gmail.com> *Cc:* GNSO Council List <council@gnso.icann.org> *Subject:* [EXTERNAL] Re: [council] ePDP
Also we need to remember that the ePDP needs to focus on the temporary spec NOT on “fixing” whois. To that end it needs to be focussed on the various policies etc., that are impacted by the temporary spec and are now out of sync.
Regards
Michele
--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
Intl. +353 (0) 59 9183072
Direct Dial: +353 (0)59 9183090
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow, R93 X265
,Ireland Company No.: 370845
*From: *council <council-bounces@gnso.icann.org> on behalf of Darcy Southwell <darcy.southwell@endurance.com> *Date: *Thursday 24 May 2018 at 02:21 *To: *Rubens Kuhl <rubensk@nic.br>, Susan Kawaguchi < susankpolicy@gmail.com> *Cc: *GNSO Council List <council@gnso.icann.org> *Subject: *Re: [council] ePDP
Agree with Rubens that no one SO/AC is more important than another.
Is Susan’s suggestion 5-6 per SO/AC or SG/C? I’m confused.
*From: *council <council-bounces@gnso.icann.org> on behalf of Rubens Kuhl <rubensk@nic.br> *Date: *Wednesday, May 23, 2018 at 9:16 PM *To: *Susan Kawaguchi <susankpolicy@gmail.com> *Cc: *GNSO Council List <council@gnso.icann.org> *Subject: *Re: [council] ePDP
Susan,
Responses inline.
On 23 May 2018, at 21:26, Susan Kawaguchi <susankpolicy@gmail.com> wrote:
Hello All,
I have given the potential ePDP much thought over the last two days.
To effectively do this work at the speed that it will require we need to focus the ePDP. As you all know this is a tremendous amount of work.
We need to address the following:
Including at the very least the GAC and SSAC in this ePDP will be critical.
While this is still a GNSO ePDP, the fact that we will likely not run an open WG means that we should invite ACs, but I don't see why some ACs would be critical and others would not.
The members of the team should be limited to 5-6 members of each SG/AC.
I'm more inclined to a lesser number of members per SG, and even less from ACs, perhaps one each per AC.
Each member must agree to accept the fast paced extensive work load, participating on calls, subgroups and drafting when necessary.
And to be willing to come to common grounds... which is the only way for this effort to not fail like all others before them have.
Understand that their work is representational of the community they are affiliated with and will receive endorsement to express views.
I'm not sure of that; while I understand that idea, and this is how Council representation works for 3 of the 4 GNSO SGs, I'm afraid it could be not practical and hamper productivity, but I'm not ready yet to offer an alternative.
Create a leadership team with extensive knowledge and time to focus on this work.
Select a Chair that will have the time and skills to effectively manage the ePDP.
Yeap.
Include a Board member for oversight and check ins on the team.
I believe Board liaison(s) would be helpful in not causing a delay by drafting a policy Board wouldn't be able to accept, but I wouldn't call them members.
This ePDP should focus on the critical needs identified in the Annex of the Temporary Spec. first as these issues are of critical importance. (copied below for ease of reference)
But if the main topics are not dealt with by the ePDP, temp spec will expire and lose effect... so I would rather see the opposite: taking first the items already included in the spec, bake all the uncontroversial ones into policy and begin implementation of them ASAP. Only after that first report, deal with controversial and further community action ones. Having parallel PDP/IRT teams also seem to be needed to achieve the ambitious timeframe imposed by the temp spec framework.
Rubens
Annex: Important Issues for Further Community Action
The purpose of this Annex is to set forth implementation issues raised during the course of development of this Temporary Specification for which the ICANN Board encourages the community to continue discussing so that they may be resolved as quickly as possible after the effective date of the Temporary Specification. This Annex does not create new or modified requirements for Registrar or Registry Operator, nor is it intended to direct the scope of the Policy Development Process, which will be initiated as a result of the Board’s adoption of thisTemporary Specification.
1. Pursuant to Section 4.4, continuing community work to develop an accreditation and access model that complies with GDPR, while recognizing the need to obtain additional guidance from Article 29 Working Party/European Data Protection Board. 2. Addressing the feasibility of requiring unique contacts to have a uniform anonymized email address across domain name registrations at a given Registrar, while ensuring security/stability and meeting the requirements of Section 2.5.1 of Appendix A. 3. Developing methods to provide potential URS and UDRP complainants with sufficient access to Registration Data to support good-faith filings of complaints. 4. Consistent process for continued access to Registration Data, including non- public data, for users with a legitimate purpose, until the time when a final accreditation and access mechanism is fully operational, on a mandatory basis for all contracted parties. 5. Distinguishing between legal and natural persons to allow for public access to the Registration Data of legal persons, which are not in the remit of the GDPR. 6. Limitations in terms of query volume envisaged under an accreditation program balanced against realistic investigatory cross-referencing needs. 7. Confidentiality of queries for Registration Data by law enforcement authorities.
Looking forward to discussing further tonight.
Susan Kawaguchi
BC Councilor.
_______________________________________________ council mailing list council@gnso.icann.org https://mm.icann.org/mailman/listinfo/council
_______________________________________________ council mailing list council@gnso.icann.org https://mm.icann.org/mailman/listinfo/council
On 24 May 2018, at 15:48, Susan Kawaguchi <susankpolicy@gmail.com> wrote:
Hi Keith,
It appears to me that all policy is within the picket fence so will be interesting to see a document with your view point on what the RySG views as outside the picket fence.
Susan, The RySG is working on that, but the number of those are small (around 10%) and those clauses are the ones with less interest of other constituencies. I understand you will reserve judgement to when you see it, but I'm confident that it won't be controversial. What could be more controversial is that the almost entirety of the temporary policy fails the security and stability definition that was in effect by the time the agreements were signed and commonplace/scientific/academia definitions for those terms. Which leaves it vulnerable to challenge thru accountability mechanisms, arbitration and litigation. So anything that we as a Council can do to expedite the policy of what is already in the spec, can mitigate that risk by replacing the temporary policy with a capital C capital P Consensus Policy. And for me, that passes to running first thru what is already in the spec, pushing it to an IRT, and then looking at items marked "Further Community Action". I understand the interest that those items, including accreditation programs, bring, but focusing on them is overlooking the risk of the thin ice ICANN has put itself into by using a temporary policy. I would like see that part of the temporary policy not having to be reissued after 90 days, if possible. I understand it's a bold milestone, but it's compatible with the work and risks involved. Rubens
Considering, that this is a new process to all I think we will be learning as we go.
Best,
Susan
On Wed, May 23, 2018 at 9:46 PM, Drazek, Keith <kdrazek@verisign.com <mailto:kdrazek@verisign.com>> wrote: And, as a GNSO PDP, it must respect the picket fence. Not all issues in the Temporary Specification are eligible for a PDP. This is going to be one of the important scoping questions for the Council’s attention.
Regards,
Keith
From: council <council-bounces@gnso.icann.org <mailto:council-bounces@gnso.icann.org>> On Behalf Of Michele Neylon - Blacknight Sent: Thursday, May 24, 2018 12:35 AM To: Darcy Southwell <darcy.southwell@endurance.com <mailto:darcy.southwell@endurance.com>>; Rubens Kuhl <rubensk@nic.br <mailto:rubensk@nic.br>>; Susan Kawaguchi <susankpolicy@gmail.com <mailto:susankpolicy@gmail.com>> Cc: GNSO Council List <council@gnso.icann.org <mailto:council@gnso.icann.org>> Subject: [EXTERNAL] Re: [council] ePDP
Also we need to remember that the ePDP needs to focus on the temporary spec NOT on “fixing” whois. To that end it needs to be focussed on the various policies etc., that are impacted by the temporary spec and are now out of sync.
Regards
Michele
--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
https://www.blacknight.com <https://www.blacknight.com/> https://blacknight.blog <https://blacknight.blog/> /
http://ceo.hosting/ <http://ceo.hosting/> Intl. +353 (0) 59 9183072
Direct Dial: +353 (0)59 9183090
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow, R93 X265
,Ireland Company No.: 370845
From: council <council-bounces@gnso.icann.org <mailto:council-bounces@gnso.icann.org>> on behalf of Darcy Southwell <darcy.southwell@endurance.com <mailto:darcy.southwell@endurance.com>> Date: Thursday 24 May 2018 at 02:21 To: Rubens Kuhl <rubensk@nic.br <mailto:rubensk@nic.br>>, Susan Kawaguchi <susankpolicy@gmail.com <mailto:susankpolicy@gmail.com>> Cc: GNSO Council List <council@gnso.icann.org <mailto:council@gnso.icann.org>> Subject: Re: [council] ePDP
Agree with Rubens that no one SO/AC is more important than another.
Is Susan’s suggestion 5-6 per SO/AC or SG/C? I’m confused.
From: council <council-bounces@gnso.icann.org <mailto:council-bounces@gnso.icann.org>> on behalf of Rubens Kuhl <rubensk@nic.br <mailto:rubensk@nic.br>> Date: Wednesday, May 23, 2018 at 9:16 PM To: Susan Kawaguchi <susankpolicy@gmail.com <mailto:susankpolicy@gmail.com>> Cc: GNSO Council List <council@gnso.icann.org <mailto:council@gnso.icann.org>> Subject: Re: [council] ePDP
Susan,
Responses inline.
On 23 May 2018, at 21:26, Susan Kawaguchi <susankpolicy@gmail.com <mailto:susankpolicy@gmail.com>> wrote:
Hello All,
I have given the potential ePDP much thought over the last two days.
To effectively do this work at the speed that it will require we need to focus the ePDP. As you all know this is a tremendous amount of work.
We need to address the following:
Including at the very least the GAC and SSAC in this ePDP will be critical.
While this is still a GNSO ePDP, the fact that we will likely not run an open WG means that we should invite ACs, but I don't see why some ACs would be critical and others would not.
The members of the team should be limited to 5-6 members of each SG/AC.
I'm more inclined to a lesser number of members per SG, and even less from ACs, perhaps one each per AC.
Each member must agree to accept the fast paced extensive work load, participating on calls, subgroups and drafting when necessary.
And to be willing to come to common grounds... which is the only way for this effort to not fail like all others before them have.
Understand that their work is representational of the community they are affiliated with and will receive endorsement to express views.
I'm not sure of that; while I understand that idea, and this is how Council representation works for 3 of the 4 GNSO SGs, I'm afraid it could be not practical and hamper productivity, but I'm not ready yet to offer an alternative.
Create a leadership team with extensive knowledge and time to focus on this work.
Select a Chair that will have the time and skills to effectively manage the ePDP.
Yeap.
Include a Board member for oversight and check ins on the team.
I believe Board liaison(s) would be helpful in not causing a delay by drafting a policy Board wouldn't be able to accept, but I wouldn't call them members.
This ePDP should focus on the critical needs identified in the Annex of the Temporary Spec. first as these issues are of critical importance. (copied below for ease of reference)
But if the main topics are not dealt with by the ePDP, temp spec will expire and lose effect... so I would rather see the opposite: taking first the items already included in the spec, bake all the uncontroversial ones into policy and begin implementation of them ASAP. Only after that first report, deal with controversial and further community action ones. Having parallel PDP/IRT teams also seem to be needed to achieve the ambitious timeframe imposed by the temp spec framework.
Rubens
Annex: Important Issues for Further Community Action
The purpose of this Annex is to set forth implementation issues raised during the course of development of this Temporary Specification for which the ICANN Board encourages the community to continue discussing so that they may be resolved as quickly as possible after the effective date of the Temporary Specification. This Annex does not create new or modified requirements for Registrar or Registry Operator, nor is it intended to direct the scope of the Policy Development Process, which will be initiated as a result of the Board’s adoption of thisTemporary Specification.
Pursuant to Section 4.4, continuing community work to develop an accreditation and access model that complies with GDPR, while recognizing the need to obtain additional guidance from Article 29 Working Party/European Data Protection Board. Addressing the feasibility of requiring unique contacts to have a uniform anonymized email address across domain name registrations at a given Registrar, while ensuring security/stability and meeting the requirements of Section 2.5.1 of Appendix A. Developing methods to provide potential URS and UDRP complainants with sufficient access to Registration Data to support good-faith filings of complaints. Consistent process for continued access to Registration Data, including non- public data, for users with a legitimate purpose, until the time when a final accreditation and access mechanism is fully operational, on a mandatory basis for all contracted parties. Distinguishing between legal and natural persons to allow for public access to the Registration Data of legal persons, which are not in the remit of the GDPR. Limitations in terms of query volume envisaged under an accreditation program balanced against realistic investigatory cross-referencing needs. Confidentiality of queries for Registration Data by law enforcement authorities. Looking forward to discussing further tonight.
Susan Kawaguchi
BC Councilor.
_______________________________________________ council mailing list council@gnso.icann.org <mailto:council@gnso.icann.org> https://mm.icann.org/mailman/listinfo/council <https://mm.icann.org/mailman/listinfo/council>
_______________________________________________ council mailing list council@gnso.icann.org <mailto:council@gnso.icann.org> https://mm.icann.org/mailman/listinfo/council <https://mm.icann.org/mailman/listinfo/council> _______________________________________________ council mailing list council@gnso.icann.org https://mm.icann.org/mailman/listinfo/council
Thanks for sharing your views here, Rubens - I very much agree with your comments, especially in regards to keeping the number of participants manageable. And thank you to Susan for laying out a proposal for how an ePDP could be composed. It is great to have something concrete on the table to kick off this discussion. Best wishes, Ayden ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On 24 May 2018 3:15 AM, Rubens Kuhl <rubensk@nic.br> wrote:
Susan,
Responses inline.
On 23 May 2018, at 21:26, Susan Kawaguchi <susankpolicy@gmail.com> wrote:
Hello All,
I have given the potential ePDP much thought over the last two days.
To effectively do this work at the speed that it will require we need to focus the ePDP. As you all know this is a tremendous amount of work.
We need to address the following:
Including at the very least the GAC and SSAC in this ePDP will be critical.
While this is still a GNSO ePDP, the fact that we will likely not run an open WG means that we should invite ACs, but I don't see why some ACs would be critical and others would not.
The members of the team should be limited to 5-6 members of each SG/AC.
I'm more inclined to a lesser number of members per SG, and even less from ACs, perhaps one each per AC.
Each member must agree to accept the fast paced extensive work load, participating on calls, subgroups and drafting when necessary.
And to be willing to come to common grounds... which is the only way for this effort to not fail like all others before them have.
Understand that their work is representational of the community they are affiliated with and will receive endorsement to express views.
I'm not sure of that; while I understand that idea, and this is how Council representation works for 3 of the 4 GNSO SGs, I'm afraid it could be not practical and hamper productivity, but I'm not ready yet to offer an alternative.
Create a leadership team with extensive knowledge and time to focus on this work.
Select a Chair that will have the time and skills to effectively manage the ePDP.
Yeap.
Include a Board member for oversight and check ins on the team.
I believe Board liaison(s) would be helpful in not causing a delay by drafting a policy Board wouldn't be able to accept, but I wouldn't call them members.
This ePDP should focus on the critical needs identified in the Annex of the Temporary Spec. first as these issues are of critical importance. (copied below for ease of reference)
But if the main topics are not dealt with by the ePDP, temp spec will expire and lose effect... so I would rather see the opposite: taking first the items already included in the spec, bake all the uncontroversial ones into policy and begin implementation of them ASAP. Only after that first report, deal with controversial and further community action ones. Having parallel PDP/IRT teams also seem to be needed to achieve the ambitious timeframe imposed by the temp spec framework.
Rubens
Annex: Important Issues for Further Community Action
The purpose of this Annex is to set forth implementation issues raised during the course of development of this Temporary Specification for which the ICANN Board encourages the community to continue discussing so that they may be resolved as quickly as possible after the effective date of the Temporary Specification. This Annex does not create new or modified requirements for Registrar or Registry Operator, nor is it intended to direct the scope of the Policy Development Process, which will be initiated as a result of the Board’s adoption of thisTemporary Specification.
-
Pursuant to Section 4.4, continuing community work to develop an accreditation and access model that complies with GDPR, while recognizing the need to obtain additional guidance from Article 29 Working Party/European Data Protection Board.
-
Addressing the feasibility of requiring unique contacts to have a uniform anonymized email address across domain name registrations at a given Registrar, while ensuring security/stability and meeting the requirements of Section 2.5.1 of Appendix A.
-
Developing methods to provide potential URS and UDRP complainants with sufficient access to Registration Data to support good-faith filings of complaints.
-
Consistent process for continued access to Registration Data, including non- public data, for users with a legitimate purpose, until the time when a final accreditation and access mechanism is fully operational, on a mandatory basis for all contracted parties.
-
Distinguishing between legal and natural persons to allow for public access to the Registration Data of legal persons, which are not in the remit of the GDPR.
-
Limitations in terms of query volume envisaged under an accreditation program balanced against realistic investigatory cross-referencing needs.
-
Confidentiality of queries for Registration Data by law enforcement authorities.
Looking forward to discussing further tonight.
Susan Kawaguchi
BC Councilor.
_______________________________________________ council mailing list council@gnso.icann.org https://mm.icann.org/mailman/listinfo/council
participants (6)
-
Ayden Férdeline -
Darcy Southwell -
Drazek, Keith -
Michele Neylon - Blacknight -
Rubens Kuhl -
Susan Kawaguchi