ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

>>BRUCE TONKIN: Okay.
We'll get started.
The purpose of this session is for the GNSO Council to get input from members of the ICANN community on the issues that we're currently working on.
So what we'll be covering this morning, firstly, just what does the GNSO do as an organization.
The GNSO stands for the generic name supporting organization.
And we're responsible for developing policies to the board that relate to generic top-level domains.
So these include com, net, ORG, biz, aero, info, and museum.
If we develop consensus policies, these are applied uniformly across all those top-level domains: The topics that we will run through this morning include an update on how we're going in policy development in the area of WHOIS, an in particular, we have one WHOIS recommendation that we are planning to move through the final stages of the consensus process.
But we'll also give an update on other work that we're doing in the WHOIS area.
We're also working on a process that registry operators can use if they wish to introduce a change of their own so that it goes through a review from ICANN to ensure that it's consistent with the objectives of maintaining security and stability.
We'll also talk about an issue that is beginning to arise between registries and registrars where names are deleted but have some high value, and hence there is a lot of contention amongst registrars to reregister those previously-registered names.
Then, finally, we are in the midst of doing a review of the GNSO Council itself and its processes, and we will give an update on some thoughts that the GNSO Council has in this area.
But we're also seeking feedback from the community.
So on all of these topics, the approach will be to give a bit of context and information on what we're doing, and then seek comments from the audience here or that people might be accessing this session online, you can either ask a question about what we're doing or you can propose some ideas or things that we should consider.
So starting with WHOIS, there's a current recommendation in the area of WHOIS, and that is that although there are requirements in the agreement between a registrar and an entity registering a domain name or a registrant, these requirements include that the registrar must provide accurate WHOIS information and also there's a requirement that that WHOIS information is published via the WHOIS service.
These are both requirements of the agreements.
But often the agreements are fairly long documents, if you're looking at them online, they may be many pages.
And one of the recommendations from the task force is to make those obligations far more prominent at the time of registration so that registrants understand their obligations with respect to WHOIS and acknowledge that as part of registering a domain name they must provide that information.
So at this point, I'll hand over to Jordyn Buchanan, who's the co-chair of that workshop, and he can provide a bit more of an update on what those WHOIS recommendations are and then essentially, we're seeking feedback from the community on that.

>>JORDYN BUCHANAN: Sorry.
Okay.
This is, as Bruce indicated, a brief update on the recommendations that the joint WHOIS task force one and two is making for consideration by the council, along with a brief status on some of our other work, because the work is somewhat more wide ranging than encompassed by this first recommendation.
First, a little bit of history to provide councillors and the public of where we stand.
Back in October 2003, three WHOIS task forces were chartered by the GNSO Council in order to look at WHOIS generally with regards to privacy and accuracy.
Task force one was chartered to look -- for marketing purposes.
Task force 2 for the review of data collected and displayed within the WHOIS system, and task force 3 for improving the accuracy of the collected indicate.
All three task forces submitted some sort of initial report to the council back in May 2004.
I'll general characterize saying that all of the task forces, or at least certainly in task force 1 and 2, we felt that there was some need for ongoing work in order to fully flesh out our recommendations and the work of the task force in order to be more actionable by the council.
And in particular, in task force 1 and 2, we noticed there was some significant amount of overlap in the topic area between the two task forces, so in Kuala Lumpur, the council merged the two task forces to develop the recommendations based on both groups' work.
After that, essentially, the task force has internally narrowed the scope of its work to three major topic areas.
The first of those is improving the methods by which registrars provide notice and obtain consent for the use of their contact information in the WHOIS.
And that's the topic that Bruce mentioned we actually have developed a recommendation for consideration.
The second area where I think we're fairly close to doing so but a little work remains is providing a mechanism for registries and registrars to resolve conflict between ICANN contractual requirements and their local privacy laws.
The third issue, which is actually where the majority of the overlap between the two task forces occurred, is on the concept of tiered access, which has been discussed in the past, but essentially providing different types or different sets of information in response to different queries, either differentiating based on who's making the query or what the purpose of the query is.
So looking at the first topic, improving notice and consent, this was originally within the scope of the charter of the old task force 2, which had examined the practices of various registrars and resellers for providing notice to registrants and on take their consent for the use of data within the WHOIS system, and found really quite a wide range of practices, ranging from some fairly obvious notice that the data would be used in the WHOIS system to simply a mention somewhere within the terms and conditions that registrants agree to.
Now, it is important to note that all registrants in all registration agreements today do consent to the use of their data within the WHOIS system.
So the issue here is not so much making sure that they are actually agreeing, but making sure that they are fully aware that the data is being used in sort of a public manner in the WHOIS system, and improving -- simply improving the mechanism by which we provide that notice in order to have a well-informed registrant community on this topic.
So the task force has developed some recommendations that are designed to improve the -- sorry.
I typed registrar -- registrant awareness of the use of contact data within the WHOIS system.
And we'll move to those now.
Hopefully, the type's not too small.
I'll just read through, the recommendations, there's three of them.
They're not terribly long, so I'll read through them and explain briefly.
First of all, registrars must ensure that disclosures regarding availability and third-party access to personal data associated with domain names actually be presented to registrants during the registration process.
Linking to an external Web page is not sufficient.
So, essentially, that somewhere during the registration process, the information has to be available on the Web page or however the registration is actually made to make sure -- how -- just to indicate how the data is going to be used within the WHOIS system.
Secondly, that registrars must ensure that these disclosures are set aside from other provisions of the registration agreement if they are presented to registrants together with that agreement.
Alternatively, registrars may present data access disclosures separate from the registration agreement.
The wording of the notice provided by the registrars should, to the extent feasible, be uniform.
And that last sentence actually is something where we think that the council may want to consider how we make that happen, whether it be an implementation committee may be formed in order to develop wording or simply that the council commit staff in order to consider the -- creating some sort of uniform language.
But the idea here is simply that, you know, it's not good enough to simply have a single line that says "I agree to the terms and conditions of registering."
Some additional text must be set aside from that, indicating that there's understanding of the use of the WHOIS data as well.
The third area is that registrars must obtain a separate acknowledgment -- oops -- from registrants that they have read and understand these disclosures.
And this provision does not affect registrars' existing obligation to obtain registrant consent to the use of their contact within the WHOIS system.
So, essentially, this is just saying that registrants must essentially explicitly agree that they have read and understand the way their data is being used.
They're already consenting to this within their agreement to the registration -- within the -- their consent to the registration agreement, and this doesn't change that.
So those are the recommendations that the task force has developed on this topic.
I'd like to briefly sort of run through a status on the other two topics that we're working on.
People may be interested in commenting on the development and progress of those by the task force as well.
The next topic is conflict with local laws.
The concept here is that ICANN make certain -- registrars and registries essentially have to publish registrant contact information in the WHOIS system, has to be publicly available.
And there's a risk that some local privacy regulations may conflict with -- local or national privacy regulations may conflict with these requirements.
We think that there's been an example of this in the past, which is dot name, which worked with ICANN, actually, to develop an amendment to its registry agreement to change the WHOIS privacy in order to -- in response to concerns about local privacy regulations.
And there they essentially implemented some sort of version of a tiered access system, which we'll talk about in our third topic area.
We're not necessarily recommending that's the response in all cases, but simply that sometimes there may be some tension between the ICANN requirements and local privacy regulations, or at least there's a possibility that that may occur.
And so the task forces -- in order to address that, the task force is developing a procedure to be used to resolve conflicts, essentially.
And the procedure involves consultation between the registry or registrar, the relevant local or national authority, and ICANN, to identify the minimal changes necessary for compliance.
Some concerns have developed around this which we're in the process of addressing before we put the procedure forwarded.
These include added workload for the ICANN staff in the consultation process in considering what action to take, effects on interoperability or stability of different -- if different registrars or registries have different WHOIS requirements that may affect interoperability.
In transfers, for example, if a local authority were to say, E-mail address cannot ever be published in -- publicly, make, essentially, impossible to conduct transfers which would have significant operational effects.
And the last concept is similar but effects on competition and whether there's an opportunity for, essentially, venue-shopping by looking for favorable privacy laws.
The last topic on which the task force is working is the concept of tiered access.
And it's fairly simple.
The idea is that there's basic contact information for everyone, anonymous users, just like is available for the WHOIS system today.
And then additional information would be available for identified users or users with a specific purpose and one that's essentially considered good or approved by the process.
This work is not nearly as developed, I would say, as the work in the other two areas, because there's a large number of issues around this, including what data should be provided in each tier, how we identify the requesters of the data, how -- or, alternatively, how we identify the purpose of a request.
Questions such as should the registrant be notified when their protected data is accessed.
So -- and also, will the existing technology standards support such a system and who will pay for it.
So we continue to work through those issues.
We think both task force 1 and task force 2 made some -- have a significant body of work on these topics.
We continue to -- but there's, I think, a large amount of complexity to it.
And I think we are hoping to have additional progress at future meetings and for the council to consider in the not-too-distant future.
That's it.
Thank you.
And look forward to any comments or questions that I can assist with.

