INSIGHTS FROM ICANN 62 IN PANAMA CITY

Annie: Hello, everyone, and welcome to today's webinar. Greetings from the Canal, Insights from ICANN 62 in Panama City. My name is Annie Bruxelles, and I will be your moderator. Joining us today is Gretchen Olive. Gretchen is the director of policy and domain name services for CSC. For nearly two decades, Gretchen has helped Global 2000 companies divides global domain names, trademarks, and online brand protection strategies, and is a leading authority on the ICANN new gTLD program. And with that, let's welcome Gretchen.

Gretchen: Thanks, Annie. Every time you say almost two decades, 20 years, it's been a long time, so it just always gets me every time I hear that. So, welcome, everybody. Thank you very much for taking the time to join us today. As always, the ICANN meeting was eventful. It never disappoints. There's always lots going on and this was no exception.

So, before we get started, let's just quickly kind of look through what we're going to cover today. So, we'll do our usual ICANN overview. I do see some new names on our attendee list today. So, thanks for joining us. For veterans of this webinar series this will be a bit of an overview, the first couple of slides, but then we'll get right into key policy updates, particularly the new gTLD subsequent procedures, PDP, and also the ICANN Temporary Specification and GDPR, which are two hot topics.

Then at this time, we'll get the quick update on the rights protection mechanisms PDP, current thinking around the auction proceeds from round one of the new gTLD programs, and a quick discussion on geographical designations.

So, as some of you heard me say before, ICANN is a consensus policy, multi-stakeholder model. And consensus when you have people coming from many different kinds of perspectives is a hard-fought battle. And so, oftentimes while it does seem that it takes quite a bit of time for things to get accomplished within ICANN, the fact that matter is that there are a lot of people at the table.

And so, just to give you a sense of who we are talking about when we say ICANN, first of all ICANN, the acronym stands for the Internet Corporation for Assigned Names and Numbers. And that's the organization, but you'll often hear myself and others refer to the ICANN community. And the ICANN community is sort of all these people that are on the slide. So, you have both the ICANN organization, which is inclusive of staff, the president, as well as the board of directors. But then you have supporting organizations, which are in the kind of blue shaded boxes. And then you have advisory committees, which are in the gray and black shaded boxes.

So, the supporting organizations, we mostly focus in this webinar series on the GNSL, the generic name supporting organization. That group is made of different stakeholder groups that have very kind of vested interests in the generic name space. So, those are folks like the registrees, the registrars, ISPs, IP interest, business interests, non-commercial internet users, not-for-profit organizations. Those are the kinds of groups that make up the GNSO.

Because it is a consensus policy, a bottom-up consensus policy organization, typically policy matters get first discussed and identified at the different stakeholder level and then it kind of bubbles up to this stakeholder organization for a policy process often referred to as a PDP, a policy development process. And then decisions get bubbled up to the board for a vote. We'll be talking a lot of a PDP this session, so that's why I figured I'd just point that out.

So that's the structure of ICANN, if you will, and the folks who are not staff, these are volunteers. These are people who come from different organizations, so the ones in the light blue boxes. They're coming from different organizations. They may work for a company, but they volunteer their time to the ICANN policy process. So, they don't get paid for their time for their work there by ICANN. It's just something that you can help shape these policies as part of maybe other responsibilities with another employer, but again, not paid for by ICANN.

And then the people in the gray, these are also volunteers that come from largely technical, the technical community. So, like software engineers and operators of different parts of the backbone of the internet, as well as governments, and that's that dark gray box. The Governmental Advisory Committee is made up of representatives typically from countries like Telecom Ministry or something like that.

And they come to help provide input ICANN as to the different policies that are bubbling up from these stakeholder organizations. They give the lens of the public policy, whether or not these things that are coming up through the stakeholders are really taking care of some of the public policy concerns that government has. So, there's a natural tension there, and over the last three to five years, the Government Advisory Committee has taken on a greater and greater role within the ICANN community. So, we'll talk more about that as we go along.

Now, you also need to understand that there are three public meetings per year. And so, they're kind of originally titled Meeting A, Meeting B, and then Meeting C. They've got to work on some marketing there, I think, for the names of their meetings.

