At-Large Session Reports from ICANN76

What happened?

Example: This session discussed....

What are the At-Large specific takeaways from this session? 

Example: At-Large is interested in...

What are the At-Large specific action items (next steps)?

Example: At-Large needs to... 

Sat, 11 Mar, 09:00-10:00

& 10:30-12:00

What happened

The EPDP-IDNs team continued its working sessions at ICANN76 with two sessions on Saturday. The topics discussed included:

• D1b - Single application fee & cumulative transaction fees
  
• E1 - Variant Labels of reserved names
• A Consolidated table of Consolidated Draft Phase 1 Recommendations is now available
• Second reading of draft text circulated prior to ICANN76 (We ran out of time to complete the second reading of the draft text).

Since the Phase 1 report of the EPDP is due by the end of April, the team increasing the number of meetings in April in order to complete the work.

Transfer Policy Review PDP Working Group (Sessions 1 & 2)

Session 1

• Recording
• Slide deck presented

Session 2

• Gap Analysis - Reversal of Inter-Registrar Transfers
• Recording

Sat, 11 Mar, 09:00-10:00

& 10:30-12:00

Session 1

What happened

A majority of the session was used to inform about the work done by the Working group for the GNSO Transfer Policy Review work done up to ICANN76.

Thereafter the session continued the deliberations of the Transfer Dispute Resolution Policy (TDRP). The TDRP has been discussed in the last two meetings prior to ICANN76.

Next Steps

At-Large has drafted a response to the GNSO TPR PDP request for early input to the charter questions for Phase 2. The proposal is to add to the WG deliberations for Phase 2 a possibility for the Registered Name Holder (RNH) to initiate a transfer dispute.

In the present TDRP the RNH cannot initiate a transfer dispute - the policy is “reserved” for the losing and gaining registrar.

The deadline for the response to the GNSO TPR PDP early input to Phase 2 is due on April 4, 2023, hence At-Large needs to decide if a formal request should be submitted before the deadline.

Session 2

What happened

The session was discussing questions raised by George Kirikos (Canadian domain investor. Not a member of the WG): 

1. The TDRP must be seen in connection with Change of Registrant (Phase 1b).
2. Current TDRP, 3.2.4(ii): If the Gaining Registrar is unable to provide a complete FOA with data matching that contained within the authoritative Whois database at the time of the transfer request, then the Dispute Resolution Panel shall find that the transfer should be reversed.
   The problem is that the Gaining registrar is unable to collect the data from the losing registrar.
3. Current TDRP, 3.2.4 vi and vii:
1. vi) Transfers from a Gaining Registrar to a third registrar, and all other subsequent transfers, are invalid if the Gaining Registrar acquired sponsorship of the domain name(s) at issue through an Invalid Transfer, as determined through the dispute resolution process set forth in this Transfer Dispute Resolution Policy.
2. vii) In the event the Dispute Resolution Panel determines that an Invalid Transfer occurred, the domain shall be transferred back to the registrar that was Registrar of Record immediately prior to the Invalid Transfer.

These are important questions that the working group MUST take this into consideration when discussing Change of Registrant (CoR).

Present TDRP: https://www.icann.org/resources/pages/tdrp-2016-06-01-en.

Next Steps

At-Large representatives should play an important role in the deliberations of the upcoming CoR discussions.

What Happened 

The ICANN Board is reviewing 38 pending issues. Some issues require further review, and other issues require the community to complete the ongoing work prior to a new round.

• On the ODA implementation timeline, while Board could not provide any definitive timeline they opined that an 18 month timeline may be difficult and needs careful thought.
• On the discussion of the upfront development cost of ODA and how ICANN org will pay, it was pointed out that they were costs of lifetime and the program needs to be ultimately self-funding. The Board is reviewing specifics of funding, where can costs be mitigated or lowered, etc.
• On the question of which of the two options of ODA the Board will direct ICANN org to implement, it was stated that the Board is looking on how to balance in an efficient way the options of automation and manual processing, while being reasonable and flexible.

Takeaways