>>BRUCE TONKIN: Thanks, Jordyn.
At this point, we're really just completely open for any comment on the topic of the work of the WHOIS, if anyone has any questions or would like to make any suggestion.
This is a useful exercise for us, because this has been transcribed -- is being transcribed, so any comments will be useful in actually forming our final views on this topic.

>> Hi. Testing.

Maybe you can repeat the question.
Okay.
The question is, what is the procedure, if there is one, for interface between the Governmental Advisory Committee and the WHOIS working groups, in case there's government concerns involved in the decisions that they're going to be making.
>> Who is asking the question?
MARC CRANDALL: Marc Crandall from the United States.
>>jordyn buchannan: I'm going to repeat the question.
>>MARC CRANDALL: It doesn't work.
Okay.
I'll repeat the question now.
The question was, is -- what is the process, if there is one, in communication between the Governmental Advisory Committee and any input they may have or thoughts they may have in representing governments into this WHOIS process?
Has there been some sort of interaction?
>>jordyn buchanan: Sure.
Let me respond purely -- I think there's actually a task force response.
I might allow Bruce to respond from the perspective of the council as well, which, actually, may be more controlling in this case.
But the task force 2, at least, actually explicitly solicited that earlier in the process, before the joint task force came to be, explicitly solicited input from the GAC on a number of topics within its purview.
I don't believe we received any responses from any -- either from the GAC or from any individual governments.
We've also been consulting with the GAC task force on the GNSO issues or whatever more slightly complicated name it may have.
And we've recently been consulting and working on discussing the issues generally.
We had a brief discussion with various members of that GAC task force about the issues, and, basically, have made a commitment to continue to work back and forth in a somewhat informal manner, but basically soliciting input from the GAC task force, which presumably, hopefully, will be circulated to the general GAC when appropriate.
And we're certainly delighted to have input from the GAC wherever appropriate.
So that's, I think, from the task force perspective.
Bruce may be able to comment on what formal mechanisms exist between the GNSO process and the GAC process.
>>MARC CRANDALL: Thank you.
And by the way, I was Marc CRANDALL from the United States government, the delegation.
Thanks.
>>bruce tonkin: Just to add another level of data, I think, from the GNSO Council's point of view, one of the things we're currently working on is defining better ways of interaction between the GNSO Council and the Government Advisory Committee.
We did have a brief meeting earlier this week between a working group of the GAC, which looks at WHOIS and gTLD issues.
But what we're wanting to do in future is have a much more structured discussion where we would have a paper in advance explaining what the current status of something like WHOIS is and then invite the GAC to also have a paper beforehand saying these are some of the issues and questions that we have as part of input.
So certainly we -- there are a couple of -- ultimately, the Government Advisory Committee would be advising the ICANN board before the board took any decision on anything that we advised.
But we would much prefer that rather than having late advice, that we were able to obtain earlier advice so that we can refine the policies before they actually go to the board.
Because, otherwise, what would happen is if the government advisory had some new information for the board, the board would then just have to send it back to the GNSO for reconsideration, anyway.
So we would hope that we could get that advice before that occurs.
Jordyn -- and, you know, please come forward if you have any other comments or concerns on anything that Jordyn has raised.
With respect to task force 3, which has been looking at accuracy issues, essentially, we have a -- the trend in that work at the moment is to say that we will continue the mechanism that's currently there for dealing with accuracy problems, is, firstly, the registrant must provide accurate information.
If somebody uses that WHOIS information to contact the registrant and is unsuccessful, perhaps because the address is no longer valid or phone number doesn't work or there's no E-mail address, then that registrant may contact the registrar.
And the registrar will attempt to get in touch with the registrant.
And if that is unsuccessful, then the domain name can be canceled or deleted, because it is a violation of the agreement between a registrant and a registrar if their details are not accurate.
Now, one of the issues there is that the processes a registrar might use between when they're being notified by a member of the community of the inaccurate data and when the name may finally be deleted is subject to many different practices.
And this is perhaps difficult for members of the community to interact with registrars.
One of the options there is, instead of canceling a name, that a name may be put on hold, which, essentially, would remove it from the DNS.
But the name would still be registered in the system.
So we're considering options there for perhaps a two-stage process, where if the registrar attempts to contact the customer or the registrant, the registrant hasn't responded after a certain period of time, the name would be put on hold.
And then if the registrant doesn't respond after another period of time, then the name would eventually be canceled.
So, essentially, what we're looking at there is making the process a lot more defined.
The other thing that we're considering is, how do we deal with situations where a domain name is causing some issue perhaps related to security and stability of the Internet, and a registrar needs to take action more promptly than perhaps a 15- or 30-day period.
What are the circumstances when urgent action is required.
So we're very interested in feedback from the community on what circumstances the community believes a registrar should act very promptly, you know, say within 24 hours.
And then we need to look at how do we manage that in such a way that a registrar is not placed in a situation of making some subjective judgment, and certainly not wanting to be caught between two parties that both, perhaps, have an equal right to use a name.
So task force 3, come ahead, Jon.
>>JON NEVETT: Excuse me, Jon NEVETT, network solutions.
I want to raise something that came up in the network constituency this week on these recommendations.
It came out that these recommendations weren't fully or in our opinion adequately vetted to the registrar community.
So we would urge the council not to make any final decisions on this issue and take a more holistic approach by waiting, as you will, on the other recommendations and not approving the initial recommendations, which would have significant cost implications to registrars, because you're changing business flows and some other aspects of the -- of our sales process.
So our recommendation is that you hold off on taking any action at this meeting and that you move to combine these recommendations with the recommendations that'll be coming down the road probably at the next meeting that Jordyn mentioned.
Thank you.
>>jordyn buchanan: Sure, just a note by way of process to the council.
As councillors will certainly know, and maybe public less so, the -- in order to comply with the PDP, these recommendations have to be submitted as part of an initial report, which is followed by -- upon acceptance by the council, a public comment period, which is then followed by additional review within the task force, which is then followed by a final report, which ultimately can be approved by the council for submission to the board.
So we're some ways away, I suppose, from the council being in a position to commend these action items to the board as part of a consensus policy.
I will note, however, I think that, you know, we have had registrar representatives on the task force.
And at least to this phase, the policies have been -- to move to this point, I guess, it was recommended unanimously within the task force that these recommendations be at least moved to the -- to review and public comment phase here in Cape Town.
>>KEN STUBBS: Bruce.
>>bruce tonkin: Yes, go ahead, Ken.
>>KEN STUBBS: Yeah.
I'm not exactly sure whether the comment from the gentleman from network solutions was directed towards task force 1 or 2 or whether that was task force 3.
But in the case of task force 3, we're nowhere near consensus yet at all.
There's a significant difference between the perspectives there for that problem.
I requested that Barbara provide a summary of the positions as she saw them.
But by no means would I see the council in any sort of a position to be able to act on any of the recommendations that have been proposed on task force 3.
That's just my perspective.
Maybe Ross has a different view.
But I'm inclined to think that there's no consensus on those recommendations at all right now, Ross.
>>BRUCE TONKIN: Go ahead, Marilyn.
But bear in mind that we at this stage are not having a council meeting, but we're taking public input.
>>marilyn cade: Exactly.
I think, in fact, as councillors, what we're doing right now is seeking clarification, not debating each other.
I'm just seeking clarification.
I believe what I understood that we were doing with both of the task forces was putting the -- what we had agreement on or consensus on, was to put a report forward to take public comment on, and that we were all reserving our positions, but that we were trying to move information forward for the community to be able to see the progress of the report.
And I think that consensus about moving a report forward, which is what I thought you said -- would you just clarify that for me.
>>JORDYN BUCHANAN: Yeah, absolutely.
The consensus within the task force, and like I said, the unanimity within the task force was to introduce the proposals to the community for public comment, not -- not -- these proposals have not even been formally approved by the task force in the form of the initial report that would be formally submitted to the council.
>>bruce tonkin: Yeah, if I can just comment on what's an initial report.
Right now, what commonly happens in a consensus process is trying to work out what is the key issue that most members of the task force agree on.
And that's what Jordyn sort of presented today in terms of task force 1 and 2.
The next steps before that goes into a formal public comment process is that the report includes constituency impact statements.
So what the impact is on each constituency.
And, clearly, the members of the task force will be interacting with their constituencies to get that information.
There's also a financial impact statement included in that report, which is saying what is the financial impact on any of the constituencies that would be resulting if that recommendation was approved.
So it's quite a thorough report that needs to be produced before it goes to public comment, but what we're seeking in this forum is the opportunity, given that people can see the direction the task force is headed to, give input. And I think what the task force would value from organizations like network solutions is to understand the objectives, and it is clearly in that statement to make sure the public is better informed and if you take the sense of those recommendations, suggest wording that makes it easier to implement, that will be very valuable in this stage of the process. Of course that's open to any registrar to contribute that through their representative on task force 1 and 2, which I think is Tom Keller from the registrars.
Ross.
>>ROSS RADER: I wanted to specify with Jon which task force he was directing his comments on, one or two, or both.
>>JON NEVETT: One and two. Task force 1 and 2.
>>BRUCE TONKIN: Okay. Are there any other questions or comments on the work of the WHOIS task forces?
Okay. We'll move on to the next item, then. And let me just put up a....
Okay. The next policy development work that the GNSO is working on is looking at a process for use by registry operators when they wish to make a change. So right now, there's really two very distinct streams for changes in operation of a gtld registry. One is by the consensus policy approach which is saying that members of the ICANN community, which would be registries, registrars, individual users, intellectual property users, business users, noncommercial users, Internet service providers, can say this is something that we believe needs to be changed uniformly across the board for all registries and registrars. And that's a consensus policy development process. Changes can only be implemented if there is consensus within the community to make those changes.
And those changes become obligations for registries and registrars. They must implement them.
The other opportunity is that an individual registry operator may wish to make a change to the operations of their registry, and clearly the intent of that change is to provide a better service for the community. And this request would go to ICANN because ICANN has the registry agreement with the registry operator. And ICANN would then need to approve a change to the operation of the registry in accordance with the terms of the contract.
So, for example, if there was a particular measurement that may be provided to ICANN as part of some report, the registry operator might say, well, here's a better way of doing that measurement. You know, we recommend a change to the agreement. And a lot of those routine issues should be able to be approved relatively quickly, provided they are consistent with existing ICANN policy, and provided that they provide -- ensure that there is no damage to the security or stability from an Internet point of view.
So when a decision or when a request is received by ICANN, the essential criteria here is really from the mission of ICANN, and really the question is will the change proposed make a detrimental and material impact on the security and stability of the Internet's unique identifier systems. So in respect to gTLDs, that would be with respect to domain names. And while fostering competition where appropriate. So clearly, fundamental objective is security and stability and the intent is also to make sure competition is preserved in any change that is made.
So that's really the criteria for the decision.
And the issue has been in the past is that different decisions have involved different processes. In some cases, decisions have actually been handed to the GNSO council to comment on, and the length of time these processes takes has been very, I guess, hard to predict in advance, and, therefore, hard for registry operators to make a business decision.
So essentially, what the council has proposed is to -- when ICANN receives a request, to make a decision fairly early on. Is this a very simple, straightforward request and therefore should follow what we call a quick-look process or is this something that may have implications for security and stability, and, therefore, should go through some sort of expert review process before approval is granted.
So taking the example of a quick look, a quick look is basically saying that in ICANN's view, there is no impact on security and stability. ICANN doesn't believe there's an impact on competition.
However, there still may well be an impact on third parties as a result of that decision.
So, for example, if a registry operator wished to change something like a grace period for a registration process, that grace period would clearly have an impact on registrars because they'd have to change their systems.
At a high level, it may not be seen to have an impact on competition and stability, it may not seem to impact competition, but because it's affecting a third party, in this case registrars, registrars should at least have the ability to comment on the that change, in particular if there are any issues that they can think of that would affect competition or security.
In this case, it would go for a short public comment period and it would finally be approved by either the staff or the board depending on the nature of the change.
The intent of the quick-look process is it should take no more than a few weeks. In most cases, it should take a few days. So we're saying a few weeks is assuming there's not seem for public consultation.
But this is really just putting it out for information, allowing people to comment back to ICANN, and then ICANN would make the final decision.
The other process is where ICANN believes that the change probably should have -- may have, rather than "have," believes the change may have a detrimental and material impact and therefore a thorough review would be conducted. In this case ICANN would appoint an expert evaluator or panel of expert evaluators. The sense is this would be sort of paid experts with a particular time frame for conducting their analysis. So it's not just an open-ended process. It would be along the lines of appointing an evaluator, saying this is the terms of the evaluation, you need to conduct some fact finding, you might need to interview various stakeholders, and ultimately produce a report.
During this detailed review, there would also be public comment periods, and different ways of managing those public comments would probably depend on the type of issue. If the issue is very focused on registrars, then there may be targeted briefings for registrars in addition to a general public comment period that anyone could respond.
So this detailed review process is more likely to take a few months at the outside rather than a few days. So it's a more thorough process.
But the intent here is that the detailed review should be less than 20% of the cases. The registry operator should be able to have a predictable process, know what the criteria is, and have an expectation that they would be going through the quick-look process, because anything they propose should certainly meet the criteria of competition, stability, and security, and certainly meeting the criteria that it doesn't impact on the competition. In the registration of names.
So at that point, again, I open it up for public comment. If anyone has any questions about the status of the process being considered by the council, or anyone wishes to provide comments or advice, please come forward.
>>CHUCK GOMES: Chuck Gomes from Verisign.
Bruce, in your quick-look process, you referred to a service that may have an impact on registrars. It seems to me that's always the case, if it's a service that's sold through registrars.
And so -- but assuming it's not a service that is mandatory for registrars, I don't understand why you even have to have that check. If a registrar is not being forced to implement a service, they have the option. I mean, anything that they do is going to have impact on them; okay? Whether it just be preparing to market it or there are some system changes or so forth.
So I don't understand that step at all.
Why does it have to be checked? Why is that even a checking point? Unless it's a mandatory service that has impact on registrars, but in that case they're required to do it and, obviously, there are provisions already in the agreements for notice, et cetera.
>>BRUCE TONKIN: I don't believe that that's what I've said. And but this is also fairly early in the process, and what we expect to produce is the current status is there was a draft report developed within the committee a few months ago. We are also sought some input on that, and the staff did some case studies of previous processes and found some cases where it was very simple and it was really just a matter of days; some cases did require a change. And there was some public comment.
I think the wording of this, and this isn't final, but if you're saying if this is something that's optional and doesn't affect the existing operation, I don't think it would meet this test here because this says does it substantially affect the operation of third parties. So if I gave the example of changing a grace period and I have a whole system built around that particular existing grace period, then that affects the operation.
If you were to offer a new service that met the high-order criteria of competition, security, et cetera, and I could choose to use that new service or not, but it doesn't affect my current services, I would say that's not an issue.
That's just me -- my personal comment. But the wording here doesn't say -- I don't think reflects what you're saying.
>>CHUCK GOMES:Okay. I appreciate your clarification there, because I obviously read it a little bit differently and it's important to understand what you were intending there.
Second question, you use the word "material." And, you know, I think that was another adjective too with regard to going into the detailed process.
How is that defined?
>>BRUCE TONKIN: Just in answer to that question, it isn't defined, so I guess what I would say, as your public input, I guess, you're requesting clarification on the definition. Because it is not yet defined.
>>CHUCK GOMES: And I wasn't necessarily trying to put you on the spot except I think it is a very important question to answer; otherwise, you have a subjective interpretation of that, and we get back to the same things we've been through for the last three or four years.
>>BRUCE TONKIN: Yeah. And I think that's something that we, as council, would seek advice from the general counsel as well from ICANN. But my understanding is "material" is a fairly standard legal term but I may be wrong there.
>>CHUCK GOMES: You know, aim not an attorney either, so that's fine, but thank you.
>>BRUCE TONKIN: I believe Marilyn Cade had a question for you also.
>>MARILYN CADE: Yes, thank you. Before I ask my question, I would like to make a statement. The work done and put forward in these reports is the work of council. So all of us, of course, take seriously the fact that we are all participating and in representing business users, I have a -- I guess a question for you about the first point you made.
I look at this perhaps a little differently in that I think that registries and registrars are providing a very critical service. It is not the totality of the services provided in the Internet, but it is, of course, a critical set of services.
So when those -- and I look at this as, in registries, as being sort of given a sole-source monopoly within a defined space in which they should be providing certain services. And that's a franchise agreement, which we've all bought into in support across the community, really.
Now, you're saying, I think, that if the registry, which is in a somewhat unique space in the hierarchy in the Internet, is offering services and if they're not mandatory, that you think there shouldn't -- it shouldn't have a requirement for an examination. But I look at it and say, you know, the registries are in this unique space, and I, as a registrant, am ultimately affected, even if the service is optional and certain registrars choose not to use it. And I'd like to have an examination of whether or not it does have an impact on the registrants ultimately.
So how do we sort of balance that, Chuck, to make sure that there is at least a quick examination. A registry might have one opinion based on the research they've done. It might be a valid opinion.
But a different look at it from someone else might broaden even their understanding of the impact it were to have.
>>CHUCK GOMES: Well, first of all, in my opinion, if it's a service for registrants, it will always have an impact on registrants. So I guess I'm not totally clear on the question that's being asked.
In the marketplace today, all of us, regardless of what marketplace you're talking about, have options to buy or not buy particular services. And, in fact, whether we do is totally our choice. And assuming that it's not something that impacts the security or stability of the Internet, and the same way with registrars. And that was my point, is that any service offered through registrars is going to impact registrars. So if you're asking the question will this have an impact on registrars, of course it will. If they want to add a new service, they have to add things to their systems to do that.
Assuming it's optional, though, for them to do that, it's not being forced on them. It's not being forced on the consumer. That happens every day in the marketplace. How is this any different?
Now, secondly, there's a difference between the core registration services and some added value services that might give registrars and registrants a new option that could make their life better. It will benefit some, not benefit others. It's their choice. What's wrong with letting the market determine that?
>>MARILYN CADE: I have a follow-up comment. But we all have to acknowledge and that in the space of a registry, there really aren't -- there's really not competition at the registry level, and we all understand that. So when we say what's wrong with letting the market decide that, in fact, the registrar doesn't have competition in that space. And I'm not trying to be burdensome about that. I'm just saying why wouldn't we ask that question in the process.
>>CHUCK GOMES: First of all, I totally disagree with you that there's no competition in that space. I see Ken raising his hand wanting to talk. They offer different services for dot info, added value services, than we offer for dot com.
The ccTLD registries offer different things for their community than we do.
There is competition, and that's, of course, the reason we introduce competition.
>>MARILYN CADE: I'm sorry; but I asked a question at the end of my statement.
>>CHUCK GOMES: Your question was?
>>MARILYN CADE:What's wrong with just taking the quick look?
>>CHUCK GOMES: I'm trying to figure out what it is accomplishing. What is -- A quick look -- by the way, the quick look, I think you're being more specific than just the quick-look process.
The part of the quick-look process that I was trying to get clarification on just had to do with this question of does it have an impact on registrars or registrants. Of course it will. So I'm not sure what you have to look at there.
If it's not a forced service; okay? If there's still choice there by the registrar and the registrant, then what's being accomplished? It's not clear to me.
>>BRUCE TONKIN: Go ahead, Ken.
>>KEN STUBBS: Well, naturally, I want to echo Chuck's comments with regard to competition. The last time I looked, there's about 260, 270-plus competitors out there for global TLDs.
Secondly, I also would agree, I think from a practical standpoint, if -- the marketplace is going to determine whether or not a service has a direct impact on the areas Bruce described is critical, infrastructure, stability and so forth. I think the market to a great extent will determine whether or not the service is worth using and is worth the effort. For all intents and purposes, I don't think a service that doesn't impact the areas we're discussing here should -- the provisioning of a service like that should be something that's determined by the registry. I don't think we should go to a body of people to determine whether or not they think it's a good idea that we offer this service, because I think that's what the market is for.
I think even in -- I always hesitate to delve into the world of telephony because I don't honestly understand everything, but there are providers that may or may not offer services, but the decision that they're making in many cases is whether or not they feel the market will take the services that they offer. Not because they necessarily affect stability. And I don't necessarily believe that every provider has to go to a regulatory agency to get permission from the public to provide every service that they have.
I may be wrong there. It may be the case in some countries.
So I think to a great extent we need to let the market decide whether it makes sense.
>>BRUCE TONKIN: Thanks, Ken. So to clarify, the intent here is not for us to necessarily be able to create the answers to all the questions that are raised on the fly, but if it's a point of clarification, we can clarify. If it's something that we should consider, which I think Chuck has raised, that we need to consider the issue where there might be a change that doesn't affect your current operations but might be introducing a new service that someone has the option to use, you know, how should that be handled. So I think we'll take that as a -- something that needs to be considered.
>>CHUCK GOMES: Thank you.
>>BRUCE TONKIN: Anyone else who would like to comment on raise any questions about the approval process?
>>Christopher Spottiswoode: Good morning. My name is Christopher Spottiswoode. I'm from cape town. I'm an ICANN outsider trying to understand ICANN.
This morning, we're talking about the -- how registrants are dealt with. That's people like me. It really is tragic there are so few people like me in this enormous auditorium. I mean, that is amazing.
Here we are with online systems. Everybody is supposed to be able to find out about these issues and the debates, the constraints, and why is nobody here? Because they cannot find out. If one goes onto the ICANN Web site, it's just patch work. There's no systematic setting out of problems. There's no systematic liaison between the different bodies in ICANN and in its constituencies and in its various stakeholders.
What really shocked me is this phrase the consensus process, and the fuss, you can almost say, that ICANN office BEARS and mission statements and I don't know what make about the consensus process. We heard about it today. Our chairman proudly told us about it, too.
Ladies and gentlemen, in the mid-'80s I wrote a book about the consensus process, how it should be conducted online. And it streaks ahead of anything that ICANN has got now 18 years later.
Okay. I'm still trying to put the system up, but that's another story.
So my question, then, is what work in progress is there to improve the online debating, the raising of issues, the guides to the ICANN structures, and how they relate to the specific issues being debated at meetings like this? I can only assume that there has to be such work in progress, because there's no evidence of it anywhere. So I'll leave that question. That something really needs to be done. If it is being done, tell us what it is. Thank you.
>>BRUCE TONKIN: I think you raise a very good issue. As part of the review of the GNSO council and its processes, we've certainly identified that the public comment process, the information and the structure of the information provided on the Web site needs to be improved.
The ICANN strategic plan I think is probably consistent with that goal as well in that it's setting out over the next three years, this is the things that we want to accomplish. And one of those things is providing more resources, provide better outreach to people such as yourself in different locations around the world, and also provide better vehicles for both in terms of the information content towards you and also in terms of collecting the input from you back into ICANN.
In the strategic plan it mentions that ICANN gets 20,000 e-mails a day. Now, clearly, a single person is not going to be able to assimilate all of that information, and so there needs to be ways to extracting out of those 20,000 e-mails, how many of those can be dealt with by better information on the ICANN Web site, how many of those could have been dealt with by registrars, for example, and then the ones that are left over, the real sort of comments and input on important policy decisions, we can then collect that input.
So I think it is a work in progress. And I think we are that while we're certainly not there yet, the structure you're talking about with different linkages within ICANN and between different groups, the country code group was only formed about three months ago so they're still working on their internal processes before they look at their interaction with us. So I think we accept your comment and agree with you. And we are looking at progressively improving those things.
>>KIYOSHI TSURU: I just want to ask for a copy of your book for the council.
>>MARILYN CADE: And Bruce, I do have a question.
I think I'm seeking clarification. It seems to me that your comments are appropriate not just to us in terms of the policy body for the gTLDs but probably, I'm assuming, more broadly. Yes, thank you.
My second question is, in your opinion, would it be helpful to you and to the broad community to have as a starter what I might call a fact-based issues paper or white paper posted about topics that explain the issue in layman's language, followed, then, by the opportunity to provide input and comment about the impact of change of policy.
>>CHRISTOPHER SPOTTISWOODE: Yes, indeed, that would be very helpful.
The -- a lot of this debate should, in fact, be taking place online.
And the 20,000 E-mails would be reduced to a tiny fraction if there were already structured debate and those outputs to the constituencies can be in pertinent terms rather than shotgun approach that E-mail encourages.