Generally, Meeting A happens in the beginning of the year in the March timeframe. And that's a long meeting. It's a six-day meeting. Meeting B, which is the one we're talking about here today, typically in the June timeframe, is a four-day format and it's really intended to be a true working meeting. It's where these different work groups, and stakeholder organizations, and different stakeholder groups get together and actually do face-to-face meetings to work through these issues.

So, sometimes they're working within their own community, but other times, there's an opportunity to cross collaborate. So, you might have like the Governmental Advisory Committee, or the GAC, meeting with the PDP group that's working on the new gTLD subsequent procedures. So, you get a lot of cross communication, which is good.

And they're, again, working meetings. They're less about trying to point out the accomplishments. It's more about trying to make decisions. So, it's a pretty intense four days. There's a lot going on and a lot to follow.

And then Meeting C is their annual meeting every year. And then we'll address that when we talk about that one later this year.

With that aside, now we understand who ICANN is and how frequently they meet publicly. There are certainly intercessional meetings. Let's talk about what they focus on this session.

So, one of the key policy initiatives going on right now is what's called the New gTLD Subsequent Procedures PDP. I understand that's a mouthful, but really what it is, is it's the policy development process to try to assess and improve the procedures and the policies that were in play for round one of the new gTLD program.

So, for those of you who are familiar with round one, that was something that…there was a defined application window between January 2012 and May 2012 where people put forth applications to run top-level domains or TLDs. New gTLDs they were titled. And the challenge there is they got way more applications than they ever expected. And because there was such a quantity and a variety of applications, not all the policies that needed to be in place were at the time. That this took place, so, that caused a lot of challenges.

So, you'll see that this PDP is really trying to address some major issues and there are three overarching ones, I'll highlight. One is the different types of TLDs. The application process really just envisioned a standard TLD and a community TLD. But as we moved through the process, we realized that wasn't enough. Having those two big buckets, one-size-fits-all model was sometimes problematic. So, you had TLDs that were dot-brand, and that was companies coming forward and saying they wanted a dot product name or dot company name and they wanted to operate it just for their benefit and to interact with their customers. This wasn't going to be sort of a place where they're going to send lots of domain names to a third party. So, this was a very different model than what had existed before.

Then you had nonprofits coming forward that wanted to have more space for advocacy and awareness of different issues. You also had Geo TLDs or Geographic TLDs that broke out of the norms that we saw in the past. So we had seen a dot-EU and the dot-Asia, but now we saw cities dot-London, dot-Paris. We saw almost regional areas with the very controversial dot-Amazon, which was not intended to be about the Amazon region, but certainly the Amazon region took issue with Amazon the company applying for that. So, lots of new issues and challenges to deal with different types of TLDs.

Again, with all the variety that was there, the policies not all being in place, there was a challenge with predictability in sort of community engagement. So, there were a lot of things happening. It was relatively fast moving once everything hit the ground. And it was hard to keep up with everything and for people to step away from their day jobs and engage on issues that potentially could impact them. And so, community engagement kind of went up and down a bit.

And then just the whole process of assessing applications and rounds, meaning…they call this round one, the new gTLD program. Given the fact that they received 1,930 applications, of which there were 1,409 unique strings, that's a lot to assess all at one time. Is it a good idea to do this in rounds? Should it just be a perpetually open round so that they space out bit more? Is there another way of doing this? Do you do it by type of application or type of applicant? There are a lot of things around that.

So, the work has been pretty much…they've been working on this PDP for just about over a year now. And they separated this analysis in four work tracks initially. So, you see WT1 through 4 there, and that's Work Track 1 through 4, and the different categories of work that's being looked at in each of those work tracks.

Work Track 5 came along about six to eight months after those first four got started, so it got a late start. I think over time people realized the geographic name issues had a lot of specialized thinking that needed to be done, particularly a lot of the governments are very…there's been a lot of controversy and contention between the Governmental Advisory Committee and ICANN and the community at large related to geographic names. So, anyway, that really needed to become a separate work track to properly address that.

But these work tracks have been under way and they have issued just recently an initial report. You see on the top of this slide, I give you three links. And what these three links are is it's the initial report, Annex C, and then also a summary of those initial recommendations and questions in more of a table format in Excel. So, if you don't have time to read the whole initial report, even the executive summary, you could go to the summary of initial recommendations and questions and see things bulleted out a bit, which might be helpful if you're pressed for time. But these three documents make up the initial report of Work Tracks 1 through 4.