• Applicant Support. On the question whether an applicant needs to identify a pre-validated Registry Service Provider (RSP) or if the applicant can simply indicate that it would use a pre-evaluated, it was stated that in the ODA the provider would be named in the application so that analysis can be done. However the scenario where a specific RSP is not named, will be looked into.
• Closed Generics and RVCs. On the question of Bylaw change to ensure enforceability of Registry Voluntary Commitments (RVCs) related to Closed Generics before next round, it was stated that the Board will engage with the GNSO Council to discuss and work to hopefully change or clarify the text in existing Bylaws to remove doubt and grounds for disputes.
• Outreach. In terms of timelines and vendor for the Global Communication and Outreach program it was shared that the firm that was used in the previous round will be retained. The 24 months allocated for this program development is partially predicated on the prior knowledge and experience of this vendor and it will start with awareness building of UA and IDNs to begin momentum around the end of May of this year.

Next Steps

• A call for volunteers will be soon started to assist with the IRT.

What Happened

The group discussed the community update that was happening on Tuesday. The areas that were added since ICANN 75 were:

Variant management, Review and Confusing similarity. The group then continued to work on the stress testing scenarios. 

Next steps:

• Continue discussions on stress testing
• Review Confusing Similarity recommendations

GNSO Guidance Process Working Group for Applicant Support

Presentation

This was the first face-to-face meeting of the group since its first meeting on 6 Dec 2023.

The meeting consisted of:

1. A brief recap of the 6 tasks that the GGP WG must complete by ICANN77 when the WG's draft report is to be presented to the GNSO Council and before it is moved on for Public Comment.
2. A brief review of what has been accomplished so far with regard to Tasks 3, 4, and 5, which ultimately look at what represents success with regard to data collection and metrics and the best approach to achieve our tasks.
3. A proposed format for detailing our guidance for each of the recommended areas proposed in Section 17 of the SubPro Final Report was presented and discussed.
4. Homework activities were set to:
   1. develop on a proposal for the introduction to the report
   2. develop the contents relating to each of the Life Cycle Elements of the Applicant Support Process:
      1. Outreach/Awareness
      2. Business Case - understanding and determining need/opportunity and developing application
      3. ICANN Org setup of Applicant Support process for success
      4. Application submission and evaluation
      5. Contracting/delegation
      6. Ongoing operations of the gTLD

CPH*: DNS Abuse Outreach

*Contracted Parties House

What happened

1. Brian Symbolic and Reg Levy, who co-chairs the Registry Stakeholder Group Abuse Working Group and Registrar Stakeholder Group Abuse Working Group, respectively, updated on the negotiations to establish baseline obligations in the RA/RAA agreements. These obligations will require contracted parties to take reasonable and appropriate action to disrupt and/or mitigate DNS abuse. The negotiations focused on specific types of DNS abuse, such as fishing, farming, malware, botnets, and spam, when used to deliver any of the mentioned abuses. The objective is to set a minimum standard for all registrars and registries rather than a maximum standard. The co-chairs anticipate that they will share a red-line draft for Public Comment shortly. Additionally, the co-chairs expressed their concerns regarding the term "bulk registrations" and the possibility of defining it as a form of DNS abuse. They suggested that this approach might be too broad and may not fully capture all legitimate uses of bulk registration and, thus, should not be the main focus of the negotiations. He also discussed a publicly available tool called Acidtool.com that allows anyone to report DNS abuse. The tool provides contact information for the hosting provider, email server, and registry/registrar associated with the offending domain. Users can then use this information to report abuse to the appropriate parties, whether it be phishing, malware, botnet, general content, spam or any other abuse-related issue.

2. Graham Bunton from the DNS Abuse Institute discussed two projects: Net Beacon and DNS AI Compass.
   1. The NetBeacon is a tool that allows Internet security experts to report abuse at scale, with plans to push the data into the Compass project to provide high-quality abuse reports to the industry. Net Beacon also recently enabled abuse reporter verification to clarify the reporting process.
   2. The Compass project aims to measure fishing and malware prevalence, persistence, mitigation, and registration type. They have been publishing data monthly but plan to close the gap between the high-level data and the more granular individual registrar and TLD data. The project also plans to create individualized dashboards for registries and registrars to help them understand abuse in their area of responsibility and compare that to their peers. The speakers mentioned that they are careful about what metrics they put into the public domain to avoid unintended consequences or overcorrections based on the data. They are also engaging with the broader community to gather feedback on what information would be helpful and what unintended consequences could arise from publishing specific data. They said that individual dashboards are meant to empower registries and registrars with data to address abuse internally and provide them with a consistent metric to compare over time. The speakers then briefly overviewed their data type and how it can be presented through the dashboards. They use data reports from GoDaddy and Google as examples. These dashboards are not open to the public. However, you can see aggregated data reports every month being published for the public in general.
      

