View source for ICANN 71

{{ICANNMeetings|
| logo            = ICANNLogo.png
| dates           = June 14-17, 2021
| location        = The Hague, NL 
| host             = 
| venue        = Virtual
| website      = https://71.schedule.icann.org/ 
| totalregistrants =
| registration    = 
| keyappointments       = 
| historicalimport   = 
}}

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


==Meetings==
===Plenaries===
====Multistakeholder Model Evolution====
The discussion mainly focused on:
* The pros and cons of encouraging or permitting adversarial interactions <br/>
::[[Ron Andruff]] proffered, "The [[Consensus Policy|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." 
* Whether ICANN's role in [[Internet Governance]] should be streamlined <br/>
::[[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 <br/>
::[[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 <br/>
:: [[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====
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:
* The effort to increase [[Cybersecurity]] in Europe with the Proposal for a Regulation on a Single Market For Digital Services ([[DSA|Digital Services Act]]), the [[EC]] proposals (to correct or) enhance the GDPR, Proposal for a Directive on measures for a high common level of cybersecurity across the Union ([[NIS2]]), [[SSAD]], and how to go beyond ICANN's [[Contracted Party House]] <br/>
::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.” 
*[[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====
This plenary was guided by the objective of helping the ICANN community understand [[RBL]]s: what they are, how they're made, what they can be used for, obstacles, and advances. Three people ([[Carel Bitter]], [[Roman Huessy]], and [[Ben Coon]]) from the RBL field were interviewed by the moderator ([[LG Forsberg]]). A cybersecurity expert from ICANN's [[OCTO]] ([[Samaneh Tajalizadehkhoob]]), the vice-chair of [[M3AAWG]] ([[Matt Thomas]]), the co-chair of ICANN's DNS Abuse working group ([[Reg Levy]]), and the co-vice chair of [[ALAC]] [[Joanna Kulesza]] also spoke. <br/>
''The panel discussed:''
* Whether the lists are maintained through automation or by humans
:: The datasets are generally automated but humans spot-check URLs that don’t score high enough to be included in the RBL, add/remove them from the lists, and verify false positives.
* The frequency of false positives, and the most common reasons behind them
:: Most malware is sent through email; using shorteners in emails is [[Phishing|phishy]] behavior. False positives are not very common. The most common reasons are that in emails, readers don't understand what is malicious or they don’t like what they see; so, they report it.
* Why RBL providers do not share information with each other
:: They use different methodologies, look for different types of abuse, and do not want to publish their findings when there are not mitigation mechanisms
* Why evidence is not included in RBLs
:: Including evidence is not possible at scale (2-3K emails/second) because it would reveal [[Honeypots]]
''Critiques and concerns included:''
:: Reg Levy: false positives;
:: Joanna Kulesza: end users ending up on RBLs and transparency on criteria.
:: [[John McCormac]]: Detection versus reporting may be a limiting factor for RBLs, which in turn may always be behind the curve. "One possible metric that could help some RBLs would be whether a domain name was registered at full fee or at a heavy discount. It might be a bit of a meta-metric. In terms of webspam doms, the patterns in new gTLDs from web usage surveys revealed that 95% of them were gone within a year, locking registries into a kind of discount addiction to survive." 
:: [[Crystal Ondo]]: the difference between maliciously registered vs hacked domains needs to be underscored. "A lot of domains that end up on RBLs are victims themselves, not bad actors. Further muddying the waters." 
:: Roman Hussey: RBLs, such as [[Abuse.CH]], do not have a way to determine whether a domain name is a victim of a compromise or registered for malicious purposes for two reasons: Missing [[Whois]] (not registrant data, but the sponsoring registrar and registration data) and missing p[[DNS]] data (when the domain name was first observed).

===Policy===
====GNSO====
The GNSO held 18 sessions.
* [[Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data (EPDP)|EPDP Phase 2A Update]]<br/>
:Two outstanding issues:
# Legal vs. natural persons<br/>
#::Consensus is unlikely
#::NIS2 will require the distinction and must publish legal data, leading to an unequal playing field. Those subject to EU regulations will have to and others will not.
# Feasibility of unique contacts/anonymized emails: possible policy stances include that they are feasible, required, suggested with guidance, or not at all.
* GNSO [[Policy Development Process to Review the Transfer Policy]] [[WG]]
: The session was dedicated to determining PDP Goals, specifically around the retention/overall security of [[Transfer Authorization Code]] (TAC). The hope is that if the TAC is strong enough, the WG could recommend eliminating [[FOA]]s. The WG decided to include a request to tech ops to determine whether TACs would be secure enough to ensure that the requesting registrant owns the domain in question. [[James Galvin]] raised several questions about the TAC mechanism. He asked about specifications such as one-time use, lifetime, and length. Galvin also reminded the group that ICANN uses FOAs for a paper trail as security/authorization. If the WG wants to recommend using TACs, it will have to be properly implemented to be as secure as possible. [[Roger Carney]] said that the goal is to remove or make optional FOAs and only use the code (TAC), which has been used for the last 3 years. There was also a discussion over the metrics for determining the secureness of TACs. There is anecdotal evidence but by security principles, the mechanism is not yet entirely secure.

=====Contracted=====
======RrSG======
* 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.
* [[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.
======RySG======
'''GeoTLD Group Community Session'''
'''Brand Registry Group'''

=====Non-Contracted=====
======BC======
The [[BC]] listened to a talk about a recent [[M3AAWG]] [https://community.icann.org/x/kYO1CQ survey] by [[Severin Walker]] and [[Laurin Weissinger]]. 
The Names and numbers Committee (FKA the DNS Abuse Committee) oversaw the WHOIS survey. 
The results:
* From 2018 to 2021, there was a drop in [[Cybersecurity]] users of whois and an increase in [[IP]] users and lawyers.  
* Out of 4000 members, 277 participants responded,  indicating a 7% response rate.
* Nearly 71% said the temporary specification in response to the GDPR has led them to exceed the acceptable threshold for mitigating threats, which was up by 5 % since 2018.
* Respondents said they are having to wait longer for redacted data.
* 76% are dissatisfied with [[ICANN]]'s [[Contractual Compliance]] response to disclosure complaints.

======ISPCPC======
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 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.
[[Jeffrey Bedser]] from the [[SSAC]] explained [[SAC115]] to the audience. 
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
# Escalation paths in response to reporters sending complaints to the wrong point of responsibility
# Universal standards for evidence (types include: temporal, visual, behavioral, and demonstrative) 
# Acceptable response timeframes
# Availability of quality contact info (not natural, legal) <br/>
The framework stays away from terms of criminality to avoid jurisdictional issues.

======NCSG======
At the Policy Committee Meeting, the members discussed: 
* The GNSO Action Decision Radar (ADR);
* The framework for continuous improvement as a pilot project;
* [[Marika Konings]]'s explanation that the [[GAC]] does not appoint liaisons because no one can speak for the GAC, only the GAC Chair can do so;
* The [[IDN]] operational track and how can the NCSG can participate, as they may gain knowledge but may not have the skills to contribute;
* [[Whois]] accuracy: [[Stephanie Perrin]] said all the old issues are going to resurface;
* Perrin celebrated that GAC has become much more involved. However, she raised the concern that the GAC liaison is supposed to be a diplomatic position, and the incumbent ([[Jeff Neuman]], GNSO Liaison to the GAC) is very, very active, which may lead to GAC affecting the GNSO. Thus, it was argued that they have got to better define the role of liaison because the position has become an ad hoc counselor and that they need a clear job description; and,
* EPDP Phase 2A: NCSG has a position in the initial report, which is that it is difficult to determine who is a legal person.

====ccNSO====
The ccNSO held eight sessions. 
# 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. 
# The ccPDP4 working group discussed the principles for [[IDN]] [[ccTLD]]s determination, focusing on questions about: 
#* how to define territory; 
#* the relationship 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====
Did not meet at ICANN 71.

===Advice===
====GAC====
#[[Brian Beckham]] from [[WIPO]] presented on [[Protection of IGO and INGO Identifiers in All gTLDs Policy|IGO protection]]. There is the UDRP option, but IGOs cannot really use it. The privileges of IGOs conflict with the [[UDRP]]. Thus, IGOs cannot take action on bad faith domain uses of their IGO names. The GAC is in charge of maintaining the list of IGOs that was generated March 2013. Due to the principle of coexistence, and international trademark treaties (such as the Paris treaty) means a notification should be sent to an IGO if new gTLDs in the future lead to domain name confusions. Currently, a moratorium is in place.  

The questions are whether to lift the moratorium, create alternatives to the UDRP for IGOs, and when to shift to post-registration notification. 
[[Chris Disspain]] is overseeing these developments.
#SubPro on sub rounds of nTLDs
[[Lars Hoffmann]] gave a description of the [[ODP]] , including what is needed to trigger a vote on whether to do an ODP at all. The [[ICANN Board]] decides if recommendations are complex enough, triggering an ODP.

====ALAC====
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====
[[SAC115]]
====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.
	
=====DNSSEC & Security=====
* [[Jacques Latour]] spoke about [[Internet of Things]] (IoT) Device Identity Management. IoT devices appear to work very similarly to domains in terms of [[DNSSEC]], and his team wants to make DNSSEC integral to IoT security.
* [[Daniel Migault]] spoke about the [[Transport Layer Security]] (TLS) [https://developer.apple.com/news/?id=g9ejcf8y Identity Pinning protocol], which is meant to ensure that users have a confidential channel with an authenticated peer. It is a complementary way to authenticate in addition to the DNSSEC protocol. It is being developed to be used for critical infrastructure (and not necessarily regular end users). Whereas DNSSEC is a trust-based quest for information, TLS establishes a session based on existing information. TLS is about the communication users are establishing with an entity, while DNSSEC is about the information users are asking about the entity with which they're establishing a session.
* [[Steve Crocker]] discussed two gaps in original DNSSEC protocol specifications:
# Automation of DS Updates <br/> The question is how to convey DS from 3rd party DNS providers to Registrars or Registries
# 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]]