>>BRUCE TONKIN: So by that I understand you mean more of an interaction as opposed to an E-mail that goes to a public comment and then there's no response for several months; is that --
>>CHRISTOPHER SPOTTISWOODE: Yes.
The interaction would follow naturally if the debate was structured properly in the first place.
>>BRUCE TONKIN: Right.
Okay.
Thank you.
Any other comments on the registry approval process?
Okay.
The next topic is the issue that's occurring now between registries and registrars in contention for reregistering a name that has existed already and has subsequently been canceled and is now available for reregistration.
One of the issues here is that previously-registered names may well have a market value well above the market value of a completely new domain name.
So if a completely new domain name might have a market value of the order of, say, 10 to $100 depending on the services provided by the registrar, but some names that have been previously registered, either because of the name itself being very attractive or perhaps because there was traffic that has been directed at that name over a period of time, may well have values well in excess of $100, even into many thousands.
And in this situation, then, there's a lot of people that would like to be able to obtain that name at a very low price and potentially be able to take advantage of the real market value of that name.
The mechanism that happens today is that after a name has been canceled by a registrar, it goes into redemption/grace period for 30 days.
This is an opportunity for the registrant to retrieve a name if they had accidentally canceled it.
At the conclusion of that period, the name is published in a list called a pending delete list.
And this is a list of names that will be deleted in five days' time.
And depending on the registry, in some cases, the time that the name will be deleted might be known to the nearest hour; in some cases, the time that a name is deleted is known within, say, a day's time frame.
What this encourages is, many registrars will seek to send an add command to obtain the name.
They don't know the precise microsecond when the name will become available, so they keep sending commands.
And, statistically, the more add commands you send, the more chance that one of those might be successful in obtaining that name.
This creates significant computing and network load or consumes considerable resources at a registry.
It even consumes considerable resources at registrars.
And what's tended to happen is it's gone through an evolution where first individual registrars would send a lot of requests for a name.
What would happen then is the registry would then put a limit on how many requests a registrar could send within a particular time frame.
And so then what's happened is that people have decided that they'll just create new registrars, because every time they get new registrars, they get a new allocation of resource to be able to send commands at the registry.
So, clearly, this is what I call a game of chance.
Registrars send as many add commands as possible to increase the probability that one of those commands will be successful.
And we're now getting a situation where we're getting hundreds of accreditation requests to ICANN at $4,000 a request to gain additional capacity to fire these commands at the registry.
So it's an inefficient use of resources both at the registrars, the registries, and ICANN itself having to process hundreds of applications for new registrars purely to gain, effectively, additional tickets to -- or additional resources to send commands to a registry.
So, fundamentally, it doesn't scale.
So there was a workshop on this held earlier this week to look at some different solutions.
And, again, I'm just interested in comments from the community on whether people believe this is a big issue, whether the community believes that the GNSO should be looking at this.
The sorts of things that were talked about, there is a proposed service called a wait list service where, if a person wishes to register a name sometime in the future and it's currently registered, they can put their name down on a white list.
And if that name becomes available sometime in the future, they would obtain the name.
The idea being that if many people opted for this service, then there would be a reduced number of names that would be in this area of contention.
This service has yet to be launched, however.
Another model is to try to create different models for how many commands each registrar can send.
At the moment, there's a certain amount of commands that you can send on a per-registrar basis.
This encourages people to create more registrars purely for the purposes of obtaining those commands.
Another option, which means that the number of commands that you send is in -- proportional to the number of successful commands that you send, so this would get rid of the problem of having multiple registrars seeking more accreditation.
But it's still, essentially, a game of chance, and it may have some implications between whether you're a large or small registrar as to how much capacity you get.
Another option is a pay-per-command model so every time you send an ad command, you pay for that, irrespective of whether it's successful or not. And this would give more income to a registry to scale its operations.
Another model is an auction model where a name becomes available in the pending delete period and it is placed for auction.
And the registrar can -- with the highest bid for that auction would receive the name on behalf of their customer.
Or a combination of these are possible.
In fact, pretty much all of these could operate together.
So those are things that are being considered, at least amongst the registry/registrar community.
Various variations of these models have been used by registrars for managing their operations, so there's a fair bit of experience in these models, and the issue is really, you know, how do we come to a view as to what's the most appropriate model for use by a registry.
The choice we also have here is, do individual registries implement their own solutions or do we try and identify a consensus policy and find a solution that can apply to all registry operators?
This issue has become particularly acute with gTLDs, but I'm also aware that it occurs in ccTLDs as well.
So, again, invite any comments or questions on this issue, any comments whether people believe the GNSO should be looking at this in more detail, any experiences anyone might have had in the community with these issues.
Okay.
Probably a bit complex to understand.
Next topic, then, that we're considering is a review of the GNSO itself, how the council has operated in the past two years since ICANN revised its bylaws.
The process for that review is that ICANN has appointed an external evaluator who's conducting an evaluator of the council.
That person is interviewing members of the council and members of the community, going through, looking at the minutes of past council meetings, the contents of past policies, and collecting all that together, and will be producing a report for the board.
The council is also conducting its own review internally just basically giving our feedback on what we as councillors have learned in the last couple of years and what we think could be areas for improvement.
And, ultimately, this review report will be subject to a public comment period before being acted upon by the board or the council.
So I can't comment on the external evaluators report because that has yet to be released.
But I can comment the GNSO Council point of view on what we've learned.
One of the new issues in the ICANN bylaws was dropping from three representatives per area from registrars, registries, and intellectual property, to two.
But we've found that three is more effective both in gaining geographic coverage and also in showing there's enough resources amongst members of council to participate in task forces and committees, so we will be recommending to the board that it retain the current three representatives per area rather than reduce to two.
The other thing we have found is that different policy topics take different time to resolve in the context of the criteria for dot net, that was able to be developed within a month or so because we already had an operational dot net registry, and really all we needed to do was confirm the main elements of that and identify what we thought should be the main criteria for conducting a process for selecting an operator for dot net.
In contrast, something like WHOIS has often got very strongly different, divergent views.
We have on one side people wanting access at low cost to very accurate information.
And that might be appropriate for something like law enforcement.
On the other side, we have people that are concerned about putting their personal details, which might be their home phone number or home address, into a public directory that anybody can retrieve from.
So there's often very different views there and it takes some considerable time to work through all the issues and obtain consensus.
One of the areas that we've identified, and it partly relates to a question we had from the audience earlier, but the comment was that a lot of these issues are hard to grapple with and understand to be really able to comment on.
The council itself also finds this is the case, that some of these issues, such as the one that I just went through in contention, are known amongst a small group of experts.
But even amongst the council, there may not be a lot of the knowledge on how that particular issue arises and what the legal issues are around that.
So for our task forces and council, we're seeking support from the ICANN staff to create a bit more background analysis on an issue and create a more comprehensive report before we start policy development.
And so that would be not only useful for us, but clearly useful for people here to understand what the issue is.
Another thing that we have found in past processes where we might have created some recommendations, but they may not be in a form that allows them to be implemented in terms of the contracts between ICANN and registries, and ICANN and registrars, so what we're seeking there is better legal analysis of our recommendations before we move to finalize those recommendations.
When we create a final policy, we also believe that the actual relevant legal text that would be changes in agreements would be included as part of that policy and signed off by the council and the board at the same time.
Because in the past, we've signed off on recommendations and then found it's taken many months beyond that to resolve the legal contractual issues.
And, finally, we're seeking staff support to ensure monitoring and enforcement mechanisms for any new policies that are developed.
Further improvements in this, I think, also relates to the comment that was made earlier, is looking at what mechanisms can we use to encourage people from the ICANN community or the Internet community to contribute early in the policy development process.
And, you know, I think the sorts of things that were suggested, some better interactive forums, better debating structure, debating forums, so that we can actually get much better feel from the community on what the community thinks before we start getting into a detailed policy development process.
And, finally, that the council needs to look at how would we measure success?
We've made a change to the policy.
How do we actually measure whether that's been a good or a bad change?
So we are seeking support from ICANN to -- after we have developed those metrics, to actually carry out the measurement of the effectiveness of the policy and report on that.
And, in fact, in just the last day or so, ICANN has just released a report on the effectiveness of the new policy that was developed last year on WHOIS data reporting.
So that's basically our views so far in terms of areas for improvement for the GNSO Council.
And, again, I open the topic up for anyone to ask questions or make suggestions as to how the GNSO itself, and particularly the GNSO Council, can improve the way it operates.
Okay.
Well, I take that either of two ways.
One, it means people think it's operating well.
Or, two, people don't understand what it's about, and therefore can't comment.
Marilyn.
>>MARILYN CADE: Maybe we could make ourselves a little more accessible in terms of a couple of other questions we could ask you.
Because I think it is kind of daunting when you're looking outside the council into the council to kind of understand how to offer advice to us.
But one of the things that this meeting represents is our first formal public forum; right?
And, you know, perhaps -- and because it is our first public forum, we didn't necessarily have a big -- we didn't have a posted presentation ahead of time.
But maybe one of the things we could ask the audience for feedback on is, you know, in order to make the public forum more accessible and useful to them, would it be helpful for us to have our agenda posted a week before the ICANN meeting for the public forum?
It -- you know, that kind of thing, so that people could prepare a bit.
Do we need to provide a summary of the issues, a synopsis of the issues, a background statement of the issues, so that they're prepared for the public forum?
>>BRUCE TONKIN: Okay.
I think chuck is going to make a comment.
I might, after Chuck's comment, just ask for a show of hands on that comment just to get a sense.
>>CHUCK GOMES: I think Marilyn makes a very good suggestion.
Myself, I wasn't quite sure -- because of my experience, I had a pretty good idea of what this was all about.
But it really wasn't clear.
And for people who haven't been around very long, I think your suggestion is excellent.
And I would hope that you don't take -- if there's minimal response today -- of course, part of the problem, you have the early morning session, too -- but I hope you don't take that as this is a bad idea, because I myself have heard, and I know you have heard, too, that there's been frustration because there's no ability to interact with the council in the past.
So I compliment you on what you have done.
I think Marilyn makes a very good suggestion.
Thanks.

