ICANN 83: Insights from the Meeting in Prague, Czech Republic

Disclaimer: Please be advised that this recorded webinar has been edited from its original format, which may have included a product demo and other engagement features. To set up a live demo, please complete the form above on our website. If you currently are not on our website and are watching this on our YouTube channel, there's a link to the website in the description of this video. Thank you.

Christy: Hello, everyone, and welcome to today's webinar, "ICANN 83: Insights from the Meeting in Prague, Czech Republic." My name is Christy DeMaio Ziegler, and I will be your moderator.

Joining us today is Gretchen Olive. Gretchen is the Vice President of Policy for CSC. For over two decades, Gretchen has helped Global 2000 companies devise global domain name, trademark, and online brand protection strategies and is a leading authority on ICANN. And with that, it is my pleasure to welcome Gretchen.

Gretchen: Thank you so much, Christy, and thank you, everyone, for joining us today. I know lots of busy schedules, lots going on. So really appreciate the attendance.

So as usual, a very busy ICANN meeting. While this is the Policy Forum, it's a shorter format, there was no shortage of updates. So we have a pretty packed agenda, so I'm going to just move right on with it.

Let's first start with a few kind of like table setting things to make sure that we all kind of understand a few things about ICANN. So first of all, ICANN has three public meetings a year — a Community Forum, a Policy Forum, and an Annual Meeting. We're here to talk about the Policy Forum, which is typically in the June time frame. It's a four-day format. Like I said, a little bit reduced time frame from the other seven-day meetings. And it's really focused on policy work and community interaction.

During this webinar series, you'll hear me say ICANN or the ICANN community or the ICANN Board, and there's also a bunch of supporting organizations I'll mention. So let's just kind of give everybody a little bit of an orientation. So ICANN is made up, you'll see all these boxes under the Board of Directors, of a number of supporting organizations and advisory committees.

The one supporting organization that we really focus on is the GNSO, which is this big blue box in the middle. That's where you're going to find the registrars, the registries, intellectual property holders, the business users, ISPs. This is sort of the group that we really, really follow for this webinar series.

You'll also see a dark gray box to the bottom of the chart. That's the Governmental Advisory Committee, and that is a group of really think of them as like ministers from like the telecom ministries in different countries that come to advise the ICANN Board from a public policy standpoint.

So ICANN is a consensus policy organization. Things come from the bottom up, and then ultimately the ICANN Board votes to adopt things. So that's sort of how ICANN works. And this whole group here is often referred to as the ICANN community.

Most of these organizations, most of these stakeholder organizations are made up of volunteers. They're not paid staff. There is ICANN paid staff. There is a CEO. There's staff. But the supporting organizations are made up of volunteers. Typically, the volunteers do come from companies, though they're not getting paid. They're not being paid by ICANN to participate in this process.

All righty. So let's jump right into it. Obviously, one of the hot topics of the day and it was certainly a hot topic at the Policy Forum is the New gTLD Program. ICANN has been working to open up what's called Round 2. Just by way of a little history, Round 1 happened in 2012. So hard to believe it's 13 years ago when ICANN opened up the first opportunity for entities to come forward and apply for their own gTLD. They received over 1,900 applications, about 1,409 unique strings because there were some multiple applicants for the same string, and about 33% of them were what were considered Dot Brand TLDs, where companies were coming forward and saying they wanted a TLD of their company name or a brand that they wanted to operate for their exclusive use.

So it's been a long road since 2012. Some people are excited about Round 2. Some people are like, "Oh, no, here we go again." So there are definitely mixed emotions out there. Over the last 12 years one of the things ICANN had to commit to, when they opened Round 1, is they did commit to the Governmental Advisory Committee that they would do studies and assessments and kind of look at what went right, what went wrong, and then take corrective action. And so that's really what's been going on in earnest really the last 9 to 10 years, and we're finally to the point where they're getting ready for Round 2.

Now some people ask like, "Why do we need Round 2? Like really, don't we have enough TLDs?" Well, ICANN really wants to focus on diversity and inclusivity. When they look back at Round 2 (sic), a lot of the applications came from North America, with EMEA kind of in second place, APAC, and then it was really low participation in like Latin America or in the Middle East or Africa, very low participation.

One of the things we all have to kind of realize is that there were a lot of communities and places around the globe that have not really yet had full adoption of the internet. There are a lot of emerging economies that are trying to kind of tap into that. There are a lot of non-English speaking people around the world who are really not utilizing the internet. So they really want to kind of like broaden the participation of the internet create spaces for people all over the world.

