FW: Engagement on DNS Abuse
Evin has suggested that I had, perhaps, NOT forwarded this to the group. Here’s the discussion thread, initiated by Keith Drazek on the Contracted Party House DNS Abuse Work Group. This includes, Joanna’s expression of mission creep concern. Jonathan Jonathan Zuck Executive Director Innovators Network Foundation www.InnovatorsNetwork.org From: Joanna Kulesza<mailto:jkuleszaicann@gmail.com> Sent: Wednesday, January 27, 2021 2:12 AM To: Maureen Hilyard<mailto:maureen.hilyard@gmail.com>; Jonathan Zuck<mailto:JZuck@innovatorsnetwork.org> Subject: Re: Engagement on DNS Abuse Great stuff Jonathan, as always. Feel free to share. If I were to add my two cents, I'd put these in the "pain points" section while these are of a more general nature. "From the discussions we've had within At-Large it is clear that the very scope and definition of DNS Abuse is a "pain point". This was also the take away from the discussions we've had with the invited guests from within and beyond the ICANN community. "DNS Abuse" as it is now defined in the proposed Framework affects the entire internet community of end users while being already covered by existing national and international norms and standards. Keeping these in mind the proposed definition and scope of DNS Abuse strikes as arbitrary: what were the criteria set for selecting these specific categories as DNS Abuse while leaving other potential categories out? This is particularly relevant with regard to our second concern: the proposed scope of DNS Abuse clearly crosses the content "picket fence" that the ICANN community had set for itself. Including IP infringement on equal footing with CSAM raises serious concerns among At-Large members. We are concerned not only with the very fact of the picket fence being crossed but also by the way in which this is being done. Does this mean we should finally abandon the well established yet always controversial narrative of a strictly technical infrastructure management? Once content is concerned, the existing and proposed practice fails to recognize international legal safeguards when it comes to restrictions put on individual freedoms. Whenever an individual liberty is to be restricted, due process must be ensured. The procedures proposed by the DNS Abuse framework fail to ensure e.g. a right to an effective legal remedy. While we realize this argument brings us back tot he general discussion on limits of ICANN's contractual jurisdiction, that is an argument we would be interested to during any upcoming DNS Abuse work. Only once these concerns relating to the scope of the definition of DNS Abuse can be addressed, can we focus on metrics and effective enforcement that will provide a fair and operational framework protecting the rights of end users." By all means to feel free to rephrase!:) What I'm arguing for is that for us to be able to "measure" DNS Abuse we should first clearly and transparently decide what it means. The current framework means the contracted parties are indeed trying to play a self-proclaimed internet police (militia?). Why did we presume DNS Abuse is CSAM and (in the same breath) fake Gucci bags but not hate speech and inciting violence? While we clearly would not have the answer ready, that is definitely a discussion we should have. The GAC might be interested in this as well (see last update from Veni on the ITU processes). Thanks for considering team! Best, J. W dniu 27.01.2021 o 01:39, Maureen Hilyard pisze: In your inimitable style. Love it. Send it. M On Tue, Jan 26, 2021 at 12:34 PM Jonathan Zuck <JZuck@innovatorsnetwork.org<mailto:JZuck@innovatorsnetwork.org>> wrote: Ladies, Here’s my draft response. Let me know what you think! Jonathan ============================================================= Hey folks! Thanks for reaching out. Joanna and I, for sure, would be willing to join you and I suspect others, as well, once we know the timing. With respect to the questions below, I’ll do my best to provide some initial responses but I suspect the first question might be pivotal. There seems to be a lack of real data on the topic and perhaps some additional objective research is the answers. We endeavored to begin this process, during the CCTRT (sadag-final-09aug17-en.pdf (icann.org)<https://www.icann.org/en/system/files/files/sadag-final-09aug17-en.pdf>, but obviously barely scratched the surface. Perhaps a more comprehensive study, funded by ICANN rather than the CPH or CSG might be in order? I know DAAR provides some answers but it seems to be more of a survey than an example of rigorous research. Specifically to your questions. 1. What information do you use and how do you use it to assess DNS Abuse levels? This is obviously where we are weak. There doesn’t appear to be a great source for DNS Abuse “levels,” particularly because of the short time period over which a particular initiative takes place. A snapshot analysis doesn’t seem to get the full picture. The ALAC relies on the concerned raised by the GAC and the SSAC to fuel our belief that there’s more we should be doing. A recent report from Microsoft suggests the problem is bigger than we realize and David Taylor’s analysis of “responsiveness,” even among those who have signed onto the framework, seems damning. 2. What are the ALAC’s pain points regarding DNS Abuse? Not sure to answer this in terms of how it’s handled inside ICANN or more generally from where our interests stems. To the latter point, we’re tasked with advancing the interests of those not represented by a constituency in the GNSO, namely those engaged in everyday use of the internet, as opposed to registrants. As the user base continues to grow, as we all desire, so too will the numbers of less sophisticated users, more easily duped by a phishing, malware or fraudulent advertising attack. As for the situation inside ICANN, the At-Large community have attempted to engage constructively as opposed to “attacking” the CPH, focusing instead on so-called “bad actors.” The first session<https://community.icann.org/display/atlarge/At-Large+Meetings+-+Monday%2C+09+March+2020?preview=/124847126/126428447/CCWholistic02.pdf> was an attempt to bring the CPH and Contract Compliance into the same room to figure out where the holes are. * What exactly are the relevant limits on Contract Compliance? We feel this is a question which comes up constantly and is never successfully or consistently answered. It seems to be an area in which the ICANN community is constantly chasing it’s tail. It would seem that the only real enforced contract provision is payment. I’m sure this is an exaggeration but it seems to be a repeated situation where that is ultimately what foils a “ bad actor” after YEARS of neglect, if not outright facilitation of abuse. The answer to THIS question should be a HIGH priority. It might just be agreeing to an interpretation of the contracts or it might require an amendment to the contracts but this issue needs to stop being a merry go round. * Insufficient Transparency from Contract Compliance Contract Compliance undocumented endeavors at soft touch diplomacy with bad actors seem to need some better limits or, at least, transparency. For “the market” to play a role in this, knowing about legitimate complaints for every contracted party could help customers make better decisions about which businesses to use and help us better understand where policy development needs to take place. * Deflection and Minimization of the Problem I would say that one “pain point” is that our efforts have been largely “trolled” by certain members of the CPH, rather than engaging constructively. EVEN our effort to conceive of some sort of end user education campaign, to take the pressure off the CPH, was trolled. Jim, not to put you on the spot but, during one conversation, you said you didn’t even understand why this was being discussed because it affects such a small percentage of registered names. To date, we have proposed: i. Better contract enforcement ii. More tools for Contract Compliance iii. DNS Abuse “threshold,” an idea that found some support among the CPH at one point iv. Predictive Analytics platform, perhaps financed by ICANN The At-Large community has absolutely no desire to over regulate or over tax the CPH and we understand most of the contracted parties, particularly those showing up to meetings, are trying to do well and continuously improve. That said, this notion that it’s somehow not “our place,” to be trying to help is nothing short of offensive. It is the active participation of the ALAC and GAC that enable the ICANN to portray itself as something other than a trade association. The At-Large mandate is to advance the interests of those MOST impacted by DNS Abuse. That said, we WELCOME suggestions on how better to engage with the CPH for constructive outcomes. 1. Are you seeing practices from registrars or registries you find helpful? If we haven’t said it enough, the At-Large appreciates the efforts of those behind the Framework for DNS Abuse and the huge efforts that went into cooperation with law enforcement to track down COVID related abuse. We’d love to see the framework evolve to include specific commitments and metrics, however, for it to be something on which the community could truly rely. We hope these answers are constructive and not inflammatory as it is our intention to find the most effective ways to proceed to further minimize the incidence of DNS Abuse , in all its forms. Thanks for the opportunity to be part of your conversation. Maureen, Joanna & Jonathan From: Keith Drazek <kdrazek@verisign.com<mailto:kdrazek@verisign.com>> Date: Friday, January 22, 2021 at 12:00 PM To: "maureen.hilyard@gmail.com<mailto:maureen.hilyard@gmail.com>" <maureen.hilyard@gmail.com<mailto:maureen.hilyard@gmail.com>>, Jonathan Zuck <JZuck@innovatorsnetwork.org<mailto:JZuck@innovatorsnetwork.org>>, "jkuleszaicann@gmail.com<mailto:jkuleszaicann@gmail.com>" <jkuleszaicann@gmail.com<mailto:jkuleszaicann@gmail.com>> Cc: "Brian F. Cimbolic" <BCimbolic@pir.org<mailto:BCimbolic@pir.org>>, Jim Galvin <jgalvin@afilias.info<mailto:jgalvin@afilias.info>>, Graeme Bunton <gbunton@tucows.com<mailto:gbunton@tucows.com>> Subject: Engagement on DNS Abuse Hello Maureen, Jonathan and Joanna, I hope you’re all doing well and staying healthy and safe. I am reaching out to you on behalf of the Contracted Party House DNS Abuse Working Group as we look ahead to ICANN 70 and the rest of 2021. The Contracted Party House (CPH) DNS Abuse Group is conducting outreach to our friends in other SO/AC/SG/Cs regarding DNS Abuse. As previously noted by the CPH, DNS Abuse<https://rrsg.org/wp-content/uploads/2020/10/CPH-Definition-of-DNS-Abuse.pdf> comprises five categories: phishing, pharming, malware, botnets, and spam when it acts as a delivery mechanism for one of the other forms of DNS Abuse. We want to open a more direct dialogue to understand pain points, hear suggestions and identify common ground where we can work together to mitigate DNS Abuse. Is there a subset of the At-Large focusing on DNS Abuse questions that would be able to join the CPH DNS Abuse group on a call to discuss this topic? We want to encourage frank and productive discussions on the topic that lead to really informing our dialogues and actions. As a starting point, we propose the following questions to guide our discussion. Are there any other questions ALAC would like discuss?: What information do you use and how do you use it to assess DNS Abuse levels? What are the ALAC’s pain points regarding DNS Abuse? Are you seeing practices from registrars or registries you find helpful? Please let us know if a subgroup of the ALAC would be willing to join us. Our group meets regularly on Tuesdays at 1500 UTC. If so, please propose a Tuesday when you are available. Best regards, Keith Keith Drazek Vice President, Public Policy & Government Relations Verisign, Inc. +1-571-377-9182 Kdrazek@verisign.com<mailto:Kdrazek@verisign.com> -- Kind regards, Joanna Kulesza ------------------- Joanna Kulesza, PhD University of Lodz, Poland ICANN ALAC Vice Chair SOI: https://community.icann.org/display/atlarge/Joanna+Kulesza+SOI TT: @KuleszaJ
Dear all, My comments, adding onto Johanna’s:
Keeping these in mind the proposed definition and scope of DNS Abuse strikes as arbitrary: what were the criteria set for selecting these specific categories as DNS Abuse while leaving other potential categories out?
The perspective I am getting from SSR2 is to start with the obvious, technically detectable ones: phishing, C2, plus reports of those. Essentially, stop crimes in progress that do not require complicated and long human oversight. I am worried about including issues that are private disputes. Even if many use Copyright to stop crimes in progress, as it is the only thing that works. (Consider how insane this is: I need to use the fact that someone is using my logo not as evidence but as a CR issue to stop an actual crime in progress.)
Including IP infringement on equal footing with CSAM raises serious concerns among At-Large members
Absolutely agree with Johanna on the CSAM aspect. It is, imho, ridiculous and more so offensive to name _private_ copyright _disputes_ alongside CSAM.* Again, speaking from SSR2 experience: focus can be put on forcing immediate review in case of reports, allowing bulk reports, introducing hurdles for criminals on registration, pre-review of suspicious names, etc. (I.e. do things that reduce abuse before it happens) All the best Laurin * Indeed, beyond this being ethically and morally unacceptable, companies (not gonna name names) use copyright complaints to silence their critics (free speech issue), arguably themselves being abusers of the system, at least in some cases. On Wed, Feb 3, 2021 at 15:49, Jonathan Zuck <JZuck@innovatorsnetwork.org> wrote:
Evin has suggested that I had, perhaps, NOT forwarded this to the group. Here’s the discussion thread, initiated by Keith Drazek on the Contracted Party House DNS Abuse Work Group. This includes, Joanna’s expression of mission creep concern.
Jonathan
Jonathan Zuck
Executive Director
Innovators Network Foundation
www.InnovatorsNetwork.org
From: [Joanna Kulesza](mailto:jkuleszaicann@gmail.com) Sent: Wednesday, January 27, 2021 2:12 AM To: [Maureen Hilyard](mailto:maureen.hilyard@gmail.com); [Jonathan Zuck](mailto:JZuck@innovatorsnetwork.org) Subject: Re: Engagement on DNS Abuse
Great stuff Jonathan, as always. Feel free to share. If I were to add my two cents, I'd put these in the "pain points" section while these are of a more general nature.
"From the discussions we've had within At-Large it is clear that the very scope and definition of DNS Abuse is a "pain point". This was also the take away from the discussions we've had with the invited guests from within and beyond the ICANN community. "DNS Abuse" as it is now defined in the proposed Framework affects the entire internet community of end users while being already covered by existing national and international norms and standards. Keeping these in mind the proposed definition and scope of DNS Abuse strikes as arbitrary: what were the criteria set for selecting these specific categories as DNS Abuse while leaving other potential categories out?
This is particularly relevant with regard to our second concern: the proposed scope of DNS Abuse clearly crosses the content "picket fence" that the ICANN community had set for itself. Including IP infringement on equal footing with CSAM raises serious concerns among At-Large members. We are concerned not only with the very fact of the picket fence being crossed but also by the way in which this is being done. Does this mean we should finally abandon the well established yet always controversial narrative of a strictly technical infrastructure management?
Once content is concerned, the existing and proposed practice fails to recognize international legal safeguards when it comes to restrictions put on individual freedoms. Whenever an individual liberty is to be restricted, due process must be ensured. The procedures proposed by the DNS Abuse framework fail to ensure e.g. a right to an effective legal remedy. While we realize this argument brings us back tot he general discussion on limits of ICANN's contractual jurisdiction, that is an argument we would be interested to during any upcoming DNS Abuse work.
Only once these concerns relating to the scope of the definition of DNS Abuse can be addressed, can we focus on metrics and effective enforcement that will provide a fair and operational framework protecting the rights of end users."
By all means to feel free to rephrase!:) What I'm arguing for is that for us to be able to "measure" DNS Abuse we should first clearly and transparently decide what it means. The current framework means the contracted parties are indeed trying to play a self-proclaimed internet police (militia?). Why did we presume DNS Abuse is CSAM and (in the same breath) fake Gucci bags but not hate speech and inciting violence? While we clearly would not have the answer ready, that is definitely a discussion we should have. The GAC might be interested in this as well (see last update from Veni on the ITU processes).
Thanks for considering team!
Best,
J.
W dniu 27.01.2021 o 01:39, Maureen Hilyard pisze:
In your inimitable style. Love it. Send it.
M
On Tue, Jan 26, 2021 at 12:34 PM Jonathan Zuck <JZuck@innovatorsnetwork.org> wrote:
Ladies,
Here’s my draft response. Let me know what you think!
Jonathan
=============================================================
Hey folks! Thanks for reaching out. Joanna and I, for sure, would be willing to join you and I suspect others, as well, once we know the timing. With respect to the questions below, I’ll do my best to provide some initial responses but I suspect the first question might be pivotal. There seems to be a lack of real data on the topic and perhaps some additional objective research is the answers. We endeavored to begin this process, during the CCTRT ([sadag-final-09aug17-en.pdf (icann.org)](https://www.icann.org/en/system/files/files/sadag-final-09aug17-en.pdf), but obviously barely scratched the surface. Perhaps a more comprehensive study, funded by ICANN rather than the CPH or CSG might be in order? I know DAAR provides some answers but it seems to be more of a survey than an example of rigorous research. Specifically to your questions.
- What information do you use and how do you use it to assess DNS Abuse levels? This is obviously where we are weak. There doesn’t appear to be a great source for DNS Abuse “levels,” particularly because of the short time period over which a particular initiative takes place. A snapshot analysis doesn’t seem to get the full picture. The ALAC relies on the concerned raised by the GAC and the SSAC to fuel our belief that there’s more we should be doing. A recent report from Microsoft suggests the problem is bigger than we realize and David Taylor’s analysis of “responsiveness,” even among those who have signed onto the framework, seems damning. - What are the ALAC’s pain points regarding DNS Abuse? Not sure to answer this in terms of how it’s handled inside ICANN or more generally from where our interests stems. To the latter point, we’re tasked with advancing the interests of those not represented by a constituency in the GNSO, namely those engaged in everyday use of the internet, as opposed to registrants. As the user base continues to grow, as we all desire, so too will the numbers of less sophisticated users, more easily duped by a phishing, malware or fraudulent advertising attack. As for the situation inside ICANN, the At-Large community have attempted to engage constructively as opposed to “attacking” the CPH, focusing instead on so-called “bad actors.” The first [session](https://community.icann.org/display/atlarge/At-Large+Meetings+-+Monday%2C+09...) was an attempt to bring the CPH and Contract Compliance into the same room to figure out where the holes are.
- What exactly are the relevant limits on Contract Compliance?We feel this is a question which comes up constantly and is never successfully or consistently answered. It seems to be an area in which the ICANN community is constantly chasing it’s tail. It would seem that the only real enforced contract provision is payment. I’m sure this is an exaggeration but it seems to be a repeated situation where that is ultimately what foils a “ bad actor” after YEARS of neglect, if not outright facilitation of abuse. The answer to THIS question should be a HIGH priority. It might just be agreeing to an interpretation of the contracts or it might require an amendment to the contracts but this issue needs to stop being a merry go round. - Insufficient Transparency from Contract ComplianceContract Compliance undocumented endeavors at soft touch diplomacy with bad actors seem to need some better limits or, at least, transparency. For “the market” to play a role in this, knowing about legitimate complaints for every contracted party could help customers make better decisions about which businesses to use and help us better understand where policy development needs to take place. - Deflection and Minimization of the ProblemI would say that one “pain point” is that our efforts have been largely “trolled” by certain members of the CPH, rather than engaging constructively. EVEN our effort to conceive of some sort of end user education campaign, to take the pressure off the CPH, was trolled. Jim, not to put you on the spot but, during one conversation, you said you didn’t even understand why this was being discussed because it affects such a small percentage of registered names. To date, we have proposed:
i.Better contract enforcement
ii.More tools for Contract Compliance
iii.DNS Abuse “threshold,” an idea that found some support among the CPH at one point
iv.Predictive Analytics platform, perhaps financed by ICANN
The At-Large community has absolutely no desire to over regulate or over tax the CPH and we understand most of the contracted parties, particularly those showing up to meetings, are trying to do well and continuously improve. That said, this notion that it’s somehow not “our place,” to be trying to help is nothing short of offensive. It is the active participation of the ALAC and GAC that enable the ICANN to portray itself as something other than a trade association. The At-Large mandate is to advance the interests of those MOST impacted by DNS Abuse. That said, we WELCOME suggestions on how better to engage with the CPH for constructive outcomes.
- Are you seeing practices from registrars or registries you find helpful? If we haven’t said it enough, the At-Large appreciates the efforts of those behind the Framework for DNS Abuse and the huge efforts that went into cooperation with law enforcement to track down COVID related abuse. We’d love to see the framework evolve to include specific commitments and metrics, however, for it to be something on which the community could truly rely.
We hope these answers are constructive and not inflammatory as it is our intention to find the most effective ways to proceed to further minimize the incidence of DNS Abuse , in all its forms. Thanks for the opportunity to be part of your conversation.
Maureen, Joanna & Jonathan
From: Keith Drazek <kdrazek@verisign.com> Date: Friday, January 22, 2021 at 12:00 PM To: "maureen.hilyard@gmail.com" <maureen.hilyard@gmail.com>, Jonathan Zuck <JZuck@innovatorsnetwork.org>, "jkuleszaicann@gmail.com" <jkuleszaicann@gmail.com> Cc: "Brian F. Cimbolic" <BCimbolic@pir.org>, Jim Galvin <jgalvin@afilias.info>, Graeme Bunton <gbunton@tucows.com> Subject: Engagement on DNS Abuse
Hello Maureen, Jonathan and Joanna,
I hope you’re all doing well and staying healthy and safe. I am reaching out to you on behalf of the Contracted Party House DNS Abuse Working Group as we look ahead to ICANN 70 and the rest of 2021.
The Contracted Party House (CPH) DNS Abuse Group is conducting outreach to our friends in other SO/AC/SG/Cs regarding DNS Abuse. As previously noted by the CPH, [DNS Abuse](https://rrsg.org/wp-content/uploads/2020/10/CPH-Definition-of-DNS-Abuse.pdf) comprises five categories: phishing, pharming, malware, botnets, and spam when it acts as a delivery mechanism for one of the other forms of DNS Abuse.
We want to open a more direct dialogue to understand pain points, hear suggestions and identify common ground where we can work together to mitigate DNS Abuse. Is there a subset of the At-Large focusing on DNS Abuse questions that would be able to join the CPH DNS Abuse group on a call to discuss this topic? We want to encourage frank and productive discussions on the topic that lead to really informing our dialogues and actions.
As a starting point, we propose the following questions to guide our discussion. Are there any other questions ALAC would like discuss?:
What information do you use and how do you use it to assess DNS Abuse levels?
What are the ALAC’s pain points regarding DNS Abuse?
Are you seeing practices from registrars or registries you find helpful?
Please let us know if a subgroup of the ALAC would be willing to join us. Our group meets regularly on Tuesdays at 1500 UTC. If so, please propose a Tuesday when you are available.
Best regards,
Keith
Keith Drazek
Vice President, Public Policy & Government Relations
Verisign, Inc.
+1-571-377-9182
Kdrazek@verisign.com
--
Kind regards,
Joanna Kulesza
-------------------
Joanna Kulesza, PhD
University of Lodz, Poland
ICANN ALAC Vice Chair
SOI: https://community.icann.org/display/atlarge/Joanna+Kulesza+SOI
TT: @KuleszaJ
Jonathan, Thanks for posting. Simple question first ... Can someone please tell me what "CSAM" stands for? I apologize for the uniformed question. Second question ... Can someone point me to a link that records ICANN's decision not to cross the content "picket fence". I'd like to understand the context ofJoanna's statement better ... "crosses the content "picket fence" that the ICANN community had set for itself". Thanks! David On Wed, Feb 3, 2021 at 10:27 AM Laurin B Weissinger via CPWG <cpwg@icann.org> wrote:
Dear all,
My comments, adding onto Johanna’s:
Keeping these in mind the proposed definition and scope of DNS Abuse strikes as arbitrary: what were the criteria set for selecting these specific categories as DNS Abuse while leaving other potential categories out?
The perspective I am getting from SSR2 is to start with the obvious, technically detectable ones: phishing, C2, plus reports of those. Essentially, stop crimes in progress that do not require complicated and long human oversight.
I am worried about including issues that are private disputes. Even if many use Copyright to stop crimes in progress, as it is the only thing that works. (Consider how insane this is: I need to use the fact that someone is using my logo not as evidence but as a CR issue to stop an actual crime in progress.)
Including IP infringement on equal footing with CSAM raises serious concerns among At-Large members
Absolutely agree with Johanna on the CSAM aspect. It is, imho, ridiculous and more so offensive to name _private_ copyright _disputes_ alongside CSAM.*
Again, speaking from SSR2 experience: focus can be put on forcing immediate review in case of reports, allowing bulk reports, introducing hurdles for criminals on registration, pre-review of suspicious names, etc. (I.e. do things that reduce abuse before it happens)
All the best Laurin
* Indeed, beyond this being ethically and morally unacceptable, companies (not gonna name names) use copyright complaints to silence their critics (free speech issue), arguably themselves being abusers of the system, at least in some cases.
On Wed, Feb 3, 2021 at 15:49, Jonathan Zuck <JZuck@innovatorsnetwork.org> wrote:
Evin has suggested that I had, perhaps, NOT forwarded this to the group. Here’s the discussion thread, initiated by Keith Drazek on the Contracted Party House DNS Abuse Work Group. This includes, Joanna’s expression of mission creep concern.
Jonathan
Jonathan Zuck
Executive Director
Innovators Network Foundation
www.InnovatorsNetwork.org
*From: *Joanna Kulesza <jkuleszaicann@gmail.com> *Sent: *Wednesday, January 27, 2021 2:12 AM *To: *Maureen Hilyard <maureen.hilyard@gmail.com>; Jonathan Zuck <JZuck@innovatorsnetwork.org> *Subject: *Re: Engagement on DNS Abuse
Great stuff Jonathan, as always. Feel free to share. If I were to add my two cents, I'd put these in the "pain points" section while these are of a more general nature.
"From the discussions we've had within At-Large it is clear that the very scope and definition of DNS Abuse is a "pain point". This was also the take away from the discussions we've had with the invited guests from within and beyond the ICANN community. "DNS Abuse" as it is now defined in the proposed Framework affects the entire internet community of end users while being already covered by existing national and international norms and standards. Keeping these in mind the proposed definition and scope of DNS Abuse strikes as arbitrary: what were the criteria set for selecting these specific categories as DNS Abuse while leaving other potential categories out?
This is particularly relevant with regard to our second concern: the proposed scope of DNS Abuse clearly crosses the content "picket fence" that the ICANN community had set for itself. Including IP infringement on equal footing with CSAM raises serious concerns among At-Large members. We are concerned not only with the very fact of the picket fence being crossed but also by the way in which this is being done. Does this mean we should finally abandon the well established yet always controversial narrative of a strictly technical infrastructure management?
Once content is concerned, the existing and proposed practice fails to recognize international legal safeguards when it comes to restrictions put on individual freedoms. Whenever an individual liberty is to be restricted, due process must be ensured. The procedures proposed by the DNS Abuse framework fail to ensure e.g. a right to an effective legal remedy. While we realize this argument brings us back tot he general discussion on limits of ICANN's contractual jurisdiction, that is an argument we would be interested to during any upcoming DNS Abuse work.
Only once these concerns relating to the scope of the definition of DNS Abuse can be addressed, can we focus on metrics and effective enforcement that will provide a fair and operational framework protecting the rights of end users."
By all means to feel free to rephrase!:) What I'm arguing for is that for us to be able to "measure" DNS Abuse we should first clearly and transparently decide what it means. The current framework means the contracted parties are indeed trying to play a self-proclaimed internet police (militia?). Why did we presume DNS Abuse is CSAM and (in the same breath) fake Gucci bags but not hate speech and inciting violence? While we clearly would not have the answer ready, that is definitely a discussion we should have. The GAC might be interested in this as well (see last update from Veni on the ITU processes).
Thanks for considering team!
Best,
J.
W dniu 27.01.2021 o 01:39, Maureen Hilyard pisze:
In your inimitable style. Love it. Send it.
M
On Tue, Jan 26, 2021 at 12:34 PM Jonathan Zuck < JZuck@innovatorsnetwork.org> wrote:
Ladies,
Here’s my draft response. Let me know what you think!
Jonathan
=============================================================
Hey folks! Thanks for reaching out. Joanna and I, for sure, would be willing to join you and I suspect others, as well, once we know the timing. With respect to the questions below, I’ll do my best to provide some initial responses but I suspect the first question might be pivotal. There seems to be a lack of real data on the topic and perhaps some additional objective research is the answers. We endeavored to begin this process, during the CCTRT (sadag-final-09aug17-en.pdf (icann.org) <https://www.icann.org/en/system/files/files/sadag-final-09aug17-en.pdf>, but obviously barely scratched the surface. Perhaps a more comprehensive study, funded by ICANN rather than the CPH or CSG might be in order? I know DAAR provides some answers but it seems to be more of a survey than an example of rigorous research. Specifically to your questions.
1. *What information do you use and how do you use it to assess DNS Abuse levels?* This is obviously where we are weak. There doesn’t appear to be a great source for DNS Abuse “levels,” particularly because of the short time period over which a particular initiative takes place. A snapshot analysis doesn’t seem to get the full picture. The ALAC relies on the concerned raised by the GAC and the SSAC to fuel our belief that there’s more we should be doing. A recent report from Microsoft suggests the problem is bigger than we realize and David Taylor’s analysis of “responsiveness,” even among those who have signed onto the framework, seems damning. 2. *What are the ALAC’s pain points regarding DNS Abuse?* Not sure to answer this in terms of how it’s handled inside ICANN or more generally from where our interests stems. To the latter point, we’re tasked with advancing the interests of those not represented by a constituency in the GNSO, namely those engaged in everyday use of the internet, as opposed to registrants. As the user base continues to grow, as we all desire, so too will the numbers of less sophisticated users, more easily duped by a phishing, malware or fraudulent advertising attack. As for the situation inside ICANN, the At-Large community have attempted to engage constructively as opposed to “attacking” the CPH, focusing instead on so-called “bad actors.” The first session <https://community.icann.org/display/atlarge/At-Large+Meetings+-+Monday%2C+09+March+2020?preview=/124847126/126428447/CCWholistic02.pdf> was an attempt to bring the CPH and Contract Compliance into the same room to figure out where the holes are.
1. *What exactly are the relevant limits on Contract Compliance? *We feel this is a question which comes up constantly and is never successfully or consistently answered. It seems to be an area in which the ICANN community is constantly chasing it’s tail. It would seem that the only real enforced contract provision is payment. I’m sure this is an exaggeration but it seems to be a repeated situation where that is ultimately what foils a “ bad actor” after YEARS of neglect, if not outright facilitation of abuse. The answer to THIS question should be a HIGH priority. It might just be agreeing to an interpretation of the contracts or it might require an amendment to the contracts but this issue needs to stop being a merry go round. 2. *Insufficient Transparency from Contract Compliance *Contract Compliance undocumented endeavors at soft touch diplomacy with bad actors seem to need some better limits or, at least, transparency. For “the market” to play a role in this, knowing about legitimate complaints for every contracted party could help customers make better decisions about which businesses to use and help us better understand where policy development needs to take place. 3. *Deflection and Minimization of the Problem *I would say that one “pain point” is that our efforts have been largely “trolled” by certain members of the CPH, rather than engaging constructively. EVEN our effort to conceive of some sort of end user education campaign, to take the pressure off the CPH, was trolled. Jim, not to put you on the spot but, during one conversation, you said you didn’t even understand why this was being discussed because it affects such a small percentage of registered names. To date, we have proposed:
*i.* *Better contract enforcement*
*ii.* *More tools for Contract Compliance*
*iii.* *DNS Abuse “threshold,” an idea that found some support among the CPH at one point*
*iv.* *Predictive Analytics platform, perhaps financed by ICANN*
The At-Large community has *absolutely* no desire to over regulate or over tax the CPH and we understand most of the contracted parties, particularly those showing up to meetings, are trying to do well and continuously improve. That said, this notion that it’s somehow not “our place,” to be trying to help is nothing short of offensive. It is the active participation of the ALAC and GAC that enable the ICANN to portray itself as something other than a trade association. The At-Large mandate is to advance the interests of those MOST impacted by DNS Abuse. That said, we WELCOME suggestions on how better to engage with the CPH for constructive outcomes.
1. *Are you seeing practices from registrars or registries you find helpful?* If we haven’t said it enough, the At-Large appreciates the efforts of those behind the Framework for DNS Abuse and the huge efforts that went into cooperation with law enforcement to track down COVID related abuse. We’d love to see the framework evolve to include specific commitments and metrics, however, for it to be something on which the community could truly rely.
We hope these answers are constructive and not inflammatory as it is our intention to find the most effective ways to proceed to further minimize the incidence of DNS Abuse , in all its forms. Thanks for the opportunity to be part of your conversation.
Maureen, Joanna & Jonathan
*From: *Keith Drazek <kdrazek@verisign.com> *Date: *Friday, January 22, 2021 at 12:00 PM *To: *"maureen.hilyard@gmail.com" <maureen.hilyard@gmail.com>, Jonathan Zuck <JZuck@innovatorsnetwork.org>, "jkuleszaicann@gmail.com" < jkuleszaicann@gmail.com> *Cc: *"Brian F. Cimbolic" <BCimbolic@pir.org>, Jim Galvin < jgalvin@afilias.info>, Graeme Bunton <gbunton@tucows.com> *Subject: *Engagement on DNS Abuse
Hello Maureen, Jonathan and Joanna,
I hope you’re all doing well and staying healthy and safe. I am reaching out to you on behalf of the Contracted Party House DNS Abuse Working Group as we look ahead to ICANN 70 and the rest of 2021.
The Contracted Party House (CPH) DNS Abuse Group is conducting outreach to our friends in other SO/AC/SG/Cs regarding DNS Abuse. As previously noted by the CPH, DNS Abuse <https://rrsg.org/wp-content/uploads/2020/10/CPH-Definition-of-DNS-Abuse.pdf> comprises five categories: phishing, pharming, malware, botnets, and spam when it acts as a delivery mechanism for one of the other forms of DNS Abuse.
We want to open a more direct dialogue to understand pain points, hear suggestions and identify common ground where we can work together to mitigate DNS Abuse. Is there a subset of the At-Large focusing on DNS Abuse questions that would be able to join the CPH DNS Abuse group on a call to discuss this topic? We want to encourage frank and productive discussions on the topic that lead to really informing our dialogues and actions.
As a starting point, we propose the following questions to guide our discussion. Are there any other questions ALAC would like discuss?:
What information do you use and how do you use it to assess DNS Abuse levels?
What are the ALAC’s pain points regarding DNS Abuse?
Are you seeing practices from registrars or registries you find helpful?
Please let us know if a subgroup of the ALAC would be willing to join us. Our group meets regularly on Tuesdays at 1500 UTC. If so, please propose a Tuesday when you are available.
Best regards,
Keith
Keith Drazek
Vice President, Public Policy & Government Relations
Verisign, Inc.
+1-571-377-9182
Kdrazek@verisign.com
--
Kind regards,
Joanna Kulesza
-------------------
Joanna Kulesza, PhD
University of Lodz, Poland
ICANN ALAC Vice Chair
SOI: https://community.icann.org/display/atlarge/Joanna+Kulesza+SOI
TT: @KuleszaJ
_______________________________________________ CPWG mailing list CPWG@icann.org https://mm.icann.org/mailman/listinfo/cpwg
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi David, happy to help on the first issue: https://www.ecpat.org/wp-content/uploads/legacy/SECO%20Manifestations_CSAM.p... ( *Child Sexual Abuse Material* (CSAM) ) and equally happy to explore the root of the picket fence (pun intended). Thanks, J. W dniu 03.02.2021 o 17:35, David Mackey pisze:
Jonathan,
Thanks for posting.
Simple question first ... Can someone please tell me what "CSAM" stands for? I apologize for the uniformed question.
Second question ... Can someone point me to a link that records ICANN's decision not to cross the content "picket fence". I'd like to understand the context ofJoanna's statement better ... "crosses the content "picket fence" that the ICANN community had set for itself".
Thanks! David
On Wed, Feb 3, 2021 at 10:27 AM Laurin B Weissinger via CPWG <cpwg@icann.org <mailto:cpwg@icann.org>> wrote:
Dear all,
My comments, adding onto Johanna’s:
Keeping these in mind the proposed definition and scope of DNS Abuse strikes as arbitrary: what were the criteria set for selecting these specific categories as DNS Abuse while leaving other potential categories out?
The perspective I am getting from SSR2 is to start with the obvious, technically detectable ones: phishing, C2, plus reports of those. Essentially, stop crimes in progress that do not require complicated and long human oversight.
I am worried about including issues that are private disputes. Even if many use Copyright to stop crimes in progress, as it is the only thing that works. (Consider how insane this is: I need to use the fact that someone is using my logo not as evidence but as a CR issue to stop an actual crime in progress.)
Including IP infringement on equal footing with CSAM raises serious concerns among At-Large members
Absolutely agree with Johanna on the CSAM aspect. It is, imho, ridiculous and more so offensive to name _private_ copyright _disputes_ alongside CSAM.*
Again, speaking from SSR2 experience: focus can be put on forcing immediate review in case of reports, allowing bulk reports, introducing hurdles for criminals on registration, pre-review of suspicious names, etc. (I.e. do things that reduce abuse before it happens)
All the best Laurin
* Indeed, beyond this being ethically and morally unacceptable, companies (not gonna name names) use copyright complaints to silence their critics (free speech issue), arguably themselves being abusers of the system, at least in some cases.
On Wed, Feb 3, 2021 at 15:49, Jonathan Zuck <JZuck@innovatorsnetwork.org <mailto:JZuck@innovatorsnetwork.org>> wrote:
Evin has suggested that I had, perhaps, NOT forwarded this to the group. Here’s the discussion thread, initiated by Keith Drazek on the Contracted Party House DNS Abuse Work Group. This includes, Joanna’s expression of mission creep concern.
Jonathan
Jonathan Zuck
Executive Director
Innovators Network Foundation
www.InnovatorsNetwork.org <http://www.InnovatorsNetwork.org>
*From: *Joanna Kulesza <mailto:jkuleszaicann@gmail.com> *Sent: *Wednesday, January 27, 2021 2:12 AM *To: *Maureen Hilyard <mailto:maureen.hilyard@gmail.com>; Jonathan Zuck <mailto:JZuck@innovatorsnetwork.org> *Subject: *Re: Engagement on DNS Abuse
Great stuff Jonathan, as always. Feel free to share. If I were to add my two cents, I'd put these in the "pain points" section while these are of a more general nature.
"From the discussions we've had within At-Large it is clear that the very scope and definition of DNS Abuse is a "pain point". This was also the take away from the discussions we've had with the invited guests from within and beyond the ICANN community. "DNS Abuse" as it is now defined in the proposed Framework affects the entire internet community of end users while being already covered by existing national and international norms and standards. Keeping these in mind the proposed definition and scope of DNS Abuse strikes as arbitrary: what were the criteria set for selecting these specific categories as DNS Abuse while leaving other potential categories out?
This is particularly relevant with regard to our second concern: the proposed scope of DNS Abuse clearly crosses the content "picket fence" that the ICANN community had set for itself. Including IP infringement on equal footing with CSAM raises serious concerns among At-Large members. We are concerned not only with the very fact of the picket fence being crossed but also by the way in which this is being done. Does this mean we should finally abandon the well established yet always controversial narrative of a strictly technical infrastructure management?
Once content is concerned, the existing and proposed practice fails to recognize international legal safeguards when it comes to restrictions put on individual freedoms. Whenever an individual liberty is to be restricted, due process must be ensured. The procedures proposed by the DNS Abuse framework fail to ensure e.g. a right to an effective legal remedy. While we realize this argument brings us back tot he general discussion on limits of ICANN's contractual jurisdiction, that is an argument we would be interested to during any upcoming DNS Abuse work.
Only once these concerns relating to the scope of the definition of DNS Abuse can be addressed, can we focus on metrics and effective enforcement that will provide a fair and operational framework protecting the rights of end users."
By all means to feel free to rephrase!:) What I'm arguing for is that for us to be able to "measure" DNS Abuse we should first clearly and transparently decide what it means. The current framework means the contracted parties are indeed trying to play a self-proclaimed internet police (militia?). Why did we presume DNS Abuse is CSAM and (in the same breath) fake Gucci bags but not hate speech and inciting violence? While we clearly would not have the answer ready, that is definitely a discussion we should have. The GAC might be interested in this as well (see last update from Veni on the ITU processes).
Thanks for considering team!
Best,
J.
W dniu 27.01.2021 o 01:39, Maureen Hilyard pisze:
In your inimitable style. Love it. Send it.
M
On Tue, Jan 26, 2021 at 12:34 PM Jonathan Zuck <JZuck@innovatorsnetwork.org <mailto:JZuck@innovatorsnetwork.org>> wrote:
Ladies,
Here’s my draft response. Let me know what you think!
Jonathan
=============================================================
Hey folks! Thanks for reaching out. Joanna and I, for sure, would be willing to join you and I suspect others, as well, once we know the timing. With respect to the questions below, I’ll do my best to provide some initial responses but I suspect the first question might be pivotal. There seems to be a lack of real data on the topic and perhaps some additional objective research is the answers. We endeavored to begin this process, during the CCTRT (sadag-final-09aug17-en.pdf (icann.org) <https://www.icann.org/en/system/files/files/sadag-final-09aug17-en.pdf>, but obviously barely scratched the surface. Perhaps a more comprehensive study, funded by ICANN rather than the CPH or CSG might be in order? I know DAAR provides some answers but it seems to be more of a survey than an example of rigorous research. Specifically to your questions.
1. *What information do you use and how do you use it to assess DNS Abuse levels?* This is obviously where we are weak. There doesn’t appear to be a great source for DNS Abuse “levels,” particularly because of the short time period over which a particular initiative takes place. A snapshot analysis doesn’t seem to get the full picture. The ALAC relies on the concerned raised by the GAC and the SSAC to fuel our belief that there’s more we should be doing. A recent report from Microsoft suggests the problem is bigger than we realize and David Taylor’s analysis of “responsiveness,” even among those who have signed onto the framework, seems damning. 2. *What are the ALAC’s pain points regarding DNS Abuse?* Not sure to answer this in terms of how it’s handled inside ICANN or more generally from where our interests stems. To the latter point, we’re tasked with advancing the interests of those not represented by a constituency in the GNSO, namely those engaged in everyday use of the internet, as opposed to registrants. As the user base continues to grow, as we all desire, so too will the numbers of less sophisticated users, more easily duped by a phishing, malware or fraudulent advertising attack. As for the situation inside ICANN, the At-Large community have attempted to engage constructively as opposed to “attacking” the CPH, focusing instead on so-called “bad actors.” The first session <https://community.icann.org/display/atlarge/At-Large+Meetings+-+Monday%2C+09+March+2020?preview=/124847126/126428447/CCWholistic02.pdf> was an attempt to bring the CPH and Contract Compliance into the same room to figure out where the holes are.
1. *What exactly are the relevant limits on Contract Compliance? *We feel this is a question which comes up constantly and is never successfully or consistently answered. It seems to be an area in which the ICANN community is constantly chasing it’s tail. It would seem that the only real enforced contract provision is payment. I’m sure this is an exaggeration but it seems to be a repeated situation where that is ultimately what foils a “ bad actor” after YEARS of neglect, if not outright facilitation of abuse. The answer to THIS question should be a HIGH priority. It might just be agreeing to an interpretation of the contracts or it might require an amendment to the contracts but this issue needs to stop being a merry go round. 2. *Insufficient Transparency from Contract Compliance *Contract Compliance undocumented endeavors at soft touch diplomacy with bad actors seem to need some better limits or, at least, transparency. For “the market” to play a role in this, knowing about legitimate complaints for every contracted party could help customers make better decisions about which businesses to use and help us better understand where policy development needs to take place. 3. *Deflection and Minimization of the Problem *I would say that one “pain point” is that our efforts have been largely “trolled” by certain members of the CPH, rather than engaging constructively. EVEN our effort to conceive of some sort of end user education campaign, to take the pressure off the CPH, was trolled. Jim, not to put you on the spot but, during one conversation, you said you didn’t even understand why this was being discussed because it affects such a small percentage of registered names. To date, we have proposed:
///i.////Better contract enforcement/
///ii.////More tools for Contract Compliance/
///iii.////DNS Abuse “threshold,” an idea that found some support among the CPH at one point/
///iv.////Predictive Analytics platform, perhaps financed by ICANN/
The At-Large community has /absolutely/ no desire to over regulate or over tax the CPH and we understand most of the contracted parties, particularly those showing up to meetings, are trying to do well and continuously improve. That said, this notion that it’s somehow not “our place,” to be trying to help is nothing short of offensive. It is the active participation of the ALAC and GAC that enable the ICANN to portray itself as something other than a trade association. The At-Large mandate is to advance the interests of those MOST impacted by DNS Abuse. That said, we WELCOME suggestions on how better to engage with the CPH for constructive outcomes.
3. *Are you seeing practices from registrars or registries you find helpful?* If we haven’t said it enough, the At-Large appreciates the efforts of those behind the Framework for DNS Abuse and the huge efforts that went into cooperation with law enforcement to track down COVID related abuse. We’d love to see the framework evolve to include specific commitments and metrics, however, for it to be something on which the community could truly rely.
We hope these answers are constructive and not inflammatory as it is our intention to find the most effective ways to proceed to further minimize the incidence of DNS Abuse , in all its forms. Thanks for the opportunity to be part of your conversation.
Maureen, Joanna & Jonathan
*From: *Keith Drazek <kdrazek@verisign.com <mailto:kdrazek@verisign.com>> *Date: *Friday, January 22, 2021 at 12:00 PM *To: *"maureen.hilyard@gmail.com <mailto:maureen.hilyard@gmail.com>" <maureen.hilyard@gmail.com <mailto:maureen.hilyard@gmail.com>>, Jonathan Zuck <JZuck@innovatorsnetwork.org <mailto:JZuck@innovatorsnetwork.org>>, "jkuleszaicann@gmail.com <mailto:jkuleszaicann@gmail.com>" <jkuleszaicann@gmail.com <mailto:jkuleszaicann@gmail.com>> *Cc: *"Brian F. Cimbolic" <BCimbolic@pir.org <mailto:BCimbolic@pir.org>>, Jim Galvin <jgalvin@afilias.info <mailto:jgalvin@afilias.info>>, Graeme Bunton <gbunton@tucows.com <mailto:gbunton@tucows.com>> *Subject: *Engagement on DNS Abuse
Hello Maureen, Jonathan and Joanna,
I hope you’re all doing well and staying healthy and safe. I am reaching out to you on behalf of the Contracted Party House DNS Abuse Working Group as we look ahead to ICANN 70 and the rest of 2021.
The Contracted Party House (CPH) DNS Abuse Group is conducting outreach to our friends in other SO/AC/SG/Cs regarding DNS Abuse. As previously noted by the CPH, DNS Abuse <https://rrsg.org/wp-content/uploads/2020/10/CPH-Definition-of-DNS-Abuse.pdf> comprises five categories: phishing, pharming, malware, botnets, and spam when it acts as a delivery mechanism for one of the other forms of DNS Abuse.
We want to open a more direct dialogue to understand pain points, hear suggestions and identify common ground where we can work together to mitigate DNS Abuse. Is there a subset of the At-Large focusing on DNS Abuse questions that would be able to join the CPH DNS Abuse group on a call to discuss this topic? We want to encourage frank and productive discussions on the topic that lead to really informing our dialogues and actions.
As a starting point, we propose the following questions to guide our discussion. Are there any other questions ALAC would like discuss?:
What information do you use and how do you use it to assess DNS Abuse levels?
What are the ALAC’s pain points regarding DNS Abuse?
Are you seeing practices from registrars or registries you find helpful?
Please let us know if a subgroup of the ALAC would be willing to join us. Our group meets regularly on Tuesdays at 1500 UTC. If so, please propose a Tuesday when you are available.
Best regards,
Keith
Keith Drazek
Vice President, Public Policy & Government Relations
Verisign, Inc.
+1-571-377-9182
Kdrazek@verisign.com <mailto:Kdrazek@verisign.com>
-- Kind regards, Joanna Kulesza ------------------- Joanna Kulesza, PhD University of Lodz, Poland ICANN ALAC Vice Chair SOI:https://community.icann.org/display/atlarge/Joanna+Kulesza+SOI <https://community.icann.org/display/atlarge/Joanna+Kulesza+SOI> TT: @KuleszaJ
_______________________________________________ CPWG mailing list CPWG@icann.org <mailto:CPWG@icann.org> https://mm.icann.org/mailman/listinfo/cpwg <https://mm.icann.org/mailman/listinfo/cpwg>
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ CPWG mailing list CPWG@icann.org https://mm.icann.org/mailman/listinfo/cpwg
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-- Kind regards, Joanna Kulesza ------------------- Joanna Kulesza, PhD University of Lodz, Poland ICANN ALAC Vice Chair SOI: https://community.icann.org/display/atlarge/Joanna+Kulesza+SOI TT: @KuleszaJ
Joanna, Wonderful! Thank you! I also found a useful ICANN66 - GAC Plenary Meeting <https://gac.icann.org/presentations/public/ICANN66%20-%20Slides%20-%2021%20-%20DNS%20Abuse.pdf?language_id=1> document with DNS Abuse background material for other At-Large members who aren't as well versed as the main players who are doing the heavy lifting on this issue. Cheers! David On Wed, Feb 3, 2021 at 1:04 PM Joanna Kulesza <jkuleszaicann@gmail.com> wrote:
Hi David,
happy to help on the first issue: https://www.ecpat.org/wp-content/uploads/legacy/SECO%20Manifestations_CSAM.p... ( *Child Sexual Abuse Material* (CSAM) ) and equally happy to explore the root of the picket fence (pun intended).
Thanks,
J. W dniu 03.02.2021 o 17:35, David Mackey pisze:
Jonathan,
Thanks for posting.
Simple question first ... Can someone please tell me what "CSAM" stands for? I apologize for the uniformed question.
Second question ... Can someone point me to a link that records ICANN's decision not to cross the content "picket fence". I'd like to understand the context ofJoanna's statement better ... "crosses the content "picket fence" that the ICANN community had set for itself".
Thanks! David
On Wed, Feb 3, 2021 at 10:27 AM Laurin B Weissinger via CPWG < cpwg@icann.org> wrote:
Dear all,
My comments, adding onto Johanna’s:
Keeping these in mind the proposed definition and scope of DNS Abuse strikes as arbitrary: what were the criteria set for selecting these specific categories as DNS Abuse while leaving other potential categories out?
The perspective I am getting from SSR2 is to start with the obvious, technically detectable ones: phishing, C2, plus reports of those. Essentially, stop crimes in progress that do not require complicated and long human oversight.
I am worried about including issues that are private disputes. Even if many use Copyright to stop crimes in progress, as it is the only thing that works. (Consider how insane this is: I need to use the fact that someone is using my logo not as evidence but as a CR issue to stop an actual crime in progress.)
Including IP infringement on equal footing with CSAM raises serious concerns among At-Large members
Absolutely agree with Johanna on the CSAM aspect. It is, imho, ridiculous and more so offensive to name _private_ copyright _disputes_ alongside CSAM.*
Again, speaking from SSR2 experience: focus can be put on forcing immediate review in case of reports, allowing bulk reports, introducing hurdles for criminals on registration, pre-review of suspicious names, etc. (I.e. do things that reduce abuse before it happens)
All the best Laurin
* Indeed, beyond this being ethically and morally unacceptable, companies (not gonna name names) use copyright complaints to silence their critics (free speech issue), arguably themselves being abusers of the system, at least in some cases.
On Wed, Feb 3, 2021 at 15:49, Jonathan Zuck <JZuck@innovatorsnetwork.org> wrote:
Evin has suggested that I had, perhaps, NOT forwarded this to the group. Here’s the discussion thread, initiated by Keith Drazek on the Contracted Party House DNS Abuse Work Group. This includes, Joanna’s expression of mission creep concern.
Jonathan
Jonathan Zuck
Executive Director
Innovators Network Foundation
www.InnovatorsNetwork.org
*From: *Joanna Kulesza <jkuleszaicann@gmail.com> *Sent: *Wednesday, January 27, 2021 2:12 AM *To: *Maureen Hilyard <maureen.hilyard@gmail.com>; Jonathan Zuck <JZuck@innovatorsnetwork.org> *Subject: *Re: Engagement on DNS Abuse
Great stuff Jonathan, as always. Feel free to share. If I were to add my two cents, I'd put these in the "pain points" section while these are of a more general nature.
"From the discussions we've had within At-Large it is clear that the very scope and definition of DNS Abuse is a "pain point". This was also the take away from the discussions we've had with the invited guests from within and beyond the ICANN community. "DNS Abuse" as it is now defined in the proposed Framework affects the entire internet community of end users while being already covered by existing national and international norms and standards. Keeping these in mind the proposed definition and scope of DNS Abuse strikes as arbitrary: what were the criteria set for selecting these specific categories as DNS Abuse while leaving other potential categories out?
This is particularly relevant with regard to our second concern: the proposed scope of DNS Abuse clearly crosses the content "picket fence" that the ICANN community had set for itself. Including IP infringement on equal footing with CSAM raises serious concerns among At-Large members. We are concerned not only with the very fact of the picket fence being crossed but also by the way in which this is being done. Does this mean we should finally abandon the well established yet always controversial narrative of a strictly technical infrastructure management?
Once content is concerned, the existing and proposed practice fails to recognize international legal safeguards when it comes to restrictions put on individual freedoms. Whenever an individual liberty is to be restricted, due process must be ensured. The procedures proposed by the DNS Abuse framework fail to ensure e.g. a right to an effective legal remedy. While we realize this argument brings us back tot he general discussion on limits of ICANN's contractual jurisdiction, that is an argument we would be interested to during any upcoming DNS Abuse work.
Only once these concerns relating to the scope of the definition of DNS Abuse can be addressed, can we focus on metrics and effective enforcement that will provide a fair and operational framework protecting the rights of end users."
By all means to feel free to rephrase!:) What I'm arguing for is that for us to be able to "measure" DNS Abuse we should first clearly and transparently decide what it means. The current framework means the contracted parties are indeed trying to play a self-proclaimed internet police (militia?). Why did we presume DNS Abuse is CSAM and (in the same breath) fake Gucci bags but not hate speech and inciting violence? While we clearly would not have the answer ready, that is definitely a discussion we should have. The GAC might be interested in this as well (see last update from Veni on the ITU processes).
Thanks for considering team!
Best,
J.
W dniu 27.01.2021 o 01:39, Maureen Hilyard pisze:
In your inimitable style. Love it. Send it.
M
On Tue, Jan 26, 2021 at 12:34 PM Jonathan Zuck < JZuck@innovatorsnetwork.org> wrote:
Ladies,
Here’s my draft response. Let me know what you think!
Jonathan
=============================================================
Hey folks! Thanks for reaching out. Joanna and I, for sure, would be willing to join you and I suspect others, as well, once we know the timing. With respect to the questions below, I’ll do my best to provide some initial responses but I suspect the first question might be pivotal. There seems to be a lack of real data on the topic and perhaps some additional objective research is the answers. We endeavored to begin this process, during the CCTRT (sadag-final-09aug17-en.pdf (icann.org) <https://www.icann.org/en/system/files/files/sadag-final-09aug17-en.pdf>, but obviously barely scratched the surface. Perhaps a more comprehensive study, funded by ICANN rather than the CPH or CSG might be in order? I know DAAR provides some answers but it seems to be more of a survey than an example of rigorous research. Specifically to your questions.
1. *What information do you use and how do you use it to assess DNS Abuse levels?* This is obviously where we are weak. There doesn’t appear to be a great source for DNS Abuse “levels,” particularly because of the short time period over which a particular initiative takes place. A snapshot analysis doesn’t seem to get the full picture. The ALAC relies on the concerned raised by the GAC and the SSAC to fuel our belief that there’s more we should be doing. A recent report from Microsoft suggests the problem is bigger than we realize and David Taylor’s analysis of “responsiveness,” even among those who have signed onto the framework, seems damning. 2. *What are the ALAC’s pain points regarding DNS Abuse?* Not sure to answer this in terms of how it’s handled inside ICANN or more generally from where our interests stems. To the latter point, we’re tasked with advancing the interests of those not represented by a constituency in the GNSO, namely those engaged in everyday use of the internet, as opposed to registrants. As the user base continues to grow, as we all desire, so too will the numbers of less sophisticated users, more easily duped by a phishing, malware or fraudulent advertising attack. As for the situation inside ICANN, the At-Large community have attempted to engage constructively as opposed to “attacking” the CPH, focusing instead on so-called “bad actors.” The first session <https://community.icann.org/display/atlarge/At-Large+Meetings+-+Monday%2C+09+March+2020?preview=/124847126/126428447/CCWholistic02.pdf> was an attempt to bring the CPH and Contract Compliance into the same room to figure out where the holes are.
1. *What exactly are the relevant limits on Contract Compliance? *We feel this is a question which comes up constantly and is never successfully or consistently answered. It seems to be an area in which the ICANN community is constantly chasing it’s tail. It would seem that the only real enforced contract provision is payment. I’m sure this is an exaggeration but it seems to be a repeated situation where that is ultimately what foils a “ bad actor” after YEARS of neglect, if not outright facilitation of abuse. The answer to THIS question should be a HIGH priority. It might just be agreeing to an interpretation of the contracts or it might require an amendment to the contracts but this issue needs to stop being a merry go round. 2. *Insufficient Transparency from Contract Compliance *Contract Compliance undocumented endeavors at soft touch diplomacy with bad actors seem to need some better limits or, at least, transparency. For “the market” to play a role in this, knowing about legitimate complaints for every contracted party could help customers make better decisions about which businesses to use and help us better understand where policy development needs to take place. 3. *Deflection and Minimization of the Problem *I would say that one “pain point” is that our efforts have been largely “trolled” by certain members of the CPH, rather than engaging constructively. EVEN our effort to conceive of some sort of end user education campaign, to take the pressure off the CPH, was trolled. Jim, not to put you on the spot but, during one conversation, you said you didn’t even understand why this was being discussed because it affects such a small percentage of registered names. To date, we have proposed:
*i.* *Better contract enforcement*
*ii.* *More tools for Contract Compliance*
*iii.* *DNS Abuse “threshold,” an idea that found some support among the CPH at one point*
*iv.* *Predictive Analytics platform, perhaps financed by ICANN*
The At-Large community has *absolutely* no desire to over regulate or over tax the CPH and we understand most of the contracted parties, particularly those showing up to meetings, are trying to do well and continuously improve. That said, this notion that it’s somehow not “our place,” to be trying to help is nothing short of offensive. It is the active participation of the ALAC and GAC that enable the ICANN to portray itself as something other than a trade association. The At-Large mandate is to advance the interests of those MOST impacted by DNS Abuse. That said, we WELCOME suggestions on how better to engage with the CPH for constructive outcomes.
1. *Are you seeing practices from registrars or registries you find helpful?* If we haven’t said it enough, the At-Large appreciates the efforts of those behind the Framework for DNS Abuse and the huge efforts that went into cooperation with law enforcement to track down COVID related abuse. We’d love to see the framework evolve to include specific commitments and metrics, however, for it to be something on which the community could truly rely.
We hope these answers are constructive and not inflammatory as it is our intention to find the most effective ways to proceed to further minimize the incidence of DNS Abuse , in all its forms. Thanks for the opportunity to be part of your conversation.
Maureen, Joanna & Jonathan
*From: *Keith Drazek <kdrazek@verisign.com> *Date: *Friday, January 22, 2021 at 12:00 PM *To: *"maureen.hilyard@gmail.com" <maureen.hilyard@gmail.com>, Jonathan Zuck <JZuck@innovatorsnetwork.org>, "jkuleszaicann@gmail.com" < jkuleszaicann@gmail.com> *Cc: *"Brian F. Cimbolic" <BCimbolic@pir.org>, Jim Galvin < jgalvin@afilias.info>, Graeme Bunton <gbunton@tucows.com> *Subject: *Engagement on DNS Abuse
Hello Maureen, Jonathan and Joanna,
I hope you’re all doing well and staying healthy and safe. I am reaching out to you on behalf of the Contracted Party House DNS Abuse Working Group as we look ahead to ICANN 70 and the rest of 2021.
The Contracted Party House (CPH) DNS Abuse Group is conducting outreach to our friends in other SO/AC/SG/Cs regarding DNS Abuse. As previously noted by the CPH, DNS Abuse <https://rrsg.org/wp-content/uploads/2020/10/CPH-Definition-of-DNS-Abuse.pdf> comprises five categories: phishing, pharming, malware, botnets, and spam when it acts as a delivery mechanism for one of the other forms of DNS Abuse.
We want to open a more direct dialogue to understand pain points, hear suggestions and identify common ground where we can work together to mitigate DNS Abuse. Is there a subset of the At-Large focusing on DNS Abuse questions that would be able to join the CPH DNS Abuse group on a call to discuss this topic? We want to encourage frank and productive discussions on the topic that lead to really informing our dialogues and actions.
As a starting point, we propose the following questions to guide our discussion. Are there any other questions ALAC would like discuss?:
What information do you use and how do you use it to assess DNS Abuse levels?
What are the ALAC’s pain points regarding DNS Abuse?
Are you seeing practices from registrars or registries you find helpful?
Please let us know if a subgroup of the ALAC would be willing to join us. Our group meets regularly on Tuesdays at 1500 UTC. If so, please propose a Tuesday when you are available.
Best regards,
Keith
Keith Drazek
Vice President, Public Policy & Government Relations
Verisign, Inc.
+1-571-377-9182
Kdrazek@verisign.com
--
Kind regards,
Joanna Kulesza
-------------------
Joanna Kulesza, PhD
University of Lodz, Poland
ICANN ALAC Vice Chair
SOI: https://community.icann.org/display/atlarge/Joanna+Kulesza+SOI
TT: @KuleszaJ
_______________________________________________ CPWG mailing list CPWG@icann.org https://mm.icann.org/mailman/listinfo/cpwg
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ CPWG mailing listCPWG@icann.orghttps://mm.icann.org/mailman/listinfo/cpwg
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-- Kind regards, Joanna Kulesza ------------------- Joanna Kulesza, PhD University of Lodz, Poland ICANN ALAC Vice Chair SOI: https://community.icann.org/display/atlarge/Joanna+Kulesza+SOI TT: @KuleszaJ
_______________________________________________ CPWG mailing list CPWG@icann.org https://mm.icann.org/mailman/listinfo/cpwg
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Laurin wrote: * Again, speaking from SSR2 experience: focus can be put on forcing immediate review in case of reports, allowing bulk reports, introducing hurdles for criminals on registration, pre-review of suspicious names, etc. (I.e. do things that reduce abuse before it happens)* Have to tell you that IMHO, all of that - what normal regulators would shop as KYC rules - is covered in existing [RAA and RRA] contracts and/or consensus policies. The problem is for the most part, some of our brethren have declared them one or other of burdensome to transaction processing/alien to businesses operating at internet speed/not commercially reasonable/plain abusive of registrant rights. And as intimated in the thread, ICANN CC has shown neither appetite to enforce or the gumption for enforcement. The arguments I've heard since time out of memory to justify inaction is the concern that Compliance not overstep the general ICANN obligations detailed in the RAA. Never mind that there is a specific clause in the RAA that compels the Registrar to collect "*accurate and reliable contact details*" along with some indicative responses when those are in doubt! There is a [WHOIS] Accuracy Specification which outlines the expectations for accurate and reliable registration data. That Specification also outlines in clear text the responses when otherwise suspected. Some of us have argued that fifteen (15) days before effective corrective or coercive [re]action - suspend the ability for name resolution! - was totally out of whack to damage that could be wrought on end users. Then there is a specific clause in the RAA that enjoins the Registrar to keep the data collected safe and sound. And one that enjoins the Registrar to share it, as necessary and requested, with a court of lawful jurisdiction. I personally don't see how one can say a registered name holder is '*identified and identifiable*' without verification of the elements used to establish identity. I also know that knowingly sending inaccurate data to a court of lawful jurisdiction is, in some [common law] jurisdictions, deemed an abuse of process and contempt of court. Interestingly, there is a clause in the RAA that enjoins a Registrar not to activate a name until they are sure of payment! That same rule devolved and applied to establishing identity is a no brainer. But nooooooo..... Carlton ============================== *Carlton A Samuels* *Mobile: 876-818-1799Strategy, Process, Governance, Assessment & Turnaround* ============================= On Wed, Feb 3, 2021 at 10:27 AM Laurin B Weissinger via CPWG <cpwg@icann.org> wrote:
Dear all,
My comments, adding onto Johanna’s:
Keeping these in mind the proposed definition and scope of DNS Abuse strikes as arbitrary: what were the criteria set for selecting these specific categories as DNS Abuse while leaving other potential categories out?
The perspective I am getting from SSR2 is to start with the obvious, technically detectable ones: phishing, C2, plus reports of those. Essentially, stop crimes in progress that do not require complicated and long human oversight.
I am worried about including issues that are private disputes. Even if many use Copyright to stop crimes in progress, as it is the only thing that works. (Consider how insane this is: I need to use the fact that someone is using my logo not as evidence but as a CR issue to stop an actual crime in progress.)
Including IP infringement on equal footing with CSAM raises serious concerns among At-Large members
Absolutely agree with Johanna on the CSAM aspect. It is, imho, ridiculous and more so offensive to name _private_ copyright _disputes_ alongside CSAM.*
Again, speaking from SSR2 experience: focus can be put on forcing immediate review in case of reports, allowing bulk reports, introducing hurdles for criminals on registration, pre-review of suspicious names, etc. (I.e. do things that reduce abuse before it happens)
All the best Laurin
* Indeed, beyond this being ethically and morally unacceptable, companies (not gonna name names) use copyright complaints to silence their critics (free speech issue), arguably themselves being abusers of the system, at least in some cases.
On Wed, Feb 3, 2021 at 15:49, Jonathan Zuck <JZuck@innovatorsnetwork.org> wrote:
Evin has suggested that I had, perhaps, NOT forwarded this to the group. Here’s the discussion thread, initiated by Keith Drazek on the Contracted Party House DNS Abuse Work Group. This includes, Joanna’s expression of mission creep concern.
Jonathan
Jonathan Zuck
Executive Director
Innovators Network Foundation
www.InnovatorsNetwork.org
*From: *Joanna Kulesza <jkuleszaicann@gmail.com> *Sent: *Wednesday, January 27, 2021 2:12 AM *To: *Maureen Hilyard <maureen.hilyard@gmail.com>; Jonathan Zuck <JZuck@innovatorsnetwork.org> *Subject: *Re: Engagement on DNS Abuse
Great stuff Jonathan, as always. Feel free to share. If I were to add my two cents, I'd put these in the "pain points" section while these are of a more general nature.
"From the discussions we've had within At-Large it is clear that the very scope and definition of DNS Abuse is a "pain point". This was also the take away from the discussions we've had with the invited guests from within and beyond the ICANN community. "DNS Abuse" as it is now defined in the proposed Framework affects the entire internet community of end users while being already covered by existing national and international norms and standards. Keeping these in mind the proposed definition and scope of DNS Abuse strikes as arbitrary: what were the criteria set for selecting these specific categories as DNS Abuse while leaving other potential categories out?
This is particularly relevant with regard to our second concern: the proposed scope of DNS Abuse clearly crosses the content "picket fence" that the ICANN community had set for itself. Including IP infringement on equal footing with CSAM raises serious concerns among At-Large members. We are concerned not only with the very fact of the picket fence being crossed but also by the way in which this is being done. Does this mean we should finally abandon the well established yet always controversial narrative of a strictly technical infrastructure management?
Once content is concerned, the existing and proposed practice fails to recognize international legal safeguards when it comes to restrictions put on individual freedoms. Whenever an individual liberty is to be restricted, due process must be ensured. The procedures proposed by the DNS Abuse framework fail to ensure e.g. a right to an effective legal remedy. While we realize this argument brings us back tot he general discussion on limits of ICANN's contractual jurisdiction, that is an argument we would be interested to during any upcoming DNS Abuse work.
Only once these concerns relating to the scope of the definition of DNS Abuse can be addressed, can we focus on metrics and effective enforcement that will provide a fair and operational framework protecting the rights of end users."
By all means to feel free to rephrase!:) What I'm arguing for is that for us to be able to "measure" DNS Abuse we should first clearly and transparently decide what it means. The current framework means the contracted parties are indeed trying to play a self-proclaimed internet police (militia?). Why did we presume DNS Abuse is CSAM and (in the same breath) fake Gucci bags but not hate speech and inciting violence? While we clearly would not have the answer ready, that is definitely a discussion we should have. The GAC might be interested in this as well (see last update from Veni on the ITU processes).
Thanks for considering team!
Best,
J.
W dniu 27.01.2021 o 01:39, Maureen Hilyard pisze:
In your inimitable style. Love it. Send it.
M
On Tue, Jan 26, 2021 at 12:34 PM Jonathan Zuck < JZuck@innovatorsnetwork.org> wrote:
Ladies,
Here’s my draft response. Let me know what you think!
Jonathan
=============================================================
Hey folks! Thanks for reaching out. Joanna and I, for sure, would be willing to join you and I suspect others, as well, once we know the timing. With respect to the questions below, I’ll do my best to provide some initial responses but I suspect the first question might be pivotal. There seems to be a lack of real data on the topic and perhaps some additional objective research is the answers. We endeavored to begin this process, during the CCTRT (sadag-final-09aug17-en.pdf (icann.org) <https://www.icann.org/en/system/files/files/sadag-final-09aug17-en.pdf>, but obviously barely scratched the surface. Perhaps a more comprehensive study, funded by ICANN rather than the CPH or CSG might be in order? I know DAAR provides some answers but it seems to be more of a survey than an example of rigorous research. Specifically to your questions.
1. *What information do you use and how do you use it to assess DNS Abuse levels?* This is obviously where we are weak. There doesn’t appear to be a great source for DNS Abuse “levels,” particularly because of the short time period over which a particular initiative takes place. A snapshot analysis doesn’t seem to get the full picture. The ALAC relies on the concerned raised by the GAC and the SSAC to fuel our belief that there’s more we should be doing. A recent report from Microsoft suggests the problem is bigger than we realize and David Taylor’s analysis of “responsiveness,” even among those who have signed onto the framework, seems damning. 2. *What are the ALAC’s pain points regarding DNS Abuse?* Not sure to answer this in terms of how it’s handled inside ICANN or more generally from where our interests stems. To the latter point, we’re tasked with advancing the interests of those not represented by a constituency in the GNSO, namely those engaged in everyday use of the internet, as opposed to registrants. As the user base continues to grow, as we all desire, so too will the numbers of less sophisticated users, more easily duped by a phishing, malware or fraudulent advertising attack. As for the situation inside ICANN, the At-Large community have attempted to engage constructively as opposed to “attacking” the CPH, focusing instead on so-called “bad actors.” The first session <https://community.icann.org/display/atlarge/At-Large+Meetings+-+Monday%2C+09+March+2020?preview=/124847126/126428447/CCWholistic02.pdf> was an attempt to bring the CPH and Contract Compliance into the same room to figure out where the holes are.
1. *What exactly are the relevant limits on Contract Compliance? *We feel this is a question which comes up constantly and is never successfully or consistently answered. It seems to be an area in which the ICANN community is constantly chasing it’s tail. It would seem that the only real enforced contract provision is payment. I’m sure this is an exaggeration but it seems to be a repeated situation where that is ultimately what foils a “ bad actor” after YEARS of neglect, if not outright facilitation of abuse. The answer to THIS question should be a HIGH priority. It might just be agreeing to an interpretation of the contracts or it might require an amendment to the contracts but this issue needs to stop being a merry go round. 2. *Insufficient Transparency from Contract Compliance *Contract Compliance undocumented endeavors at soft touch diplomacy with bad actors seem to need some better limits or, at least, transparency. For “the market” to play a role in this, knowing about legitimate complaints for every contracted party could help customers make better decisions about which businesses to use and help us better understand where policy development needs to take place. 3. *Deflection and Minimization of the Problem *I would say that one “pain point” is that our efforts have been largely “trolled” by certain members of the CPH, rather than engaging constructively. EVEN our effort to conceive of some sort of end user education campaign, to take the pressure off the CPH, was trolled. Jim, not to put you on the spot but, during one conversation, you said you didn’t even understand why this was being discussed because it affects such a small percentage of registered names. To date, we have proposed:
*i.* *Better contract enforcement*
*ii.* *More tools for Contract Compliance*
*iii.* *DNS Abuse “threshold,” an idea that found some support among the CPH at one point*
*iv.* *Predictive Analytics platform, perhaps financed by ICANN*
The At-Large community has *absolutely* no desire to over regulate or over tax the CPH and we understand most of the contracted parties, particularly those showing up to meetings, are trying to do well and continuously improve. That said, this notion that it’s somehow not “our place,” to be trying to help is nothing short of offensive. It is the active participation of the ALAC and GAC that enable the ICANN to portray itself as something other than a trade association. The At-Large mandate is to advance the interests of those MOST impacted by DNS Abuse. That said, we WELCOME suggestions on how better to engage with the CPH for constructive outcomes.
1. *Are you seeing practices from registrars or registries you find helpful?* If we haven’t said it enough, the At-Large appreciates the efforts of those behind the Framework for DNS Abuse and the huge efforts that went into cooperation with law enforcement to track down COVID related abuse. We’d love to see the framework evolve to include specific commitments and metrics, however, for it to be something on which the community could truly rely.
We hope these answers are constructive and not inflammatory as it is our intention to find the most effective ways to proceed to further minimize the incidence of DNS Abuse , in all its forms. Thanks for the opportunity to be part of your conversation.
Maureen, Joanna & Jonathan
*From: *Keith Drazek <kdrazek@verisign.com> *Date: *Friday, January 22, 2021 at 12:00 PM *To: *"maureen.hilyard@gmail.com" <maureen.hilyard@gmail.com>, Jonathan Zuck <JZuck@innovatorsnetwork.org>, "jkuleszaicann@gmail.com" < jkuleszaicann@gmail.com> *Cc: *"Brian F. Cimbolic" <BCimbolic@pir.org>, Jim Galvin < jgalvin@afilias.info>, Graeme Bunton <gbunton@tucows.com> *Subject: *Engagement on DNS Abuse
Hello Maureen, Jonathan and Joanna,
I hope you’re all doing well and staying healthy and safe. I am reaching out to you on behalf of the Contracted Party House DNS Abuse Working Group as we look ahead to ICANN 70 and the rest of 2021.
The Contracted Party House (CPH) DNS Abuse Group is conducting outreach to our friends in other SO/AC/SG/Cs regarding DNS Abuse. As previously noted by the CPH, DNS Abuse <https://rrsg.org/wp-content/uploads/2020/10/CPH-Definition-of-DNS-Abuse.pdf> comprises five categories: phishing, pharming, malware, botnets, and spam when it acts as a delivery mechanism for one of the other forms of DNS Abuse.
We want to open a more direct dialogue to understand pain points, hear suggestions and identify common ground where we can work together to mitigate DNS Abuse. Is there a subset of the At-Large focusing on DNS Abuse questions that would be able to join the CPH DNS Abuse group on a call to discuss this topic? We want to encourage frank and productive discussions on the topic that lead to really informing our dialogues and actions.
As a starting point, we propose the following questions to guide our discussion. Are there any other questions ALAC would like discuss?:
What information do you use and how do you use it to assess DNS Abuse levels?
What are the ALAC’s pain points regarding DNS Abuse?
Are you seeing practices from registrars or registries you find helpful?
Please let us know if a subgroup of the ALAC would be willing to join us. Our group meets regularly on Tuesdays at 1500 UTC. If so, please propose a Tuesday when you are available.
Best regards,
Keith
Keith Drazek
Vice President, Public Policy & Government Relations
Verisign, Inc.
+1-571-377-9182
Kdrazek@verisign.com
--
Kind regards,
Joanna Kulesza
-------------------
Joanna Kulesza, PhD
University of Lodz, Poland
ICANN ALAC Vice Chair
SOI: https://community.icann.org/display/atlarge/Joanna+Kulesza+SOI
TT: @KuleszaJ
_______________________________________________ CPWG mailing list CPWG@icann.org https://mm.icann.org/mailman/listinfo/cpwg
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Dear Carlton and all, Yes, technically some of these things might exist to a greater or lesser extent on paper, some do not (I recently had the pleasure reading the publicly available documents). However, no matter what is on paper, they clearly do not exist/are not applied in practice. Furthermore, as you rightly state, ICANN is not enforcing the clauses that are there. (Alpnames comes to mind as well as others). This is a problem. The issue is clearly unwillingness to change on the part of certain parties, which is only rational considering their business interests. Furthermore, it is obvious that perfect security is impossible and that expense must be balanced against the usefulness. Without any doubt, we are far far away from that point. Nevertheless, (continued pressure to establish) new policies are needed. From a public safety and security perspective, things need to change. All the best Laurin P.S. The SSR2 report addresses this as well. If correctly / in a useful way — I don’t know. On Wed, Feb 3, 2021 at 17:55, Carlton Samuels <carlton.samuels@gmail.com> wrote:
Laurin wrote: Again, speaking from SSR2 experience: focus can be put on forcing immediate review in case of reports, allowing bulk reports, introducing hurdles for criminals on registration, pre-review of suspicious names, etc. (I.e. do things that reduce abuse before it happens)
Have to tell you that IMHO, all of that - what normal regulators would shop as KYC rules - is covered in existing [RAA and RRA] contracts and/or consensus policies. The problem is for the most part, some of our brethren have declared them one or other of burdensome to transaction processing/alien to businesses operating at internet speed/not commercially reasonable/plain abusive of registrant rights. And as intimated in the thread, ICANN CC has shown neither appetite to enforce or the gumption for enforcement.
The arguments I've heard since time out of memory to justify inaction is the concern that Compliance not overstep the general ICANN obligations detailed in the RAA. Never mind that there is a specific clause in the RAA that compels the Registrar to collect "accurate and reliable contact details" along with some indicative responses when those are in doubt!
There is a [WHOIS] Accuracy Specification which outlines the expectations for accurate and reliable registration data. That Specification also outlines in clear text the responses when otherwise suspected. Some of us have argued that fifteen (15) days before effective corrective or coercive [re]action - suspend the ability for name resolution! - was totally out of whack to damage that could be wrought on end users.
Then there is a specific clause in the RAA that enjoins the Registrar to keep the data collected safe and sound. And one that enjoins the Registrar to share it, as necessary and requested, with a court of lawful jurisdiction.
I personally don't see how one can say a registered name holder is 'identified and identifiable' without verification of the elements used to establish identity. I also know that knowingly sending inaccurate data to a court of lawful jurisdiction is, in some [common law] jurisdictions, deemed an abuse of process and contempt of court.
Interestingly, there is a clause in the RAA that enjoins a Registrar not to activate a name until they are sure of payment! That same rule devolved and applied to establishing identity is a no brainer. But nooooooo.....
Carlton ============================== Carlton A Samuels Mobile: 876-818-1799 Strategy, Process, Governance, Assessment & Turnaround =============================
On Wed, Feb 3, 2021 at 10:27 AM Laurin B Weissinger via CPWG <cpwg@icann.org> wrote:
Dear all,
My comments, adding onto Johanna’s:
Keeping these in mind the proposed definition and scope of DNS Abuse strikes as arbitrary: what were the criteria set for selecting these specific categories as DNS Abuse while leaving other potential categories out?
The perspective I am getting from SSR2 is to start with the obvious, technically detectable ones: phishing, C2, plus reports of those. Essentially, stop crimes in progress that do not require complicated and long human oversight.
I am worried about including issues that are private disputes. Even if many use Copyright to stop crimes in progress, as it is the only thing that works. (Consider how insane this is: I need to use the fact that someone is using my logo not as evidence but as a CR issue to stop an actual crime in progress.)
Including IP infringement on equal footing with CSAM raises serious concerns among At-Large members
Absolutely agree with Johanna on the CSAM aspect. It is, imho, ridiculous and more so offensive to name _private_ copyright _disputes_ alongside CSAM.*
Again, speaking from SSR2 experience: focus can be put on forcing immediate review in case of reports, allowing bulk reports, introducing hurdles for criminals on registration, pre-review of suspicious names, etc. (I.e. do things that reduce abuse before it happens)
All the best Laurin
* Indeed, beyond this being ethically and morally unacceptable, companies (not gonna name names) use copyright complaints to silence their critics (free speech issue), arguably themselves being abusers of the system, at least in some cases.
On Wed, Feb 3, 2021 at 15:49, Jonathan Zuck <JZuck@innovatorsnetwork.org> wrote:
Evin has suggested that I had, perhaps, NOT forwarded this to the group. Here’s the discussion thread, initiated by Keith Drazek on the Contracted Party House DNS Abuse Work Group. This includes, Joanna’s expression of mission creep concern.
Jonathan
Jonathan Zuck
Executive Director
Innovators Network Foundation
www.InnovatorsNetwork.org
From: [Joanna Kulesza](mailto:jkuleszaicann@gmail.com) Sent: Wednesday, January 27, 2021 2:12 AM To: [Maureen Hilyard](mailto:maureen.hilyard@gmail.com); [Jonathan Zuck](mailto:JZuck@innovatorsnetwork.org) Subject: Re: Engagement on DNS Abuse
Great stuff Jonathan, as always. Feel free to share. If I were to add my two cents, I'd put these in the "pain points" section while these are of a more general nature.
"From the discussions we've had within At-Large it is clear that the very scope and definition of DNS Abuse is a "pain point". This was also the take away from the discussions we've had with the invited guests from within and beyond the ICANN community. "DNS Abuse" as it is now defined in the proposed Framework affects the entire internet community of end users while being already covered by existing national and international norms and standards. Keeping these in mind the proposed definition and scope of DNS Abuse strikes as arbitrary: what were the criteria set for selecting these specific categories as DNS Abuse while leaving other potential categories out?
This is particularly relevant with regard to our second concern: the proposed scope of DNS Abuse clearly crosses the content "picket fence" that the ICANN community had set for itself. Including IP infringement on equal footing with CSAM raises serious concerns among At-Large members. We are concerned not only with the very fact of the picket fence being crossed but also by the way in which this is being done. Does this mean we should finally abandon the well established yet always controversial narrative of a strictly technical infrastructure management?
Once content is concerned, the existing and proposed practice fails to recognize international legal safeguards when it comes to restrictions put on individual freedoms. Whenever an individual liberty is to be restricted, due process must be ensured. The procedures proposed by the DNS Abuse framework fail to ensure e.g. a right to an effective legal remedy. While we realize this argument brings us back tot he general discussion on limits of ICANN's contractual jurisdiction, that is an argument we would be interested to during any upcoming DNS Abuse work.
Only once these concerns relating to the scope of the definition of DNS Abuse can be addressed, can we focus on metrics and effective enforcement that will provide a fair and operational framework protecting the rights of end users."
By all means to feel free to rephrase!:) What I'm arguing for is that for us to be able to "measure" DNS Abuse we should first clearly and transparently decide what it means. The current framework means the contracted parties are indeed trying to play a self-proclaimed internet police (militia?). Why did we presume DNS Abuse is CSAM and (in the same breath) fake Gucci bags but not hate speech and inciting violence? While we clearly would not have the answer ready, that is definitely a discussion we should have. The GAC might be interested in this as well (see last update from Veni on the ITU processes).
Thanks for considering team!
Best,
J.
W dniu 27.01.2021 o 01:39, Maureen Hilyard pisze:
In your inimitable style. Love it. Send it.
M
On Tue, Jan 26, 2021 at 12:34 PM Jonathan Zuck <JZuck@innovatorsnetwork.org> wrote:
Ladies,
Here’s my draft response. Let me know what you think!
Jonathan
=============================================================
Hey folks! Thanks for reaching out. Joanna and I, for sure, would be willing to join you and I suspect others, as well, once we know the timing. With respect to the questions below, I’ll do my best to provide some initial responses but I suspect the first question might be pivotal. There seems to be a lack of real data on the topic and perhaps some additional objective research is the answers. We endeavored to begin this process, during the CCTRT ([sadag-final-09aug17-en.pdf (icann.org)](https://www.icann.org/en/system/files/files/sadag-final-09aug17-en.pdf), but obviously barely scratched the surface. Perhaps a more comprehensive study, funded by ICANN rather than the CPH or CSG might be in order? I know DAAR provides some answers but it seems to be more of a survey than an example of rigorous research. Specifically to your questions.
- What information do you use and how do you use it to assess DNS Abuse levels? This is obviously where we are weak. There doesn’t appear to be a great source for DNS Abuse “levels,” particularly because of the short time period over which a particular initiative takes place. A snapshot analysis doesn’t seem to get the full picture. The ALAC relies on the concerned raised by the GAC and the SSAC to fuel our belief that there’s more we should be doing. A recent report from Microsoft suggests the problem is bigger than we realize and David Taylor’s analysis of “responsiveness,” even among those who have signed onto the framework, seems damning. - What are the ALAC’s pain points regarding DNS Abuse? Not sure to answer this in terms of how it’s handled inside ICANN or more generally from where our interests stems. To the latter point, we’re tasked with advancing the interests of those not represented by a constituency in the GNSO, namely those engaged in everyday use of the internet, as opposed to registrants. As the user base continues to grow, as we all desire, so too will the numbers of less sophisticated users, more easily duped by a phishing, malware or fraudulent advertising attack. As for the situation inside ICANN, the At-Large community have attempted to engage constructively as opposed to “attacking” the CPH, focusing instead on so-called “bad actors.” The first [session](https://community.icann.org/display/atlarge/At-Large+Meetings+-+Monday%2C+09...) was an attempt to bring the CPH and Contract Compliance into the same room to figure out where the holes are.
- What exactly are the relevant limits on Contract Compliance?We feel this is a question which comes up constantly and is never successfully or consistently answered. It seems to be an area in which the ICANN community is constantly chasing it’s tail. It would seem that the only real enforced contract provision is payment. I’m sure this is an exaggeration but it seems to be a repeated situation where that is ultimately what foils a “ bad actor” after YEARS of neglect, if not outright facilitation of abuse. The answer to THIS question should be a HIGH priority. It might just be agreeing to an interpretation of the contracts or it might require an amendment to the contracts but this issue needs to stop being a merry go round. - Insufficient Transparency from Contract ComplianceContract Compliance undocumented endeavors at soft touch diplomacy with bad actors seem to need some better limits or, at least, transparency. For “the market” to play a role in this, knowing about legitimate complaints for every contracted party could help customers make better decisions about which businesses to use and help us better understand where policy development needs to take place. - Deflection and Minimization of the ProblemI would say that one “pain point” is that our efforts have been largely “trolled” by certain members of the CPH, rather than engaging constructively. EVEN our effort to conceive of some sort of end user education campaign, to take the pressure off the CPH, was trolled. Jim, not to put you on the spot but, during one conversation, you said you didn’t even understand why this was being discussed because it affects such a small percentage of registered names. To date, we have proposed:
i.Better contract enforcement
ii.More tools for Contract Compliance
iii.DNS Abuse “threshold,” an idea that found some support among the CPH at one point
iv.Predictive Analytics platform, perhaps financed by ICANN
The At-Large community has absolutely no desire to over regulate or over tax the CPH and we understand most of the contracted parties, particularly those showing up to meetings, are trying to do well and continuously improve. That said, this notion that it’s somehow not “our place,” to be trying to help is nothing short of offensive. It is the active participation of the ALAC and GAC that enable the ICANN to portray itself as something other than a trade association. The At-Large mandate is to advance the interests of those MOST impacted by DNS Abuse. That said, we WELCOME suggestions on how better to engage with the CPH for constructive outcomes.
- Are you seeing practices from registrars or registries you find helpful? If we haven’t said it enough, the At-Large appreciates the efforts of those behind the Framework for DNS Abuse and the huge efforts that went into cooperation with law enforcement to track down COVID related abuse. We’d love to see the framework evolve to include specific commitments and metrics, however, for it to be something on which the community could truly rely.
We hope these answers are constructive and not inflammatory as it is our intention to find the most effective ways to proceed to further minimize the incidence of DNS Abuse , in all its forms. Thanks for the opportunity to be part of your conversation.
Maureen, Joanna & Jonathan
From: Keith Drazek <kdrazek@verisign.com> Date: Friday, January 22, 2021 at 12:00 PM To: "maureen.hilyard@gmail.com" <maureen.hilyard@gmail.com>, Jonathan Zuck <JZuck@innovatorsnetwork.org>, "jkuleszaicann@gmail.com" <jkuleszaicann@gmail.com> Cc: "Brian F. Cimbolic" <BCimbolic@pir.org>, Jim Galvin <jgalvin@afilias.info>, Graeme Bunton <gbunton@tucows.com> Subject: Engagement on DNS Abuse
Hello Maureen, Jonathan and Joanna,
I hope you’re all doing well and staying healthy and safe. I am reaching out to you on behalf of the Contracted Party House DNS Abuse Working Group as we look ahead to ICANN 70 and the rest of 2021.
The Contracted Party House (CPH) DNS Abuse Group is conducting outreach to our friends in other SO/AC/SG/Cs regarding DNS Abuse. As previously noted by the CPH, [DNS Abuse](https://rrsg.org/wp-content/uploads/2020/10/CPH-Definition-of-DNS-Abuse.pdf) comprises five categories: phishing, pharming, malware, botnets, and spam when it acts as a delivery mechanism for one of the other forms of DNS Abuse.
We want to open a more direct dialogue to understand pain points, hear suggestions and identify common ground where we can work together to mitigate DNS Abuse. Is there a subset of the At-Large focusing on DNS Abuse questions that would be able to join the CPH DNS Abuse group on a call to discuss this topic? We want to encourage frank and productive discussions on the topic that lead to really informing our dialogues and actions.
As a starting point, we propose the following questions to guide our discussion. Are there any other questions ALAC would like discuss?:
What information do you use and how do you use it to assess DNS Abuse levels?
What are the ALAC’s pain points regarding DNS Abuse?
Are you seeing practices from registrars or registries you find helpful?
Please let us know if a subgroup of the ALAC would be willing to join us. Our group meets regularly on Tuesdays at 1500 UTC. If so, please propose a Tuesday when you are available.
Best regards,
Keith
Keith Drazek
Vice President, Public Policy & Government Relations
Verisign, Inc.
+1-571-377-9182
Kdrazek@verisign.com
--
Kind regards,
Joanna Kulesza
-------------------
Joanna Kulesza, PhD
University of Lodz, Poland
ICANN ALAC Vice Chair
SOI: https://community.icann.org/display/atlarge/Joanna+Kulesza+SOI
TT: @KuleszaJ
_______________________________________________ CPWG mailing list CPWG@icann.org https://mm.icann.org/mailman/listinfo/cpwg
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi Laurin: One of the things I learned from public policy advocacy in my home region is to be avowedly incrementalist if one should not lose heart. So I would take it as progress and a big win if we commit to simply enforcing the rules already! You would have seen my colleague and friend Evan's intervention. He and I have been at this matter since 2009, the apogee of those engagements coinciding with the emergence of the 2013 RAA. The [then] preponderant At-Large view hews somewhat to one framed by a justice of the U.S. Supreme Court when asked how he could tell if something was obscene; his pithy response " *I know it when I see it*". In a funny kind of way, end users tend to know abuse when they feel it. And there's the rub. As John McCormac rightly pointed out in respect of DNS Abuse, the struggle now is no longer definitional but on scope. And the argument is inebriated - yes, made drunk! - by the circular is this determined by detection or reporting. Our colleagues in aa419 and Legitscript will tell you regardless, the fight for each is only from different fronts. I tend to agree with this. So, the struggle continues. Carlton ============================== *Carlton A Samuels* *Mobile: 876-818-1799Strategy, Process, Governance, Assessment & Turnaround* ============================= On Wed, Feb 3, 2021 at 1:27 PM Laurin B Weissinger <Laurin-lists@pm.me> wrote:
Dear Carlton and all,
Yes, technically some of these things might exist to a greater or lesser extent on paper, some do not (I recently had the pleasure reading the publicly available documents). However, no matter what is on paper, they clearly do not exist/are not applied in practice.
Furthermore, as you rightly state, ICANN is not enforcing the clauses that are there. (Alpnames comes to mind as well as others). This is a problem.
The issue is clearly unwillingness to change on the part of certain parties, which is only rational considering their business interests. Furthermore, it is obvious that perfect security is impossible and that expense must be balanced against the usefulness. Without any doubt, we are far far away from that point.
Nevertheless, (continued pressure to establish) new policies are needed. From a public safety and security perspective, things need to change.
All the best Laurin
P.S. The SSR2 report addresses this as well. If correctly / in a useful way — I don’t know.
On Wed, Feb 3, 2021 at 17:55, Carlton Samuels <carlton.samuels@gmail.com> wrote:
Laurin wrote: * Again, speaking from SSR2 experience: focus can be put on forcing immediate review in case of reports, allowing bulk reports, introducing hurdles for criminals on registration, pre-review of suspicious names, etc. (I.e. do things that reduce abuse before it happens)*
Have to tell you that IMHO, all of that - what normal regulators would shop as KYC rules - is covered in existing [RAA and RRA] contracts and/or consensus policies. The problem is for the most part, some of our brethren have declared them one or other of burdensome to transaction processing/alien to businesses operating at internet speed/not commercially reasonable/plain abusive of registrant rights. And as intimated in the thread, ICANN CC has shown neither appetite to enforce or the gumption for enforcement.
The arguments I've heard since time out of memory to justify inaction is the concern that Compliance not overstep the general ICANN obligations detailed in the RAA. Never mind that there is a specific clause in the RAA that compels the Registrar to collect "*accurate and reliable contact details*" along with some indicative responses when those are in doubt!
There is a [WHOIS] Accuracy Specification which outlines the expectations for accurate and reliable registration data. That Specification also outlines in clear text the responses when otherwise suspected. Some of us have argued that fifteen (15) days before effective corrective or coercive [re]action - suspend the ability for name resolution! - was totally out of whack to damage that could be wrought on end users.
Then there is a specific clause in the RAA that enjoins the Registrar to keep the data collected safe and sound. And one that enjoins the Registrar to share it, as necessary and requested, with a court of lawful jurisdiction.
I personally don't see how one can say a registered name holder is '*identified and identifiable*' without verification of the elements used to establish identity. I also know that knowingly sending inaccurate data to a court of lawful jurisdiction is, in some [common law] jurisdictions, deemed an abuse of process and contempt of court.
Interestingly, there is a clause in the RAA that enjoins a Registrar not to activate a name until they are sure of payment! That same rule devolved and applied to establishing identity is a no brainer. But nooooooo.....
Carlton ============================== *Carlton A Samuels*
*Mobile: 876-818-1799Strategy, Process, Governance, Assessment & Turnaround* =============================
On Wed, Feb 3, 2021 at 10:27 AM Laurin B Weissinger via CPWG < cpwg@icann.org> wrote:
Dear all,
My comments, adding onto Johanna’s:
Keeping these in mind the proposed definition and scope of DNS Abuse strikes as arbitrary: what were the criteria set for selecting these specific categories as DNS Abuse while leaving other potential categories out?
The perspective I am getting from SSR2 is to start with the obvious, technically detectable ones: phishing, C2, plus reports of those. Essentially, stop crimes in progress that do not require complicated and long human oversight.
I am worried about including issues that are private disputes. Even if many use Copyright to stop crimes in progress, as it is the only thing that works. (Consider how insane this is: I need to use the fact that someone is using my logo not as evidence but as a CR issue to stop an actual crime in progress.)
Including IP infringement on equal footing with CSAM raises serious concerns among At-Large members
Absolutely agree with Johanna on the CSAM aspect. It is, imho, ridiculous and more so offensive to name _private_ copyright _disputes_ alongside CSAM.*
Again, speaking from SSR2 experience: focus can be put on forcing immediate review in case of reports, allowing bulk reports, introducing hurdles for criminals on registration, pre-review of suspicious names, etc. (I.e. do things that reduce abuse before it happens)
All the best Laurin
* Indeed, beyond this being ethically and morally unacceptable, companies (not gonna name names) use copyright complaints to silence their critics (free speech issue), arguably themselves being abusers of the system, at least in some cases.
On Wed, Feb 3, 2021 at 15:49, Jonathan Zuck <JZuck@innovatorsnetwork.org> wrote:
Evin has suggested that I had, perhaps, NOT forwarded this to the group. Here’s the discussion thread, initiated by Keith Drazek on the Contracted Party House DNS Abuse Work Group. This includes, Joanna’s expression of mission creep concern.
Jonathan
Jonathan Zuck
Executive Director
Innovators Network Foundation
www.InnovatorsNetwork.org
*From: *Joanna Kulesza <jkuleszaicann@gmail.com> *Sent: *Wednesday, January 27, 2021 2:12 AM *To: *Maureen Hilyard <maureen.hilyard@gmail.com>; Jonathan Zuck <JZuck@innovatorsnetwork.org> *Subject: *Re: Engagement on DNS Abuse
Great stuff Jonathan, as always. Feel free to share. If I were to add my two cents, I'd put these in the "pain points" section while these are of a more general nature.
"From the discussions we've had within At-Large it is clear that the very scope and definition of DNS Abuse is a "pain point". This was also the take away from the discussions we've had with the invited guests from within and beyond the ICANN community. "DNS Abuse" as it is now defined in the proposed Framework affects the entire internet community of end users while being already covered by existing national and international norms and standards. Keeping these in mind the proposed definition and scope of DNS Abuse strikes as arbitrary: what were the criteria set for selecting these specific categories as DNS Abuse while leaving other potential categories out?
This is particularly relevant with regard to our second concern: the proposed scope of DNS Abuse clearly crosses the content "picket fence" that the ICANN community had set for itself. Including IP infringement on equal footing with CSAM raises serious concerns among At-Large members. We are concerned not only with the very fact of the picket fence being crossed but also by the way in which this is being done. Does this mean we should finally abandon the well established yet always controversial narrative of a strictly technical infrastructure management?
Once content is concerned, the existing and proposed practice fails to recognize international legal safeguards when it comes to restrictions put on individual freedoms. Whenever an individual liberty is to be restricted, due process must be ensured. The procedures proposed by the DNS Abuse framework fail to ensure e.g. a right to an effective legal remedy. While we realize this argument brings us back tot he general discussion on limits of ICANN's contractual jurisdiction, that is an argument we would be interested to during any upcoming DNS Abuse work.
Only once these concerns relating to the scope of the definition of DNS Abuse can be addressed, can we focus on metrics and effective enforcement that will provide a fair and operational framework protecting the rights of end users."
By all means to feel free to rephrase!:) What I'm arguing for is that for us to be able to "measure" DNS Abuse we should first clearly and transparently decide what it means. The current framework means the contracted parties are indeed trying to play a self-proclaimed internet police (militia?). Why did we presume DNS Abuse is CSAM and (in the same breath) fake Gucci bags but not hate speech and inciting violence? While we clearly would not have the answer ready, that is definitely a discussion we should have. The GAC might be interested in this as well (see last update from Veni on the ITU processes).
Thanks for considering team!
Best,
J.
W dniu 27.01.2021 o 01:39, Maureen Hilyard pisze:
In your inimitable style. Love it. Send it.
M
On Tue, Jan 26, 2021 at 12:34 PM Jonathan Zuck < JZuck@innovatorsnetwork.org> wrote:
Ladies,
Here’s my draft response. Let me know what you think!
Jonathan
=============================================================
Hey folks! Thanks for reaching out. Joanna and I, for sure, would be willing to join you and I suspect others, as well, once we know the timing. With respect to the questions below, I’ll do my best to provide some initial responses but I suspect the first question might be pivotal. There seems to be a lack of real data on the topic and perhaps some additional objective research is the answers. We endeavored to begin this process, during the CCTRT (sadag-final-09aug17-en.pdf (icann.org) <https://www.icann.org/en/system/files/files/sadag-final-09aug17-en.pdf>, but obviously barely scratched the surface. Perhaps a more comprehensive study, funded by ICANN rather than the CPH or CSG might be in order? I know DAAR provides some answers but it seems to be more of a survey than an example of rigorous research. Specifically to your questions.
1. *What information do you use and how do you use it to assess DNS Abuse levels?* This is obviously where we are weak. There doesn’t appear to be a great source for DNS Abuse “levels,” particularly because of the short time period over which a particular initiative takes place. A snapshot analysis doesn’t seem to get the full picture. The ALAC relies on the concerned raised by the GAC and the SSAC to fuel our belief that there’s more we should be doing. A recent report from Microsoft suggests the problem is bigger than we realize and David Taylor’s analysis of “responsiveness,” even among those who have signed onto the framework, seems damning. 2. *What are the ALAC’s pain points regarding DNS Abuse?* Not sure to answer this in terms of how it’s handled inside ICANN or more generally from where our interests stems. To the latter point, we’re tasked with advancing the interests of those not represented by a constituency in the GNSO, namely those engaged in everyday use of the internet, as opposed to registrants. As the user base continues to grow, as we all desire, so too will the numbers of less sophisticated users, more easily duped by a phishing, malware or fraudulent advertising attack. As for the situation inside ICANN, the At-Large community have attempted to engage constructively as opposed to “attacking” the CPH, focusing instead on so-called “bad actors.” The first session <https://community.icann.org/display/atlarge/At-Large+Meetings+-+Monday%2C+09+March+2020?preview=/124847126/126428447/CCWholistic02.pdf> was an attempt to bring the CPH and Contract Compliance into the same room to figure out where the holes are.
1. *What exactly are the relevant limits on Contract Compliance? *We feel this is a question which comes up constantly and is never successfully or consistently answered. It seems to be an area in which the ICANN community is constantly chasing it’s tail. It would seem that the only real enforced contract provision is payment. I’m sure this is an exaggeration but it seems to be a repeated situation where that is ultimately what foils a “ bad actor” after YEARS of neglect, if not outright facilitation of abuse. The answer to THIS question should be a HIGH priority. It might just be agreeing to an interpretation of the contracts or it might require an amendment to the contracts but this issue needs to stop being a merry go round. 2. *Insufficient Transparency from Contract Compliance *Contract Compliance undocumented endeavors at soft touch diplomacy with bad actors seem to need some better limits or, at least, transparency. For “the market” to play a role in this, knowing about legitimate complaints for every contracted party could help customers make better decisions about which businesses to use and help us better understand where policy development needs to take place. 3. *Deflection and Minimization of the Problem *I would say that one “pain point” is that our efforts have been largely “trolled” by certain members of the CPH, rather than engaging constructively. EVEN our effort to conceive of some sort of end user education campaign, to take the pressure off the CPH, was trolled. Jim, not to put you on the spot but, during one conversation, you said you didn’t even understand why this was being discussed because it affects such a small percentage of registered names. To date, we have proposed:
*i.* *Better contract enforcement*
*ii.* *More tools for Contract Compliance*
*iii.* *DNS Abuse “threshold,” an idea that found some support among the CPH at one point*
*iv.* *Predictive Analytics platform, perhaps financed by ICANN*
The At-Large community has *absolutely* no desire to over regulate or over tax the CPH and we understand most of the contracted parties, particularly those showing up to meetings, are trying to do well and continuously improve. That said, this notion that it’s somehow not “our place,” to be trying to help is nothing short of offensive. It is the active participation of the ALAC and GAC that enable the ICANN to portray itself as something other than a trade association. The At-Large mandate is to advance the interests of those MOST impacted by DNS Abuse. That said, we WELCOME suggestions on how better to engage with the CPH for constructive outcomes.
1. *Are you seeing practices from registrars or registries you find helpful?* If we haven’t said it enough, the At-Large appreciates the efforts of those behind the Framework for DNS Abuse and the huge efforts that went into cooperation with law enforcement to track down COVID related abuse. We’d love to see the framework evolve to include specific commitments and metrics, however, for it to be something on which the community could truly rely.
We hope these answers are constructive and not inflammatory as it is our intention to find the most effective ways to proceed to further minimize the incidence of DNS Abuse , in all its forms. Thanks for the opportunity to be part of your conversation.
Maureen, Joanna & Jonathan
*From: *Keith Drazek <kdrazek@verisign.com> *Date: *Friday, January 22, 2021 at 12:00 PM *To: *"maureen.hilyard@gmail.com" <maureen.hilyard@gmail.com>, Jonathan Zuck <JZuck@innovatorsnetwork.org>, "jkuleszaicann@gmail.com" < jkuleszaicann@gmail.com> *Cc: *"Brian F. Cimbolic" <BCimbolic@pir.org>, Jim Galvin < jgalvin@afilias.info>, Graeme Bunton <gbunton@tucows.com> *Subject: *Engagement on DNS Abuse
Hello Maureen, Jonathan and Joanna,
I hope you’re all doing well and staying healthy and safe. I am reaching out to you on behalf of the Contracted Party House DNS Abuse Working Group as we look ahead to ICANN 70 and the rest of 2021.
The Contracted Party House (CPH) DNS Abuse Group is conducting outreach to our friends in other SO/AC/SG/Cs regarding DNS Abuse. As previously noted by the CPH, DNS Abuse <https://rrsg.org/wp-content/uploads/2020/10/CPH-Definition-of-DNS-Abuse.pdf> comprises five categories: phishing, pharming, malware, botnets, and spam when it acts as a delivery mechanism for one of the other forms of DNS Abuse.
We want to open a more direct dialogue to understand pain points, hear suggestions and identify common ground where we can work together to mitigate DNS Abuse. Is there a subset of the At-Large focusing on DNS Abuse questions that would be able to join the CPH DNS Abuse group on a call to discuss this topic? We want to encourage frank and productive discussions on the topic that lead to really informing our dialogues and actions.
As a starting point, we propose the following questions to guide our discussion. Are there any other questions ALAC would like discuss?:
What information do you use and how do you use it to assess DNS Abuse levels?
What are the ALAC’s pain points regarding DNS Abuse?
Are you seeing practices from registrars or registries you find helpful?
Please let us know if a subgroup of the ALAC would be willing to join us. Our group meets regularly on Tuesdays at 1500 UTC. If so, please propose a Tuesday when you are available.
Best regards,
Keith
Keith Drazek
Vice President, Public Policy & Government Relations
Verisign, Inc.
+1-571-377-9182
Kdrazek@verisign.com
--
Kind regards,
Joanna Kulesza
-------------------
Joanna Kulesza, PhD
University of Lodz, Poland
ICANN ALAC Vice Chair
SOI: https://community.icann.org/display/atlarge/Joanna+Kulesza+SOI
TT: @KuleszaJ
_______________________________________________ CPWG mailing list CPWG@icann.org https://mm.icann.org/mailman/listinfo/cpwg
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
On 03/02/2021 14:49, Jonathan Zuck wrote:
Evin has suggested that I had, perhaps, NOT forwarded this to the group. Here’s the discussion thread, initiated by Keith Drazek on the Contracted Party House DNS Abuse Work Group. This includes, Joanna’s expression of mission creep concern.
It looks like the term "DNS Abuse" has been arrived at but the scope is still unclear. The mission creep angle is important. Without a clear definition of what constitutes DNS Abuse, the conversation is just going to go round in circles. The DAAR and other approaches rely upon reporting. The majority of the blacklists it uses seem to depend on reporting rather than detection. This means that potentially only a small part of the problem is identified. Moving from a reporting model to a detection model is difficult and given the limited resources and expertise of ICANN, it would not be possible for ICANN to monitor all websites for a detection based model. And the definition of DNS Abuse also, I think, covers e-mail spam and DDoS. So not only would a detection based system have to cover websites, it would also have to cover DNS and mailserver monitoring. The snapshot point mentioned in the thread is a good one because it will miss the transition of latent bad actor domain names to actively abusive domain names/websites. With website detection, the problem is one of depth rather than width. The number of active websites (non-templated PPC/parking/holding content) in most well used TLDs is around 30%. Some of the new gTLDs have active site levels below 10%. The ccTLDs generally have a higher active usage %. When it gets to problems like phishing, the phishing is often done in a subdirectory of the main website and may not be accessible from the site's links. Problem websites involving Intellectual Property are often quite obvious. The low registration fee of some of the zone-stuffer new gTLDs has facilitated a shift of much of this kind of activity from the legacy gTLDs. (This was mentioned in the (SIDN?) study that the CCT cited.) The definition of "DNS Abuse" needs to be clear. Then it needs to be quantified. Making registries and registrars responsible for the problem may seem like a good approach when the definition of the problem and the scale of the problem are unknown. It is not a good approach. Putting registries and registrars in the position of having to monitor and deal with everything changes their position from being effectively "common carriers" to one where they are in a position of editorial control. With Section 230 of the CDA in the US coming up for review, that could put the registries, registrars and ultimately ICANN (it still is a US company) in some bother if S230 is revoked or amended. The current model of having registrars and registries take action on serious problems but leaving the IP issues to the lawyers to sort out is probably the best one at the moment and it is working. The inclusion of "hate speech" as DNS Abuse is serious mission creep because it is a highly subjective issue. Leave that to the local legislative frameworks. The comments in that e-mail about defining the issue are important. The worst thing that could be done is for everyone to go off with their own definition of what should constitute DNS Abuse and then start arguing about why their view matters more than others. ALAC and the other parties will end up with years of futile arguments while little or nothing will be done to solve the problems. And as a bonus, the threat landscape of DNS Abuse is continually changing as new techiques are developed and older ones fall out of use. (e.g link injection (monetisation of abuse) on websites overtaking website defacements (ego/political abuse)) The Precog approach with predictive analytics may sound impressive but the reality is that to be effective, it would need more than the past history of registrants. That brings up the concept of bad registrars and bad TLDs. Getting access to some of the financial data for a better predictive model might not be possible due to registries and registrars having multi-jurisdictional markets. Anecdotally, many mailserver admins have taken to blocking the new gTLDs on their servers because all they see from them is spam. URLs from some heavily discounted new gTLDs in some ccTLD or country level web usage surveys are strong indications of a compromised website. It would appear that the fact that a boom and bust model of heavily discounted registration fees would result in abusive registrations was ignored in the 2013 round. Unfortunately, it was all too obvious to people who have to deal with the results. But then ICANN's numerology projections cluelessly expected 35 millon new gTLD registrations in the first year. A minimum resale price would be one way of limiting the effect of organised DNS Abuse but it might directly impact the financial viability of some gTLDs in future rounds. Existing gTLD operators would also object as the boom and bust model is their only model since Brand Protection registrations were effectively taken out of their projections. Without the guaranteed revenue from brand protection registrations, some of the new gTLDs didn't have much of a market left. Regards...jmcc -- ********************************************************** John McCormac * e-mail: jmcc@hosterstats.com MC2 * web: http://www.hosterstats.com/ 22 Viewmount * Domain Registrations Statistics Waterford * Domnomics - the business of domain names Ireland * https://amzn.to/2OPtEIO IE * Skype: hosterstats.com ********************************************************** -- This email has been checked for viruses by AVG. https://www.avg.com
Good email John, covers a lot. While price is a factor, lets not forget that threat actors like Emotet were responsible for 36-40% of all malware distribution for many years. This crime as a service operator was doing pretty well into hacking Wordpress installations of legitimate domain name owners with a Wordpress installation. The CPH DNS Abuse framework is pragmatic in the sense that it covers what CPH's can do on their technical level. However, the reality is a lot of cybercrime cannot be addressed on the CPH technical level. We currently ingest 72 blocklists and cyber intelligence feeds and our current reality is that 2% is pure domain name abuse, 6% is on a hostname level and 92% is URL/Content abuse. Our data goes till 2014. URL/content abuse is very problematic to address (often impossible) as a registrar and as many of you heard the reasons for many years I am not going to repeat them. But as a community we need to be very sensible and not conflate all kinds of abuse and indeed get a good understanding what is DNS Abuse and what can actually be done within the ICANN remit and be realistic of the technical reality what CPH's can do. If we want to remain relevant on this topic we need to push ahead and come up with solutions that address the issues we actually can address. Best, Theo On Wed, Feb 3, 2021, at 4:46 PM, John McCormac wrote:
On 03/02/2021 14:49, Jonathan Zuck wrote:
Evin has suggested that I had, perhaps, NOT forwarded this to the group. Here’s the discussion thread, initiated by Keith Drazek on the Contracted Party House DNS Abuse Work Group. This includes, Joanna’s expression of mission creep concern.
It looks like the term "DNS Abuse" has been arrived at but the scope is still unclear. The mission creep angle is important. Without a clear definition of what constitutes DNS Abuse, the conversation is just going to go round in circles.
The DAAR and other approaches rely upon reporting. The majority of the blacklists it uses seem to depend on reporting rather than detection. This means that potentially only a small part of the problem is identified. Moving from a reporting model to a detection model is difficult and given the limited resources and expertise of ICANN, it would not be possible for ICANN to monitor all websites for a detection based model. And the definition of DNS Abuse also, I think, covers e-mail spam and DDoS. So not only would a detection based system have to cover websites, it would also have to cover DNS and mailserver monitoring. The snapshot point mentioned in the thread is a good one because it will miss the transition of latent bad actor domain names to actively abusive domain names/websites.
With website detection, the problem is one of depth rather than width. The number of active websites (non-templated PPC/parking/holding content) in most well used TLDs is around 30%. Some of the new gTLDs have active site levels below 10%. The ccTLDs generally have a higher active usage %. When it gets to problems like phishing, the phishing is often done in a subdirectory of the main website and may not be accessible from the site's links.
Problem websites involving Intellectual Property are often quite obvious. The low registration fee of some of the zone-stuffer new gTLDs has facilitated a shift of much of this kind of activity from the legacy gTLDs. (This was mentioned in the (SIDN?) study that the CCT cited.)
The definition of "DNS Abuse" needs to be clear. Then it needs to be quantified.
Making registries and registrars responsible for the problem may seem like a good approach when the definition of the problem and the scale of the problem are unknown. It is not a good approach.
Putting registries and registrars in the position of having to monitor and deal with everything changes their position from being effectively "common carriers" to one where they are in a position of editorial control. With Section 230 of the CDA in the US coming up for review, that could put the registries, registrars and ultimately ICANN (it still is a US company) in some bother if S230 is revoked or amended. The current model of having registrars and registries take action on serious problems but leaving the IP issues to the lawyers to sort out is probably the best one at the moment and it is working.
The inclusion of "hate speech" as DNS Abuse is serious mission creep because it is a highly subjective issue. Leave that to the local legislative frameworks.
The comments in that e-mail about defining the issue are important. The worst thing that could be done is for everyone to go off with their own definition of what should constitute DNS Abuse and then start arguing about why their view matters more than others. ALAC and the other parties will end up with years of futile arguments while little or nothing will be done to solve the problems. And as a bonus, the threat landscape of DNS Abuse is continually changing as new techiques are developed and older ones fall out of use. (e.g link injection (monetisation of abuse) on websites overtaking website defacements (ego/political abuse))
The Precog approach with predictive analytics may sound impressive but the reality is that to be effective, it would need more than the past history of registrants. That brings up the concept of bad registrars and bad TLDs. Getting access to some of the financial data for a better predictive model might not be possible due to registries and registrars having multi-jurisdictional markets.
Anecdotally, many mailserver admins have taken to blocking the new gTLDs on their servers because all they see from them is spam. URLs from some heavily discounted new gTLDs in some ccTLD or country level web usage surveys are strong indications of a compromised website.
It would appear that the fact that a boom and bust model of heavily discounted registration fees would result in abusive registrations was ignored in the 2013 round. Unfortunately, it was all too obvious to people who have to deal with the results. But then ICANN's numerology projections cluelessly expected 35 millon new gTLD registrations in the first year.
A minimum resale price would be one way of limiting the effect of organised DNS Abuse but it might directly impact the financial viability of some gTLDs in future rounds. Existing gTLD operators would also object as the boom and bust model is their only model since Brand Protection registrations were effectively taken out of their projections. Without the guaranteed revenue from brand protection registrations, some of the new gTLDs didn't have much of a market left.
Regards...jmcc -- ********************************************************** John McCormac * e-mail: jmcc@hosterstats.com MC2 * web: http://www.hosterstats.com/ 22 Viewmount * Domain Registrations Statistics Waterford * Domnomics - the business of domain names Ireland * https://amzn.to/2OPtEIO IE * Skype: hosterstats.com **********************************************************
-- This email has been checked for viruses by AVG. https://www.avg.com
_______________________________________________ CPWG mailing list CPWG@icann.org https://mm.icann.org/mailman/listinfo/cpwg
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi Jonathan and Joanna, A few comments on scope: - I feel the need to periodically remind my colleagues that ALAC's scope is whatever it deems to be in scope. The ICANN bylaws explicitly do not limit the subject matter on which we can comment in the manner that SOs are. We are able to advise the Board on policy, on operations, on core values, on budget, and indeed on scope. I reject the arbitrary imposition of limitations upon what we can comment based on the limitations placed on (or assumed by) other ICANN sub-communities. If there is something that ALAC deems is (a) important to end users and (b) addressable by ICANN then it's in-scope. *We* are the sole arbitrators of what is important to us, and I find it intensely frustrating when ALAC muzzles itself in order to be synchronized with the self-imposed limits of others. - In response to the question: "*Does this mean we should finally abandon the well established yet always controversial narrative of a strictly technical infrastructure management?*" I answer: That ship sailed long ago and is now on the ocean floor. Anyone who believes that ICANN adheres to a strictly technical mandate -- or even pretends to -- has not been following its history very deeply. From the money-driven decisions on expanding the number of gTLDs, to the utterly political decisions about the "appropriateness" of artifacts such as .XXX or vertical integration or closed generics, to philosophical issues such as the balance between registrant privacy versus accountability, ICANN long ago shed any pretense of purely technical function. Most recently, the admonishment of ICANN on the issue of the .ORG transfer by its overseer (the California Attorney General) demonstrates beyond doubt that societal expectations of ICANN's function go WELL beyond the purely technical. By all means let's be clear on what we mean by "DNS Abuse"; without clarity we won't have the necessary focus and our resulting advice will be easily ignored. But let's not artificially constrain ourselves in advance. Cheers, Evan Leibovitch, Toronto Canada @evanleibovitch / @el56 On Wed, 3 Feb 2021 at 09:50, Jonathan Zuck <JZuck@innovatorsnetwork.org> wrote:
Evin has suggested that I had, perhaps, NOT forwarded this to the group. Here’s the discussion thread, initiated by Keith Drazek on the Contracted Party House DNS Abuse Work Group. This includes, Joanna’s expression of mission creep concern.
Jonathan
Jonathan Zuck
Executive Director
Innovators Network Foundation
www.InnovatorsNetwork.org
*From: *Joanna Kulesza <jkuleszaicann@gmail.com> *Sent: *Wednesday, January 27, 2021 2:12 AM *To: *Maureen Hilyard <maureen.hilyard@gmail.com>; Jonathan Zuck <JZuck@innovatorsnetwork.org> *Subject: *Re: Engagement on DNS Abuse
Great stuff Jonathan, as always. Feel free to share. If I were to add my two cents, I'd put these in the "pain points" section while these are of a more general nature.
"From the discussions we've had within At-Large it is clear that the very scope and definition of DNS Abuse is a "pain point". This was also the take away from the discussions we've had with the invited guests from within and beyond the ICANN community. "DNS Abuse" as it is now defined in the proposed Framework affects the entire internet community of end users while being already covered by existing national and international norms and standards. Keeping these in mind the proposed definition and scope of DNS Abuse strikes as arbitrary: what were the criteria set for selecting these specific categories as DNS Abuse while leaving other potential categories out?
This is particularly relevant with regard to our second concern: the proposed scope of DNS Abuse clearly crosses the content "picket fence" that the ICANN community had set for itself. Including IP infringement on equal footing with CSAM raises serious concerns among At-Large members. We are concerned not only with the very fact of the picket fence being crossed but also by the way in which this is being done. Does this mean we should finally abandon the well established yet always controversial narrative of a strictly technical infrastructure management?
Once content is concerned, the existing and proposed practice fails to recognize international legal safeguards when it comes to restrictions put on individual freedoms. Whenever an individual liberty is to be restricted, due process must be ensured. The procedures proposed by the DNS Abuse framework fail to ensure e.g. a right to an effective legal remedy. While we realize this argument brings us back tot he general discussion on limits of ICANN's contractual jurisdiction, that is an argument we would be interested to during any upcoming DNS Abuse work.
Only once these concerns relating to the scope of the definition of DNS Abuse can be addressed, can we focus on metrics and effective enforcement that will provide a fair and operational framework protecting the rights of end users."
By all means to feel free to rephrase!:) What I'm arguing for is that for us to be able to "measure" DNS Abuse we should first clearly and transparently decide what it means. The current framework means the contracted parties are indeed trying to play a self-proclaimed internet police (militia?). Why did we presume DNS Abuse is CSAM and (in the same breath) fake Gucci bags but not hate speech and inciting violence? While we clearly would not have the answer ready, that is definitely a discussion we should have. The GAC might be interested in this as well (see last update from Veni on the ITU processes).
Thanks for considering team!
Best,
J.
W dniu 27.01.2021 o 01:39, Maureen Hilyard pisze:
In your inimitable style. Love it. Send it.
M
On Tue, Jan 26, 2021 at 12:34 PM Jonathan Zuck < JZuck@innovatorsnetwork.org> wrote:
Ladies,
Here’s my draft response. Let me know what you think!
Jonathan
=============================================================
Hey folks! Thanks for reaching out. Joanna and I, for sure, would be willing to join you and I suspect others, as well, once we know the timing. With respect to the questions below, I’ll do my best to provide some initial responses but I suspect the first question might be pivotal. There seems to be a lack of real data on the topic and perhaps some additional objective research is the answers. We endeavored to begin this process, during the CCTRT (sadag-final-09aug17-en.pdf (icann.org) <https://www.icann.org/en/system/files/files/sadag-final-09aug17-en.pdf>, but obviously barely scratched the surface. Perhaps a more comprehensive study, funded by ICANN rather than the CPH or CSG might be in order? I know DAAR provides some answers but it seems to be more of a survey than an example of rigorous research. Specifically to your questions.
1. *What information do you use and how do you use it to assess DNS Abuse levels?* This is obviously where we are weak. There doesn’t appear to be a great source for DNS Abuse “levels,” particularly because of the short time period over which a particular initiative takes place. A snapshot analysis doesn’t seem to get the full picture. The ALAC relies on the concerned raised by the GAC and the SSAC to fuel our belief that there’s more we should be doing. A recent report from Microsoft suggests the problem is bigger than we realize and David Taylor’s analysis of “responsiveness,” even among those who have signed onto the framework, seems damning. 2. *What are the ALAC’s pain points regarding DNS Abuse?* Not sure to answer this in terms of how it’s handled inside ICANN or more generally from where our interests stems. To the latter point, we’re tasked with advancing the interests of those not represented by a constituency in the GNSO, namely those engaged in everyday use of the internet, as opposed to registrants. As the user base continues to grow, as we all desire, so too will the numbers of less sophisticated users, more easily duped by a phishing, malware or fraudulent advertising attack. As for the situation inside ICANN, the At-Large community have attempted to engage constructively as opposed to “attacking” the CPH, focusing instead on so-called “bad actors.” The first session <https://community.icann.org/display/atlarge/At-Large+Meetings+-+Monday%2C+09+March+2020?preview=/124847126/126428447/CCWholistic02.pdf> was an attempt to bring the CPH and Contract Compliance into the same room to figure out where the holes are.
1. *What exactly are the relevant limits on Contract Compliance? *We feel this is a question which comes up constantly and is never successfully or consistently answered. It seems to be an area in which the ICANN community is constantly chasing it’s tail. It would seem that the only real enforced contract provision is payment. I’m sure this is an exaggeration but it seems to be a repeated situation where that is ultimately what foils a “ bad actor” after YEARS of neglect, if not outright facilitation of abuse. The answer to THIS question should be a HIGH priority. It might just be agreeing to an interpretation of the contracts or it might require an amendment to the contracts but this issue needs to stop being a merry go round. 2. *Insufficient Transparency from Contract Compliance *Contract Compliance undocumented endeavors at soft touch diplomacy with bad actors seem to need some better limits or, at least, transparency. For “the market” to play a role in this, knowing about legitimate complaints for every contracted party could help customers make better decisions about which businesses to use and help us better understand where policy development needs to take place. 3. *Deflection and Minimization of the Problem *I would say that one “pain point” is that our efforts have been largely “trolled” by certain members of the CPH, rather than engaging constructively. EVEN our effort to conceive of some sort of end user education campaign, to take the pressure off the CPH, was trolled. Jim, not to put you on the spot but, during one conversation, you said you didn’t even understand why this was being discussed because it affects such a small percentage of registered names. To date, we have proposed:
*i.* *Better contract enforcement*
*ii.* *More tools for Contract Compliance*
*iii.* *DNS Abuse “threshold,” an idea that found some support among the CPH at one point*
*iv.* *Predictive Analytics platform, perhaps financed by ICANN*
The At-Large community has *absolutely* no desire to over regulate or over tax the CPH and we understand most of the contracted parties, particularly those showing up to meetings, are trying to do well and continuously improve. That said, this notion that it’s somehow not “our place,” to be trying to help is nothing short of offensive. It is the active participation of the ALAC and GAC that enable the ICANN to portray itself as something other than a trade association. The At-Large mandate is to advance the interests of those MOST impacted by DNS Abuse. That said, we WELCOME suggestions on how better to engage with the CPH for constructive outcomes.
1. *Are you seeing practices from registrars or registries you find helpful?* If we haven’t said it enough, the At-Large appreciates the efforts of those behind the Framework for DNS Abuse and the huge efforts that went into cooperation with law enforcement to track down COVID related abuse. We’d love to see the framework evolve to include specific commitments and metrics, however, for it to be something on which the community could truly rely.
We hope these answers are constructive and not inflammatory as it is our intention to find the most effective ways to proceed to further minimize the incidence of DNS Abuse , in all its forms. Thanks for the opportunity to be part of your conversation.
Maureen, Joanna & Jonathan
*From: *Keith Drazek <kdrazek@verisign.com> *Date: *Friday, January 22, 2021 at 12:00 PM *To: *"maureen.hilyard@gmail.com" <maureen.hilyard@gmail.com>, Jonathan Zuck <JZuck@innovatorsnetwork.org>, "jkuleszaicann@gmail.com" < jkuleszaicann@gmail.com> *Cc: *"Brian F. Cimbolic" <BCimbolic@pir.org>, Jim Galvin < jgalvin@afilias.info>, Graeme Bunton <gbunton@tucows.com> *Subject: *Engagement on DNS Abuse
Hello Maureen, Jonathan and Joanna,
I hope you’re all doing well and staying healthy and safe. I am reaching out to you on behalf of the Contracted Party House DNS Abuse Working Group as we look ahead to ICANN 70 and the rest of 2021.
The Contracted Party House (CPH) DNS Abuse Group is conducting outreach to our friends in other SO/AC/SG/Cs regarding DNS Abuse. As previously noted by the CPH, DNS Abuse <https://rrsg.org/wp-content/uploads/2020/10/CPH-Definition-of-DNS-Abuse.pdf> comprises five categories: phishing, pharming, malware, botnets, and spam when it acts as a delivery mechanism for one of the other forms of DNS Abuse.
We want to open a more direct dialogue to understand pain points, hear suggestions and identify common ground where we can work together to mitigate DNS Abuse. Is there a subset of the At-Large focusing on DNS Abuse questions that would be able to join the CPH DNS Abuse group on a call to discuss this topic? We want to encourage frank and productive discussions on the topic that lead to really informing our dialogues and actions.
As a starting point, we propose the following questions to guide our discussion. Are there any other questions ALAC would like discuss?:
What information do you use and how do you use it to assess DNS Abuse levels?
What are the ALAC’s pain points regarding DNS Abuse?
Are you seeing practices from registrars or registries you find helpful?
Please let us know if a subgroup of the ALAC would be willing to join us. Our group meets regularly on Tuesdays at 1500 UTC. If so, please propose a Tuesday when you are available.
Best regards,
Keith
Keith Drazek
Vice President, Public Policy & Government Relations
Verisign, Inc.
+1-571-377-9182
Kdrazek@verisign.com
--
Kind regards,
Joanna Kulesza
-------------------
Joanna Kulesza, PhD
University of Lodz, Poland
ICANN ALAC Vice Chair
SOI: https://community.icann.org/display/atlarge/Joanna+Kulesza+SOI
TT: @KuleszaJ
_______________________________________________ CPWG mailing list CPWG@icann.org https://mm.icann.org/mailman/listinfo/cpwg
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi all I agree with Evan on both points. Indeed the scope of the advice of ALAC does not have the limits that are imposed on other bodies, like the SOs. This because it is advice, and not a binding decision. And agree as well about the strictly technical mandate of ICANN. Quoting one of Evan’s examples, the new gTLDs, there were just a couple of things that were within that remit, like the study on how many TLDs could be introduced with no risk for the root - and how fast this could be done - or issues about collision with widely used keywords. All the rest has nothing to do with technical issues. If somebody can explain to me what is technical about, for instance, whether large non-capital cities should have their name reserved or not, I might change my mind - but until then I remain convinced that the footprint of ICANN expands well beyond a coordination of technical issues. Cheers, Roberto PS: since Evan mentions it, my opinion about .XXX is that it should not have been delegated for the simple reason that it violated one key condition for sponsored TLDs: evidence of consensus of the served community - and we have received, as Board, many statements from parts of the adult industry who disagreed (for a number of reasons) with the delegation of .XXX. Initially the Board denied delegation, but later (but I was already off the Board) changed the opinion - some folks hinted that it was for fear of lawsuits. But the question is: what was the impact of that decision on the technical infrastructure management? Who is ICANN to have the power to decide yes or no?
On 03.02.2021, at 19:01, Evan Leibovitch <evan@telly.org> wrote:
Hi Jonathan and Joanna,
A few comments on scope: I feel the need to periodically remind my colleagues that ALAC's scope is whatever it deems to be in scope. The ICANN bylaws explicitly do not limit the subject matter on which we can comment in the manner that SOs are. We are able to advise the Board on policy, on operations, on core values, on budget, and indeed on scope. I reject the arbitrary imposition of limitations upon what we can comment based on the limitations placed on (or assumed by) other ICANN sub-communities. If there is something that ALAC deems is (a) important to end users and (b) addressable by ICANN then it's in-scope. We are the sole arbitrators of what is important to us, and I find it intensely frustrating when ALAC muzzles itself in order to be synchronized with the self-imposed limits of others.
In response to the question: "Does this mean we should finally abandon the well established yet always controversial narrative of a strictly technical infrastructure management?" I answer: That ship sailed long ago and is now on the ocean floor. Anyone who believes that ICANN adheres to a strictly technical mandate -- or even pretends to -- has not been following its history very deeply. From the money-driven decisions on expanding the number of gTLDs, to the utterly political decisions about the "appropriateness" of artifacts such as .XXX or vertical integration or closed generics, to philosophical issues such as the balance between registrant privacy versus accountability, ICANN long ago shed any pretense of purely technical function. Most recently, the admonishment of ICANN on the issue of the .ORG transfer by its overseer (the California Attorney General) demonstrates beyond doubt that societal expectations of ICANN's function go WELL beyond the purely technical. By all means let's be clear on what we mean by "DNS Abuse"; without clarity we won't have the necessary focus and our resulting advice will be easily ignored. But let's not artificially constrain ourselves in advance.
Cheers,
Evan Leibovitch, Toronto Canada @evanleibovitch / @el56
On Wed, 3 Feb 2021 at 09:50, Jonathan Zuck <JZuck@innovatorsnetwork.org <mailto:JZuck@innovatorsnetwork.org>> wrote: Evin has suggested that I had, perhaps, NOT forwarded this to the group. Here’s the discussion thread, initiated by Keith Drazek on the Contracted Party House DNS Abuse Work Group. This includes, Joanna’s expression of mission creep concern.
Jonathan
Jonathan Zuck
Executive Director
Innovators Network Foundation
www.InnovatorsNetwork.org <http://www.innovatorsnetwork.org/>
From: Joanna Kulesza <mailto:jkuleszaicann@gmail.com> Sent: Wednesday, January 27, 2021 2:12 AM To: Maureen Hilyard <mailto:maureen.hilyard@gmail.com>; Jonathan Zuck <mailto:JZuck@innovatorsnetwork.org> Subject: Re: Engagement on DNS Abuse
Great stuff Jonathan, as always. Feel free to share. If I were to add my two cents, I'd put these in the "pain points" section while these are of a more general nature.
"From the discussions we've had within At-Large it is clear that the very scope and definition of DNS Abuse is a "pain point". This was also the take away from the discussions we've had with the invited guests from within and beyond the ICANN community. "DNS Abuse" as it is now defined in the proposed Framework affects the entire internet community of end users while being already covered by existing national and international norms and standards. Keeping these in mind the proposed definition and scope of DNS Abuse strikes as arbitrary: what were the criteria set for selecting these specific categories as DNS Abuse while leaving other potential categories out?
This is particularly relevant with regard to our second concern: the proposed scope of DNS Abuse clearly crosses the content "picket fence" that the ICANN community had set for itself. Including IP infringement on equal footing with CSAM raises serious concerns among At-Large members. We are concerned not only with the very fact of the picket fence being crossed but also by the way in which this is being done. Does this mean we should finally abandon the well established yet always controversial narrative of a strictly technical infrastructure management?
Once content is concerned, the existing and proposed practice fails to recognize international legal safeguards when it comes to restrictions put on individual freedoms. Whenever an individual liberty is to be restricted, due process must be ensured. The procedures proposed by the DNS Abuse framework fail to ensure e.g. a right to an effective legal remedy. While we realize this argument brings us back tot he general discussion on limits of ICANN's contractual jurisdiction, that is an argument we would be interested to during any upcoming DNS Abuse work.
Only once these concerns relating to the scope of the definition of DNS Abuse can be addressed, can we focus on metrics and effective enforcement that will provide a fair and operational framework protecting the rights of end users."
By all means to feel free to rephrase!:) What I'm arguing for is that for us to be able to "measure" DNS Abuse we should first clearly and transparently decide what it means. The current framework means the contracted parties are indeed trying to play a self-proclaimed internet police (militia?). Why did we presume DNS Abuse is CSAM and (in the same breath) fake Gucci bags but not hate speech and inciting violence? While we clearly would not have the answer ready, that is definitely a discussion we should have. The GAC might be interested in this as well (see last update from Veni on the ITU processes).
Thanks for considering team!
Best,
J.
W dniu 27.01.2021 o 01:39, Maureen Hilyard pisze:
In your inimitable style. Love it. Send it.
M
On Tue, Jan 26, 2021 at 12:34 PM Jonathan Zuck <JZuck@innovatorsnetwork.org <mailto:JZuck@innovatorsnetwork.org>> wrote:
Ladies,
Here’s my draft response. Let me know what you think!
Jonathan
=============================================================
Hey folks! Thanks for reaching out. Joanna and I, for sure, would be willing to join you and I suspect others, as well, once we know the timing. With respect to the questions below, I’ll do my best to provide some initial responses but I suspect the first question might be pivotal. There seems to be a lack of real data on the topic and perhaps some additional objective research is the answers. We endeavored to begin this process, during the CCTRT (sadag-final-09aug17-en.pdf (icann.org) <https://www.icann.org/en/system/files/files/sadag-final-09aug17-en.pdf>, but obviously barely scratched the surface. Perhaps a more comprehensive study, funded by ICANN rather than the CPH or CSG might be in order? I know DAAR provides some answers but it seems to be more of a survey than an example of rigorous research. Specifically to your questions.
What information do you use and how do you use it to assess DNS Abuse levels? This is obviously where we are weak. There doesn’t appear to be a great source for DNS Abuse “levels,” particularly because of the short time period over which a particular initiative takes place. A snapshot analysis doesn’t seem to get the full picture. The ALAC relies on the concerned raised by the GAC and the SSAC to fuel our belief that there’s more we should be doing. A recent report from Microsoft suggests the problem is bigger than we realize and David Taylor’s analysis of “responsiveness,” even among those who have signed onto the framework, seems damning. What are the ALAC’s pain points regarding DNS Abuse? Not sure to answer this in terms of how it’s handled inside ICANN or more generally from where our interests stems. To the latter point, we’re tasked with advancing the interests of those not represented by a constituency in the GNSO, namely those engaged in everyday use of the internet, as opposed to registrants. As the user base continues to grow, as we all desire, so too will the numbers of less sophisticated users, more easily duped by a phishing, malware or fraudulent advertising attack. As for the situation inside ICANN, the At-Large community have attempted to engage constructively as opposed to “attacking” the CPH, focusing instead on so-called “bad actors.” The first session <https://community.icann.org/display/atlarge/At-Large+Meetings+-+Monday%2C+09+March+2020?preview=/124847126/126428447/CCWholistic02.pdf> was an attempt to bring the CPH and Contract Compliance into the same room to figure out where the holes are. What exactly are the relevant limits on Contract Compliance? We feel this is a question which comes up constantly and is never successfully or consistently answered. It seems to be an area in which the ICANN community is constantly chasing it’s tail. It would seem that the only real enforced contract provision is payment. I’m sure this is an exaggeration but it seems to be a repeated situation where that is ultimately what foils a “ bad actor” after YEARS of neglect, if not outright facilitation of abuse. The answer to THIS question should be a HIGH priority. It might just be agreeing to an interpretation of the contracts or it might require an amendment to the contracts but this issue needs to stop being a merry go round. Insufficient Transparency from Contract Compliance Contract Compliance undocumented endeavors at soft touch diplomacy with bad actors seem to need some better limits or, at least, transparency. For “the market” to play a role in this, knowing about legitimate complaints for every contracted party could help customers make better decisions about which businesses to use and help us better understand where policy development needs to take place. Deflection and Minimization of the Problem I would say that one “pain point” is that our efforts have been largely “trolled” by certain members of the CPH, rather than engaging constructively. EVEN our effort to conceive of some sort of end user education campaign, to take the pressure off the CPH, was trolled. Jim, not to put you on the spot but, during one conversation, you said you didn’t even understand why this was being discussed because it affects such a small percentage of registered names. To date, we have proposed: i. Better contract enforcement
ii. More tools for Contract Compliance
iii. DNS Abuse “threshold,” an idea that found some support among the CPH at one point
iv. Predictive Analytics platform, perhaps financed by ICANN
The At-Large community has absolutely no desire to over regulate or over tax the CPH and we understand most of the contracted parties, particularly those showing up to meetings, are trying to do well and continuously improve. That said, this notion that it’s somehow not “our place,” to be trying to help is nothing short of offensive. It is the active participation of the ALAC and GAC that enable the ICANN to portray itself as something other than a trade association. The At-Large mandate is to advance the interests of those MOST impacted by DNS Abuse. That said, we WELCOME suggestions on how better to engage with the CPH for constructive outcomes.
Are you seeing practices from registrars or registries you find helpful? If we haven’t said it enough, the At-Large appreciates the efforts of those behind the Framework for DNS Abuse and the huge efforts that went into cooperation with law enforcement to track down COVID related abuse. We’d love to see the framework evolve to include specific commitments and metrics, however, for it to be something on which the community could truly rely.
We hope these answers are constructive and not inflammatory as it is our intention to find the most effective ways to proceed to further minimize the incidence of DNS Abuse , in all its forms. Thanks for the opportunity to be part of your conversation.
Maureen, Joanna & Jonathan
From: Keith Drazek <kdrazek@verisign.com <mailto:kdrazek@verisign.com>> Date: Friday, January 22, 2021 at 12:00 PM To: "maureen.hilyard@gmail.com <mailto:maureen.hilyard@gmail.com>" <maureen.hilyard@gmail.com <mailto:maureen.hilyard@gmail.com>>, Jonathan Zuck <JZuck@innovatorsnetwork.org <mailto:JZuck@innovatorsnetwork.org>>, "jkuleszaicann@gmail.com <mailto:jkuleszaicann@gmail.com>" <jkuleszaicann@gmail.com <mailto:jkuleszaicann@gmail.com>> Cc: "Brian F. Cimbolic" <BCimbolic@pir.org <mailto:BCimbolic@pir.org>>, Jim Galvin <jgalvin@afilias.info <mailto:jgalvin@afilias.info>>, Graeme Bunton <gbunton@tucows.com <mailto:gbunton@tucows.com>> Subject: Engagement on DNS Abuse
Hello Maureen, Jonathan and Joanna,
I hope you’re all doing well and staying healthy and safe. I am reaching out to you on behalf of the Contracted Party House DNS Abuse Working Group as we look ahead to ICANN 70 and the rest of 2021.
The Contracted Party House (CPH) DNS Abuse Group is conducting outreach to our friends in other SO/AC/SG/Cs regarding DNS Abuse. As previously noted by the CPH, DNS Abuse <https://rrsg.org/wp-content/uploads/2020/10/CPH-Definition-of-DNS-Abuse.pdf> comprises five categories: phishing, pharming, malware, botnets, and spam when it acts as a delivery mechanism for one of the other forms of DNS Abuse.
We want to open a more direct dialogue to understand pain points, hear suggestions and identify common ground where we can work together to mitigate DNS Abuse. Is there a subset of the At-Large focusing on DNS Abuse questions that would be able to join the CPH DNS Abuse group on a call to discuss this topic? We want to encourage frank and productive discussions on the topic that lead to really informing our dialogues and actions.
As a starting point, we propose the following questions to guide our discussion. Are there any other questions ALAC would like discuss?:
What information do you use and how do you use it to assess DNS Abuse levels?
What are the ALAC’s pain points regarding DNS Abuse?
Are you seeing practices from registrars or registries you find helpful?
Please let us know if a subgroup of the ALAC would be willing to join us. Our group meets regularly on Tuesdays at 1500 UTC. If so, please propose a Tuesday when you are available.
Best regards,
Keith
Keith Drazek
Vice President, Public Policy & Government Relations
Verisign, Inc.
+1-571-377-9182
Kdrazek@verisign.com <mailto:Kdrazek@verisign.com>
-- Kind regards, Joanna Kulesza ------------------- Joanna Kulesza, PhD University of Lodz, Poland ICANN ALAC Vice Chair SOI: https://community.icann.org/display/atlarge/Joanna+Kulesza+SOI <https://community.icann.org/display/atlarge/Joanna+Kulesza+SOI> TT: @KuleszaJ
_______________________________________________ CPWG mailing list CPWG@icann.org <mailto:CPWG@icann.org> https://mm.icann.org/mailman/listinfo/cpwg <https://mm.icann.org/mailman/listinfo/cpwg>
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ CPWG mailing list CPWG@icann.org https://mm.icann.org/mailman/listinfo/cpwg
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Dear Roberto, Evan, Carlton, and all, Thank you — in my humble opinion, the essential problem here is that ICANN is filling roles that are problematic to fill for an organization like ICANN, all advisory committees and so on considered. (Not that other approaches would be better) Nevertheless, there are many decisions that must be made by someone (not blaming anyone here) that simply are purely policy and extremely value-based. Therefore, these questions are linked to normative and fundamental legal questions that might not be best addressed by a small body of volunteers in a system marked by overly strong industry presence (again no blame here, statement of fact). I can definitely tell you from experience that the differences between Europe and US on some of these matters are stark, not even zooming out to the world. (We are seeing similar issues with the tech giants, making unilateral global decisions from a private company and US perspective—things could be worse. ;) ) This is why I fear we will struggle to find consensus here that will be acceptable to everyone. That is why, in a previous email, I was proposing that we might want to be thinking about where at least some consensus could be reached, where we have a chance to get somewhere. To me, this will likely be in the area of cybercrime and what is covered by criminal law. Yes, there will be differences between what is perceived as crime in different countries/regions but there is likely more there that consensus can be reached about. (And where legal requirements will already require some action). Hope this makes sense. All the best Laurin On Thu, Feb 4, 2021 at 17:57, Roberto Gaetano <mail.roberto.gaetano@gmail.com> wrote:
Hi all
I agree with Evan on both points.
Indeed the scope of the advice of ALAC does not have the limits that are imposed on other bodies, like the SOs. This because it is advice, and not a binding decision.
And agree as well about the strictly technical mandate of ICANN. Quoting one of Evan’s examples, the new gTLDs, there were just a couple of things that were within that remit, like the study on how many TLDs could be introduced with no risk for the root - and how fast this could be done - or issues about collision with widely used keywords. All the rest has nothing to do with technical issues. If somebody can explain to me what is technical about, for instance, whether large non-capital cities should have their name reserved or not, I might change my mind - but until then I remain convinced that the footprint of ICANN expands well beyond a coordination of technical issues.
Cheers, Roberto
PS: since Evan mentions it, my opinion about .XXX is that it should not have been delegated for the simple reason that it violated one key condition for sponsored TLDs: evidence of consensus of the served community - and we have received, as Board, many statements from parts of the adult industry who disagreed (for a number of reasons) with the delegation of .XXX. Initially the Board denied delegation, but later (but I was already off the Board) changed the opinion - some folks hinted that it was for fear of lawsuits. But the question is: what was the impact of that decision on the technical infrastructure management? Who is ICANN to have the power to decide yes or no?
On 03.02.2021, at 19:01, Evan Leibovitch <evan@telly.org> wrote:
Hi Jonathan and Joanna,
A few comments on scope:
- I feel the need to periodically remind my colleagues that ALAC's scope is whatever it deems to be in scope. The ICANN bylaws explicitly do not limit the subject matter on which we can comment in the manner that SOs are. We are able to advise the Board on policy, on operations, on core values, on budget, and indeed on scope. I reject the arbitrary imposition of limitations upon what we can comment based on the limitations placed on (or assumed by) other ICANN sub-communities. If there is something that ALAC deems is (a) important to end users and (b) addressable by ICANN then it's in-scope. We are the sole arbitrators of what is important to us, and I find it intensely frustrating when ALAC muzzles itself in order to be synchronized with the self-imposed limits of others.
- In response to the question:
"Does this mean we should finally abandon the well established yet always controversial narrative of a strictly technical infrastructure management?" I answer: That ship sailed long ago and is now on the ocean floor. Anyone who believes that ICANN adheres to a strictly technical mandate -- or even pretends to -- has not been following its history very deeply. From the money-driven decisions on expanding the number of gTLDs, to the utterly political decisions about the "appropriateness" of artifacts such as .XXX or vertical integration or closed generics, to philosophical issues such as the balance between registrant privacy versus accountability, ICANN long ago shed any pretense of purely technical function. Most recently, the admonishment of ICANN on the issue of the .ORG transfer by its overseer (the California Attorney General) demonstrates beyond doubt that societal expectations of ICANN's function go WELL beyond the purely technical. By all means let's be clear on what we mean by "DNS Abuse"; without clarity we won't have the necessary focus and our resulting advice will be easily ignored. But let's not artificially constrain ourselves in advance.
Cheers,
Evan Leibovitch, Toronto Canada @evanleibovitch / @el56
On Wed, 3 Feb 2021 at 09:50, Jonathan Zuck <JZuck@innovatorsnetwork.org> wrote:
Evin has suggested that I had, perhaps, NOT forwarded this to the group. Here’s the discussion thread, initiated by Keith Drazek on the Contracted Party House DNS Abuse Work Group. This includes, Joanna’s expression of mission creep concern.
Jonathan
Jonathan Zuck
Executive Director
Innovators Network Foundation
[www.InnovatorsNetwork.org](http://www.innovatorsnetwork.org/)
From: [Joanna Kulesza](mailto:jkuleszaicann@gmail.com) Sent: Wednesday, January 27, 2021 2:12 AM To: [Maureen Hilyard](mailto:maureen.hilyard@gmail.com); [Jonathan Zuck](mailto:JZuck@innovatorsnetwork.org) Subject: Re: Engagement on DNS Abuse
Great stuff Jonathan, as always. Feel free to share. If I were to add my two cents, I'd put these in the "pain points" section while these are of a more general nature.
"From the discussions we've had within At-Large it is clear that the very scope and definition of DNS Abuse is a "pain point". This was also the take away from the discussions we've had with the invited guests from within and beyond the ICANN community. "DNS Abuse" as it is now defined in the proposed Framework affects the entire internet community of end users while being already covered by existing national and international norms and standards. Keeping these in mind the proposed definition and scope of DNS Abuse strikes as arbitrary: what were the criteria set for selecting these specific categories as DNS Abuse while leaving other potential categories out?
This is particularly relevant with regard to our second concern: the proposed scope of DNS Abuse clearly crosses the content "picket fence" that the ICANN community had set for itself. Including IP infringement on equal footing with CSAM raises serious concerns among At-Large members. We are concerned not only with the very fact of the picket fence being crossed but also by the way in which this is being done. Does this mean we should finally abandon the well established yet always controversial narrative of a strictly technical infrastructure management?
Once content is concerned, the existing and proposed practice fails to recognize international legal safeguards when it comes to restrictions put on individual freedoms. Whenever an individual liberty is to be restricted, due process must be ensured. The procedures proposed by the DNS Abuse framework fail to ensure e.g. a right to an effective legal remedy. While we realize this argument brings us back tot he general discussion on limits of ICANN's contractual jurisdiction, that is an argument we would be interested to during any upcoming DNS Abuse work.
Only once these concerns relating to the scope of the definition of DNS Abuse can be addressed, can we focus on metrics and effective enforcement that will provide a fair and operational framework protecting the rights of end users."
By all means to feel free to rephrase!:) What I'm arguing for is that for us to be able to "measure" DNS Abuse we should first clearly and transparently decide what it means. The current framework means the contracted parties are indeed trying to play a self-proclaimed internet police (militia?). Why did we presume DNS Abuse is CSAM and (in the same breath) fake Gucci bags but not hate speech and inciting violence? While we clearly would not have the answer ready, that is definitely a discussion we should have. The GAC might be interested in this as well (see last update from Veni on the ITU processes).
Thanks for considering team!
Best,
J.
W dniu 27.01.2021 o 01:39, Maureen Hilyard pisze:
In your inimitable style. Love it. Send it.
M
On Tue, Jan 26, 2021 at 12:34 PM Jonathan Zuck <JZuck@innovatorsnetwork.org> wrote:
Ladies,
Here’s my draft response. Let me know what you think!
Jonathan
=============================================================
Hey folks! Thanks for reaching out. Joanna and I, for sure, would be willing to join you and I suspect others, as well, once we know the timing. With respect to the questions below, I’ll do my best to provide some initial responses but I suspect the first question might be pivotal. There seems to be a lack of real data on the topic and perhaps some additional objective research is the answers. We endeavored to begin this process, during the CCTRT ([sadag-final-09aug17-en.pdf (icann.org)](https://www.icann.org/en/system/files/files/sadag-final-09aug17-en.pdf), but obviously barely scratched the surface. Perhaps a more comprehensive study, funded by ICANN rather than the CPH or CSG might be in order? I know DAAR provides some answers but it seems to be more of a survey than an example of rigorous research. Specifically to your questions.
- What information do you use and how do you use it to assess DNS Abuse levels? This is obviously where we are weak. There doesn’t appear to be a great source for DNS Abuse “levels,” particularly because of the short time period over which a particular initiative takes place. A snapshot analysis doesn’t seem to get the full picture. The ALAC relies on the concerned raised by the GAC and the SSAC to fuel our belief that there’s more we should be doing. A recent report from Microsoft suggests the problem is bigger than we realize and David Taylor’s analysis of “responsiveness,” even among those who have signed onto the framework, seems damning. - What are the ALAC’s pain points regarding DNS Abuse? Not sure to answer this in terms of how it’s handled inside ICANN or more generally from where our interests stems. To the latter point, we’re tasked with advancing the interests of those not represented by a constituency in the GNSO, namely those engaged in everyday use of the internet, as opposed to registrants. As the user base continues to grow, as we all desire, so too will the numbers of less sophisticated users, more easily duped by a phishing, malware or fraudulent advertising attack. As for the situation inside ICANN, the At-Large community have attempted to engage constructively as opposed to “attacking” the CPH, focusing instead on so-called “bad actors.” The first [session](https://community.icann.org/display/atlarge/At-Large+Meetings+-+Monday%2C+09...) was an attempt to bring the CPH and Contract Compliance into the same room to figure out where the holes are.
- What exactly are the relevant limits on Contract Compliance?We feel this is a question which comes up constantly and is never successfully or consistently answered. It seems to be an area in which the ICANN community is constantly chasing it’s tail. It would seem that the only real enforced contract provision is payment. I’m sure this is an exaggeration but it seems to be a repeated situation where that is ultimately what foils a “ bad actor” after YEARS of neglect, if not outright facilitation of abuse. The answer to THIS question should be a HIGH priority. It might just be agreeing to an interpretation of the contracts or it might require an amendment to the contracts but this issue needs to stop being a merry go round. - Insufficient Transparency from Contract ComplianceContract Compliance undocumented endeavors at soft touch diplomacy with bad actors seem to need some better limits or, at least, transparency. For “the market” to play a role in this, knowing about legitimate complaints for every contracted party could help customers make better decisions about which businesses to use and help us better understand where policy development needs to take place. - Deflection and Minimization of the ProblemI would say that one “pain point” is that our efforts have been largely “trolled” by certain members of the CPH, rather than engaging constructively. EVEN our effort to conceive of some sort of end user education campaign, to take the pressure off the CPH, was trolled. Jim, not to put you on the spot but, during one conversation, you said you didn’t even understand why this was being discussed because it affects such a small percentage of registered names. To date, we have proposed:
i.Better contract enforcement
ii.More tools for Contract Compliance
iii.DNS Abuse “threshold,” an idea that found some support among the CPH at one point
iv.Predictive Analytics platform, perhaps financed by ICANN
The At-Large community has absolutely no desire to over regulate or over tax the CPH and we understand most of the contracted parties, particularly those showing up to meetings, are trying to do well and continuously improve. That said, this notion that it’s somehow not “our place,” to be trying to help is nothing short of offensive. It is the active participation of the ALAC and GAC that enable the ICANN to portray itself as something other than a trade association. The At-Large mandate is to advance the interests of those MOST impacted by DNS Abuse. That said, we WELCOME suggestions on how better to engage with the CPH for constructive outcomes.
- Are you seeing practices from registrars or registries you find helpful? If we haven’t said it enough, the At-Large appreciates the efforts of those behind the Framework for DNS Abuse and the huge efforts that went into cooperation with law enforcement to track down COVID related abuse. We’d love to see the framework evolve to include specific commitments and metrics, however, for it to be something on which the community could truly rely.
We hope these answers are constructive and not inflammatory as it is our intention to find the most effective ways to proceed to further minimize the incidence of DNS Abuse , in all its forms. Thanks for the opportunity to be part of your conversation.
Maureen, Joanna & Jonathan
From: Keith Drazek <kdrazek@verisign.com> Date: Friday, January 22, 2021 at 12:00 PM To: "maureen.hilyard@gmail.com" <maureen.hilyard@gmail.com>, Jonathan Zuck <JZuck@innovatorsnetwork.org>, "jkuleszaicann@gmail.com" <jkuleszaicann@gmail.com> Cc: "Brian F. Cimbolic" <BCimbolic@pir.org>, Jim Galvin <jgalvin@afilias.info>, Graeme Bunton <gbunton@tucows.com> Subject: Engagement on DNS Abuse
Hello Maureen, Jonathan and Joanna,
I hope you’re all doing well and staying healthy and safe. I am reaching out to you on behalf of the Contracted Party House DNS Abuse Working Group as we look ahead to ICANN 70 and the rest of 2021.
The Contracted Party House (CPH) DNS Abuse Group is conducting outreach to our friends in other SO/AC/SG/Cs regarding DNS Abuse. As previously noted by the CPH, [DNS Abuse](https://rrsg.org/wp-content/uploads/2020/10/CPH-Definition-of-DNS-Abuse.pdf) comprises five categories: phishing, pharming, malware, botnets, and spam when it acts as a delivery mechanism for one of the other forms of DNS Abuse.
We want to open a more direct dialogue to understand pain points, hear suggestions and identify common ground where we can work together to mitigate DNS Abuse. Is there a subset of the At-Large focusing on DNS Abuse questions that would be able to join the CPH DNS Abuse group on a call to discuss this topic? We want to encourage frank and productive discussions on the topic that lead to really informing our dialogues and actions.
As a starting point, we propose the following questions to guide our discussion. Are there any other questions ALAC would like discuss?:
What information do you use and how do you use it to assess DNS Abuse levels?
What are the ALAC’s pain points regarding DNS Abuse?
Are you seeing practices from registrars or registries you find helpful?
Please let us know if a subgroup of the ALAC would be willing to join us. Our group meets regularly on Tuesdays at 1500 UTC. If so, please propose a Tuesday when you are available.
Best regards,
Keith
Keith Drazek
Vice President, Public Policy & Government Relations
Verisign, Inc.
+1-571-377-9182
Kdrazek@verisign.com
--
Kind regards,
Joanna Kulesza
-------------------
Joanna Kulesza, PhD
University of Lodz, Poland
ICANN ALAC Vice Chair
SOI: https://community.icann.org/display/atlarge/Joanna+Kulesza+SOI
TT: @KuleszaJ
_______________________________________________ CPWG mailing list CPWG@icann.org https://mm.icann.org/mailman/listinfo/cpwg
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ CPWG mailing list CPWG@icann.org https://mm.icann.org/mailman/listinfo/cpwg
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Laurin, It's my understanding the ICANN by-laws give voting power to the ALAC in a way that balances the interests of different stakeholders as originally intended when ICANN was created. If the ALAC is currently structured in a way that it cannot fulfill its by-law duties, because the DNS Abuse issue "might not be best addressed by a small body of volunteers", I'd like to suggest that maybe the entire ICANN organization has a problem meeting its mission as stated in our bylaws. It may be wise to address any perceived capability problems with ALAC directly, rather than bypassing ICANN's bylaws for the sake of expediency. However, I do agree it's best to look for consensus within the current context, since the question about the capability of "a small body of volunteers" won't be solved quickly. Cheers! David On Thu, Feb 4, 2021 at 12:50 PM Laurin B Weissinger via CPWG <cpwg@icann.org> wrote:
Dear Roberto, Evan, Carlton, and all,
Thank you — in my humble opinion, the essential problem here is that ICANN is filling roles that are problematic to fill for an organization like ICANN, all advisory committees and so on considered. (Not that other approaches would be better)
Nevertheless, there are many decisions that must be made by someone (not blaming anyone here) that simply are purely policy and extremely value-based. Therefore, these questions are linked to normative and fundamental legal questions that might not be best addressed by a small body of volunteers in a system marked by overly strong industry presence (again no blame here, statement of fact).
I can definitely tell you from experience that the differences between Europe and US on some of these matters are stark, not even zooming out to the world. (We are seeing similar issues with the tech giants, making unilateral global decisions from a private company and US perspective—things could be worse. ;) )
This is why I fear we will struggle to find consensus here that will be acceptable to everyone. That is why, in a previous email, I was proposing that we might want to be thinking about where at least some consensus could be reached, where we have a chance to get somewhere. To me, this will likely be in the area of cybercrime and what is covered by criminal law. Yes, there will be differences between what is perceived as crime in different countries/regions but there is likely more there that consensus can be reached about. (And where legal requirements will already require some action).
Hope this makes sense.
All the best Laurin
On Thu, Feb 4, 2021 at 17:57, Roberto Gaetano < mail.roberto.gaetano@gmail.com> wrote:
Hi all
I agree with Evan on both points.
Indeed the scope of the advice of ALAC does not have the limits that are imposed on other bodies, like the SOs. This because it is advice, and not a binding decision.
And agree as well about the strictly technical mandate of ICANN. Quoting one of Evan’s examples, the new gTLDs, there were just a couple of things that were within that remit, like the study on how many TLDs could be introduced with no risk for the root - and how fast this could be done - or issues about collision with widely used keywords. All the rest has nothing to do with technical issues. If somebody can explain to me what is technical about, for instance, whether large non-capital cities should have their name reserved or not, I might change my mind - but until then I remain convinced that the footprint of ICANN expands well beyond a coordination of technical issues.
Cheers, Roberto
PS: since Evan mentions it, my opinion about .XXX is that it should not have been delegated for the simple reason that it violated one key condition for sponsored TLDs: evidence of consensus of the served community - and we have received, as Board, many statements from parts of the adult industry who disagreed (for a number of reasons) with the delegation of .XXX. Initially the Board denied delegation, but later (but I was already off the Board) changed the opinion - some folks hinted that it was for fear of lawsuits. But the question is: what was the impact of that decision on the technical infrastructure management? Who is ICANN to have the power to decide yes or no?
On 03.02.2021, at 19:01, Evan Leibovitch <evan@telly.org> wrote:
Hi Jonathan and Joanna,
A few comments on scope:
- I feel the need to periodically remind my colleagues that ALAC's scope is whatever it deems to be in scope. The ICANN bylaws explicitly do not limit the subject matter on which we can comment in the manner that SOs are. We are able to advise the Board on policy, on operations, on core values, on budget, and indeed on scope. I reject the arbitrary imposition of limitations upon what we can comment based on the limitations placed on (or assumed by) other ICANN sub-communities. If there is something that ALAC deems is (a) important to end users and (b) addressable by ICANN then it's in-scope. *We* are the sole arbitrators of what is important to us, and I find it intensely frustrating when ALAC muzzles itself in order to be synchronized with the self-imposed limits of others.
- In response to the question: "*Does this mean we should finally abandon the well established yet always controversial narrative of a strictly technical infrastructure management?*" I answer: That ship sailed long ago and is now on the ocean floor. Anyone who believes that ICANN adheres to a strictly technical mandate -- or even pretends to -- has not been following its history very deeply. From the money-driven decisions on expanding the number of gTLDs, to the utterly political decisions about the "appropriateness" of artifacts such as .XXX or vertical integration or closed generics, to philosophical issues such as the balance between registrant privacy versus accountability, ICANN long ago shed any pretense of purely technical function. Most recently, the admonishment of ICANN on the issue of the .ORG transfer by its overseer (the California Attorney General) demonstrates beyond doubt that societal expectations of ICANN's function go WELL beyond the purely technical.
By all means let's be clear on what we mean by "DNS Abuse"; without clarity we won't have the necessary focus and our resulting advice will be easily ignored. But let's not artificially constrain ourselves in advance.
Cheers,
Evan Leibovitch, Toronto Canada @evanleibovitch / @el56
On Wed, 3 Feb 2021 at 09:50, Jonathan Zuck <JZuck@innovatorsnetwork.org> wrote:
Evin has suggested that I had, perhaps, NOT forwarded this to the group. Here’s the discussion thread, initiated by Keith Drazek on the Contracted Party House DNS Abuse Work Group. This includes, Joanna’s expression of mission creep concern.
Jonathan
Jonathan Zuck
Executive Director
Innovators Network Foundation
www.InnovatorsNetwork.org <http://www.innovatorsnetwork.org/>
*From: *Joanna Kulesza <jkuleszaicann@gmail.com> *Sent: *Wednesday, January 27, 2021 2:12 AM *To: *Maureen Hilyard <maureen.hilyard@gmail.com>; Jonathan Zuck <JZuck@innovatorsnetwork.org> *Subject: *Re: Engagement on DNS Abuse
Great stuff Jonathan, as always. Feel free to share. If I were to add my two cents, I'd put these in the "pain points" section while these are of a more general nature.
"From the discussions we've had within At-Large it is clear that the very scope and definition of DNS Abuse is a "pain point". This was also the take away from the discussions we've had with the invited guests from within and beyond the ICANN community. "DNS Abuse" as it is now defined in the proposed Framework affects the entire internet community of end users while being already covered by existing national and international norms and standards. Keeping these in mind the proposed definition and scope of DNS Abuse strikes as arbitrary: what were the criteria set for selecting these specific categories as DNS Abuse while leaving other potential categories out?
This is particularly relevant with regard to our second concern: the proposed scope of DNS Abuse clearly crosses the content "picket fence" that the ICANN community had set for itself. Including IP infringement on equal footing with CSAM raises serious concerns among At-Large members. We are concerned not only with the very fact of the picket fence being crossed but also by the way in which this is being done. Does this mean we should finally abandon the well established yet always controversial narrative of a strictly technical infrastructure management?
Once content is concerned, the existing and proposed practice fails to recognize international legal safeguards when it comes to restrictions put on individual freedoms. Whenever an individual liberty is to be restricted, due process must be ensured. The procedures proposed by the DNS Abuse framework fail to ensure e.g. a right to an effective legal remedy. While we realize this argument brings us back tot he general discussion on limits of ICANN's contractual jurisdiction, that is an argument we would be interested to during any upcoming DNS Abuse work.
Only once these concerns relating to the scope of the definition of DNS Abuse can be addressed, can we focus on metrics and effective enforcement that will provide a fair and operational framework protecting the rights of end users."
By all means to feel free to rephrase!:) What I'm arguing for is that for us to be able to "measure" DNS Abuse we should first clearly and transparently decide what it means. The current framework means the contracted parties are indeed trying to play a self-proclaimed internet police (militia?). Why did we presume DNS Abuse is CSAM and (in the same breath) fake Gucci bags but not hate speech and inciting violence? While we clearly would not have the answer ready, that is definitely a discussion we should have. The GAC might be interested in this as well (see last update from Veni on the ITU processes).
Thanks for considering team!
Best,
J.
W dniu 27.01.2021 o 01:39, Maureen Hilyard pisze:
In your inimitable style. Love it. Send it.
M
On Tue, Jan 26, 2021 at 12:34 PM Jonathan Zuck < JZuck@innovatorsnetwork.org> wrote:
Ladies,
Here’s my draft response. Let me know what you think!
Jonathan
=============================================================
Hey folks! Thanks for reaching out. Joanna and I, for sure, would be willing to join you and I suspect others, as well, once we know the timing. With respect to the questions below, I’ll do my best to provide some initial responses but I suspect the first question might be pivotal. There seems to be a lack of real data on the topic and perhaps some additional objective research is the answers. We endeavored to begin this process, during the CCTRT (sadag-final-09aug17-en.pdf (icann.org) <https://www.icann.org/en/system/files/files/sadag-final-09aug17-en.pdf>, but obviously barely scratched the surface. Perhaps a more comprehensive study, funded by ICANN rather than the CPH or CSG might be in order? I know DAAR provides some answers but it seems to be more of a survey than an example of rigorous research. Specifically to your questions.
1. *What information do you use and how do you use it to assess DNS Abuse levels?* This is obviously where we are weak. There doesn’t appear to be a great source for DNS Abuse “levels,” particularly because of the short time period over which a particular initiative takes place. A snapshot analysis doesn’t seem to get the full picture. The ALAC relies on the concerned raised by the GAC and the SSAC to fuel our belief that there’s more we should be doing. A recent report from Microsoft suggests the problem is bigger than we realize and David Taylor’s analysis of “responsiveness,” even among those who have signed onto the framework, seems damning. 2. *What are the ALAC’s pain points regarding DNS Abuse?* Not sure to answer this in terms of how it’s handled inside ICANN or more generally from where our interests stems. To the latter point, we’re tasked with advancing the interests of those not represented by a constituency in the GNSO, namely those engaged in everyday use of the internet, as opposed to registrants. As the user base continues to grow, as we all desire, so too will the numbers of less sophisticated users, more easily duped by a phishing, malware or fraudulent advertising attack. As for the situation inside ICANN, the At-Large community have attempted to engage constructively as opposed to “attacking” the CPH, focusing instead on so-called “bad actors.” The first session <https://community.icann.org/display/atlarge/At-Large+Meetings+-+Monday%2C+09+March+2020?preview=/124847126/126428447/CCWholistic02.pdf> was an attempt to bring the CPH and Contract Compliance into the same room to figure out where the holes are.
1. *What exactly are the relevant limits on Contract Compliance? *We feel this is a question which comes up constantly and is never successfully or consistently answered. It seems to be an area in which the ICANN community is constantly chasing it’s tail. It would seem that the only real enforced contract provision is payment. I’m sure this is an exaggeration but it seems to be a repeated situation where that is ultimately what foils a “ bad actor” after YEARS of neglect, if not outright facilitation of abuse. The answer to THIS question should be a HIGH priority. It might just be agreeing to an interpretation of the contracts or it might require an amendment to the contracts but this issue needs to stop being a merry go round. 2. *Insufficient Transparency from Contract Compliance *Contract Compliance undocumented endeavors at soft touch diplomacy with bad actors seem to need some better limits or, at least, transparency. For “the market” to play a role in this, knowing about legitimate complaints for every contracted party could help customers make better decisions about which businesses to use and help us better understand where policy development needs to take place. 3. *Deflection and Minimization of the Problem *I would say that one “pain point” is that our efforts have been largely “trolled” by certain members of the CPH, rather than engaging constructively. EVEN our effort to conceive of some sort of end user education campaign, to take the pressure off the CPH, was trolled. Jim, not to put you on the spot but, during one conversation, you said you didn’t even understand why this was being discussed because it affects such a small percentage of registered names. To date, we have proposed:
*i.* *Better contract enforcement*
*ii.* *More tools for Contract Compliance*
*iii.* *DNS Abuse “threshold,” an idea that found some support among the CPH at one point*
*iv.* *Predictive Analytics platform, perhaps financed by ICANN*
The At-Large community has *absolutely* no desire to over regulate or over tax the CPH and we understand most of the contracted parties, particularly those showing up to meetings, are trying to do well and continuously improve. That said, this notion that it’s somehow not “our place,” to be trying to help is nothing short of offensive. It is the active participation of the ALAC and GAC that enable the ICANN to portray itself as something other than a trade association. The At-Large mandate is to advance the interests of those MOST impacted by DNS Abuse. That said, we WELCOME suggestions on how better to engage with the CPH for constructive outcomes.
1. *Are you seeing practices from registrars or registries you find helpful?* If we haven’t said it enough, the At-Large appreciates the efforts of those behind the Framework for DNS Abuse and the huge efforts that went into cooperation with law enforcement to track down COVID related abuse. We’d love to see the framework evolve to include specific commitments and metrics, however, for it to be something on which the community could truly rely.
We hope these answers are constructive and not inflammatory as it is our intention to find the most effective ways to proceed to further minimize the incidence of DNS Abuse , in all its forms. Thanks for the opportunity to be part of your conversation.
Maureen, Joanna & Jonathan
*From: *Keith Drazek <kdrazek@verisign.com> *Date: *Friday, January 22, 2021 at 12:00 PM *To: *"maureen.hilyard@gmail.com" <maureen.hilyard@gmail.com>, Jonathan Zuck <JZuck@innovatorsnetwork.org>, "jkuleszaicann@gmail.com" < jkuleszaicann@gmail.com> *Cc: *"Brian F. Cimbolic" <BCimbolic@pir.org>, Jim Galvin < jgalvin@afilias.info>, Graeme Bunton <gbunton@tucows.com> *Subject: *Engagement on DNS Abuse
Hello Maureen, Jonathan and Joanna,
I hope you’re all doing well and staying healthy and safe. I am reaching out to you on behalf of the Contracted Party House DNS Abuse Working Group as we look ahead to ICANN 70 and the rest of 2021.
The Contracted Party House (CPH) DNS Abuse Group is conducting outreach to our friends in other SO/AC/SG/Cs regarding DNS Abuse. As previously noted by the CPH, DNS Abuse <https://rrsg.org/wp-content/uploads/2020/10/CPH-Definition-of-DNS-Abuse.pdf> comprises five categories: phishing, pharming, malware, botnets, and spam when it acts as a delivery mechanism for one of the other forms of DNS Abuse.
We want to open a more direct dialogue to understand pain points, hear suggestions and identify common ground where we can work together to mitigate DNS Abuse. Is there a subset of the At-Large focusing on DNS Abuse questions that would be able to join the CPH DNS Abuse group on a call to discuss this topic? We want to encourage frank and productive discussions on the topic that lead to really informing our dialogues and actions.
As a starting point, we propose the following questions to guide our discussion. Are there any other questions ALAC would like discuss?:
What information do you use and how do you use it to assess DNS Abuse levels?
What are the ALAC’s pain points regarding DNS Abuse?
Are you seeing practices from registrars or registries you find helpful?
Please let us know if a subgroup of the ALAC would be willing to join us. Our group meets regularly on Tuesdays at 1500 UTC. If so, please propose a Tuesday when you are available.
Best regards,
Keith
Keith Drazek
Vice President, Public Policy & Government Relations
Verisign, Inc.
+1-571-377-9182
Kdrazek@verisign.com
--
Kind regards,
Joanna Kulesza
-------------------
Joanna Kulesza, PhD
University of Lodz, Poland
ICANN ALAC Vice Chair
SOI: https://community.icann.org/display/atlarge/Joanna+Kulesza+SOI
TT: @KuleszaJ
_______________________________________________ CPWG mailing list CPWG@icann.org https://mm.icann.org/mailman/listinfo/cpwg
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ CPWG mailing list CPWG@icann.org https://mm.icann.org/mailman/listinfo/cpwg
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ CPWG mailing list CPWG@icann.org https://mm.icann.org/mailman/listinfo/cpwg
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
On Thu, 4 Feb 2021 at 13:09, David Mackey <mackey361@gmail.com> wrote:
It's my understanding the ICANN by-laws give voting power to the ALAC in a way that balances the interests of different stakeholders as originally intended when ICANN was created.
To the extent that ALAC can vote on non-binding advice, I suppose that's true. But I'm not sure what you mean by "balance the interests of different stakeholders"; the bylaws clearly indicate that ALAC is supposed to put forward the perspective of Internet end-users. While this is of course a massively diverse global constituency, it at least has some measurable distinction from the self-interested and conflicted communities that make up most of the rest of ICANN's non-technical conmstituencies. This status is often muddied, in as far as At-Large has also become a "none of the above" home for those in self-interested or conflicted situations who can't find a home elsewhere, such as the domain speculators who have of late been camping out in NARALO. At-Large did not exist "when ICANN was created"; it was a cynical consequence of the decision to eliminate community elections for the Board, to provide a facade of sensitivity to the grassroots. The public-at-large went overnight from the direct ability to elect Directors to an overly-bureaucratic, process-obsessed (IMO), underfunded mechanism for giving advice to the Board that until not long ago wasn't even acknowledged. After decades the ICANN Board has not yet deemed ALAC mature enough to elect a second Director as its own reviews have advised. If the ALAC is currently structured in a way that it cannot fulfill its
by-law duties, because the DNS Abuse issue "might not be best addressed by a small body of volunteers", I'd like to suggest that maybe the entire ICANN organization has a problem meeting its mission as stated in our bylaws. It may be wise to address any perceived capability problems with ALAC directly, rather than bypassing ICANN's bylaws for the sake of expediency.
The "small body of volunteers" issue has plagued ALAC from its beginnings. Being useful on ALAC involves a great amount of unpaid time and work, following developments led by people who have ICANN involvement as some or all of their job description. Because two-thirds of ALAC is filled by election its positions are often sought by people more interested in politicking and less in crafting relevant and useful advice. (When I was first on ALAC I saw the NomCom appointments as a curse; now I see them as a blessing.) The result indeed means that the bulk of substantive work (ie policy development and advice creation) ends up being done by a very small number of people. But it also means that the result of this work can easily be dismissed when our output contravenes ICANN's common wisdom, under the "who the hell are you to claim to speak for the billions?" argument. They love the "small body of volunteers" if we agree with them but are savage when we don't. Since leaving heavy-duty ALAC work I observe that ALAC in its current state is indeed not fit to serve its bylaw duties, but through no fault of its own or its people. Without the ability to do global surveys of public opinion, ALAC is really not capable of knowing what end-users want from ICANN. The best we can do are educated guesses -- which, to be honest, are usually pretty well-thought despite the lack of grounding. And statistical inputs such as John's strengthen our case. But we're still guessing at what the world wants. (If the public at large doesn't give a damn about closed generics, why should ALAC?) Until ICANN equips ALACs to survey the world and act as a conduit for the results, ALAC won't be able to serve its bylaw mandate. The great experiment that presumed At-Large Structures would effectively provide a broad two-way global communications channel (education going out, quality advice coming back) has generally been a failure at that goal. If you want to address capability problems we can start there. Then again, I may not be the best person to comment. The way ICANN handled the .ORG transfer fiasco (and especially ALAC's inexcusable paralysis in that matter) was shameful, and provides to me sufficient evidence (though there is much more) that ICANN is not fit for purpose. If it were up to me I'd hand off the technical coordination to either IETF or IEEE, and assemble a treaty convention to deal with the rest..... Sorry you asked? Cheers, - Evan
Dear Laurin, To your last question, yes, what you say makes sense. I feel though that I have to clarify one point: I am not suggesting at all that ICANN does not fill in the blanks - where there is a problem and nobody else is taking care of it, for instance. This is a decision that the Board of ICANN has to take. About ALAC, what I am saying is that we should not be shy of providing our opinion and/or advice - that is, we should not self-impose limits accepting comments by others (e.g. SOs). I hope I have made myself clear. Cheers, Roberto On 04.02.2021, at 18:49, Laurin B Weissinger <Laurin-lists@pm.me<mailto:Laurin-lists@pm.me>> wrote: Dear Roberto, Evan, Carlton, and all, Thank you — in my humble opinion, the essential problem here is that ICANN is filling roles that are problematic to fill for an organization like ICANN, all advisory committees and so on considered. (Not that other approaches would be better) Nevertheless, there are many decisions that must be made by someone (not blaming anyone here) that simply are purely policy and extremely value-based. Therefore, these questions are linked to normative and fundamental legal questions that might not be best addressed by a small body of volunteers in a system marked by overly strong industry presence (again no blame here, statement of fact). I can definitely tell you from experience that the differences between Europe and US on some of these matters are stark, not even zooming out to the world. (We are seeing similar issues with the tech giants, making unilateral global decisions from a private company and US perspective—things could be worse. ;) ) This is why I fear we will struggle to find consensus here that will be acceptable to everyone. That is why, in a previous email, I was proposing that we might want to be thinking about where at least some consensus could be reached, where we have a chance to get somewhere. To me, this will likely be in the area of cybercrime and what is covered by criminal law. Yes, there will be differences between what is perceived as crime in different countries/regions but there is likely more there that consensus can be reached about. (And where legal requirements will already require some action). Hope this makes sense. All the best Laurin On Thu, Feb 4, 2021 at 17:57, Roberto Gaetano <mail.roberto.gaetano@gmail.com<mailto:mail.roberto.gaetano@gmail.com>> wrote: Hi all I agree with Evan on both points. Indeed the scope of the advice of ALAC does not have the limits that are imposed on other bodies, like the SOs. This because it is advice, and not a binding decision. And agree as well about the strictly technical mandate of ICANN. Quoting one of Evan’s examples, the new gTLDs, there were just a couple of things that were within that remit, like the study on how many TLDs could be introduced with no risk for the root - and how fast this could be done - or issues about collision with widely used keywords. All the rest has nothing to do with technical issues. If somebody can explain to me what is technical about, for instance, whether large non-capital cities should have their name reserved or not, I might change my mind - but until then I remain convinced that the footprint of ICANN expands well beyond a coordination of technical issues. Cheers, Roberto PS: since Evan mentions it, my opinion about .XXX is that it should not have been delegated for the simple reason that it violated one key condition for sponsored TLDs: evidence of consensus of the served community - and we have received, as Board, many statements from parts of the adult industry who disagreed (for a number of reasons) with the delegation of .XXX. Initially the Board denied delegation, but later (but I was already off the Board) changed the opinion - some folks hinted that it was for fear of lawsuits. But the question is: what was the impact of that decision on the technical infrastructure management? Who is ICANN to have the power to decide yes or no? On 03.02.2021, at 19:01, Evan Leibovitch <evan@telly.org<mailto:evan@telly.org>> wrote: Hi Jonathan and Joanna, A few comments on scope: * I feel the need to periodically remind my colleagues that ALAC's scope is whatever it deems to be in scope. The ICANN bylaws explicitly do not limit the subject matter on which we can comment in the manner that SOs are. We are able to advise the Board on policy, on operations, on core values, on budget, and indeed on scope. I reject the arbitrary imposition of limitations upon what we can comment based on the limitations placed on (or assumed by) other ICANN sub-communities. If there is something that ALAC deems is (a) important to end users and (b) addressable by ICANN then it's in-scope. We are the sole arbitrators of what is important to us, and I find it intensely frustrating when ALAC muzzles itself in order to be synchronized with the self-imposed limits of others. * In response to the question: "Does this mean we should finally abandon the well established yet always controversial narrative of a strictly technical infrastructure management?" I answer: That ship sailed long ago and is now on the ocean floor. Anyone who believes that ICANN adheres to a strictly technical mandate -- or even pretends to -- has not been following its history very deeply. From the money-driven decisions on expanding the number of gTLDs, to the utterly political decisions about the "appropriateness" of artifacts such as .XXX or vertical integration or closed generics, to philosophical issues such as the balance between registrant privacy versus accountability, ICANN long ago shed any pretense of purely technical function. Most recently, the admonishment of ICANN on the issue of the .ORG transfer by its overseer (the California Attorney General) demonstrates beyond doubt that societal expectations of ICANN's function go WELL beyond the purely technical. By all means let's be clear on what we mean by "DNS Abuse"; without clarity we won't have the necessary focus and our resulting advice will be easily ignored. But let's not artificially constrain ourselves in advance. Cheers, Evan Leibovitch, Toronto Canada @evanleibovitch / @el56 On Wed, 3 Feb 2021 at 09:50, Jonathan Zuck <JZuck@innovatorsnetwork.org<mailto:JZuck@innovatorsnetwork.org>> wrote: Evin has suggested that I had, perhaps, NOT forwarded this to the group. Here’s the discussion thread, initiated by Keith Drazek on the Contracted Party House DNS Abuse Work Group. This includes, Joanna’s expression of mission creep concern. Jonathan Jonathan Zuck Executive Director Innovators Network Foundation www.InnovatorsNetwork.org<http://www.innovatorsnetwork.org/> From: Joanna Kulesza<mailto:jkuleszaicann@gmail.com> Sent: Wednesday, January 27, 2021 2:12 AM To: Maureen Hilyard<mailto:maureen.hilyard@gmail.com>; Jonathan Zuck<mailto:JZuck@innovatorsnetwork.org> Subject: Re: Engagement on DNS Abuse Great stuff Jonathan, as always. Feel free to share. If I were to add my two cents, I'd put these in the "pain points" section while these are of a more general nature. "From the discussions we've had within At-Large it is clear that the very scope and definition of DNS Abuse is a "pain point". This was also the take away from the discussions we've had with the invited guests from within and beyond the ICANN community. "DNS Abuse" as it is now defined in the proposed Framework affects the entire internet community of end users while being already covered by existing national and international norms and standards. Keeping these in mind the proposed definition and scope of DNS Abuse strikes as arbitrary: what were the criteria set for selecting these specific categories as DNS Abuse while leaving other potential categories out? This is particularly relevant with regard to our second concern: the proposed scope of DNS Abuse clearly crosses the content "picket fence" that the ICANN community had set for itself. Including IP infringement on equal footing with CSAM raises serious concerns among At-Large members. We are concerned not only with the very fact of the picket fence being crossed but also by the way in which this is being done. Does this mean we should finally abandon the well established yet always controversial narrative of a strictly technical infrastructure management? Once content is concerned, the existing and proposed practice fails to recognize international legal safeguards when it comes to restrictions put on individual freedoms. Whenever an individual liberty is to be restricted, due process must be ensured. The procedures proposed by the DNS Abuse framework fail to ensure e.g. a right to an effective legal remedy. While we realize this argument brings us back tot he general discussion on limits of ICANN's contractual jurisdiction, that is an argument we would be interested to during any upcoming DNS Abuse work. Only once these concerns relating to the scope of the definition of DNS Abuse can be addressed, can we focus on metrics and effective enforcement that will provide a fair and operational framework protecting the rights of end users." By all means to feel free to rephrase!:) What I'm arguing for is that for us to be able to "measure" DNS Abuse we should first clearly and transparently decide what it means. The current framework means the contracted parties are indeed trying to play a self-proclaimed internet police (militia?). Why did we presume DNS Abuse is CSAM and (in the same breath) fake Gucci bags but not hate speech and inciting violence? While we clearly would not have the answer ready, that is definitely a discussion we should have. The GAC might be interested in this as well (see last update from Veni on the ITU processes). Thanks for considering team! Best, J. W dniu 27.01.2021 o 01:39, Maureen Hilyard pisze: In your inimitable style. Love it. Send it. M On Tue, Jan 26, 2021 at 12:34 PM Jonathan Zuck <JZuck@innovatorsnetwork.org<mailto:JZuck@innovatorsnetwork.org>> wrote: Ladies, Here’s my draft response. Let me know what you think! Jonathan ============================================================= Hey folks! Thanks for reaching out. Joanna and I, for sure, would be willing to join you and I suspect others, as well, once we know the timing. With respect to the questions below, I’ll do my best to provide some initial responses but I suspect the first question might be pivotal. There seems to be a lack of real data on the topic and perhaps some additional objective research is the answers. We endeavored to begin this process, during the CCTRT (sadag-final-09aug17-en.pdf (icann.org)<https://www.icann.org/en/system/files/files/sadag-final-09aug17-en.pdf>, but obviously barely scratched the surface. Perhaps a more comprehensive study, funded by ICANN rather than the CPH or CSG might be in order? I know DAAR provides some answers but it seems to be more of a survey than an example of rigorous research. Specifically to your questions. 1. What information do you use and how do you use it to assess DNS Abuse levels? This is obviously where we are weak. There doesn’t appear to be a great source for DNS Abuse “levels,” particularly because of the short time period over which a particular initiative takes place. A snapshot analysis doesn’t seem to get the full picture. The ALAC relies on the concerned raised by the GAC and the SSAC to fuel our belief that there’s more we should be doing. A recent report from Microsoft suggests the problem is bigger than we realize and David Taylor’s analysis of “responsiveness,” even among those who have signed onto the framework, seems damning. 2. What are the ALAC’s pain points regarding DNS Abuse? Not sure to answer this in terms of how it’s handled inside ICANN or more generally from where our interests stems. To the latter point, we’re tasked with advancing the interests of those not represented by a constituency in the GNSO, namely those engaged in everyday use of the internet, as opposed to registrants. As the user base continues to grow, as we all desire, so too will the numbers of less sophisticated users, more easily duped by a phishing, malware or fraudulent advertising attack. As for the situation inside ICANN, the At-Large community have attempted to engage constructively as opposed to “attacking” the CPH, focusing instead on so-called “bad actors.” The first session<https://community.icann.org/display/atlarge/At-Large+Meetings+-+Monday%2C+09+March+2020?preview=/124847126/126428447/CCWholistic02.pdf> was an attempt to bring the CPH and Contract Compliance into the same room to figure out where the holes are. * What exactly are the relevant limits on Contract Compliance? We feel this is a question which comes up constantly and is never successfully or consistently answered. It seems to be an area in which the ICANN community is constantly chasing it’s tail. It would seem that the only real enforced contract provision is payment. I’m sure this is an exaggeration but it seems to be a repeated situation where that is ultimately what foils a “ bad actor” after YEARS of neglect, if not outright facilitation of abuse. The answer to THIS question should be a HIGH priority. It might just be agreeing to an interpretation of the contracts or it might require an amendment to the contracts but this issue needs to stop being a merry go round. * Insufficient Transparency from Contract Compliance Contract Compliance undocumented endeavors at soft touch diplomacy with bad actors seem to need some better limits or, at least, transparency. For “the market” to play a role in this, knowing about legitimate complaints for every contracted party could help customers make better decisions about which businesses to use and help us better understand where policy development needs to take place. * Deflection and Minimization of the Problem I would say that one “pain point” is that our efforts have been largely “trolled” by certain members of the CPH, rather than engaging constructively. EVEN our effort to conceive of some sort of end user education campaign, to take the pressure off the CPH, was trolled. Jim, not to put you on the spot but, during one conversation, you said you didn’t even understand why this was being discussed because it affects such a small percentage of registered names. To date, we have proposed: i. Better contract enforcement ii. More tools for Contract Compliance iii. DNS Abuse “threshold,” an idea that found some support among the CPH at one point iv. Predictive Analytics platform, perhaps financed by ICANN The At-Large community has absolutely no desire to over regulate or over tax the CPH and we understand most of the contracted parties, particularly those showing up to meetings, are trying to do well and continuously improve. That said, this notion that it’s somehow not “our place,” to be trying to help is nothing short of offensive. It is the active participation of the ALAC and GAC that enable the ICANN to portray itself as something other than a trade association. The At-Large mandate is to advance the interests of those MOST impacted by DNS Abuse. That said, we WELCOME suggestions on how better to engage with the CPH for constructive outcomes. 1. Are you seeing practices from registrars or registries you find helpful? If we haven’t said it enough, the At-Large appreciates the efforts of those behind the Framework for DNS Abuse and the huge efforts that went into cooperation with law enforcement to track down COVID related abuse. We’d love to see the framework evolve to include specific commitments and metrics, however, for it to be something on which the community could truly rely. We hope these answers are constructive and not inflammatory as it is our intention to find the most effective ways to proceed to further minimize the incidence of DNS Abuse , in all its forms. Thanks for the opportunity to be part of your conversation. Maureen, Joanna & Jonathan From: Keith Drazek <kdrazek@verisign.com<mailto:kdrazek@verisign.com>> Date: Friday, January 22, 2021 at 12:00 PM To: "maureen.hilyard@gmail.com<mailto:maureen.hilyard@gmail.com>" <maureen.hilyard@gmail.com<mailto:maureen.hilyard@gmail.com>>, Jonathan Zuck <JZuck@innovatorsnetwork.org<mailto:JZuck@innovatorsnetwork.org>>, "jkuleszaicann@gmail.com<mailto:jkuleszaicann@gmail.com>" <jkuleszaicann@gmail.com<mailto:jkuleszaicann@gmail.com>> Cc: "Brian F. Cimbolic" <BCimbolic@pir.org<mailto:BCimbolic@pir.org>>, Jim Galvin <jgalvin@afilias.info<mailto:jgalvin@afilias.info>>, Graeme Bunton <gbunton@tucows.com<mailto:gbunton@tucows.com>> Subject: Engagement on DNS Abuse Hello Maureen, Jonathan and Joanna, I hope you’re all doing well and staying healthy and safe. I am reaching out to you on behalf of the Contracted Party House DNS Abuse Working Group as we look ahead to ICANN 70 and the rest of 2021. The Contracted Party House (CPH) DNS Abuse Group is conducting outreach to our friends in other SO/AC/SG/Cs regarding DNS Abuse. As previously noted by the CPH, DNS Abuse<https://rrsg.org/wp-content/uploads/2020/10/CPH-Definition-of-DNS-Abuse.pdf> comprises five categories: phishing, pharming, malware, botnets, and spam when it acts as a delivery mechanism for one of the other forms of DNS Abuse. We want to open a more direct dialogue to understand pain points, hear suggestions and identify common ground where we can work together to mitigate DNS Abuse. Is there a subset of the At-Large focusing on DNS Abuse questions that would be able to join the CPH DNS Abuse group on a call to discuss this topic? We want to encourage frank and productive discussions on the topic that lead to really informing our dialogues and actions. As a starting point, we propose the following questions to guide our discussion. Are there any other questions ALAC would like discuss?: What information do you use and how do you use it to assess DNS Abuse levels? What are the ALAC’s pain points regarding DNS Abuse? Are you seeing practices from registrars or registries you find helpful? Please let us know if a subgroup of the ALAC would be willing to join us. Our group meets regularly on Tuesdays at 1500 UTC. If so, please propose a Tuesday when you are available. Best regards, Keith Keith Drazek Vice President, Public Policy & Government Relations Verisign, Inc. +1-571-377-9182 Kdrazek@verisign.com<mailto:Kdrazek@verisign.com> -- Kind regards, Joanna Kulesza ------------------- Joanna Kulesza, PhD University of Lodz, Poland ICANN ALAC Vice Chair SOI: https://community.icann.org/display/atlarge/Joanna+Kulesza+SOI TT: @KuleszaJ _______________________________________________ CPWG mailing list CPWG@icann.org<mailto:CPWG@icann.org> https://mm.icann.org/mailman/listinfo/cpwg _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ CPWG mailing list CPWG@icann.org<mailto:CPWG@icann.org> https://mm.icann.org/mailman/listinfo/cpwg _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
participants (10)
-
Carlton Samuels -
David Mackey -
Evan Leibovitch -
Joanna Kulesza -
John McCormac -
Jonathan Zuck -
Laurin B Weissinger -
Roberto Gaetano -
Roberto Gaetano -
Theo Geurts