Jump to content

ICANN 71

From ICANNWiki
Revision as of 17:23, 21 June 2021 by Jessica (talk | contribs) (GNSO)
Dates: June 14-17, 2021
Location: The Hague, NL
Venue: Virtual
Website: https://71.schedule.icann.org/


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.


Meetings[edit | edit source]

Plenaries[edit | edit source]

Multistakeholder Model Evolution[edit | edit source]

The discussion mainly focused on:

  • The pros and cons of encouraging or permitting adversarial interactions
Ron Andruff proffered, "The consensus model needs to be revised from meeting the highest standard: Full Consensus, to the next level: General Consensus with dissenting opinions. That change would better inform the debates."
Jorge Cancio said, "We stay in the weeds now" (as compared with work as recent as 2008) and argued that “ICANN should stay at the principle level, lean, and future proof.”
  • The backlog of unimplemented policies, some of which are now out-of-date or conflict with current work
Mason Cole worried "How big a danger to the model is unfinished work? The community has expectations regarding completing work...the SSR1 recommendations are nearly a decade old...This is like dragging weight around unnecessarily." Likewise, James Bladel said, "There is too much emphasis on process and not enough on relevance."
  • How ICANN can better involve the Global South
Claire Craig explained that ICANN must work with governments in developing nations, as they are the key access points. There are few if any capacity-building programs there, and the ICANN communities are too small; it's about striving toward equity, not equality. Jovan Kurbalija agreed, suggesting that the model should 1) embrace the public good aspect of ICANN (it's not just commercial); 2) that the pandemic made governments much stronger as it did tech; 3) ICANN should work with IGF to get more involved with politics because it’s trying to exist too far from the political center; and 4) ICANN needs to educate the general public to gain prominence via boundary spanners.

Impact of Regulatory Developments[edit | edit source]

The conversation was supposed to be general but time and again the questions drove the dialogue back to the GDPR. In its constellation, speakers addressed:

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 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

Reputation Block Lists[edit | edit source]

Policy[edit | edit source]

GNSO[edit | edit source]

  • GNSO: EPDP Phase 2A Update
Two outstanding issues:
  1. legal vs. natural persons
  2. feasibility of unique contacts/anonymized emails
Contracted[edit | edit source]
RrSG[edit | edit source]
  • 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 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.
Non-Contracted[edit | edit source]
BC[edit | edit source]
ISPCPC[edit | edit source]
IPC[edit | edit source]
NCSG[edit | edit source]

ccNSO[edit | edit source]

The main section of the meeting was dedicated to discussing the principles for IDN ccTLDs determination. There were questions about:

  • how to define territory;
  • the relations with ISO3166-1 code;
  • 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[edit | edit source]

Did not meet at ICANN 71.

Advice[edit | edit source]

GAC[edit | edit source]

ALAC[edit | edit source]

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[edit | edit source]

SAC115

RSSAC[edit | edit source]

DNSSEC & Security[edit | edit source]