One of their goals in the second round is to try to reduce barriers for applicants from these places because they feel like perhaps its financial, perhaps there's just a lack of understanding of (a) how the internet works and (b) how to participate in this process. So these have been two key objectives that ICANN has kind of really been trying to push as we move towards Round 2.

So there are lots of reports that come out about where things are. Really, I have to say I've been around for a long time. I've been in this business for about 26 years and have participated strongly in the Round 1 and helped a lot of customers get their TLDs. Round 1 was definitely blazing a new trail. It was very much every day you never really knew what was going to happen leading up to the round opening, and even after the round opened and applications were getting evaluated and coming online, it was the Wild Wild West some people would say.

ICANN has worked hard, and I will give them credit here. They have worked hard to make this process a little bit more predictable, a little bit more transparent, where there's visibility about what needs to get done, where are we on those things, and what's yet to do. So there's significant program management and governance in Round 2 here, and it's really, I think, helping everybody kind of know what's going to happen without a lot of surprises, at least to this point. So we're going to give credit where credit is due.

In terms of Round 2, where are we, the few things that ICANN has confirmed, we know that the application for a TLD in Round 2 will be $227,000 per TLD. That's like the base fee. There may be some additional costs based on what type of TLD is applied for. So for instance, right now, they're talking about an additional $500 fee if you want to apply as a Dot Brand.

The Draft Applicant Guidebook, this is something we've been waiting for, for a long time to kind of understand this program a little bit. It was just published at the end of May. The Draft Applicant Guidebook, you have to kind of look at it as like the run book for the New gTLD Program. It tells you everything from who is eligible to apply, what type of TLDs can be applied for, what the application process will look like, what the evaluation process will look like, what happens when there are multiple applicants for the same string, what if there are objections to an application, what trademark protections are there, and then also more information about if you're awarded a TLD, what are the compliance requirements, the technical requirements, the operational requirements, and all that kind of information.

So this Applicant Guidebook, the complete version was published on May 30, 2025. It's 395 pages. So if you're looking for a little light reading, I highly recommend it. It's now open for Public Comment until July 23rd. So it's a bit of a lengthy comment period, but ICANN has made it clear that they have no intention of extending that comment period. So now is the time.

What will happen at that point, once the Public Comment period closes, ICANN staff will put together a report that will summarize those comments. They'll get that published probably late August it's looking like. Then from there, there may be some tweaks that are made to the Final Applicant Guidebook. That Final Applicant Guidebook is expected to be approved and adopted by the ICANN Board by the end of the year. That's kind of the timeline that everybody is running towards.

When we say the round opening, when Round 2 opens, that means that the system opens to apply. That's, right now, planned for April of 2026. So we're still a ways out here. This is not something that's happening tomorrow. But it's time to kind of tune in. That time-limited window will be between 12 and 15 weeks. My guess, it will be closer to 15 weeks.

Something we do know about this round, as part of the policy work that's been done over the last 10 years, is there are not going to be any private auctions allowed. Closed generics will not be allowed, and plural and singular delegations will not be allowed. So it's going be one or the other.

I do give you ICANN's website. We're putting out lots of information and kind of distilling all the documents that ICANN is putting out. So certainly if you don't have time to read the 395 page Guidebook or kind of understand the program from top to bottom, we're here to help you.

All right. So where are they? Are they on track, is the question. I get that question a lot. So they've put out reports. Before every ICANN meeting kind of closes, they put out a report that kind of says where they are. So they're saying that the program is sort of yellow/green right now. There are some risks. There are some things that are taking more time than was initially scheduled. But they have developed what they call kind of "paths to green" kind of projects, if you will, to kind of get things back on track.

The two things that are really kind of slowing them down right now is there's a Registry System Testing, they're having some having some challenges with that, some glitches. So they're working through that to kind of test and pre-certify some backend registry systems. As well the portal that's going to be used to process the applications, that's taking more time.

So right now, like I said, they're saying yellow. During Prague, I would really say it was yellow/green. This report was as of the end of April. By the time the meeting happened earlier in the month, they were really feeling like things were getting closer to being back on green. So it looks like, right now, they're still feeling very strong about the timelines of approving the Applicant Guidebook by the end of the year and the application window opening up in April of 2026.