Now, what was a little bit different about this PDP's initial report is each of these work tracks worked very much in…I don't want to quite say isolation. We're very focused on their specific bucket of issues. And in fact, there was some discussion during this meeting where participants, say, in Work Track 1 had a lot of thoughts and opinions about what was going on in Work Track 4. But because they were so focused on one, they didn't have time or the opportunity to really participate in developing the content that came from Work Track 4.

So, you kind of have to look at this as four groups consolidated report, but not an integrated report. And I think that's one of the things people see as perhaps unfortunate, that that couldn't come together in this initial report. But the initial report really aims to take the temperature of the group rather than seeking full consensus among the group.

So, this will be interesting to see comments that come in. This is not only comments from…certainly members of the different work tracks can comment and a lot of them I believe will. They're very committed to sharing their views in this area, but also the public at large can comment.

There is an extended 60-day comment period for this initial report. So, it will be open through September 5. I know it's the heart of…for a lot of people in the western side of the globe, it's the heart of the summer PTO if you will. But for those of you on the AIPAC side of the globe, maybe there's some time here to take a look. So, you can see the link there where you can go to the public comment period.

Now, what will happen once their public comments for the initial report close, ICANN staff will summarize them and they will put together a staff report, and that's due on October 5. So, this won't be the last time to comment, but for those of you who follow this webinar series, I've said at different points in time this is what's going on, but this is not kind of a critical juncture. This is one of those times where it's really important to stop and look carefully at what's going on here. The initial report is that first true glimpse into how these issues are progressing. So, I really recommend that people take the time to look at this initial report.

Currently, the way things are timed out, we're expecting a final report sometime in Q1 of 2019. And the GNSO Council, the Generic Name Supporting Organization, the council who basically called for this PDP, will review the final report in Q2 of 2019.

Now, like everything ICANN, dates are subject to change, so just be aware that. I would not be surprised if some of this slides a bit, but given everything that's going on with GDPR, and we'll talk about that in a little bit, this train is moving forward, so if you have comments regarding how round one happened, and how it impacted your business, and how it made things more challenging, and if you have recommendations on how things could be better, I would strongly recommend you start following the initial report and solidifying your thoughts on that.

So, with that being said then, where do we go from here? So, the plan of the group is, as I mentioned, to get a little bit away from the work track categorization and grouping of members on this PDP team and move toward to category-based work streams. They're not going to be those work tracks. They're not going to be as defined. They're going to kind of break things into three parts, the overarching issues, foundation issues, and pre-launch being one; application submissions, processing, and evaluation two; and then disputes, contention resolution, contracting, pre-delegation, and post-delegations in a third. And if they're hoping for kind of cross participation by the different members, not that they're going to be pegged to one area.

So, this is where I think things are going to truly get fleshed out. You'll see some of it start in the comments and then I think this post work as they move toward both an interim and a final report, you'll start seeing things coming together and truly getting integrated.

The goal is for each position to be designated a level of consensus from full consensus to minority. The method of consensus is still to be determined and that's something they're hoping the co-chairs can establish, that it's those levels of consensus. But this will be morphing a bit.

As I mentioned, Work Track 5 is a bit behind these first four, and it remains behind, but there is some kind of convergence, I would say, around some of the country and territory geographical issues. So, there's some hope that this will start to catch up. But as of right now, it's not. So, we'll continue to track that.

So, with that behind us, let's talk a little bit about a couple of these related or key policy issues that are happening simultaneously. So, for a long time we've been talking about Privacy and Proxy services accreditation. It's something that was actually envisioned even before the 2013 registrar accreditation agreements, the new registration accreditation agreement that was drafted and implemented.

And in that registrar accreditation agreement, it talks about the future of Privacy and Proxy and that there would be an accreditation process and that registrars would need to comply. So, that policy work has been going on for some time and it's actually now at the implementation review stage.

