ICANN81: Industry Insights From the 2024 ICANN General Meeting
ICANN81 was held in Istanbul, Türkiye from 9-14 November 2024. Watch the webinar and read the transcript below to hear the latest news and updates in policies and procedures from Markmonitor’s Global Industry Relations Team.
Introduction – ICANN81: Industry Insights Webinar
Speaking: Prudence Malinki
Hello, everyone. Welcome to the Markmonitor ICANN81 Recap webinar. My name is Prudence Malinki. I am the head of the Global Industry Relations team here at Markmonitor and I’m excited to talk you through the highs, the lows, and the various moments that were ICANN81.
Today, I am joined by members of the fantastic Global Industry Relations team. I’d like to introduce Heidi Zhang, who’s the Head of Markmonitor China. I’d also like to introduce Chris Niemi, Manager of Strategic Initiatives and all things .Brand and Next Round. And a new face, but not new to the industry by any stretch — I’d like to very happily introduce Leanne Kenny, our latest member of the GIR team. Welcome, Leanne. You may notice that there is one person who’s not with us today, and that’s Shane Layman. Shane has recently become a father, and we’re so excited that he’s welcomed gorgeous little Lennon into the world. We sorely miss that you couldn’t be with us, Shane, and congratulations on being a fantastic dad.
Agenda: ICANN81 Webinar
We have an action-packed agenda to get through today. We’re going to cover several different topics, including:
- Subpro IRT
- Transfer PDPs
- ccNSO update
- RDRS and RDAP
- GAC Communique
- And more.
This was a very interesting ICANN meeting.
ICANN81 Meeting At-a-Glance
The ICANN 81 meeting was in glorious Istanbul. That’s the first time it was in Turkey.
However, this ICANN was a little bit different in the sense that we were saying a lot of tearful goodbyes and a lot of welcoming hellos in the ICANN community. The terms of several leadership positions in ICANN’s Contracted Party House ended. I wish Ashley Heineman all of the best and say a big thank you so much for your work as chair on the RrSG, and the same with Sam Demetriou. Thank you so much for your work with the registries as well. I wish you both every success in your future endeavors. Sam, I’ll be working with you in the Council, so I’ll be speaking to you soon. I also wanted to give a good welcome to Owen Smigelski. He’s going to be heading up the RrSG moving forward and also Beth Bacon, congratulations and good luck with all of your work.
Changes in the leadership of this nature mean changes of direction and changes in tact, and it means exciting new, fresh blood. A big congratulations to all of the new leaders, and another congratulations to Greg DiBiase, who’s remaining as GNSO Council Chair.
I want to welcome all of the new GNSO Councilors to their positions. I’m really excited to be working alongside all of you in the future. In the near future, ICANN will have a new CEO as well, Kurt Lindqvist. During this ICANN meeting we were introduced to Elizabeth Field, who is our new Ombuds, and she will have her work cut out for her with questions such as the selection process for ICANN meetings. One of the things that we noted during this specific meeting was that of absences. So, hopefully, our new Ombuds will be looking into the country selection process as well as the visa selection process.
Additionally, we are also looking into specific policy documents. We have a new Ethics Policy document and a Code of Conduct document relating to Statements of Interest. The SOI Code of Conduct document is out for public comment and closes on December 2nd.
ICANN Board Seat Elections
As I mentioned, we’re having a lot of transitions of power and a lot of movement. We’re in this interesting phase right now where we have two board seats that are up for election. We have Board Seat 12, which is for ccNSO candidates. For contracting parties, we have board seat 13. Now, I’ve literally just jumped from a candidate discussion that was happening in real time. And as you can tell by the lilt in my voice, this is one of the most exciting things that’s happening right now.
The contracting parties, or the Board Seat 13, GNSO board seat position, is up for grabs. I want to take a moment to thank Becky Burr for her exemplary role and term and for doing a fantastic job. We have some very large shoes to fill, and we have six incredible candidates for the seat. At ICANN81, a session where all of the candidates conducted a Q&A with the contracted parties was one of the hottest sessions of the entire meeting. And I’ll tell you why.
The people who you presumed were frontrunners and had this in the bag may not have put their best foot forward, candidates that you may have presumed were more of an underdog did an exemplary job of addressing the broad needs of the community and were able to provide it eloquent understandings of the nuance that is a multi-stakeholder model, and the challenges that may lie ahead. So, we have incredible candidates, and I can genuinely say we are spoilt for choice. This role is a very important role, so we really need to make sure that we stick the landing and pick the right candidate.
The themes of conflicts of interest and of policy are not going away. This is going to be a really lively vote and a lively discussion. Voting for Board Seat 13 is going to take place over the next couple of weeks. We’ll keep you posted as to how this turns out. Again, these are all amazing candidates. I wish good luck to every single one of you, including the Board Seat 12 candidates.
And now, we’re going to be talking all things SubPro IRT. I’m going to hand it over to Chris. Thanks, Chris.
Subsequent Procedures Implementation Review Team, SubPro IRT at ICANN81
Speaking: Chris Niemi
Thanks, Prudence. The word of the day in this meeting was “Next Round,” as we’re still on target for an application window in April 2026.
Leading up to that involves the Subpro IRT, or Subsequent Procedures Implementation Review Team, whose task is to complete the implementation work that’ll lead to the creation of the new, finalized Applicant Guidebook, which should be complete by the end of 2025 in anticipation of the opening of the Next Round in 2026.
There were multiple meetings by the IRT discussing issues like the new base Registry Agreement (RA). The Registry Agreement is the agreement that a registry operator (RO) signs with ICANN for the RO to run a top-level domain for a length of 10 years. There are a bunch of changes, as one might imagine, with there being a 12-year gap between the last round and the next round.
The new RA will include things like implementation updates, policy changes, and community recommendations that were approved by the ICANN board as well as operational updates. One of the main issues was that there will be a new Specification 13 at the end of the agreement that primarily talks about IDNs, or Internationalized Domain Names, and that there can be a primary TLD and a variant, potentially up to four variant TLDs, depending on the language or script set that is utilized.
Another important issue that was discussed was the GAC’s desire to remove contention wherever possible. Now, there is going to be this concept of a “replacement string” that an applicant can submit when they submit their New gTLD application in the Next Round. When they apply for their primary or original string, they can also identify a replacement string. So, if there is a contention between their primary string and another original string in a separate application, there is a secondary replacement string. There were some grumbles in the session about this from the community as it is kind of adding some unnecessary complexity. In general, the bulk of the group thought it was an acceptable way to proceed. So, there’s a notion that brands who are utilizing Specification 13 will be able to file an application change request to get their second choice of an alternate string if necessary. Let’s use the example of “delta,” there are multiple companies that utilize the delta mark. Your secondary choices could be something like “deltaairlines,” if you’re the airline, or “deltafaucet,” if you’re the faucet manufacturer.
Another session was regarding community priority evaluation, a concept from the first round that essentially said if one applied as a community, it would allow you to break contention with non-community applications. The classic example was something along the lines of, say, the Apache Native American people. They could apply for their own string and win it, as they are a community versus, say, the party that makes Apache helicopters.
ICANN continues to be a little worried about that as it potentially exposes them to legal and financial risk. So, they’re going to suggest an implementation or changes, and they proposed running a stress test to learn more about how those potential changes could work.
Lastly, there was a discussion of outreach around engagement for the Next Round. In 2024, ICANN and various entities run 124 different outreach events with 30 alone in October. ICANN is continuing to reach out, and they’ve also developed some associated materials called the Champions Toolkit.
Applicant Support Program: Next Round
One of the main issues that ICANN wants to publicize and make known in the broader Internet community is this notion of the Applicant Support Program, or ASP. The ASP was an idea introduced in the first round that helped allow underrepresented regions or countries and nations across the world to apply for their own TLDs. It was not utilized very much. There were only three applications in the 2012 round, and only one of them successfully made it through.
Since the first round, ICANN has developed the process to make it more accessible. Again, the idea is to make it accessible for applicants who do not necessarily have the financial resources or who face resource constraints to get assistance through the application process, which could be in the form of financial or non-financial support.
ICANN has noted that they will allow 5 million of the 2012 auction proceeds to fund half the cost of qualified applicants. The Application Support Program opened on November 19th, 2024, and it will remain open for one year for parties interested in seeking that support. There will be different ways for people in the community to apply, and they can receive assistance with application writing and various other means of support.
An ongoing issue that continues to be worked on is the notion of an applicant bid credit. People who utilize the Applicant Support Program could receive a bonus or help during the potential auctions, giving them roughly equal ground to other parties who might have more financial backing. The board and other parties will continue to work on developing that aspect.
Speaking of auctions, private auctions, auctions run outside of the ICANN systems, will not be allowed in the Next Round. Also, to break contention sets, creating joint ventures once applications are submitted is also not going to be allowed. There’s a lot of activity in this space to ensure that auctions are fair and viewed as a means where parties can’t gain unnecessary control over one another.
Continue to watch because there’s a lot of activity in this space. Back to you, Prudence.
Transfer Policy Development Process, Transfer PDP
Speaking: Prudence Malinki
Thanks, Chris.
Did you hear that? No private auctions, okay? This is quite contentious. Some parts of the community were really excited about the idea of a private auction because that was part of the excitement of the Next Round for them.
Now, let’s talk all things Transfer PDP and relay, at a high level, where we are and where we’re moving to. The Transfer PDP team met up during ICANN 81. Where we are at now is that we are reviewing the comments posted to the initial report. During this specific meeting, we covered a specific topic, Recommendation 27, which has to do with registrant data notifications. We reviewed Recommendation 27 in-depth and went over the comments and feedback provided by the community.
Now during this session and going through those comments, we primarily determined that further discussions are still required, specifically relating to unauthorized changes of registrant data. So, there’s going to be ongoing discussions happening. The reviews of all of the comments and initial reports will continue through the rest of the year.
We’re predicting that the final report will be delivered on time, and that’s going to be between February and March of next year. The additional steps to come will discuss how to adopt that final report once it’s created, which will be, as I’ve mentioned, in a couple of months. The Transfer PDP is moving along nicely and making progress at a decent pace.
Now we’ll move from Transfer PDPs to something equally as exciting, the IDN EPDP, or Expedited Policy Development Process on Internationalized Domain Names. I’ll hand it back over to Chris.
Expedited Policy Development Process on Internationalized Domain Names, IDN EPDP
Speaking: Chris Niemi
Thanks. The IDN EPDP was on the critical path for the Next Round. In Istanbul, the phase two final report was completed and accepted by the GNSO Council.
I won’t go into the finer details because IDNs can get very technical, very difficult, and complex quickly. The main idea is that they want to make sure that top-level domains in language scripts other than ASCII, that those existing variants are identified, and that they’re applied for and given to the appropriate parties — parties who already have existing utilities, that already have existing back end registry operators — they want to make sure that those registrants are awarded the correct second-level domains that match the variants.
IDNs are an important part of the program. Since 2012, part of the overall ICANN program has been to establish more internationalized domain names across the sector so that different parties around the world can utilize their own local languages. So, that report was completed and now we’re going to continue to move on through the process.
ccNSO, the County Code Names Supporting Organization
Speaking: Leanne Kenny
I’m very briefly going to take you into the world of ccTLDs and provide updates on some of the ccNSO sessions.
For those of you who are not familiar with or may have forgotten what the ccNSO is, they are the Country Code Names Supporting Organization. They are basically made up of ccTLDs — there are 178 members, and they don’t develop policy. They operate independently of ICANN. Quite often, they’re governed by national regulations in their own jurisdictions; ccTLDs have their own sort of policy development for their own registry. But that community really comes together to share best practices, share education, and share experiences, so that ccTLDs can all learn from each other. That brings to the DNS Abuse Standing Committee (DASC), because that’s exactly what that committee also aims to do in relation to DNS abuse. The aims of that committee are to share information and best practices in how ccTLD managers try to mitigate DNS abuse.
When we talk about DNS abuse, we refer to the definition that ICANN uses. DNS abuse consists of phishing, pharming, malware, botnets, and spam when it’s used as a delivery mechanism for any of those previous forms of abuse. The DASC is there to raise awareness of DNS abuse among ccTLD managers, promote open and constructive dialogue, and try to help ccTLDs mitigate that abuse.
In 2022, they did a survey that was repeated in 2024. They had a couple of sessions at ICANN81, and one of those sessions was to present the results of that survey. The survey went to 316 ccTLD operators and you didn’t have to be a member of the ccNSO to complete the survey. Approximately a third of ccTLD operators responded, including those of the top 10 ccTLDs, a comparable response to the 2022 survey. On a positive note, the registries now seem to have a much better awareness of levels of abuse in their ccTLD. In 2022, 35% of respondents stated that they weren’t sure how much DNS abuse existed within their ccTLD, and that dropped to 21% in 2024.
I think the committee is quite pleased that some of their efforts in terms of raising awareness of that issue are starting to pay off. Now, ccTLDs, in general, have quite a low level of DNS abuse, and it is on a downward trend, according to the NetBeacon Institute. About 69%reported less than 0-1% of DNS abuse within the domains under management in their registries. A slight caveat to that is, obviously, it’s self-reported data. There are many ccTLDs that are very small and don’t really have the resources to measure the levels of DNS abuse in a significant way.
That said, the committee was fairly confident that ccTLDs are responding to the survey honestly and in good faith, so that’s really good news. The ccTLD community seems to have fewer levels of DNS abuse than the larger gTLD community, though they don’t really know why that is. Some think it might be related to data validation or language, but there was nothing in the survey that highlighted why that is the case.
Another session was a workshop in which they discussed what they wanted to focus on next. One area of focus is investigating whether there’s a correlation between registrant data validation and lower abuse rates. A good point was also made about collaboration between ccTLDs and registrars in relation to data validation processes, and the committee seemed to take that on board, so that was really positive.
Now, we’re going to talk about funding and about the board seat. One of the presentations was about ccNSO funding. Back in 2010, the CEO of ICANN at the time made a statement regarding whether or not ccTLDs were contributing enough financially to ICANN’s costs.
To say that was controversial at the time is probably an understatement, but the ccNSO took that on. They created a finance working group to examine how much it cost ICANN to support ccTLDs compared to the contribution that ccTLDs made. They also examined whether there were any funding models that might help them arrive at a tangible figure. So, their working group came up with a value exchange model.
That value exchange model basically focused on three buckets of things, a reciprocal sort of exchange, if you will, between ccTLDs and ICANN. One of them concerned specific things like the fact that ICANN provides a secretariat for the ccNSO. Another was shared services, for example, things like IANA services, and that quite often a ccTLD registry will host the ICANN meeting. For example, the Istanbul ICANN81 meeting was hosted by the registry from Turkey. And they also looked at it from a global level, the fact that ccTLDs strengthen ICANN’s legitimacy on a global stage. So, they introduced that model in 2013, and it was reviewed in 2018. The presentation at ICANN81 was setting up the fact that they are going to need to review this again. The current estimate is that there’s an approximately 2.6 million dollar shortfall between the amount that ccTLDs actually cost ICANN and what they are contributing. We do know that some ccTLDs have recently reduced their contribution. So, they’re putting out a call for volunteers who will then review that model again. The plan is that they will present their findings at ICANN82 in Seattle. Watch this space for the results of that.
And then, as Prudence mentioned earlier, there is a board seat vacancy. There are two candidates, and they’re both industry veterans. So you’ve got Byron Holland, who’s President and CEO of CIRA, which is the Canadian registry, and Nick Wenban-Smith, who’s General Counsel of Nominet from the UK registry.
They had a Q& A session. It was interesting — they had questions that one would expect in terms of how they would manage conflicts, similar to the GNSO, and how much time they could commit to the board — the estimate is that it requires at least two days to 20 hours a week. And they also faced questions regarding skills, the experience of what they’ve already done, and what they can bring to the board. The next steps on that voting starts Tuesday, the 4th of February and closes on Tuesday, the 18th, and the term will then run until 2027. In terms of the general feeling in the room, I think the ccNSO is generally really pleased to have two such great candidates, and a little bit like the GNSO, spoilt for choice. They would like to have two if they could, but they can’t.
Privacy and Proxy Services Accreditation Issues, PPSAI
Speaking: Prudence Malinki
Thank you so much for that update, Leanne. There’s never a dull moment in the ICANN sphere.
Let’s talk all things PPSAI. PPSAI is an implementation review team that deals with privacy and proxy services and with the accreditation, or creating an accreditation or standardization, of how we use and implement these services across the sphere and across the community.
Now, this is a very lively group and as you can see from the slide, we have over 50 participants that cover all the global ICANN sphere. We had a really lovely session during the ICANN meeting. People were talking about the different business models and ways that privacy and proxy services are used, and the different instances and challenges people face trying to obtain data when a privacy or a proxy is used. And registrars showed the difference in how they implement a privacy service versus a proxy service. Now, this group has only really been meeting since June of this year, so it’s a fledgling group, and they have a lot of things to discuss, including the differences between privacy and a proxy.
There’s still a lot of education that’s happening in this group. One of the reasons why the group has come back together is because of the implementation of this policy — this isn’t creating a new policy. Taking into account current models, such as data policies that have recently come up with regards to registration data, as well as legislation, like GDPR and NIS2 — we’re having to see whether these have an impact as to how we implement the privacy and proxy accreditation services.
As you see on the slide, we are considering several different threshold questions. However, the IRT is still trying to iron out the kinks regarding what it means to have a proxy and what it means to have a privacy service. For those participating today, I’m not going to test you by asking you which is which, but I will elaborate and provide a little bit more context.
A privacy service is where a registrar will utilize either their own registration data or an affiliated company’s registration data to obscure the registration information of their registering clients. This service, I think, is what most people think of when we say proxy when what they mean is privacy. In these instances, the registrar knows who the client is.
Now, compare that to a proxy service — this is where a person registers a domain name on behalf of another person. So, this person, this proxy, will go to the registrar to register the domain name on behalf of someone else. However, in this case, the registrar is not aware of who the proxy is standing in for or who the third party is that the domain is being registered on behalf of. What this means is that for all intents and purposes, the registrar is operating on the premise that the registrant is the person who’s come to them and registered the name, not knowing that there’s another party involved, and especially not their identity.
Proxy services and privacy services are slightly different and have slightly different obligations. Right now, there are discussions about whether these services are in scope or not. Obviously, a privacy service is definitely in scope, and all of the participants are very much in favor of creating standardized notions for how privacy services are implemented—this is to ensure quality levels and consistency across the board.
When it comes to proxy services, this becomes a little bit more complex. While certain elements of the implementation review team want to make sure that we include proxies, There are challenges as to how that will actually be done realistically, especially when registrars do not know who the ultimate registrant is.
So this is going to be a very interesting team. Keep your eyes peeled for all things PPSAI because it’s going to be very interesting as we go through it. As I’ve said, this is all in the initial stages and its early days. But we’ll keep you posted on all of the major developments, and we’ll make sure that if there are any salient changes to how you implement privacy services for your domain names, we’ll keep you up to date and make sure that you can have and maintain a service level that’s useful for you. Okay, so let’s go on to the next slide and talk all things registration data.
Registration Data Request Service, RDRS
This was one of the hottest topics of the ICANN meeting. Shortly, Heidi will give the GAC update, which will discuss the GAC’s perspective on the matter because this was in the Communique. RDRS was created after the original request system, SSAD (System for Standardized Access/Disclosure), was deemed to be a little bit too costly to implement and too difficult to realistically implement.
So we created The RDRS system. Now, this was supposed to be a two-year pilot — some people call it an experiment or test — essentially, this was supposed to be for a two-year duration and we are one year in. We have spent the past year using the RDRS system. But what does that mean?
This system is supposed to be a standardized request system. What it doesn’t do is guarantee that registrars will provide the registrant data that has been requested. Gabe from the GAC provided an incredible usage statistic during the meeting, which we’ve reproduced here. This statistic gives you visibility to the issues that have been faced regarding RDRS, with regard to understanding what the RDRS can and can’t do.
Let’s discuss the pitfalls regarding the usual applications. I want to talk you through a couple of things on this specific graphic. One is that during this meeting, there were lots of hushed and unofficial asks or calls to end the RDRS pilot. The idea was that certain parts and elements of the community believe it hasn’t been successful and that we should let it be and move on to the next thing. However, that being said, we have no next thing—that technically doesn’t exist yet. So this was one of those times when we had to really come together as a community and figure out what we are going to do.
One of the really great things that happened during a board session was the clarification that RDRS will continue to be used while the board makes a decision about whether to focus on the SSAD or use the RDRS moving forward as that standardized request system. As you can see, the requests are still coming in, so we do need to have some kind of system. But the good news for now is that RDRS is not going away. Will it be maintained? We don’t know. But the rest will be, it’s not going to be done away with immediately, which there were some rumblings about during the meeting. There are a lot of disgruntled elements of the community that are not happy with the RDRS. There are a myriad of different reasons as to why that is. One of the reasons, especially as demonstrated by this graphic, is a lack of education with regard to what RDRS can and can’t do.
Have a look at this graphic. I’m just going to give you high-level representations of these numbers. The big number on the far left-hand side is around 18,000, right? We’re dealing with very high volumes of initial queries or initial people doing lookups of domains, having a check to see if it’s there. Now, this is where the education piece comes in because from that 18,000, you can literally immediately discount over 10,000 of those requests. These are requests that are being made for TLDs that are completely out of scope, such as ccTLDs or TLDs that are not part of the system. Another thing that’s been highlighted is that RDRS is an opt-in, not mandatory. We at Markmonitor are part of it, and a number of Newfold registrars are also part of it. However, it’s not mandatory.
So, what you’ll see here is that there’s a scope of around 4,000, nearly 5,000, of those requests are to registrars that are not engaged. That means that if you’re in the system and you enter a domain, it’s not going to come back with a result because that registrar isn’t signed up, and if they’re not signed up, you’re not going to be able to send that standardized request to that registrar who isn’t using that system.
Of the 18,000 requests, around 5,000 of the domains are in there — they’re eligible — this is good. But then something really interesting happens — of those 5,000 requests — even though the domains are in the system, for reasons that we don’t know, requests are only being submitted to a fraction of them. 2,000 of the 5,000 have the request being made, but around 3,000 aren’t making any requests. From the initial 18,000 there’s only about, let’s say, 400 that get approved.
When looking at the reasons why the requests are being denied, overwhelmingly, it’s because there isn’t enough information in the request. You’ll see here that for around 500 of them, more information is required, and it’s just not been provided at the time of submission, so the registry data can’t be given.
It’s informative to see a snapshot of what’s been happening regarding usage and the levels of education that are required regarding RDRS moving forward. But, as I’ve mentioned before, it’s not dead; it’s going to continue until we figure out at the board level what is coming next. And Becky made a salient comment — we have a good amount of data. They’re happy with the data. They’re happy with the results so far. It’s just not clear as to whether they’re going to be utilizing these infrastructures to help with the SSAD or whether they’ll be keeping the RDRS kind of method moving forward. We will keep you posted, and if you need help navigating the RDRS landscape, reach out to your account manager, who can help you maximize your likelihood of success. If you need to request data from a registrar, use our expertise to help you navigate.
Registration Data Access Protocol, RDAP
I would be remiss if I didn’t mention RDAP after discussing RDRS. For those who don’t know, RDAP is the successor to WHOIS. The 2025 plan for WHOIS is that we’ll be sunsetting it in part and transitioning over to the RDAP system. However, and this is at a high level, nothing’s been confirmed yet. There will potentially be a delay on the RDAP timeline affecting its release next year, as it is pending compliance with registrars and requirements relating to RDAP. However, this is all very high-level at the moment; nothing has been confirmed. As far as we know, we’re still sticking to these timelines, but there have been rumblings of that potentially changing. Never a dull moment.
Let’s move on to the next slide and discuss where we are with the Registration Data Policy. The new policy is supposed to roll out in August 2025. This is a direct result of those four letters I love so much and hold close to my heart: GDPR.
Now, we are looking at where we are with registries. Registries essentially have two options regarding how they handle registrant data. They can either keep a repository of all of the registrant information or limit it to a minimum data set, and they have a choice as to how they go about doing it. At this time, approximately 38% of registries have indicated which way they want to go. We have had the likes of Google Registry, Radix, and I think PIR, in part, disclose that they’re going to be moving to a minimal data set. We’ll keep you updated as to what that looks like and how it proceeds.
Another very hot topic during the ICANN meeting was that of the billing contact. During the registration policy group discussions, it turns out that the obligations registrars have to collect the billing contact are not entirely clear. It was announced that there is potential scope for an advisory to come out, which may not categorically say yes or no, but it can be used as a tool to assist registrars in deciding what they do with the billing contact. To remind everyone, an advisory is just that, an advisory. It’s not a policy, it’s not something set in stone per se, but it can be used to help navigate decisions. That’s where we are with the Registration Data Policy.
Let’s move on and discuss all things GAC Communique. I’ll hand it over to Heidi, who’ll take us home.
GAC Communique at ICANN81
Speaking: Heidi Zhang
Thanks, Prudence.
GAC stands for Government Advisory Committee. It is not a decision-making body; it only provides advice to ICANN. GAC sessions are held at every ICANN meeting, and this year, the GAC sessions were relatively light. We had 69 GAC members and six observers attend the meeting, and we had the annual elections for the Vice-Chair. There were five winners for Vice-Chair positions from the following countries: Australia, Colombia, Netherlands, Egypt, and Switzerland.
A suggestion was made regarding tenure because right now, the GAC Chair is only a two-year term, and the Vice-Chair is a one-year term. A lot of the members say that the tenure is too short because there are so many ongoing issues and topics in the GAC, and the current tenures are not sufficient for the members to make contributions and follow up with the topics and the questions. Extending the tenure is not a formal suggestion yet, but the recommendation is to extend the tenures for both Chair and Vice-Chair by two years. The GAC members will need more time to discuss it in their offline meetings and in the future.
As I just mentioned, the GAC sessions were relatively light at ICANN81. There was no final recommendation made to the Board. The GAC held their regular meetings and discussions with the Board-at-Large, SOs (Supporting Organizations), CPH (Contacted Party House), and the SSAC (Security and Stability Advisory Committee).
For the GAC, the Next Round of New gTLDs is a hot topic that they have spent much time talking about. The GAC really appreciates all the efforts that ICANN has made in program outreach, but the main issue right now is how to help underserved regions and countries receive the outreach efforts. The GAC recommends that ICANN align with GAC members to find the right target for those underserved regions and countries and make customized plans for them.
They also discussed the application and evaluation fees for the Next Round. The application fee will be 227,000 US dollars and there could be a maximum waiver of 85%, which would be around 34,000 dollars. The GAC is still concerned that even that amount will be a challenge for some of the applicants in the underserved countries and regions, especially because there will also be other fees and costs in addition to the application fee, like the RSP (Registry Service Provider Evaluation Program) fee, the data escrow cost, consulting fees, etc. How to support the applicants in those countries and regions is a big problem. The GAC suggests ICANN really involve the investment community to help, and also discover the right way to match the funding entities with the qualified applicants to utilize their help and support. It is a big issue.
I want to mention the private auctions. As Chris just mentioned, the auction is a topic that concerns the GAC. The GAC really wants to try every means possible to avoid private auctions, and so, the alternative string proposal is very welcomed by them.
And the last other topic about I want to mention about the GAC regards domain name and registration data. Prudence has shared a lot about RDRS, and I can share a little bit about the GAC’s perspective on it. RDRS is mid-way through the pilot, and the GAC is really interested in improvements. The GAC is very keen to know about what will eventually be the standardized system for the access and disclosure of registration data. The RDRS is not necessarily the final solution, and the GAC is open to developments and changes. We’ll have to wait and see what happens. That will be all for the GAC. I will give the floor back to the team.
Web3 and ICANN Updates
Speaking: Chris Niemi
As Prudence noted, Shane, who’s our resident expert in Web3, was unable to physically attend the ICANN81 meeting, but was kind as to provide a quick update on what’s happening in the blockchain space.
This has been a topic that’s been building for a few years now. Initially, ICANN had shown some tepid interest, but now it seems like there’s been somewhat of a pivot to the blockchain space. The session was very well represented in the community; I don’t believe there was an empty seat. The whole room was packed, which doesn’t always happen in some of these community sessions. I can give a pretty neutral, if not a positive description of what’s happening in the Web3 space, that is, not the traditional Web2 internet or DNS official top-level domains. There was some discussion of what Web3 domains should be called, they could maybe be designated “wallet identifiers” or “Web3 identifiers.”
They provided some history of alt roots or alt TLDs from the past in the session, as there have been a number of different attempts over the last 20+ years of, sort of, different attempts at providing alternate services that mimic the DNS. But the larger issue discussed concerned name collisions. There are different resolvers that provide different results depending on where one goes to see what a particular Web3 wallet identifier relates to. Now, there’s actually a specific DNS record type called “wallet RR type.”
So, things are moving in a more collaborative or crossover direction. The larger discussion was about how the community is going to develop a sort of policy around this topic. What’s going to happen? How’s it going to affect the Next Round? There are a lot of developments to happen in the space, and we’ll continue to watch it to see how ICANN continues to interact with this particular subject matter.
Get Involved with ICANN and Other Policy Groups
As Prudence said earlier, we definitely advise our clients to engage in the policy development process. There are a number of different ways to do this. Folks can join the ICANN community, as shown on the screen there. Parties who are interested in intellectual property can join the Intellectual Property Constituency or the IPC.
Commercial users of the internet can join the BC, or Business Constituency, and have their Ideas heard. Another way to join via the Brand Registry Group, comprised of parties who have their own .Brand top-level domain or are interested in applying for a .Brand in the Next Round (there’s a little perk along with that — if you do join the BRG and you attend ICANN meetings I will take you to lunch and it’ll be a good one). We encourage all of you to take advantage of joining any of these policy groups and we’ll help you and point you in the right direction if that’s something you’re interested in. With that, I’ll give it to Prudence who’ll take us home.
Final ICANN81 Updates and Remarks
As I’ve always mentioned before, we attend ICANN meetings so you don’t have to, but we do want you to come with us, and we don’t want you to miss out on all the fun because this is kind of fun. And there’s a lot of interesting things happening with the exchanges of power, new CEO, new board members, GAC members wanting to have 2+2 for tenure — it’s all very exciting stuff that’s happening. We encourage all of our clients to do that — to get involved and participate in policy with us — and we can help guide your way.
Okay, a couple of things: I want to give a big shout out to Ram who did an exemplary job of his outreach for SSAC. I want to be in SSAC. You should be in SSAC. We should all be in SSAC. SSAC is the best. I clearly have drunk the Kool-Aid. I want to give a notable nod to one of the topics that I kind of overlooked, and that is Domain Metrica, which went live and led to a lot of controversy. We’re going to keep you posted as to how Domain Metrica works out, and discuss what it is and how it works a bit later as it was another hot topic during the ICANN meeting.
Speaking of ICANN meetings, the next meeting will be in glorious Seattle in March next year. Please come with us and join us. If you can’t come with us, make sure you join us on the recap webinar and participate with us that way. We do this for you. We create this content for you. Help us make it as relevant for you as possible. If there’s a topic that you want us to hone in on, let us know. If there’s an area that you want us to cover that you don’t think was covered adequately, let us know.
And with that, we can end our webinar. Thank you so much for participating and being with us today.