So in terms of what do you need to do, everybody needs to kind of pay attention to Round 2. It will impact you in some way. If your organization is one that's thinking, "Hmm, maybe I need to get a .Brand," well, then now is the time to sort of sit around the table. You need to kind of come up with a business justification and a budget for applying because there will be costs in 2026 to apply. The good news is you only have to kind of budget for the costs to apply because there will not be any TLDs that get delegated or put into use in 2026. So really the 2026 kind of budget really needs to think of if I'm going to do an application, what I'm going to need for application preparation and submission.

You'll also want to start thinking about and looking at your current Trademark Clearinghouse registrations because this is for the folks both who are applying and who may not apply but will obviously be living in this world with more and more TLDs being added. So Trademark Clearinghouse filings, you're going to want to look at them, make sure that they're up-to-date, that they're fully registered, and you have a current proof of use on file. You also may want to revisit your blocking strategy.

So these are some things to start working on to kind of get you ready, and you may need to budget some money to do. Maybe there have been some additional brands that you want to put in the Clearinghouse. Maybe you want to take on some blocks. So those are things you should be budgeting for, for 2026.

If you are considering brand, like I said, I really would encourage you to put together a cross-functional team, kind of understand the program, and really focus on your risks and opportunities there. I recently, I believe it was in the April time frame, put out a blog on our CSC blog site, "ICANN's New gTLD Program: Round 2 – Time to Tune In," that kind of gives those considering a .Brand some kind of step-by-step instructions about what they should be working on right now. So I would recommend that you take a look at that, and I think that's also a link in our Resource Center.

So how do you understand the program? Here we've given you a little bit of a high level of be ready, what do you need to do. But like if you really want to understand the program and the requirements, especially if you're going to potentially go forward and apply for a Dot Brand, I would really recommend, again, in our Resource Center you have the ability to register for an upcoming webinar that we'll be doing, "5 Key Takeaways from the Applicant Guidebook." So we plan during that session to give you a really good, high-level overview of what's in the Guidebook, some of the things that are very particular to Dot Brands, what the kind of application journey will look like, the costs that you should be budgeting for, all those things that you need to consider. So I hope you join us for that webinar.

So with the New gTLDs kind of behind us right now, Round 2, I know a lot of thinking is going on around about that, let's talk about some of the other things, really important things that are going on in the ICANN world and were discussed during the Policy Forum. So some of them relate to WHOIS, and we're going to talk about three things specific to WHOIS. We're going to talk about the Registration Data Request Service or the RDRS, urgent requests for disclosure of registration data, and also potential future policy work on WHOIS accuracy. So let's get to that.

So let me first make sure that everybody understands what I mean by the Registration Data Request Service or RDRS. So this was kind of the byproduct of a very long policy process after the GDPR became enforceable in May of 2018. When I started to go to ICANN meetings in 2020, I can remember sitting there with about 200 people and one of the topics being WHOIS. And here we are many years later, and we're still talking about WHOIS. It's been something that's been hard to get arms around it.

The domain system is a very self-service kind of industry, where people go online, and they register domain names. They complete the WHOIS template for the name, and they move on. So there's always been this issue about like, "Well, how do we get to that information? How do we know it's accurate?"

So in terms of getting to the information, when the GDPR became enforceable, in May of 2018, it was really the first time that ICANN had to formally recognize that the obligations they put on registries and registrars to publish the WHOIS record for every domain name may violate privacy statutes. There certainly were privacy statutes and regulations that existed before the GDPR, but they were very piecemeal. It was like country by country. It was a real matrix to try to keep track of. What the GDPR tried to do is kind of, at least in the EU, unify all those privacy laws in a way that you could make it a little bit easier to work from country to country. It was a time where ICANN finally had to realize that they couldn't force registries and registrars to publish all the information they were asking because it could violate that GDPR.

So there was a lot of discussion around how could access still be provided to WHOIS information when needed, like for law enforcement, for IP enforcement, for fraud investigations, and security investigations. What happened kind of at the end of that process was a proposal that was a very expensive system that would take many, many years to implement, and there were a lot of doubts about whether or not it was really going to be the solution to the problem.

So ICANN kind of regrouped. The ICANN community kind of regrouped. This RDRS system, think of it almost as a ticketing system, was created, where it's a proof of concept system to handle requests for access to nonpublic registration data. It really is trying to connect requestors of the information to registrars. Now it's really intended to try to streamline the process of making those requests.

The big challenge with it has been that it's not mandatory for registrars to participate. CSC does participate, but not all registrars do. There have been some big name registrars, like Tucows and others, who started by participating, but then have kind of pulled out of it. So it's really made it have, in some ways, limited utility.