So, when a PDP happens, you have a situation where that PDP creates the policy, but then that policy needs to be taken on by the ICANN staff and others in the community and work toward implementation. And the implementation can sometimes take quite a bit of time. So, this is a bit of a sticky one, the Privacy and Proxy services, so this is where ICANN wants to have some rules of the road and some ability to enforce compliance against those who provide these Privacy and Proxy services, because right now, ICANN doesn't have any real authority.

The challenge here, as we will see with a few other issues, is that GDPR has a kind of an impact here, and it has an impact on a lot of issues. When one of these issues like a GDPR comes up, it sometimes can take these issues off the rails a bit. So, both the temporary specification that ICANN issued in May of this year around GDPR, which we're going to talk more specifically about in a minute, and GDPR as a whole will have an impact on this moving forward.

So, the implementation team's work has really slowed on this. They've only met a few times since ICANN 61, which was in March. A final report is with ICANN legal for review in the context of GDPR and the temporary specification.

There are also still issues around the service levels related to the timeframes in which these Privacy and Proxy service providers need to act. Law enforcement agencies want immediate contracted parties like registrars and registrees. They are saying, "If someone contacts us we can't act immediately, but we could act perhaps in 24 hours." Again, not all registrees and registrars are created equal, so there's some tension there. There's also some tension around the fees around accreditation.

So, the train is slowed, I guess, is the summary of this issue, but it is still inching along, and I know that this is an issue. These Privacy and Proxy services are something definitely near and dear to the hearts of people like us who worry about intellectual property rights online and also security. We want to be able to get to people who hold the name quickly in these Privacy and Proxy services, especially in light of the impact GDPR has had on WHOIS. This issue is one that really needs to see resolution.

There's also a working group, which has been called Next Generation RDS. RDS is an acronym for a Registry Directory Services. And it really is looking at what's the next generation of WHOIS publication. They were tasked with…this workgroup, which has been working probably the better part of a year and a half, probably even two years if I think about it, they were looking at two key questions. What are the fundamental requirements for gTLD registration data? And are new policy framework and next-generation registration directory services needed to address these requirements? This has been a working group that has been highly contentious.

I started following ICANN back in about 2000 really closely. And so, for the last almost 18 years, WHOIS has been the pink elephant under the table. It has been an issue. It has been one where the parties just cannot come to agreement and consensus. And people really dig in their heels.

This was no different, this working group, but it actually went to the next level. And at one point the ombudsman really even had to get involved here, the ICANN ombudsman, because the attacks were so personal and vicious among the participants and the behavior was so bad. The chair walked away from the group it was so volatile.

So, the question is whether or not…this is one that in light of GDPR, where Privacy and Proxy is inching along, this one it looks like will be dissolved and merged into what we're going to be talking about a few minutes, which is the ePDP for the temporary specifications that ICANN issued around GDPR. So, I'll explain those acronyms shortly, but it's likely that this work is going to stop in this location and get picked up in another location.

So, now let's go to everyone's favorite topic I know: GDPR. First, let's just understand where we've been. This slide gives you a quick timeline of what's transpired over the last almost…at least 9 months, maybe 12. But in sum, GDPR is an effort to unify or put an umbrella over the different national data privacy laws that exist in Europe. Each country has data privacy laws. And while they're similar in some respects in how they protect personal data, there are dissimilarities, and it makes it difficult for people and other companies to do business with entities and people in Europe because of needing to know a lot of specific rules per jurisdiction to navigate.

So, this GDPR, the General Data Protection Regulation, was actually enacted in late April, early May 2016. And the regulation had a two-year ramp-up period. So, it basically said, "This is the regulation and we're going to give you two years before we start to enforce the regulation." So, it's been a two-year ramp-up period.

It wasn't until about mid last year that the ICANN community said, "This GDPR thing, this could be a problem." And the problem was related to, yes, our favorite topic, WHOIS. As many of you know from your experience with domain names, the WHOIS will give you details about a domain name like its expiration date, or its DNS servers, or the registrar that's the sponsoring registrar for it. Those are all details that you'll get out of WHOIS. But also in the WHOIS are contact details, so you'll have the contact information for the registrant, the administrative contact, the technical contact, and the billing contact.