What are the At-Large specific takeaways from this session? 

1. RA/RAA agreements negotiations will help in mitigating DNS abuse as defined above. This will benefit the end-user.
2. Acidtool.com is a helpful tool for reporting DNS abuse. To use the tool, you input the domain engaging in abusive behavior. The tool provides the contact information for the hosting provider, email server, and registry/registrar. This allows you to report the abusive behavior to the appropriate parties. You should contact different parties depending on the type of abuse you want to report. For example, if the issue is related to phishing, malware, botnets, or general content, you should contact the hosting provider or registry/registrar. You should contact the email server if the issue is related to spam or other email-related issues. And if the issue is related to other types of abuse or specific content issues, you should contact the appropriate party as indicated by the Acidtool.com results.
3. The NetBeacon is a tool that allows Internet security experts to report abuse at scale, with plans to push the data into the Compass project to provide high-quality abuse reports to the industry. Net Beacon also recently enabled abuse reporter verification to clarify the reporting process.

.

What are the At-Large specific action items (next steps)?

1. ALAC should send a formal email to all RALO officers, requesting them to disseminate information about the ongoing RA/RAA agreement negotiations to raise awareness about the upcoming changes. The email should include details that the updated contracts will require all registries and registrars to take appropriate action to mitigate DNS abuse, including fishing, farming, malware, botnets, and spam when used to deliver any of these types of abuse. ALAC should provide a detailed explanation about the purpose of the RA/RAA contracts, define what registries and registrars are, and highlight the benefits of these negotiations to end-users.
2. The same formal request should include the availability of the acidtool.com and netbeacon.com tool to report abuse. With these, it should consist of a clear explanation of what these tools are and a guide on how to use them, with a couple of examples.

What happened:

This session featured: 

1) A report on law enforcement data on cybercrime (so far US and UK only, although they are trying to get others to report). Some of which is DNS abuse (i.e. phishing) and some of which is merely enabled by DNS abuse. 

2) A report from the Internet & Jurisdiction Policy Network, which is working on cross-border issues involved in addressing DNS abuse. The presenter noted that there are multiple definitions of DNS abuse being argued over, which suggests that we are asking the wrong question. He suggest a better one might be "When is it appropriate to take action in the DNS to address abuses online?" 

Fun fact: the latest thing in pharming attacks is for the DNS abuser to buy ads on Google, etc., which gets them to the top of searches -- even if the query was for a specific company website. 

Next Steps

Support the GAC call for contract changes to provide clear and enforceable obligations regarding DNS abuse. 

This session saw a cross-section of UA engagement leaders providing updates on their activities. Initially, an overall update on the UA Day preparations was provided.

Subsequent presentations examined the perspectives from:

• Web UA Remediation updates (Mahesh Kulkarni)
• End-user perspectives (Satish Babu)

• Academia Perspective (Nabil Benamar)

• Thailand UA Local Initiative Perspective (Anawin Pongsaboripat)

• Government Perspective (Abdalmonem Galila)

• UA Ambassador Perspective (Luis Sergio Valle)

Next Steps

At-Large role in supporting UA adoption could be extended to academia, by organizing awareness sessions and outreach sessions at universities and schools. ( Maybe assembly hours could be used for such kinds of sessions)

What happened

The small team managing the process of defining the role of the ccNSO with respect to UA presented to the community the roadmap to establish this role. The small team was seeking feedback from ccTLDs for the adoption of the roadmap.

The team presented the results of the ccTLD UA readiness survey. The survey was conducted between Dec. 2022 and Jan. 2023. The survey was sent to both ASCII ccTLD managers as well as IDN ccTLD managers. The objective of the survey was to:

• Understand the progress and challenges of becoming UA-ready.
• Understand how ICANN org can help support ccTLD managers.

Responses from Af IDN ccTLD: 33%,  AP:24%, and EUR:44%.

ccTLDs UA readiness based on the survey:

• 13% UA ready
• 31% not ready
• 56% partially ready

Partial UA ready support:

• Support IDNs: 83%
• Support gTLD longer than six characters: 52%
• Support short new gTLDs: 57%
• Support email addresses with long new gTLDs: 50%
• Support email addresses with short new gTLDs: 57%
• Support email addresses in the U-label@IDN form: 7%
• Support email addresses in the ASCII-label@IDN form: 14%
• Support email addresses in the U-label@ASCII domain name form: 12%

The verbatim response for UA readiness barriers