But the whole purpose of this RDRS system, this proof of concept is let's see how many requests come in. Let's see what people are asking for. Let's see how registrars respond to this. Let's see what the challenges are in evaluating their requests. Let's see the time frames it takes for this. So it was really just to collect data, and the goal was this thing was going to run for two years, and there was going to be enough data to kind of then decide if that very expensive, very long implementation system that was created post-GDPR, by the ICANN community, was the right solution.

Well, ICANN has been operating this for about a year and a half. It started up in November of 2023. There have definitely been complaints. Again, not all registrars are required to participate. Some statistics came out from the first year. There hasn't been a ton of requests. We're talking thousands, not hundreds of thousands. I think that's what people really expected. A lot of requests are denied. Things are just not working. Even though the pilot is on deck for at least two years, the year milestone really kind of got the ICANN Board kind of reflecting a little bit and the ICANN community reflecting and saying like, "Is this useful? Is this something we should continue?"

The Board has stated publicly that they do believe that the RDRS is a useful tool and should continue, but it needs changes and improvements. I think there's a lot of support for that. So things like mandatory participation by registrars, making it contractually required as part of the registrar's accreditation contract to participate. Integration of affiliated or like privacy proxy services. A lot of registrars, those kind of more consumer-grade registrars, they can have hundreds to thousands of resellers, and it's really hard to kind of get in contact with them. The registrar itself is just really providing some technology to that reseller to do registrations. So there needs to be a way to get to those folks a little bit better, and RDRS doesn't really have a way to do that currently.

There are also issues around kind of requestor authentication, especially in the case of like law enforcement. Requests will come in there with people saying I'm from this law enforcement agency. I think everybody knows like the FBI, Interpol. But it's hard to know like every law enforcement agency around the globe. With the internet, it can really come from anywhere. So there's been a lot of discussion about kind of development of a requestor authentication mechanism really to help registrars kind of like be quicker and better about responding to those requests because it's really hard to know what's legit and what's not.

Then also, maybe allowing participation voluntarily by ccTLDs. Right now, the RDRS, ICANN only governs gTLDs. So this is only applicable to gTLDs. But maybe there's some applicability here to kind of give a more centralized resource to allow ccTLDs to participate voluntarily.

So where we are right now, the GNSO has a Standing Committee. The GNSO is that supporting organization I pointed to early in the presentation, when we were looking at the org chart. That's the Generic Name Supporting Organization. So the Standing Committee as part of that GNSO organization is working on a report that is expected soon, here in August. Then that final report will go to the GNSO Council and then to the ICANN Board. So expecting that Final Report to get to the GNSO Council by the next ICANN meeting to kind of understand some recommendations for the next steps when it comes to the RDRS.

Now the other kind of WHOIS topic that is getting quite a bit of attention right now is with regard to urgent requests for disclosure. So it's related to the RDRS, but it relates to some other requests as well, which is ICANN's Registration Data Policy. So there are times where there is an urgent need to get WHOIS information. I think everybody recognizes that. But what does that look like? How do you validate that? What's the kind of legal authority? What is the timeline that needs to be responded? What is considered timely? So these are some of the questions that are being kind of asked or kind of concerns raised about this particular Policy Recommendation around urgent requests for disclosure.

So ICANN actually, as part of the Registration Data Policy, had to move forward and issue that Registration Data Policy that kind of governs the WHOIS. Starting on August 21st of this year, the new ICANN Registration Data Policy will be enforceable. So they went forward and pushed that out to registrars and registries and got that going. But there's this one piece that's lagging about how to handle these urgent requests. So that's what's going on right now.

So right now, with regard to that kind of piece that's kind of lagging in resolution here, there are kind of two pieces of it or two tracks. There's an Authentication Track and a Policy Track.

So on the authentication side, this again goes to like how do you know what law enforcement agencies are legit when someone sends you something that says they're from there and that that agency actually exists. So the GAC has done a nice job. They have what's called a Public Safety Working Group or the PSWG within the GAC, and they formed a Practitioners Group that basically brought a bunch of "umbrella" law enforcement agencies, like the FBI, like Interpol, and some other stakeholder groups together to kind of talk about how could authentication happen.

Obviously, optimally, the long-term proposal is to figure out how these different law enforcement agencies could get connected to the ICANN portal so that there could be interaction. That is certainly a long-term proposal. I think everybody recognizes that. Shorter-term is, is there some kind of list and identifiers that could be published and shared with registrars, maybe even put into the RDRS as a way to kind of like say, "Okay, yeah they're on the list," and then you can move forward quickly?