And in many cases, because not all of these domain names are owned by companies, they're owned by individuals, or small groups, or families, they're individual's information. So, it's Suzy Smith at 123 Pine Street in this city and this state. Here's her phone number, and her email, and her fax number. You can see there's a lot of personal data in that WHOIS record.

But it really wasn't realized, like I said, to mid last year that GPR wasn't going to give an exception for the WHOIS. I think the WHOIS has just existed since the beginning and for whatever reason, everybody thought, "We need this WHOIS to contact people who own websites, for law enforcement to use it as a starting point to do maybe an investigation, for intellectual property owners to defend their intellectual property rights, particularly trademark rights online." So, everybody just assumed this was a very necessary thing, and so of course it would continue. But it quickly became evident that . . .

At that time, the article 29 working group, which was the group that was working through the final implementation and enforcement pieces of GDPR, basically said, "No, WHOIS would be impacted by GDPR," and that sent the whole ICANN community into a complete spin.

And different groups started getting together and coming up with models. The Eco Model from the Eco Foundation was one that gained early steam. Then you had ICANN with different models, because they are getting legal advice as to how they should treat this all. They have contracts with registrees and registrars that say that registrees and registrars have to collect that information and publish that information. So, now something that was a contractual requirement between ICANN and key contracted parties in the domain name system was illegal, really, under GDPR, prohibited under GDPR. So, this was a new wrinkle and twist.

ICANN thought maybe they could work with the data protection authorities in Europe and convince them that there be a waiver or an extension related to WHOIS, and that did not come to fruition.

And what we found is here we were in February or March of this year, and there was no visible path to what the final outcome of this should be. The next-gen registry directory service workgroup blew up. Everybody knows that there needed to be changes, but there was no time or mechanism to really make that happen.

So, on May 17 of 2018, of this year, ICANN would up issuing a temporary specification that is now valid for a year. Basically, it will be re-upped every 90 days, but it can be re-upped for a total of one year. And this is completely new territory for the community. There's never been a temporary specification, so everybody's learning on the job on this one. It's amazing the things you'll find in the bylaws of policy documents. But we apparently have this temporary specification process.

So, to give you a sense, we've used a slide like this, and we've added a couple things this time, in previous webinars on this topic. But the models for GDPR that were evolving over the last year were diverse, and you can kind of see how they fall on this spectrum.

The ICANN community is a very diverse group. You saw in one of those very early slides in this presentation the different stakeholder organizations, etc. And everybody comes with their own perspectives and their own interests and how they interact with the WHOIS, and with the internet, and with the domain name system. And so, you have geographic diversity. You have business model and use case diversity. And then you have cultural diversity on top of that. Throw some extra rules and regulations in there and it's quite a mess.

So, where we wound up was somewhere in the middle. We're not quite at the model 2B that ICANN was trying to push along, but we're somewhere close to that with the temporary specification. So, that's where we kind of sit today, but we now have a year to work through that.

So, let's first dissect a little bit what the temporary specification is and what's in it, and then we can figure out how we're going to work through these issues and turn this temporary specification into permanent consensus policy.

So, the key areas of the temporary specification impacting businesses are…there are four key areas. One is the public WHOIS, one is contacting registrants, third is who gets access to WHOIS data, and forth is transfers. So, basically, on the public WHOIS, you're not going to see what you always saw. We're going to show you some slides there of what you're likely to be seeing.

Secondly, being able to reach out to registrants is going to be much tougher. There's a little mechanism that's being used by a lot of registrars, but we'll talk about the pros and cons of that.

And then, who gets access? So, GDPR really talks about only people with legitimate interests should have access to this data. Well, what's a legitimate interest? Who defines that? How is it defined? A lot of issues wrapped in that one.

And then the actual transfer of domain names is very significantly impacted as a result of this temporary specification and the enforcement of GDPR.

I give you on the bottom of the slide the link to the temporary specification. It's not a long read, but it's a lot of ICANN-ese, so hopefully we'll in the next few slides kind of break it down for you, but if you actually want to see the source text, you can find it at that link.

So, let's first talk about what the WHOIS looks like under the temporary specification. You may or may not know that in general…first of all, let me actually take a step back. This temporary specification only impacts gTLDs, both the legacy and the new gTLDs. It does not impact ccTLDs. Those policies are controlled by the individual governments for which their ccTLD operates. So, France controls dot-fr, United Kingdom control dot-UK, Canada devises policies for dot-ca. So, we're just talking about gTLDs here.

