Jump to content

ICANN 72: Difference between revisions

From ICANNWiki
Jessica (talk | contribs)
Jessica (talk | contribs)
Line 24: Line 24:
* [[Interisle]] gave a presentation to the [[BC]] on its [https://www.interisle.net/PhishingLandscape2021.html ''Phishing Landscape 2021''].
* [[Interisle]] gave a presentation to the [[BC]] on its [https://www.interisle.net/PhishingLandscape2021.html ''Phishing Landscape 2021''].
* [[Goran Marby]] pointed to [[DNS Security Facilitation - Technical Study Group]] recommendations as an indication of the 12 steps ICANN could take in [[DNS Abuse Responses|response]] to [[Cybersecurity]] if not directly [[DNS Abuse]]
* [[Goran Marby]] pointed to [[DNS Security Facilitation - Technical Study Group]] recommendations as an indication of the 12 steps ICANN could take in [[DNS Abuse Responses|response]] to [[Cybersecurity]] if not directly [[DNS Abuse]]
* The [[Policy Development Process to Review the Transfer Policy|GNSO Transfer Policy Review PDP Working Group]] focused on enhancing security without limiting options for verification


===SubPro===
===SubPro===
Line 57: Line 56:
===Data Accuracy===
===Data Accuracy===
* The GNSO Council created a Registration Data Accuracy Scoping Team to consider current enforcement and reporting; measurement of accuracy, and effectiveness<ref>[https://community.icann.org/display/gnsocouncilmeetings/Registration+Data+Accuracy+Scoping+Team+-+ICANN72 RDA Scoping Team, GNSO Council Meetings]</ref>; this meeting spent a significant amount of time discussing the [https://www.icann.org/resources/pages/raa-whois-accuracy-2015-11-16-en definition of accuracy] and spent a little bit of time on determining [https://community.icann.org/download/attachments/175244888/Working%20draft%20-%20Discussion%20timeline%20-%20upd%2022%20October%202021.pdf how much time each step will take] to answer whether changes should be recommended to improve accuracy levels; how and by whom they would be developed; and whether existing contractual requirements may necessitate a PDP or contractual negotiations.
* The GNSO Council created a Registration Data Accuracy Scoping Team to consider current enforcement and reporting; measurement of accuracy, and effectiveness<ref>[https://community.icann.org/display/gnsocouncilmeetings/Registration+Data+Accuracy+Scoping+Team+-+ICANN72 RDA Scoping Team, GNSO Council Meetings]</ref>; this meeting spent a significant amount of time discussing the [https://www.icann.org/resources/pages/raa-whois-accuracy-2015-11-16-en definition of accuracy] and spent a little bit of time on determining [https://community.icann.org/download/attachments/175244888/Working%20draft%20-%20Discussion%20timeline%20-%20upd%2022%20October%202021.pdf how much time each step will take] to answer whether changes should be recommended to improve accuracy levels; how and by whom they would be developed; and whether existing contractual requirements may necessitate a PDP or contractual negotiations.
===Transfer Policy===
* The [[Policy Development Process to Review the Transfer Policy|GNSO Transfer Policy Review PDP Working Group]] focused on enhancing security without limiting options for verification
* In the [[SSAC]] Public Meeting, [[Steve Crocker]] presented SAC119, which concerns two security risks:
# A domain name can experience a discontinuity of DNS resolution and [[DNSSEC]] validation if the transfer of [[:Category:DNS Services|DNS Services]] is not considered during the process.
# A domain name is more at risk of being [[Domain Name Hijacking|hijacked]] if the authInfo code is not managed based on best practice security principles.


==References==
==References==
{{reflist}}
{{reflist}}
[[Category:ICANN Meetings]]
[[Category:ICANN Meetings]]

Revision as of 15:46, 3 November 2021

Dates: Prep Week: October 12-14, 2021

AGM: October 25-28, 2021

Location: Seattle, WA
Venue: Virtual
Website: ICANN 72 (registration required)

ICANN 72 was the annual general meeting for 2021, held in October. The meeting was fully virtual in response to the COVID-19 pandemic. The meeting schedule was based on the time zone of the intended host city, Seattle.[1] Note that users must be logged in to their ICANN account in order to view information about meeting sessions, transcripts, and archived video and audio.

Board Composition & Leadership[edit | edit source]

As with every annual general meeting, a number of board members ended their terms of service: Ron da Silva (ASO), Lito Ibarra (NomCom), Merike Käo (SSAC Liaison), and Nigel Roberts (ccNSO) concluded their terms on the board.[2] Alan Barrett (ASO), Edmon Chung (NomCom), James Galvin (SSAC Liaison), and Katrina Sataki (ccNSO) were elected to the board during the organizational meeting.[3]

Themes[edit | edit source]

Interacting with Governments[edit | edit source]

DNS Abuse[edit | edit source]

SubPro[edit | edit source]

In the GAC Discussions on Subsequent Procedures, Karen Lentz explained that a version of the ODP generally happens anyway following the ICANN Board's reviewing of a Consensus Policy; now it has just been formalized. Likewise, the funding is not outside of what is already happening; rather, it reflects processes that are or would happen as ICANN Organization determined next steps toward implementation (or not).

There were several discussions around incorporating responses to DNS Abuse into the Contractual Compliance obligations of the next round.

Universal Acceptance[edit | edit source]

SSAD[edit | edit source]

On 17 May 2018, the ICANN Board approved the Temporary Specification for gTLD Registration Data to allow contracted parties to comply with ICANN contractual requirements while also complying with the European Union's General Data Protection Regulation, triggering a GNSO Council initiation of a PDP on 19 July 2018. Phase 1 was to confirm the Temporary Specification by 25 May 2019. Phase 2 was chartered to discuss a standardized access model to nonpublic registration data, aka SSAD.[4]

  • ALAC expressed unhappiness to the ICANN Board over SSAD ODP, EPDP phase 2 recommendations, emphasizing SSAD would probably not be worth the cost and would run into trouble with NIS2 when passed.
  • The BC was presented with a model and demo capable of supporting both sides of the SSAD challenge. It provides the verifiable claims to support the evaluation of requests from requesters and allows the logic engine to evaluate the lawfulness of the request, even if the backend remains manual on the registrar side.
  • In the SSAC Public Meeting, Steve Crocker presented a summary of SAC118's three recommendations.[5]
  1. The GNSO and ICANN Organization should focus on building and operating a timely, reliable, effective, and efficient differentiated access system for competing interests.
  2. to address issues around legal/natural personal registration data:
    1. There should be a data element to denote the legal status of the registrant, which can be displayed as publicly available data;
    2. at the time of new domain registration, registrars should be required to classify all registrants as natural or legal persons;
    3. Registrants should continue to have the option of making their contact data publicly available; and
    4. Legal person registrants should be able to protect their data via privacy and proxy services.
  3. On Pseudonymizing Email Contacts:
    1. separate the ability to quickly, effectively contact registrants without disclosing personal data from helping investigators correlate registrations with contact information;
    2. registrars should support registrant-based email contact and develop safeguard requirements for them;
    3. EPDP Phase 2A should not specify a method for correlating registrations with contact information

Prioritization[edit | edit source]

Data Accuracy[edit | edit source]

  • The GNSO Council created a Registration Data Accuracy Scoping Team to consider current enforcement and reporting; measurement of accuracy, and effectiveness[6]; this meeting spent a significant amount of time discussing the definition of accuracy and spent a little bit of time on determining how much time each step will take to answer whether changes should be recommended to improve accuracy levels; how and by whom they would be developed; and whether existing contractual requirements may necessitate a PDP or contractual negotiations.

Transfer Policy[edit | edit source]

  1. A domain name can experience a discontinuity of DNS resolution and DNSSEC validation if the transfer of DNS Services is not considered during the process.
  2. A domain name is more at risk of being hijacked if the authInfo code is not managed based on best practice security principles.

References[edit | edit source]