So that's some of the discussion going on with the authentication piece of it. On the Policy Track, that EPDP Phase 1, this is all the post-GDPR kind of policy work that was done around WHOIS and kind of trying to make sure that the ICANN rules comply with GDPR and other privacy regulations.

This is about the timing, like how much time is really needed and should be kind of mandated for response to an urgent request. Right now, the proposal on the table is a 24-hour response time. In the internet, 24 hours is an eternity. So we certainly still have kind of people on different sides of the spectrum. We have people saying, "Yeah, 24 hours, that's great." We have people who say, "24 hours, that's not going to be quick enough." We have other people who say, "We need more than 24 hours. We're a small registrar. We can't operate like that. We won't be able to respond that quickly."

So there are people all over the place, but the ICANN staff is currently kind of developing a new like detailed text for everybody to kind of look at and an amended proposal. That's going to be distributed for discussion. The GAC I will say has been really, really diligent on this topic. They're diligent on a lot of these topics, but this is one that's very high on their radar, and they've really been pushing the ICANN Board to expedite final resolution on this. We'll talk a little bit more about that shortly.

So then the third WHOIS topic is WHOIS accuracy. Again, a topic that's been around for as long as I have and longer. The accuracy of WHOIS data has been an issue and particularly a very big issue for the GAC. The GAC, as long as I have participated in ICANN, they've been a group that's always been like we need to understand like the level of accuracy. We need to make sure that there are ways to confirm accuracy, to validate information. There have been lots of studies and working groups through all the years that have tried to make improvements. But really, the net result of all that has been very limited.

In 2022, again, the GNSO, they did have an Accuracy Scoping Team that was kind of picking it back up and kind of trying to take it baby steps forward. That kind of all got stalled, again because there was all this policy work going on related to GDPR and WHOIS, what fields should be in there, what data should be collected, what data should be published, how to navigate that all. So they kind of picked it back up like in 2019, but then it kind of got stalled in 2022.

Early this year, the GNSO kind of picked it back up again, and again, it's because the GAC is really constantly beating the drum on this. So definitely some credit is owed to them on that. But the GNSO issued some "threshold questions" on accuracy and basically said these are some things we need the community to kind of come back and tell us. They did receive responses from the GAC and other community members.

So right now, they have a Small Team within the GNSO that's kind of focused on this, that's reviewing those responses to those "threshold questions." Just some of the suggestions that the GNSO in kind of their discussions around what the responses were that they got is a desire to shorten the current 15-day limit for registrars to conduct registration data validation. So what that is when someone submits a WHOIS accuracy complaint to ICANN, they take that complaint and then it gets forwarded to the registrar. The registrar then has 15 days to basically conduct the validation of the data and come back to ICANN. They're thinking maybe that needs to be shorter.

There's thinking around maybe there needs to be additional registrant education about accuracy requirements. Again, a very self-service industry. English is not everybody's first language. People have varying degrees of sophistication and sort of understanding the domain name system and the internet as a whole. So maybe more education is required as to why that needs to be accurate.

Then there are also some feelings about like when a name does get suspended because after the registrar conducts a registration data validation and it doesn't come back as valid, that should be published as part of the WHOIS record, that this name is suspended for data accuracy problems.

So they're working on the final recommendations, the Small Team. That's expected in a few weeks. We'll see what happens here. ICANN, the Board has also said there are other things beyond the specific kind of WHOIS accuracy program that, from a policy standpoint, we might want to look into. Sometimes it's really hard to deal directly, especially if people are being bad guys, they're somewhat elusive, that maybe there are other ways, kind of indirect ways of getting at some of these issues. So the WHOIS saga continues.

So let's talk now about some other ICANN policy development that's going on that I think it's super important for companies to know about. So one of them is the Transfer PDP. PDP stands for policy development process, and that's the very formal process within ICANN to kind of scope an issue, put it into a working group, come up with recommendations, take it through the Board, and then put together an implementation review team to implement those changes. So it's a very formalized process. It usually takes at least two years. So nothing in the ICANN world happens quickly, even though there are some EPDPs or Expedited Policy Development Processes, and they're typically limited to a year, but they often have implementation that goes beyond the year. It's sort of the policymaking piece of it or the policy guidance takes a year, but then the implementation can take longer.

But nonetheless, Transfer PDP has been going on since 2021, so a little over four years now. The Working Group that was established for that came up with a Final Report in February of this year. It had 47 recommendations. The GNSO Council approved the Final Report at the last ICANN meeting. Now it has been forwarded to the ICANN Board. The ICANN Board got it in April. Then the ICANN Board has now opened a Public Comment period, which is now running through July 2nd of this year. So after the Public Comment period, they'll look at those comments and they'll consider the Working Group's Final Report. So that's what's going on here.