>>CHRISTOPHER SPOTTISWOODE: Yes, indeed, Marilyn.
I also think that's a very good suggestion as a starting point.
Because in actual fact, the whole thing should be taken further back, that as soon as an issue is raised, it should be posted publicly.
And as soon as this has been allocated to various bodies or whatever body assumes any kind of responsibility or implication in the issue, then that, too, should be posted, together with the individuals responsible for those moves and responsible for decisions which will, in due course, be taken.
The debate should also be structured in -- this is going right back before one week before the meeting.
This is just the way it should be done in the first place, all the way through.

>>BRUCE TONKIN: Thank you for that comment.
Yeah, I think that's certainly something that we need to work more on.
And one of the things we did do for the workshop on contention, it wasn't perhaps advertised as well as it could have been.
We did seek papers well in advance -- "well" is a relative term.
More than 24 hours.
We at least extended it to 7 days.
Further back would be good.
But it gives people a focus so they perhaps have a chance to read what the issues are beforehand and form in their minds comments so they're not, particularly from a language point of view, faced with trying to grapple what the words mean and respond to those.
So that's good feedback.
>>PHILIP SHEPPARD: Bruce, just an observation, if I may.
Am I right in assuming that although we have just seen the appointment within ICANN of the ombudsman, which is basically for dealing with complaints and the like, there was another position for the manager of public participation, and that, as yet, is unfilled; is that where we are?
>>BRUCE TONKIN: That is correct.
And -- in fact, that may be a good question to ask in the board public fora.
I think either this afternoon or tomorrow, as to -- but that would help, I think.
Yes, we don't actually have --
>>PHILIP SHEPPARD: I think that's exactly -- I mean, these issues that we're discussing, I think, are exactly basically this person's job to get right.
So I think it's extremely good feedback, perhaps, that we -- if the questioner doesn't take it forward, perhaps we can to that forum, just to say that it came up here, and by the way, what is happening.