And in the gTLD world, most gTLDs are what they call thick. They're run by what's called thick registries or the WHOIS is thick. What that means is that the registry is the authoritative source for not only domain details, when was it registered, when will expire, what's the DNS, but also will be the authoritative source for the contact information.

There are some TLDs, though, the dot-com, and dot-net, and dot-jobs that are thin. And that means that the registry stores the domain details. It doesn't store the…they're not the authoritative source for the contact details for that registrant, admin, technical, and billing contact information. That sits with the registrar.

So, for example, if you were to do a WHOIS look up as VeriSign, Inc. before GDPR, they would certainly show you the domain name, when it was registered, who the sponsoring registrar is, the date it was registered, when it will expire. They'll show you all that domain-related data, but they would not show you any contact data because they don't manage that. They don't ask registrars to send it. Those authoritative contact records are with the registrar. You'd have to go out to a different WHOIS tool, and that WHOIS tool would have to get that information from the sponsoring registrar of that name.

So, you can see how it's been difficult to get that information because you have to find out who the registrar is. Some of that's done through the magic of technology, but not all of them make it easy. There are a lot of CAPTCHAs, "I'm not a robot," check this box. There are lots of hoops that you have to get through sometimes get the information. Some registrars throttle and only let you make so many inquiries per day, per hour, etc.

So, the thin WHOIS data, under the temporary specification, will not change for gTLDs. So, every registry will continue to publish and display the domain-related details, and you see the list here. Where it gets different is when we're talking about the thick data or the contact data. That's where a lot of it will not be displayed.

So, the challenge is not everybody is doing the same thing right now, and that's the case for a few reasons. One, this temporary specification didn't come out until May 17, so it takes time for registrar's to implement these changes, and for registries to implement these changes. So, some are still working through those technical development efforts to get this implemented.

The other piece is you also have the ccTLDs in the mix. I've gotten quite a number of calls from clients who say, "When I look at this ccTLD, I see this WHOIS output. But then I go to gTLD and I see this. Why is it different?" Again, ICANN only controls or governs the gTLDs. They don't govern the ccTLDs.

Some are in various stages of implementation. We also have different business models out there among registrars. So, for example, many of CSCs customers are corporate. That's who we serve, corporations and law firms. And many of them came to us and said, "We want our WHOIS information published. We don't put individual names in our WHOIS. We have generic titles, generic role, email addresses, our organizational information, and we want that information to be published. We want that published because it helps us assert our trademark rights online for branded products and names as well as it helps with SSL certificate renewals because there's a WHOIS validation component in also getting SSL. The WHOIS validation process will go much more smoothly if that information is published."

So, many of our clients said, "Can you continue to publish our information?" and we have made that our policy, but they can also request to redact and we do that where they request that.

But the challenge is that we may publish the information, so if someone came to our WHOIS and looked at it, they would see it. On the thick TLDs, we're not the authoritative WHOIS. So, you may have a registry who's decided that they are going to redact information if the registrant country is within the EU. That is happening in some cases, where despite the fact that the registrar has committed to publishing and is continuing to send that information over for publication to the registries, the registries themselves are redacting at their level. And it's even happening on the thin as well.

So, it's a bit of a challenge right now. It's a mixed bag out there. Not everybody's gotten their full policies and their development work done. So, I would say it's going to probably be another couple of months before everybody gets to at least their temporary state, and then we're going to be having additional policy work here, which we're going to talk about in a second.

Let's try if we can bowl through a little bit more here. You saw on the prior slide that, in the email fields, there's an option for a web form. So, basically, what the temporary specification says is that registrars must provide WHOIS information to requesters who have a legitimate interest. But we've gotten no guidance as to what is a legitimate interest.

Now, I can certainly sit here and I can draft a policy and that could be the policy. The challenge is that from registrar to registrar, that's likely to be seen differently. And then you also have to have staff on board who's going to manage those requests and be able to make those judgments and things like that. So, it's a bit of a tricky activity.