Just to give a quick sense, I won't go through every one of these. But just to give you a quick sense of some of the things they're looking at that came out of the Final Report of the Working Group, it's things like eliminating the 60-day inter-registrar transfer lock. So when you transfer a name from one registrar to another, it gets locked down. That was put in place to kind of prevent bad guys from kind of taking names from registrar to registrar to escape people trying to hunt them down. But there are some reasons why that necessarily isn't a good thing. So they're looking at some changes to that.

Also, trying to simplify the transfer authorization process to make it a little bit more user-friendly, but also still maintaining security. Looking at enhancing the Transfer Dispute Resolution Policy. There's also the potential introduction of something called a Transfer Emergency Action Contact or a TEAC contact, and then also try to standardize some forms and communications.

So it always amazes me about how much is going on simultaneously while in some ways very separate issues and problems all interrelated. So we'll continue to track this. As everything is going on with WHOIS and everything is going on with the New gTLD Round 2 and the Registration Data Policy coming in full effect on August 21st of this year, we will continue to keep everybody posted on how this all proceeds. The transfer policy I think is definitely one of the next things out of the ICANN kind of pipeline.

Another policy development process that's going on, and this is one of those EPDPs, so Expedited Policy Development Processes, is related to IDNs. So IDNs are internationalized domain names. ICANN loves its acronyms. Internationalized domain names are names that are not in ASCII characters. They're actually graphic files. So think of scripts, like Arabic, Japanese, Chinese. There's been a lot of trouble over the years with those scripts working on the internet, and they kind of get converted into something called Punycode.

There are lots of challenges with IDNs, but it's gotten better and better and better. Certainly, earlier in my career, IDNs operating on the internet, it was abysmal. It's definitely gotten better. There's been a ton of work, painstaking, very detailed work done around IDNs. So we're definitely getting to a much better place. This is one of those PDPs that's very important for Round 2 of the New gTLD Program because again, going back to ICANN's desire to really build inclusivity and diversity online, having these scripts, these different languages work on the internet so that people with different keyboards, it's a little bit easier for them to navigate to web properties, this all needs to work well. So there's been a ton of work here.

In 2021, GNSO had launch this EPDP. It kind of had two phases, like a lot of things in ICANN's policy processes. They kind of always start with the really big issue and say, "Oh, we might need to break that out into bite-sized pieces."

So really what we're focused on right now is Phase 2, which is kind of topics related to second-level variant management. What that means is what's right before the dot, trying to kind of deal with variants. There are a lot of scripts where there are similar things, similar characters to ASCII, similar characters to other languages causes confusion.

So the GNSO approved the Phase 2 Final Report back in December. It had 14 policy recommendations and some kind of implementation guidance. The Board ran a Public Comment on that. That's now closed, and staff is now kind of putting together a feasibility and impact analysis on the Phase 2 policy recommendations that the ICANN Board needs in order to decide sort of feasibility of all this and to make their final vote on the recommendations. So I think transfer policy and IDN EDPD are fighting for who will be next out.

So here are just some kind of key proposed changes, just to give you a flavor of what we're looking at here. So "same entity" principle, IDN table harmonization, oh, my gosh, your eyes will cross sometimes when you look at those IDN tables, and then adjustments to registry agreements and processes. So yeah, important changes that need to kind of get through.

Here are some additional. So it's not light work, for sure. It is something, though, that will certainly support ICANN's desire to kind of increase diversity on the internet here.

So another hot topic that it seems for years and years and years we've been talking about is Privacy and Proxy Accreditation. So this is like when you go to the WHOIS and it says something like domains by proxy, or it has another company's name in the WHOIS that's sort of serving as the kind of masking or hiding the true owner of the domain name. Now there are some very legitimate and good reasons why a registrant may want to do that. Many of our customers here at CSC, they're trying to secure names before product launches or before mergers and acquisitions or other important business deals. There's a reason to do that.

But what's caused challenges is that those Privacy and Proxy services do get in the way of knowing who the true owner of a domain name is. There haven't been a lot of rules around that. So ICANN registrars and ICANN registries sign contracts with ICANN. But these kind of third-party organizations that offer Privacy and Proxy services, they're usually affiliated with the registrar, but they are separate entities. They are under no contractual relationship with ICANN. So that's always been a very difficult topic in the ICANN world.