>>BRUCE TONKIN: Yeah.
I think one of the things we tried to do with this public forum, and I agree, we can improve on the structure and the information beforehand, but is to try and get much more involvement from the community earlier in the process, because in the past, there's just been a public forum before a board meeting.
But by that stage, you know, much of the decisions have already been made, because they've been through perhaps months of process and, you know, it's difficult to make changes at the last minute, where some of the topics we've mentioned here are at a much earlier stage of development and we'd really like to get as much comment as we can as early as we can.
Okay.
Well, that pretty much is the conclusion of this part of the public forum.
In the agenda, we essentially allocated an open mike session if there's anything that relates to the GNSO that anyone would want to raise or they think that we should be thinking of, please feel free to come and do so.
I think we have Milton.
Yep.
>>MILTON MUELLER: I just wanted to inform you that the noncommercial users constituency did, in fact, elect Robin gross to be our new representative.
And E-mails have been transmitted to all the relevant parties, including you.
So I would appreciate it if she could join you on the podium.
>>BRUCE TONKIN: Certainly can.
You're most welcome.
>>ROBIN GROSS: Thank you.
>>BRUCE TONKIN: Amadeu.
>>AMADEU ABRIL i ABRIL: Bruce, may I ask you a couple of questions regarding the deletes question just for the benefit of the general public that may not be quite up to speed of how this concrete market works.
Or do you think that this is not a part of this public mike session?
>>BRUCE TONKIN: Sorry, Amadeu.
I just missed part of that.
>>AMADEU ABRIL i ABRIL: I would -- just wanted to -- I'm saying that I would like, if possible, if there's still time available, ask you a couple of questions regarding how, you know, this contention in the deletes happens for the benefit of the audience who is not, you know, professional registrars or ICANN usual attendees.
I think it was not completely clear when you explained that.
>>BRUCE TONKIN: Okay.
>>AMADEU ABRIL i ABRIL: The question is, the two problems we try to solve here, on one side, the fact that this incredible amount of transactions to get a domain name at the very moment it gets delayed by many different registrars with many different connections each one puts, you know, a lot on the registry side.
This is one of the problems; correct?
>>BRUCE TONKIN: Yes.
>>AMADEU ABRIL i ABRIL: The other one -- and then we have all of these methods, WLS, many of them trying to solve especially that part.
The problem being that you can game the system first because it's free now, it's exactly the same cost for the registrar, and therefore probably for their clients, to have one attempt or one million attempts.
And then some pricing mechanism could help here.
On the other side, there is what you call the contention part, that is, the fact that there is this fight for the registrars to get this concrete domain.
Now, the question is, when these domains are deleted or are going to be deleted and there are people who want to find that, this contention happens because for domain X, Bruce and Amadeu want that and would go to different registrars to get it.
And for domain Z, each Marilyn and Ken want that and want to get that domain.
Or it's more of fact that there is somehow organized market that tries to get some profits with the different business models in the value of related domain names in general, not concrete domain names, but, you know, more or less, I would say, in the general approach of deleted domain names, knowing that some of them have some value?
So it's a question of individual fights for a given domain or, let's say the registrar's contention comes from some organized professional customers trying to profit from that concrete market?
>>BRUCE TONKIN: Okay.
I'll answer the question by giving you some examples of some of the -- I suppose, the motivations or the business models.
But I won't attempt to be exhaustive, because there's probably many.
But the starting top example is that, typically, when a customer comes to a registrar and wishes to obtain a name for their business, many people will tend to think of the same things, the most popular things.
So if I was to operate a flower business and I wanted to sell flowers online, people would tend to pick a name that has the word "flower" in it, and the shorter the name, probably the better.
So they would start with probably something like "flower."
Then they might at words to it so they might say "flowers online" or "1- 800-flowers," et cetera.
What they find is when they type the most obvious things they can think of, they often find the name is taken.
So those customers will often be interested in indicating their interest not registrar saying, okay, I know that's name's not available today, but if that name should become available in the future, please let me know.
So given that model, what you also find is that this is happening many times around the world.
At any point in time, each registrar is getting thousands of requests for different names.
And, again, the most common names come up most commonly.
So what registrars will often do is build a queue in their systems of names that customers are interested in.
And then when a list of deleted names is published, they would compare that list of deleted names with their lists of requests that they have.
And that would make their decision as to whether they would attempt to get that name for the customer.
So the early part of the market typically started with simply each registrar getting a single reservation from a customer and then if the name became available, they would obtain the name for that customer.
The market's evolved somewhat since then, because quite often, individual registrars, particularly larger ones, will have the same request for the same name from many different customers.
And what those registrars or even companies that use registrars have done is said, well, we'll obtain the name using our effective method of sending as many add commands as possible.
So they obtain the name.
And they're basically buying the name for around about $6.
Then what they will do is run their own auction amongst the customers that they're aware of, and so if they sell the name for $1,000, well, they've bought it for 6 and sold it for 1,000.
So the money is in that body that has marketed that name.
So that's one of type of market.
There's another type of market that's based on estimating a name that has actually nothing to do with requesting names in advance, it's more having a look at the names that are available for deletion, and they look at those names that are about to be deleted, and through various tracking mechanisms, they can determine how much traffic, how much Internet traffic was associated with that name in the past.
And based on that, they would register that name and put it back into the network and make it live.
But they direct the traffic from that name to one place.
So this is sort of traffic aggregation, where you register many names and you buy names that have the most traffic and you direct all that traffic to a site, or even lease that traffic to providers, say.
Does that give you some idea?
These things get progressively more complex, but....
>>AMADEU ABRIL i ABRIL: Okay.
If that's the case, could we consider the question of traffic aggregation problem is the most important at driving this model and therefore causing this problem?
At least today?
>>BRUCE TONKIN: Are you asking me the question, is traffic aggregation the biggest driver?
>>AMADEU ABRIL i ABRIL: Yeah.
The biggest -- the biggest driver for this market, this pressure in gathering the names to be deleted, traffic aggregation as the main reason.
>>BRUCE TONKIN: I think it's one of the reasons.
I hesitate to make a judgment on how big a reason it is.
It's one of the reasons.
>>AMADEU ABRIL i ABRIL: Okay.
>>BRUCE TONKIN: I think the other comment I would make, though, that might be more informative is that it -- in many ways, it's a market for professionals.
And part of the issue, I think, is, we need to create a market that the average user can understand and take advantage of rather than, you know, less than 100 people in the world really understanding the market and being able to profit from it.
>>AMADEU ABRIL i ABRIL: No, I was saying that because if traffic aggregation was the main driving force in this problem, then we could have a simple solution by extending -- I mean, by putting the domain names that are deleted in a state that cannot be registered for, let's say, six or further months.
Indeed, traffic aggregation would die with a domain name that's one -- where one name is six months not directing to anywhere, so probably the interest for having those names, in general, would decrease.
This doesn't harm anyone, as you know. If you're not interested, you don't care, you know, how soon somebody else will have it. If you want a domain name, It doesn't harm you because you will get it when it's available, and you cannot control one. And registries and registrars will get the name revenue for those names. But it will increase the traffic. Indeed, if traffic aggregation is only one and maybe even the main reason for doing this, this measure will have not and we should go to the other methods that we were proposing today.
>>BRUCE TONKIN: Then I think you have to understand why is there traffic there in the first place. And traffic maybe in the first place because of common misspellings of a well-known name or the name might itself be the sorts of things that you might take a guess at for going to a Web site. So even if a Web site was not -- let's say a name like flowers online, people might take a guess at the domain name and that's what's causing the traffic. So you can take the domain name out of the system for six months. Even if up turn it back on you can end up with traffic. So that's something to think about but it wouldn't totally solve the problem is all I'm saying.
>>KEITH TEARE: Actually, I have a little anecdote about that, because after two years of being dormant, I recently reacquired the real names dot com domain name, and I wished it on and to my surprise I was getting several thousand visitors a day from the first second I switched it on, so I'm not sure that traffic dies because there are legacy systems still in place looking for things that used to be there and have never been switched off.
But I wanted to make a broader point and by way of disclosure, I'm a board member of Snapnames, and spent some time recently as an external consultant to VeriSign helping them to understand this market. And in doing so, had the occasion to talk to many of the registrars about how they see the market.
And speaking now just as myself, not on behalf of anybody, about what I learned through that process. And I think maybe it's helpful for you all to understand that there are really three different issues which are related to the stage a name is in. And they all could be ENCAPSULATED under the broad term of a second market in names or a derivative market in names. But it's helpful to think of them in different stages.
And the three stages are the stage between the person first acquiring a name, if I was, for example, to go buy a name today, for the first 12 months or two years, for the duration of my registration, the name is mine. And if I want to sell it in a market, I can. And there are markets available for me to do that, great domains and so on. They on auction markets, I think, for the most part. And I may find an agent to help me and so on.
And that's probably the smaller of the three markets.
Then I allow the name to expire, and my registrar, to some extent, takes control of the name at that point, either with or without my agreement, preferably with, the registrar could make that name available in a secondary market, a market that's beginning to emerge. And network solutions and Snapnames have a relationship for that called the transfer fulfillment. And that's when the registrant has given permission in one way or another to the registrar to make the names available in the secondary market and take some proceeds from the sale before it's passed on to the new owner.
And then there's a third stage where if the name is not sold -- and by the way, the second stage is quite important to the batch pool issue because insofar as that second stage takes valuable names out of the market and puts them into new hands, they are no longer being dropped later on into a batch pool.
And then there's a third stage which is for the names that are not sold during the time when the registrar is the dominant authority, let's say. And that's when the registry becomes the dominant authority, in the five-day expiration period. And at the moment, the names are not allowed to be auctioned during that period. That's probably a mistake. If there was an ability to auction names during that period, a lot more names would go out of the system and that would further help the batch pool issue. If all the names could be dealt with at that stage that would totally get rid of the batch pool issue. But the registry doesn't have any right to create an auction at that stage. It probably would be helpful if they could. Fourthly the name is deleted and then there's a land grab for anything that's left. So I think it's helpful to think of one secondary market with four different stages with quite different solutions in each of the four stages, all of which I think it's!
wrong to take a moral approach to. Whether one is for or against traffic aggregation is irrelevant. It's a real market, real buyers, they have real purposes, they do real business with real companies like Google and so on. It's not up to us to determine whether they like them or not. They have a demand for names, they'll buy them, they're happy with the purchase, the buyers are happy with the sales. I think we ought to allow that market to exist in the least contentious way possible.
>>BRUCE TONKIN: Thank you.
Just to give an idea of scale of how many names we're talking about, in any given day in the COM/NET registry, to give an example, 20,000 names may become available in a given day, and out of those 20,000 names there's probably contention for about a thousand of them, just to give you rough orders of magnitude here.
So on a given day, there's heavy interest in a thousand names. It's quite, quite big numbers.
And I think also there was one question from the online forum. I wonder, Glen, if you could read that out for me.
>>GLEN DE SAINT GERY: Yes, certainly, Bruce. The question comes from Danny younger.
"I would appreciate if this comment, question could be posed during the GNSO's public forum microphone segment. The redemption grace period technical steering group proposed that six months after the adoption of the RgP ICANN's president should reconvene the steering group to review the implementation of the RGP, to suggest possible improvements to the RGP and discuss a development of a stage two which would enable registrants to choose the restoring registrar.
"The steering group rightly recognized that it would be desirable to allow registrants to be able to restore their names through a registrar other than the one that deleted their registration. The registrant community is still awaiting action.
"Making matters worse, registrants now find themselves victimized by unscrupulous registrar gouging, with certain registrars charging as much as $200 to apply to restore demand. And these registrants have no real recourse other than to submit this onerous registrar abuse. They cannot take their business elsewhere. They cannot shop for a better deal. They have no freedom of choice.
"I ask will the GNSO council be willing to act on behalf of the registrar community and ask the ICANN CEO to reconstitute the technical steering group so that it may proceed with the stage two solutions that were originally envisioned."
>>BRUCE TONKIN: Okay. Thank you, Glen.
Ross, do you have a comment, I have a vague memory that ICANN was trying to convene that group and I forget what happened.
>>ROSS RADER: I'm not aware of any developments with that group. The last that I had heard was that the -- it was a very complex process and would be taken under advisement, but I haven't heard anything since then.
>>BRUCE TONKIN: Yeah, I think that one of the issues is, I think we'll take that on notice and the council will consider it in discussion with staff. It's probably partly a resourcing issue as well and identifying how many names are actually retrieved using the redemption grace period, because it is mostly a manual process right now.
And names are supposed to have been -- redemption grace periods typically happen 45 days after expiry, and so the number of names that are in that category I think will be fairly low. And the question is how much complex procedure do you want to build on top of that. So I think what I'd need is -- council would need, I guess, is some statistical information from ICANN and registry operators on how many names are in that category and get an idea of how many registrants are affected to decide where we would prioritize that work amongst other issues that are before the ICANN and the council.
Ross.
>>ROSS RADER: Just to clarify that, Bruce, is that a roundabout way of saying we will take it on board but we don't know much about it yet?
>>BRUCE TONKIN: Yes. I think it's the when rather than the if. And I think what we need to understand is when do we do that work.
>>ROSS RADER: Gotcha.
>>BRUCE TONKIN: Any other online comments? Yeah, go ahead, Jordyn.
>>JORDYN BUCHANAN: Thanks, Bruce. I've noted with pleasure recently that ICANN seems to intend to step up its compliance activities and its ability to ensure compliance with its various contracts. However, I do note that as a number of GNSO task forces have discovered in the past, that the current contractual frameworks offer very limited ability for ICANN to pursue remedies other than essentially de-accreditation. And I would strongly urge the council to take up perhaps a PDP process or perhaps some other investigation of what other enforcement mechanisms might be available now that they're adding staff and capacity to enforce compliance to their fullest extent. Thank you.
>>BRUCE TONKIN: Thank you, Jordyn. And I believe that's also in the self-review. I think Niklas Lagergren actually added a suggestion along those lines. So that's certainly something the council was considering.
Elliot.
>>elliot noss: Thanks, Bruce. Elliot Noss from Tucows. I would note on the heels of that we are starting to sort of see the beginning of that now with the transfer process which does have some less than expulsion penalties associated with it. One point that I wanted to make was to make sure there was explicitly brought to the council's attention with respect to the secondary market. I guess it's sort of a one A and one B, is that this is a market that is primarily sorting itself out as we speak.
First of all, and I'm going to repeat some comments that I made in the registrar constituency meeting. The demand side of this market, the acquirers of names, despite the fact that prices for them have been increasing substantially are quite satisfied with the market. They appreciate the additional certainty that's been brought to it, and I think all understand that as this market matures, the public will more and more be brought to bear on the secondary market so the demand side is sorted out pretty well.
It's on the supply side where the big challenges exist. And here, this is something that we -- when I say "we," now, at Tucows, have thought about for a long time, really since we were first confronted with this problem and it was really first sort of taken up in ICANN meetings back in Montevideo so you all understand how long ago this has been rattling around in our heads.
The issue of who's entitled or -- "entitled" is probably the wrong word. Who is most appropriately entitled to the excess revenue that this demand creates is the big question that need be answered.
We very publicly stated that for a lot of reasons, we believe that the only rightful party here is the previous registrant. We feel that all of the alternatives are inappropriate or have no basis in policy. And we also feel that the only thing today that's standing between the previous registrant and clear entitlement to this revenue is a dearth of information.
We think it's important to note that we're starting to see the market sort this out, and I would really urge the council to focus on this narrow issue to the extent it chooses to take on anything with respect to this marketplace, and to ensure that you really do give the market time to evolve solutions and that whatever solutions you think that you might want to assist with are consistent with this narrow focus.
So, thank you.
>>BRUCE TONKIN: Thanks, Elliot. Can I just ask a point of clarification? So your narrow issue is where -- who is the beneficiary of any funds that would be obtained. Is that essentially --
>>ELLIOT NOSS: The demand side, Bruce, is quite happy with the way the market is working right now. Our problems -- if you look at the market in efficiencies, they really exist on a supply side of the batch pool.
>>BRUCE TONKIN: Yes.
>>ELLIOT NOSS: People competing for threads and not only the volume of threads but optimizing those threads for their ability to whack at the registry is just a useless behavior.
>>BRUCE TONKIN: Yeah. Essentially, it's a game of chance. Would you agree?
>>ELLIOT NOSS: See, you've referred to it a couple times as that. I think there are elements of chance to it, but there are -- this is a game of skill in some regards, too.
>>BRUCE TONKIN: You can increase your chance.
>>ELLIOT NOSS: Well, not just by the amount of threads you have, but even among the major players, there are greater or lesser ability to optimize those threads. You're somewhat aware of that. So it's a game of chance in the same way as throwing the ball at the barrel or at the milk jugs is. There's an element of luck and an element of skill in there. But in any event, neither behavior is really one that the market -- that provides any value in the market.
>>BRUCE TONKIN: Yes.
>>ELLIOT NOSS: So we really have a structure right now that, on the supply side, sees a lot of effort being spent, you know, in a pretty fruitless way. It's a second-order effect --
>>BRUCE TONKIN: Yes.
>>ELLIOT NOSS: -- and these are some comments that I made in Rome. These are second-order effects around us as a community completely indoctrinating and making Canonical the issues of first come, first served and equal access, which are primarily good things but, around the margins, do have some unintended sequences, and I think we're seeing that here.
>>BRUCE TONKIN: I agree with that.
Keith.
>>>: I wanted to do two winks things. One is to reinforce what element has said and secondly to slightly disagree with him on a point. I think Elliot is quite right to say the market is sorting some of this out and to be quite explicit about his point, different registrars have different ideas of what the revenue shares are during the second phase of the name when the registrar is the second party; that is to say, post-expiry.
Different registrars are -- almost every registrar, it seems, desires to make the names for sale in the second market at that point but have very different approaches as to what the appropriate register share is with the registrant. And I think the market will sort that out and is not something anyone needs to be particularly concerned with.
And I think in the first phase of the life of the market will sort it out when there's a clear registrant owner should the owner wish to choose the name in some secondary market. Where I with disagree that is in the third phase when the
Registry.
The market would actually come forward with solutions in that phase as well.
>>BRUCE TONKIN: So this is the phase of pending delete?
>>>: If that's the correct expression. The five days.
>>BRUCE TONKIN: Five days, yes.
>>>: So I think if it was permitted during that phase for the registry, should a sale occur in any secondary market to exercise a transfer from the seller to the buyer, I think the market would step up and come with solutions there as well. Today there are no solutions in that phase.
>>BRUCE TONKIN: And by transfer, there's different terms that can be used in different ways: It's transfer between registrars and transfer between registrants.
>>>: I'm probably including both, because it depends on what the market comes up with which would be appropriate. Think you want to allow the market the largest flexibility in what they're asking for, and the only requirement there is that the registry, which right now only has one action it can take at the end of those five days, which is to delete the name, should have a second option, which is to transfer the name. And if the market has created something that suggested that's the right thing, either between registrants or registrars on behalf of registrants.
>>BRUCE TONKIN: Okay.
We're going to have to bring it to a close shortly, but one more.
>>ELLIOT NOSS: It reminds me, I have no quibble with Keith's comments. I do want to note and make sure the council is aware of where we strongly believe the market is going is in that third phase what you're really going to be talking about are names with a fair market value of somewhere between six and $60. It doesn't change Keith's comments at all but I do want it to be explicitly brought to the council's attention. We believe that first phase, that phase where registrars are controlling the name, will effectively deal with all names that will have a fair market value, assume that to be an auction value, of $50 or more and we will need to find an efficient way of dealing with those names between 6 and $60. That may be a little high but that's to give you a broad feeling for it.
>>BRUCE TONKIN: At that point, I think we will break for ten minutes and then we will commence the council meeting itself.
Is there any other -- Marilyn.
>>MARILYN CADE: Bruce, I did have a question but I can ask Elliot afterward. It's just a clarification.
>>BRUCE TONKIN: I think that's probably best at this point. Thank you. So the council will reconvene in ten minutes for its meeting.
(break).