One of the things the different data protection authorities have endorsed in their back-and-forth with ICANN is they've been okay with the notion of, in the WHOIS field, providing a link to a web form where someone can basically fill out, and this is an example of one, their request for the WHOIS. While they won't see the contact email address, behind the scenes of this web form, the registrar will have this basically request emailed to the email address for them to respond to so that they can make a determination about whether or not the request is a legitimate request.

It's a good thing because it gives folks an avenue to get to the admin or registrant contacts, but there's no tracking on this, so you can send them, but there's no guarantee that's one's going to get back to you. And it's hard to follow up because you don't see their email address. So, how this actually turns out working will be something we'll watch closely.

The other thing I mentioned is that transfers really get mucked up without the WHOIS. So, in the domain name world, to initiate the transfer, that initiation happens with the gaining registrar. So, if somebody is moving their names to a different registrar, that new registrar then initiates the transfer.

And over the last three to five years, there's been a ton of policy work done on the ICANN front to tighten up that transfers process so that any loopholes where names could be lost or hijacked were tightened up where there was full disclosure and transparency on the process and controls.

But unfortunately, without the WHOIS, we've now blasted another big hole into the transfer process because there's something called an FOA, a Form of Authorization, that prior to GDPR would be sent to both to the gaining registrar with partial WHOIS information and send that form of authorization to the registrant on email. And then once it was confirmed, the gaining registrar would be able to then request the transfer. So, it was sort of like an if/then proposition as a trigger. You got that FOA in, and then you would initiate the transfer. But now those emails can't be sent because we can't see email addresses. And so, that's caused the process to really break down.

So, what's happened is, under the temporary specification, that whole kind of email form of authorization process has had to be kind of discontinued because again there's no email address. So, for transfers, the gaining registrar, if they get just simply the auth code for the name…Every one of these domain names has an authorization code often referred to as an auth code. That's given to the gaining registrar to initiate a transfer.

And so, now you have situations where you assume that auth code was retrieved by an authorized person, but what if it wasn't? What if there was some kind of data breach or something like that and auth codes got in the hands of the wrong people? So, you can see how now there's expected to be a higher risk of potential domain name hijacking to occur.

So, this is going to be a challenge and I think right now it's speculation that we'll see an uptick in this. We're a month and a half in. There's no real data yet to support that, but it's definitely a concern, especially among our clients who are the top brands that are running some of the most trafficked websites, who rely on their email, and all the other things that are based off of their different domain names in their portfolio. To lose one of those critical domain names for even a moment is quite a problem.

So, I mentioned that we recently released the product called…a platform called CSC Security Center. And in that security center platform, there's the ability to get notifications of things like transfers. I think that was definitely put in there in mind of this upcoming implementation of GDPR. While they certainly didn't know what the temporary specification was going to look at, we did have concerns around transfers.

So, what are we going to do about this temporary specification? I mentioned, I think, that this can only be good for a year. And it will be re-upped about every 90 days but the total amount of time is a year. So, how do we take this temporary specification and either make it as it exists permanently, or tweak it so that it will address the concerns and the needs that exist?

We are now venturing into uncharted territory, so the temporary specification was something new, and the other new thing we're now going to experiment with is what's called an ePDP, and that stands for an Expedited Policy Development Process.

I mentioned earlier that PDPs are usually a two-year effort, sometimes more, and that's I think in the best cases. We were looking for this ePDP process to resolve our policy issues within a year's time. Now, the good news is there's a year. That's more than just a few days when on May 17 ICANN issued the temporary specification. While there was effort over about a six- to eight-month timeframe to try to come up with a solution, we just weren't able to get there. So, this gives us more time to get there and gives us at least a temporary state that we all can be trying to track to.

But now we're in this ePDP process and its uncharted territory. The main difference between a regular PDP and an ePDP is there's no issue report required. There's no public comment on the issues report, and the final issues report is skipped. You can see on the left-hand side, there are many boxes in that flowchart, and on the right-hand side there are three boxes in that flowchart. So, it's a very streamlined process.

This is something to pay attention to the entire time. There's not going to be those lulls where you say, "Well, they're working on stuff, but wait until it comes and kind of coalesces." This is one where you're going to have to watch it every second of every day.