So in 2016, the GNSO did actually approve policy recommendations on Privacy and Proxy, and the ICANN Board adopted them. So everybody was like, "Oh, we finally made progress." But as the Implementation Review Team was working on kind of the implementation, guidance, and then actual policy language in 2019, this kind of came to a screeching halt because of all the GDPR stuff, again with what was the WHOIS going to look, what fields were still going to be there, all that. So it kind of got back-burnered. The GAC, again, beating the drum, "Where is this? Where is this? We need to talk about this. It can't sit on the back burner."

IRT was finally reconvened in the middle of last year, largely because a lot of the kind of WHOIS stuff was far down the road, the things that we've talked about in sort of like the Registration Data Policy was developed. So they really felt like the timing was good to kind of pick back up the Privacy and Proxy. So now, they've kind of reconvened that Implementation Review Team. They've outlined their purpose, and they're working through an analysis and policy design.

Just to give you a little bit of a sense here, this was back in 2016. We're almost at 10 years old something that was developed, kind of pick that back and say, "Okay, what of this is still good? What of this needs further analysis? How has the world changed?" So they put together a set of "threshold questions." There are going to be some questions and the answers to those questions that they get, that's going to require further policy work because, again, the world has changed. So that's expected. I wouldn't say this is an immediate thing we're going to see the answers to. So we've got a little bit of time here on this Privacy and Proxy, but at least it's back on the front burner, and I think that's very important.

It wouldn't be an ICANN meeting if we weren't talking about DNS abuse, and we absolutely should be. DNS abuse, we talk about this in every one of these ICANN webinars that I do. It is a pervasive and persistent problem, and it morphs every single day. About a year ago, a little over a year ago, there were DNS Abuse Amendments that were added to registry and registrar contracts. Very kind of light touch, but something that sort of said there's an obligation, when DNS abuse is brought to your attention, to do something. The something hasn't been super well-defined, but it felt like it was a really good first step to get those amendments in place at all. And now we kind of need to move that forward.

The GAC is, again, really beating the drum and saying, "Okay, we got these amendments Great, good job. But we still have a lot, lot, lot more to do." So they've kind of outlined about how they're kind of seeing things and how they think things should progress here in this little table because they believe that it is not solely ICANN's problem. DNS abuse is not solely ICANN's problem. It's really everyone's problem, all of our problem. ICANN and ICANN Compliance does have a very important role to play here in DNS abuse.

So there was a session that had a bit of a brainstorming session in it at the Prague meeting, where the contracted parties, so that's registries and registrars, kind of put together and kind of opened for discussion kind of four ideas of what their communities are kind of thinking about. Now you have to remember there are a little over 3,000 ICANN accredited registrars around the world. Most of them are consumer-grade registrars. Companies like CSC, we're kind of like an anomaly in the industry, kind of just focused on helping corporations. So largely the industry is driven by, with us and a few others chirping, these consumer-grade registrars.

So they did hold this session to share kind of some of their thinking and brainstorming and to get community kind of input. These were the four ideas they put out there.

One was related to you get a domain name abuse report as a registrar. Do you just look at that name, or do you look at other names in the account or associated with that registrant? Don't we maybe need to do more here?

Also looked at whether the current requirements of the Registrar Accreditation Agreement regarding resellers could be improved with some kind of reseller obligations with respect to DNS abuse. Again, over 3,000 ICANN accredited registrars with many, many, many thousands of resellers on top of those registrars that are sort of like a step further away from ICANN. So how do we need to get them and clarify what their obligations are?

Also talking about whether there should be a clearinghouse. This is, again, going to understanding DGAs. So who can function as the clearinghouse? What functions can the clearinghouse perform?

And then, lastly, what about the existing best practices for phishing reports? Like how do we elevate that? Could more wide adoption help mitigation efforts?

I'm not saying these are the only things registrars and registrars can do. But these are their ideas that they're putting out there initially to talk around DNS abuse. So that's one kind of conversation that's going on in the ICANN community.

Another conversation is clearly coming from the GAC. Again, this is their role, public policy, public safety, wanting to make sure that ICANN, they are an advisory committee to the ICANN Board, making sure that as all this policy work, this consensus, bottom-up policy work is being done, that the ICANN Board is being constantly reminded about the public safety and the public kind of concerns, the public impacts that these policies will have and kind of understanding from a government perspective what are some other considerations that maybe weren't considered within the ICANN community. That's really the role of the GAC. With DNS abuse, they've continued to play a really important role. So the GAC continues to push ICANN on expediting and expanding their work on DNS abuse mitigation. We talked about that a few slides ago.