1. Lack of demand. 
2. Political situation in the region.
3. Do not trust the currently available open source.
4. Maintaining the EAI mail servers requires more manpower

58% said that they had other priorities.

Survey Next steps:

• ICANN org will continue supporting UA related efforts within the ICANN community. 
• The survey results will be taken into account by ICANN org when updating its UA strategy
• The UA Readiness survey is planned to be conducted periodically to measure the UA Readiness progress

Proposed ccNSO UA Roadmap

• Activate UASG Liaison (already completed)
• Create UA committee
• In future: Explore further actions

Role of UA Committee

• Assist in organizing sessions on UA readiness and practices at Tech Day or during ccNSO Members Meetings sessions
• Liaise with other relevant ICANN groups (e.g. UASG, GAC IDN WG, Board IDN/UA WG
• Coordinate with interested ccTLDs to share IDN/UA readiness case studies and working models, to highlight and share knowledge on current practices in IDN support and UA readiness
• Provide an information repository to assist ccTLDs in adoption of UA

Takeaways 

The survey results, showed that one important barrier to UA readiness is lack of demand and thus UA is not at the top of the priorities of the ccTLDs. Raising awareness about new gTLDs and IDNs is important to raise demand. In response to what would motivate ccTLDs to become UA ready 40% mentioned in response to requests from customers and 50% said to grow our customers base. Thus stressing on the role of awareness and outreach.

EAI readiness still requires a lot of work. 

Next Steps

Liaise with the ccNSO UA Committee to create awareness and outreach UA programs and initiatives.

What happened

No question from the ASO to the Board

Two questions from the Board to the ASO:

1. Is the ASO satisfied with the amount of exposure tant numbers issues the ASO or the RIRs received at ICANN meetings and in other ICANN activities? Would you like to suggest any changes to the amount or form of interaction?
2. The RIRs are on the independent side when it comes to ICANN but, as recent events show, the independence and the self-governance concept has some risks as well. Do you see it the same way? What kind of support would you like to see from ICANN?

The answers were given mainly by the NRO Chair and other RIR chairs and finally by the ASO Chair.

• RIR are "very" independent and the work and participation is and must be done at the level of each region. And they invited members from the Board and from the region to come to RIR meetings.
• In the same time the situation of AFRINIC raise questions that the RIR community need to answer and it may end up to evolve their governance (and the relationship with ICANN).
• Everyone hope that the situation of AFRINIC will be overcome.
• Thanked the RIRs (and ASO) for their support to the work of the RALOs.

At-Large specific takeaways 

• Enhance the relationship between RIRs and RALOs.

Action Items/Next Steps

• Need not to forgot that At-Large is cross-SO. Need to have also regularly an in-depth view regarding IP addresses. 

What Happened

EAI is one of the most challenging aspects of UA. This session showcased three initiatives and the community experiences with them.

Three case studies of Email Address Internationalization (EAI) by early adapters:

1. XGenplus, which has achieved Platinum-level in EAI.
2. Anawin Pongsaboripat (.th) feedback on Roundcube, which aspires for Gold/Platinum level certification.
3. Harsha Vijayavwardhana (RoundCube, Dovecot, Postfix, Mutt)
   Postfix passed all tests, but DoveCot failed a few tests.

Of the tools used, Postfix is a Platinum-level MTA;  Dovecot (IMAP client) still has a few bugs; and Mutt (MTA/MUA/MDA) is almost Platinum-level.

The discussions that followed considered different aspects of the certification and the challenges experienced. Another discussion was about how to facilitate UA adoption with UASG009 Quick Guide to Tender and Contractual Documents.

Takeaways

• When purchasing a new email system, it is important that we check EAI support and level (Silver, Gold, or Platinum). We also need to check for the Level logo on the provider's literature.

Next Steps

• Possible Capacity Building workshops in coordination with the UASG group.

ccNSO: DNS Abuse Standing Committee Update

What Happened

A report on the survey conducted on Country Code Top Level Domains (CCs) regarding DNS abuse was presented during the meeting.

The analysis was found to be mixed and spotty, as the survey received only 35 responses despite an expected 100. While it was mentioned that a repository for reporting DNS abuse will be established, it is closed to the public and intended to be used only by the ccTLD community.

Although anyone can report DNS abuse to ccTLDs via mail, it was highlighted that most of them will not take action unless the report comes from an official authority.

Takeaways

• There are no takeaways from this session.

Next Steps

• None