Changes

{{ICANNMeetings|

{{ICANNMeetings|

| logo            = ICANNLogo.png

| logo            = ICANN71logo.PNG

| dates          = June 14-17, 2021

| dates          = June 14-17, 2021

| location        = The Hague, NL  

| location        = The Hague, NL  

| host            =  

| host            =  

| venue        = Virtual

| venue        = Virtual

| website      = https://71.schedule.icann.org/  

| website      = [https://71.schedule.icann.org/ ICANN 71] (registration required)

| totalregistrants =

| totalregistrants =

| registration    =  

| registration    =  

}}

}}

'''ICANN 71''' was a [[Policy Forum]] that was held from June 14 to June 17, 2021, virtually, due to the Covid-19 pandemic. It was supposed to have taken place in The Hague, the Netherlands. Although there was a prominent, well-attended plenary concerning [[ICANN]]'s [[Multistakeholder Model]], the vast majority of sessions were dedicated to either ICANN's response to regulatory developments in Europe or [[DNS Abuse]] mitigation.

'''ICANN 71''' was a [[Policy Forum]] that was held from June 14 to June 17, 2021, virtually, due to the Covid-19 pandemic. It was supposed to have taken place in The Hague, the Netherlands. Although there was a prominent, well-attended plenary concerning [[ICANN]]'s [[Multistakeholder Model]], the vast majority of sessions were dedicated to either ICANN's response to regulatory developments in Europe or [[DNS Abuse]] mitigation. More than 1300 people attended from 147 countries and territories.<ref>[https://www.icann.org/en/blogs/details/a-preview-of-icann71-participation-metrics-21-6-2021-en ICANN.org Blog - A Preview of ICANN 71 Participation Metrics], June 21, 2021</ref>

::For instance, [[Volker Greimann]] asked, "Why is NIS2 focussing on [[DNS]] as opposed to hosting, e.g, where the content is? Why are Hosters not subjected to the same requirements?"

::For instance, [[Volker Greimann]] asked, "Why is NIS2 focussing on [[DNS]] as opposed to hosting, e.g, where the content is? Why are Hosters not subjected to the same requirements?"

*[[Paul Muchene]] and [[Jeff Neuman]] had a side discussion about [[RDAP]]. Paul: doesn’t it already do what these proposals seek? Jeff: RDAP is a technical protocol. It is policy agnostic.”  

*[[Paul Muchene]] and [[Jeff Neuman]] had a side discussion about [[RDAP]]. Paul: doesn’t it already do what these proposals seek? Jeff: RDAP is a technical protocol. It is policy agnostic.”  

*[[Alexander Seger]], representing the European Council, gave an update on the 2nd Additional Protocol to the Budapest Convention on Cybercrime on enhanced cooperation and disclosure of electronic evidence Budapest convention on cybercrime (the [[Budapest Convention]]), which has 66 member parties and concerns criminal law, not civil

*[[Alexander Seger]], representing the [[EC|European Council]], gave an update on the Second Additional Protocol to the [[Budapest Convention]] on Cybercrime on enhanced cooperation and disclosure of electronic evidence Budapest convention on cybercrime, which has 66 member parties and concerns criminal law, not civil.

====Reputation Block Lists====

====Reputation Block Lists====

===Policy===

===Policy===

====GNSO====

====GNSO====

* [[Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data (EPDP)|EPDP Phase 2A Update]]<br/>

* [[Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data (EPDP)|EPDP Phase 2A Update]]<br/>

:Two outstanding issues:

:Two outstanding issues:

* Last year the RrSG became a formal professional (as opposed to commercial) association, and they held their first General Assembly at ICANN 71. Their legal office is located in Germany ([[Thomas Rickert]] Law Firm) so that they can have their own bank account and credit card.

* Last year the RrSG became a formal professional (as opposed to commercial) association, and they held their first General Assembly at ICANN 71. Their legal office is located in Germany ([[Thomas Rickert]] Law Firm) so that they can have their own bank account and credit card.

* [[Liz Behsudi]] from the [[I&JN]] gave a presentation on the think tank's [https://www.internetjurisdiction.net/domains/toolkit  DNS Abuse toolkit]. She discussed legal interoperability, the think tank's three foci, domains, content, and data, the importance of different thresholds for responses to DNS Abuse and understanding the typology of notifiers, and why the EU electronic evidence proposal may affect whois data.

* [[Liz Behsudi]] from the [[I&JN]] gave a presentation on the think tank's [https://www.internetjurisdiction.net/domains/toolkit  DNS Abuse toolkit]. She discussed legal interoperability, the think tank's three foci, domains, content, and data, the importance of different thresholds for responses to DNS Abuse and understanding the typology of notifiers, and why the EU electronic evidence proposal may affect whois data.

* [[Graeme Bunton]] presented on developments at the [[DNS Abuse Institute]], which is following the logic that there are two ways to reduce DNS abuse: # prevent it or # react to it. Bunton explained that economic realities indicate that there should be more emphasis on reactive solutions because they don’t have to be integrated into current technology. He also discussed [[CART]], which will include domain look-up, who’s reporting, type of malware/spam, and required information so that registrars can get information about abuse complaints from [[API]] and reporters can go to one place. He hopes it will be new, improved [[DAAR]], non-binary, better, fairer, and more concerned with the persistence than the existence of abuse.

* [[Graeme Bunton]] presented on developments at the [[DNS Abuse Institute]], which is following the logic that there are two ways to reduce DNS abuse:  

# prevent it or  

# react to it.  

Bunton explained that economic realities indicate that there should be more emphasis on reactive solutions because they don’t have to be integrated into current technology. He also discussed [[CART]], which will include domain look-up, who’s reporting, type of malware/spam, and required information so that registrars can get information about abuse complaints from [[API]] and reporters can go to one place. He hopes it will be new, improved [[DAAR]], non-binary, better, fairer, and more concerned with the persistence than the existence of abuse.

 

=====Non-Contracted=====

=====Non-Contracted=====

This session included a discussion on CSG priorities, namely:  

This session included a discussion on CSG priorities, namely:  

*The BC wants the recommendations to lower DNS abuse to be connected with the trigger to open the next round of new gTLDs. The ISPCPC does not support tying the two.

*The BC wants the recommendations to lower DNS abuse to be connected with the trigger to open the next round of new gTLDs. The ISPCPC does not support tying the two.

*The factions of the CSG all agree that [[ATRT3]] recommendations must move forward.  

*The factions of the CSG all agree that [[Accountability and Transparency Review Team|ATRT3]] recommendations must move forward.  

*DNS abuse is straining the CSG as a collective as the three subgroups do not agree on the significance of mitigating it and continue to focus on how to define it.

*DNS abuse is straining the CSG as a collective as the three subgroups do not agree on the significance of mitigating it and continue to focus on how to define it.

[[Jeffrey Bedser]] from the [[SSAC]] explained [[SAC115]] to the audience.  

[[Jeffrey Bedser]] from the [[SSAC]] explained [[SAC115]] to the audience.  

He gave credit to [[Suzanne Wolf]] for coming up with and/or emphasizing the need to find an interoperable solution for DNS abuse despite the differences in layers. <br/> The proposed framework outlines:

He gave credit to [[Suzanne Woolf]] for coming up with and/or emphasizing the need to find an interoperable solution for DNS abuse despite the differences in layers. <br/> The proposed framework outlines:

# Points of responsibility

# Points of responsibility

# Escalation paths in response to reporters sending complaints to the wrong point of responsibility

# Escalation paths in response to reporters sending complaints to the wrong point of responsibility

The framework stays away from terms of criminality to avoid jurisdictional issues.

The framework stays away from terms of criminality to avoid jurisdictional issues.

======NCSG======

======NCSG======

At the Policy Committee Meeting, the members discussed:  

At the Policy Committee Meeting, the members discussed:  

====ccNSO====

====ccNSO====

The main section of the meeting was dedicated to discussing the principles for [[IDN]] [[ccTLD]]s determination.

The ccNSO held eight sessions.

There were questions about:  

# The [[ccNSO Council]] adopted the third ccNSO Policy Development Process (ccPDP3) policy recommendations on the retirement of ccTLDs. The ccPDP3 developed a review mechanism for decisions pertaining to the delegation, transfer, revocation, and retirement of ccTLDs. The ccNSO identified decisions subject to a review mechanism and began exploring the requirements for the review mechanism itself.

* how to define territory;  

# The ccPDP4 working group discussed the principles for [[IDN]] [[ccTLD]]s determination, focusing on questions about:  

* the relations with ISO3166-1 code;

#* how to define territory;  

* why a "visual association" between the code and the territory in question is now written as a “meaningful representation of the territory”; and

#* the relationship with ISO3166-1 code;

* the difference between designated languages and official languages (the former is required, not the latter) because many languages are used within given territories but are not officially recognized. “Designated language” comes from the UN glossary and means it has legal status or serves as a language of administration.

#* why a "visual association" between the code and the territory in question is now written as a “meaningful representation of the territory”; and

#* the difference between designated languages and official languages (the former is required, not the latter) because many languages are used within given territories but are not officially recognized. “Designated language” comes from the UN glossary and means it has legal status or serves as a language of administration.

====ASO====

====ASO====

===Advice===

===Advice===

====GAC====

====GAC====

====ALAC====

====ALAC====

The key issues discussed in the ALAC meeting were: the prospects for [[SSAD]]; the [[U.S. Patent and Trademark Office v. Booking.com]] decision, the debate over whether domain names should be trademarked, and fears over the privatization of generic nouns; the potential policy implications of [[Verisign]]'s US Patent 10,979,384; and questions over why ICANN's GDPR response is talking so long: is it due to technical or policy complications?

The At-Large community held ten sessions about at-large policy, outreach, and operations.The key issues discussed in the ALAC meeting were: the prospects for [[SSAD]]; the [[U.S. Patent and Trademark Office v. Booking.com]] decision, the debate over whether domain names should be trademarked, and fears over the privatization of generic nouns; the potential policy implications of [[Verisign]]'s US Patent 10,979,384; and questions over why ICANN's GDPR response is talking so long: is it due to technical or policy complications?

 

====SSAC====

====SSAC====

[[SAC115]]

[[SAC115]]

====RSSAC====

====RSSAC====

The RSSAC held a working session to develop the "Requirements for Measurements of the Local Perspective on the Root Server System." The main debate was over whether the data (results from the tool) should be made publicly available. If the tool is primarily for root server operators then the team should drop the recursive operator language. Likewise, there were concerns over the [[RFC]] language used around “data repository users should publish their results.” RSOs just using it for their own needs may hesitate if they know their results will be published elsewhere. Public availability may be fine for researchers. [[Wes Hardaker]] suggested that there could be a button on the results page that says “publish results;” he has had good results with this type of button on a DNSSEC checking tool. Thus, he argued results publication should be opt-in, not opt-out. Conversely, [[Brad Verd]] argued that data results should be shared in exchange for using the service and that the notice that users can opt out can be included at the beginning or end of the process. [[Paul Hoffman]] reminded the group to emphasize that the tool is for information, not giving best/good evaluations or determinations.

The RSSAC held a working session to develop the "Requirements for Measurements of the Local Perspective on the Root Server System." The main debate was over whether the data (results from the tool) should be made publicly available. If the tool is primarily for root server operators then the team should drop the recursive operator language. Likewise, there were concerns over the [[RFC]] language used around “data repository users should publish their results.” RSOs just using it for their own needs may hesitate if they know their results will be published elsewhere. Public availability may be fine for researchers. [[Wes Hardaker]] suggested that there could be a button on the results page that says “publish results;” he has had good results with this type of button on a [[DNSSEC]] checking tool. Thus, he argued results publication should be opt-in, not opt-out. Conversely, [[Brad Verd]] argued that data results should be shared in exchange for using the service and that the notice that users can opt-out can be included at the beginning or end of the process. [[Paul Hoffman]] reminded the group to emphasize that the tool is for information, not giving best/good evaluations or determinations.

=====DNSSEC & Security=====

=====DNSSEC & Security=====

# Multiple DNS providers <br/> It is difficult to accommodate the transfer of DNS services from one provider to another because the effects may be worse than expected. Multi-signer protocol (RFC 8901) has been completed but there are many moving parts and things left to do  

# Multiple DNS providers <br/> It is difficult to accommodate the transfer of DNS services from one provider to another because the effects may be worse than expected. Multi-signer protocol (RFC 8901) has been completed but there are many moving parts and things left to do  

[[Category:ICANN Meetings]]

[[Category:ICANN Meetings]]