But every meeting, at the end of the meeting, it used to be on the last day of the meeting, but now it happens several days after the meeting, the GAC issues what is called their Communiqué for the meeting. The Communiqué, it will summarize kind of some of the groups they met with and things they talked about while at the ICANN meeting. They'll talk about some internal matters, committees they're setting up, or reports they expect to issue or something like that. But then it will have two sections. It will have one which is called Issues of Interest to the GAC or Issues of Importance to the GAC. Then they have a section called GAC Consensus Advice.

The GAC Consensus Advice is a very formal piece of advice that the GAC is giving the ICANN Board. And actually, the ICANN bylaws have requirements about how the ICANN Board has to handle that advice. They either have to accept it. They either have to ask for clarification. Or if they reject it, in whole or a part, there's then a process by which that kind of dispute gets mediated, and they try to work through those differences. So the ICANN Board just can't go, "Well, thanks GAC, that was great advice," and move on and do their own thing. They have to respond to that.

The last couple of meanings they haven't issued any advice, which has been highly unusual. But this meeting, they did issue advice around kind of getting ICANN moving on the Policy Development Process on DNS abuse issues, and they're particularly worried about bulk registrations of malicious domains. Especially in kind of the age of AI, there is a lot going on. We thought the internet moved fast now. AI is just accelerating everything, including the bad acts.

And so they have basically said they need to urge the GNSO Council, because that's where this bottom-up policy work will come and work will be done, to get the necessary preparations, prior to ICANN84, towards starting targeted and narrowly scoped Policy Development Processes on DNS abuse. So enough talking, is what they're saying. We want some very narrowly-scoped improvements, and the PDPs need to start on those ASAP. So very clear what the GAC wants.

So like I mentioned before, DNS abuse, persistent, pervasive. AI spilling gas onto it. It is very, very difficult to keep track of everything and to understand everything that's going on out there.

So I just want to make sure I mentioned this the last couple of sessions, CSC has recently released CSC DomainSec UI. It really is a great portal to help you understand sort of your domain security, brand protection, fraud protection. It's a first-of-its-kind kind of platform. It has machine learning, artificial intelligence, clustering technology. It kind of takes it all, looks at the data 360, and highlights the risks, the actionable insights that are risks that you really should be taking a look at. We're actively demoing this to our customers right now. But certainly if either we haven't yet reached out to you or you're not yet a customer of CSC, you can go and schedule a demo at that URL. I think you'll find it a very useful platform.

So to wrap up here, we talked about the GAC throughout. I thought it would be important and I want you to understand, right now, there are 184 member states. There are 40 observer organizations. Participating in this last meeting, 80 GAC members and 9 observers. So there's always never full participation. A lot of people do participate in and out remotely. But they're a force. I always say that if you want to know what's going on in the ICANN world, what's going well, what's not, watch the GAC. You'll know what's happening based on their kind of reactions and discussions on things.

So I mentioned the Communiqué, and I mentioned what the GAC Advice was this time. But I also wanted to mention and kind of highlight some of what they consider their Issues of Importance. So these are things where they're saying, to ICANN, we are tracking these very closely. They'll give kudos, and they'll also give like encouragement. But they'll also kind of try to point ICANN in a certain direction. We've gone through a lot of these as part of this presentation. But I wanted to give you a sense of domain name registration data, very, very important to them. Round 2, very important. They're happy that the Draft Applicant Guidebook is finally out.

The GAC is a little worried about their own readiness. So they're really talking about that because when applications get put forward, after the application window closes, there is an opportunity for GAC, for countries to basically object to applications. So there's a whole what they call early warning system that the GAC needs to be able to act in a timely way for. So they're kind of preparing.

They're also looking at governance of regional internet registries. Also looking at general ethics policies and Code of Conduct. There have been some concerns about people, particularly from law firms, not being exactly clear who they're representing in some of these working groups and in some of these public forums.

DNS abuse, we talked a lot about. Then, lastly, there are accountability and transparency reviews that happen at ICANN and reports are issued on a periodic basis. We're up for the 4th ICANN Accountability and Transparency Review since ICANN kind of spun off outside of the control of the U.S. government. So there has been a decision to defer that given everything that's going on right now. But the GAC is saying that should not be deferred for long.

So lots of issues and lots of things going on. But certainly, things that we have to keep watch of to make sure that everybody stays informed and we're able to kind of navigate any changes that come at us that come from ICANN.