In theory, it should be a quicker process, and the advisory committees also have a shorter time to provide input. This is something that's concerning the Governmental Advisory Committee, the GAC, a lot because governments don't work fast. And in fairness to them, these representatives are just that, they're representatives. They have to go back into their governments, they have to talk to people not only in their offices, but throughout governments, get their feedback, toss that around, and then come back with a position. That doesn't happen quickly. So, there's a lot of concern about the timelines here.

The purpose though is we're trying to solve some issues here. The issue we're trying to solve is "let's try to keep resolving this GDPR issue. Let's keep the scope small and focused," but there are forces wanting to make this bigger.

WHOIS has been an issue that's been around for 20 years. I mentioned that earlier. And people have their camps and they dig their heels in and no one has been willing to budge. We've now reached the point where that's not good enough anymore. People just can't kind of fold their hands and say, "Well, then, I guess it just stays the way it is," because that's not an option.

So, there's a lot of pressure to try to make this the all-be-it solution, but we need to really just focus and get to the issues that need to be solved right away. And hopefully that will break the logjam on the whole WHOIS issue. It's unfortunate that that next-gen RDS group has fallen apart, because that could have been a good running head start. But we're not going to be able to rely on that. In fact, we're now tossing this into the ePDP process.

There are many parts of the community trying to stagger the work on access, so the IP constituency and the business constituency, I think, did a really nice job during this ICANN meeting trying to get out in front with a proposal on how access to a full WHOIS can be possible.

So, there has been acceptance of the fact that we're not going to see the WHOIS like we've seen the WHOIS in the past. That is done. We're not going to be able to go back to that. But how do we give people different levels of access? That's the question now. Like I mentioned, the IP and business constituency groups really did a nice job this time of trying to get out in front of that and try to define some of the access issues.

But determination on what access is actually required is yet to be determined. What data will be available? There's a lawsuit that some of you may have heard about. ICANN sued a subsidiary of a registrar called Tucows. The subsidiary is located in Germany. It's called EPAG.

And basically, every registrar's contract with ICANN says, "We'll collect WHOIS information, all that contact data, and then we'll publish it." Well, the temporary specification has alleviated the publication requirement. So, we're not violating GDPR, but EPAG is now trying to take it a step further and say, "Well, since we don't have to publish it anymore, we shouldn't have to collect it anymore." And ICANN has issue with that because the belief is that down the road, we're going to have this sort of tiered access, this gated access, and that information will be critical for legitimate requesters.

And the European Data Protection Board, which kind of replaced the article 29 working group within the EU community, the data protection authorities, just keeps on reiterating its advice to ICANN that you need to comply with GDPR. So, it's trying to get to the heart of that. There's a lot of discourse and wrangling over who should be part of this ePDP. Everyone wants a seat at the table. I think there's pretty good consensus around it shouldn't be 200 people, but the sense is somewhere around 30 or maybe 40 participants.

There's been some work done on breakout, but really there are questions about who should be the chair? Can they have any kind of vested interest? How much they need to know about the domain system? There are just a lot of issues that are baked into this and need to be on the fast track. And I think it's by July 19 they're hoping to define what this composition will look like and figure out a chair.

So, access is the key issue. There's a little bit of a flowchart that ICANN had that outlined this. I think it's agreed that governments and law enforcement, they have very legitimate interest, but then how do you define the interests of everybody else, researchers, IP, all that? It's still way up in the air.

And the challenge is we're already behind. So, this was issued May 17 of 2018. We need to complete the policy work and replace the temp spec by May 17, 2019. If you're counting, that's 45 weeks from now. So, tick tock, tick tock. We're behind despite, I would say, a lot of heavy lifting and really good discussion at the policy forum, but we're in the summer holidays and these groups are going to be working, but this is a heavy lift, so it'll be interesting to see how we get there.

We're not going to have time for a lot of other meeting insights, but I'll just put the slide up for a second, and certainly I encourage you to download the slides. You'll get just a quick update on where each of these is.

I guess the short end of this is that GDPR is sucking up all the air in the room. And when I say GDPR, that now means also the ePDP around the temporary specification. All the energy of ICANN and the community at large will be focused on this. I see things already slowing and will continue to slow on other fronts until this is resolved, not only for bandwidth issues, but also because some of these other issues are dependent on this getting worked out.