ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

>>BRUCE TONKIN: Okay. Welcome, everybody. I'd like to get started.

Just in terms of the agenda for this morning, what I propose to do is spend the sort of next half an hour or so just going through the status of the new gTLD document and a time line for completing that document and the process or the next steps to get that document completed; then have a -- spend an hour or so talking through the reserved words output from the reserved words working group, and then an hour or so just talking about different options for dispute resolution. And Jon Bing, a member of the GNSO Council, will help walk us through that.

So just to sort of kick off, then, I'd like to just do a round of introductions for everybody that's in the room. If you could just state your name, if you're affiliated with a constituency, indicate that, if you're a member of one of the committees, indicate that, and if you're here as an observer, to -- if you can indicate, I guess, your affiliation at least as to what organization you're from.

So my name is Bruce Tonkin. I'm a member of the GNSO Council and I'm chair of the new gTLD working group, and I'll start from the end where Steve Crocker is.

Steve, if you'd just like to introduce yourself.

Glen, can I also confirm, is this now being recorded?

>>GLEN de SAINT GERY: Yes.

>>BRUCE TONKIN: Okay. So for the awareness of people in the room --

>>GLEN de SAINT GERY: Please say their names [inaudible].

>>BRUCE TONKIN: Okay. So two things. One is, these meetings are open meetings. We do record them, and we also use some automated transcription software. So to assist that, it helps if, when you speak -- so firstly, introduce yourself by name. That at least gets a bit of a voiceprint. But also, when you're commenting on issues during the day, if you could just state your name first, just before you speak, so that when we go to review the recording, we can accurately reflect that.

So starting again -- sorry -- with Steve Crocker.

>>STEVE CROCKER: Excuse me. I'm Steve Crocker. I chair the Stability and Security Advisory Committee, and I'm just visiting here.

>>STUART DUNCAN: Stuart Duncan, ICM registry, and I'm just an observer.

>>CARY KARP: Cary Karp. I'm a member of the GNSO Council, and I believe I'm on one of the committees that's represented here, if not both.

>>WERNER STAUB: Werner Staub from COR here as an observer, also as a member of the IDN -- GNSO IDN committee.

>>AVRI DORIA: Avri Doria, a NomCom appointee to the council and a member of, I think, all of them.

>>JON BING: Jon Bing, NomCom appointee to the council, and also a member of the PRO working group. Thank you.

>>VICTORIA McEVEDY: Victoria McEvedy, NCUC. I'm on the PRO and the RN working groups. Thank you.

>>TONY HARRIS: Tony Harris. I'm with the ISPCP.

>>GREG RUTH: Greg Ruth, council rep for ISPCP.

>>NEAL BLAIR: Neal Blair, a member of the BC and the RN working group.

>>MARILYN CADE: Marilyn Cade. I'm a member of the BC. I'm here as an observer to the PDP '06, and I am a member of the IDN and the reserved name working group.

>>GLEN de SAINT GERY: Glen de Saint Gery. I am the GNSO secretariat.

>>DENISE MICHEL: Denise Michel, vice president, ICANN.

>>MARIA FARRELL: Maria Farrell, GNSO policy officer.

>>LIZ WILLIAMS: Sorry. Liz Williams, ICANN's policy counselor. I'm going to take a little diverse, too, and just step you through this, which is at the end near Steve Crocker. In front of him. If you want a printed copy, it's there. In the back, you will find an implementation chart and some stuff on dispute resolution models. All of this is on-line, but if you want a paper copy of it, it's right in front of where Steve Crocker is sitting.

>>OLOF NORDLING: Olof Nordling, ICANN staff.

>>KRISTINA ROSETTE: Kristina Rosette, GNSO Council, IPC.

>>TOM KELLER: Tom Keller, registrar constituency and member of the council.

>>MIKE RODENBAUGH: Mike Rodenbaugh, GNSO counselor from the business constituency and member of all three working groups.

>>PHILIP SHEPPARD: Philip Sheppard, business constituency counselor, member of the TLD, and the PRO working group.

>>CHUCK GOMES: Chuck Gomes, representing the registry constituency, on the council, and member of the reserved name working group.

[Laughter]

>>JOHANNES LENZ-HAWLIZCEK: Johannes Lenz-Hawlizcek. I'm with dot Berlin and I'm an observer.

>> DIRK KRISCHENOWSKI: Dirk Krischenowski. Observer as well, and I'm representing dot Berlin.

>>CRAIG SCHWARTZ: Craig Schwartz, ICANN staff.

>>PATRICK JONES: Patrick Jones, ICANN staff.

>>NORBERT KLEIN: Norbert Klein, noncommercial as a constituency.

>>SUSAN CRAWFORD: I'm Susan Crawford. I'm a member of the ICANN board here as an observer.

>>MIKE PALAGE: Hi. Mike Palage, a member of the business constituency ISP registries. I've participated in the reserved name working group and the [inaudible] working group.

>>BRUCE TONKIN: Okay. So in terms of the new gTLD report, I've had some discussions with Liz just in the last day or so, and I think we should be aiming as an objective to complete our work in time for the board to consider the matter at their meeting in Puerto Rico, which is the 25th of June, or the week beginning 25th of June, and if we're sure that we're asking the board to meet at that time -- Liz?

>>LIZ WILLIAMS: Right.

>>BRUCE TONKIN: -- then we would -- then working back from that, the board needs enough time to consider the final report, and the final report would also be available for any public comments that the board might wish to receive.

And so working back from that, we'd be aiming to release the board report by the 4th of June.

And the aim is that that report would include an outline base contract, an outlet RFP, and as much information about the implementation plan as we have available.

Working back from that date, then, before we publish it for the board, is coming back into May then, probably around 20th of May, to -- and some of this is internal process-driven, so the ICANN staff need to -- the document needs to go through a legal review, making sure that all the recommendations are implementable.

That means by mid-May, we'd want to get any input that the staff would use for completing the report, including the completion of the work from the various working groups and -- oops. I've dropped something off the bottom here. But essentially, that would imply that by --

So what date would you see the council meeting to sign off on the report?

>>LIZ WILLIAMS: I think that I would suggest, as we discussed last night, an establishment of a special council meeting to consider the report, which obviously it needs to be at least 17 -- at least 7 days prior, so that everyone has a chance to read it, and then convene a special meeting meeting -- council meeting to consider it. There is not a list yet, Glen, if I'm correct --

>>GLEN de SAINT GERY: No.

>>LIZ WILLIAMS: -- of meetings scheduled for the new Daylight Saving Times, so I'd suggest we set that pretty quickly --

>>GLEN de SAINT GERY: Yes.

>>LIZ WILLIAMS: -- and then commit to that, because that's a stop point.

>>BRUCE TONKIN: So essentially, it would be towards the end of May.

>>LIZ WILLIAMS: Yep, exactly.

>>BRUCE TONKIN: Yeah.

>>LIZ WILLIAMS: I would suggest around 27 May, because we need that date inserted in there.

>>BRUCE TONKIN: Yeah. So we'll have a look at the --

>>MARILYN CADE: Bruce?

>>BRUCE TONKIN: Yeah.

>>MARILYN CADE: Yes. But just keep in mind, the 30th of May, the Memorial Day holiday in the U.S., when you do that.

>>BRUCE TONKIN: Okay.

>>MALE SPEAKER: I have a question.

>>BRUCE TONKIN: Yeah, go ahead.

>> Bruce, I have a question.

>>BRUCE TONKIN: Yes.

>> With this time line, when you say 4th of June the report would be sent up to the board, does that mean that there will be no further comment periods then, as from then? It would just -- would be -- the comment periods would be over with, is that right?

>>BRUCE TONKIN: No. On the 4th of June, it will be published as a board report, so that's basically the end of our policy development cycle, but the board process -- before a board meeting -- or before considering a matter, there's a section of the ICANN bylaws that I believe requires the board -- the board to take any further public input.

So it would be public input -- we wouldn't be considering it; the board would be considering the public input.

>> Normally, what -- how much does that entail, historically? Is there any history on that, how long it will take?

>>BRUCE TONKIN: Oh, yeah. We've done it a number of times, Tony, so using, for example, the transfers working group report -- sorry, the transfers report from the council, the, you know, deleted names report from the council, generally it's aiming for 21 days from date of posting, to allow the community to comment on that, and then the staff would summarize those comments for the board for their meeting on the 25th.

>> Okay. Thank you.

>>BRUCE TONKIN: Yeah. So that -- those public comments don't ever become part of our report. They just are material that would be available for the board. Marilyn?

>>MARILYN CADE: Bruce, I do just, though, want to call attention to the fact that that is -- that's actually probably too tight for the 21 days, right? We release our board report, right? So we're saying when it goes to the board, it also is published for -- or the board publishes it for public comment? Which one is it?

>>LIZ WILLIAMS: [inaudible] It's called the board report.

>>BRUCE TONKIN: Yeah. It's -- I guess what Liz is saying is that the board report is the document that's described after the council has voted on the report.

>>MARILYN CADE: Right, right.

>>BRUCE TONKIN: The results of that vote get added to our document.

>>MARILYN CADE: Right, right.

>>BRUCE TONKIN: And then it's posted on ICANN's main Web site.

>>MARILYN CADE: For 21 days.

>>BRUCE TONKIN: Yes.

>>MARILYN CADE: But if we do the count here, June the 4th to June the 25th --

>>BRUCE TONKIN: Yeah.

>>MARILYN CADE: -- I'm not -- and we really -- you know, one of the complaints about ICANN is that it delivers material --

>>BRUCE TONKIN: Too late.

>>MARILYN CADE: -- just in time to you to pick it, as opposed to read it.

>>BRUCE TONKIN: Yeah, yeah. So we're saying that this is, you know, on the ICANN Web site on the 4th of June is the objective.

>>MARILYN CADE: I understand. That means that for the comment period, the 21-day comment period, to Tony's point --

>>BRUCE TONKIN: Yes.

>>MARILYN CADE: -- the board will be walking into -- they have the report from us for 21 days, but they will be getting a summary of the public comments.

>>BRUCE TONKIN: Oh, I see what you're getting at.

>>MARILYN CADE: And there's likely to be a huge number of public comments.

>>BRUCE TONKIN: Yeah.

>>MARILYN CADE: Just -- not that I'll be writing them, but...

[Laughter]

>>BRUCE TONKIN: Yeah. I think -- I think neither -- I have to go back. We'd have to revise. This is just kind of a draft to give you a bit of a flow.

>>MARILYN CADE: Sure.

>>BRUCE TONKIN: I'm not attempting to lock these dates in yet.

I'm not sure that it is 21 days that the board would want.

>> It's 20.

>>BRUCE TONKIN: It's how long?

>> It's 20.

>>BRUCE TONKIN: It's 20. But, I mean, effectively that would be saving comments all during the week. That's the week beginning the 25th of June, too, remember, so the board would probably not actually vote on it until --

>> Friday.

>>BRUCE TONKIN: -- you know, the 29th of June or something. So there will be, no doubt, public forums and other things where they're getting input.

So if you're saying that you're -- we're going to be driven by the fact that it will take the staff a while to compile those inputs, you know --

>> Bruce, would it be correct to say, then, that they would be unable to make any move on that during the Puerto Rico meeting because the comment period would go beyond the Puerto Rico meeting?

>>BRUCE TONKIN: I don't know. I don't know the answer to that.

>> But it would seem that way, from the -- from what we've just said.

>>BRUCE TONKIN: Yeah. Well, I mean, what I think is -- if I look at what the board has done in the past, and also I guess what the council has done in the past, the board may well decide to form a special board meeting to make that decision, which might happen after the 25th of June, but I'd see that meeting in Puerto Rico as being the main meeting where the issue is considered, if you like -- you know, like. They would hear all the input, they would probably discuss it at the board level as part of that meeting, but they may make their final decision, you know, a couple of weeks later after all that input's put together. But I -- but I -- you know, this is just conjecture because that's the board's decision.

>> So theoretically, it would be heavily featured in the public forum, then.

>>BRUCE TONKIN: Yes. Yeah, that would be my intent, yeah.

Now, bear in mind, it's not our decision. I mean, the board will decide when it feels ready to vote on something, so we're just kind of putting a target time frame here when we release the board report. The board might decide, you know, "We need another month to think about it." But that would be their decision.

>>LIZ WILLIAMS: Just for some clarity for everybody, if you look quickly at the GNSO's PDP guidelines, Section 13 deals particularly with what the board does, and the board will meet to discuss the GNSO Council recommendation as soon as feasible after the release of the report. And then there's a whole range of other provisions that are sitting within those bylaws there. So that's what we'd be working towards. It's very important for us to have, though, for the -- the work that is not completed yet, some stop dates for that to be completed so that the writing can finish. It is not a desirable outcome for me to have fairly loose deadlines for completion of work because it means that the draft never gets finished, and we have a lot of internal work to do. So as soon as we can agree on a time line, that is very, very helpful for our planning purposes, and it's very helpful for the completion -- stepping up of the completion of the work which is still outstanding.

But you can all, of course, refer to the PDP guidelines, which is what we'll be trying to stick to as closely as we can.

>>BRUCE TONKIN: Okay. So now what I propose to do is just briefly go through this document that we currently have, and, as part of that, sort of identify how we progress. But what -- what I would see as being the next steps is we're now moving into more of an editorial phase, so I believe most of the core policy work is now concluded. We're getting some further input from some of the working groups on implementation issues, and now we're really looking at improving this current document with an editing phase and taking input from members of the committee on areas of improving the wording here and there.

For that to work, what we'd need, I think, is to set some clear time lines, so we say, "Okay, the document's now open for, say, 14 days where, you know, everyone's free to suggest editorial content, as opposed to new policies."

The staff would then publish a new version of the report, taking into account those editorial suggestions, and then we'd review that document, and then we'd move forward to a council vote.

So just to sort of kick off that kind of editorial phase, I'll just provide some of my own comments, and then -- just to give you a flavor for where I was thinking, but obviously I want to hear other inputs as well. So --

>>LIZ WILLIAMS: Would you mind if I added just one note, Bruce, if you don't mind?

>>BRUCE TONKIN: Huh?

>>LIZ WILLIAMS: Would you mind if I just added something, just to tell people what I'm going to do during --

>>BRUCE TONKIN: Yeah. Sure. Go ahead, Liz.

>>LIZ WILLIAMS: Everyone, just first of all, I wanted to put on record my thanks to everybody who has been involved in the production of the work so far. It's been a very valuable process.

What is going to happen from my side, because I'm the one that happens to hold the pen here, or the fingers on the keyboard, if you have specific line edits and text that you wish to have included, please send it to me, identifying the section number and your suggested changes, so that they can be captured as we go along.

Please also send me -- and I'm going to turn on my ichat, so I can do IMing, for anyone who wishes to ask a question as you're going along -- and please come to me at any time for how we are going to structure the document.

Just so that you know, this document is substantially different than happened in L.A., and it reflects all of the materials that were discussed in great detail in L.A. Some of the things did not have majority agreement, and I've tried to be as objective and as fair and as reasonable as possible to reflect what I thought we had agreement on.

Now, we need to produce a report that is ready for the board and will be part of the completed piece of the policy development process.

What I intend to do, in the remaining portion of the work, is to considerably change things in terms of representing things graphically. Part of our challenge is to talk about this work outside of this closed environment, and then start to talk about it in public.

If you have good statistics, good background, good metrics, good documents, good diagrams, let me know, because it is of great benefit to the production of the report, and I'm looking forward to this last little iteration of it.

To turn it into a board report, you'll also notice in Section 13, I'm required to, by the bylaws, put in a statement of where recommendations had majority support, where there's an impact on constituencies, what the cost of implementing the policy would be, and I'd urge each of the constituency reps to have a look at the bylaws, to see what's required of your constituency, because I will need those constituency statements, those constituency impact statements.

So there's a number of formal requirements that I'm required to put into the board report that do have a bearing on your having to go away and do a bit more work.

Of course any questions, just let me know.

>>BRUCE TONKIN: Okay. Thanks, Liz.

So just walking through the document, the first section, I guess, is related to principles. One of the things I'd like to do to add to that section is specifically identify the core values from the ICANN bylaws that relate to this policy development work, and that was basically the material that we covered in Washington, if you recall.

And -- and in Washington -- and I'll just put some of these up, just as a recollection, but just go through them very quickly -- you know, ICANN's mission, some of the key words I put in red here: Ensuring the stable and secure operation of the Internet. And in terms of core values, the ones -- there's obviously enhancing operational stability. There's respecting creativity and innovation. But limiting those -- like ICANN activities to matters within ICANN's mission.

To the extent feasible and appropriate, recognizing the policy role of other entities. So a lot of these elements now, now that we've sort of moved towards the end of the process, you can sort of go back and reflect on, and so some of the things that we've been talking about with dispute resolution and sort of the public policy inputs there, we're effectively saying there's other responsible entities that would be involved in that.

Where feasible and appropriate, depending on market mechanisms, introducing and promoting market competition, and so on.

So rather than going through all those now, what I'd like to see in this report is, just before we get into our principles, that we also just reiterate what the core values are, and perhaps highlight the core values that were the ones that were most relevant in driving our work. And I think these were the three core values that came out of our Washington meeting, which was: preserving and enhancing stability; depending on market mechanisms, to promote and sustain a competitive environment; and seeking broad and informed participation reflecting functional, geographic and cultural diversity.

So I think it's important that we state those up front, but also constrain the scope, because there's many things that people look at that and say, "How come you didn't put in such and such a policy recommendation?" And, you know, a fundamental answer in many of those cases: "Well, that's not consistent with the mission and core values. That might be a nice idea, but the reason it's not included is because it's not part of ICANN's role.

So that's what I was suggesting in terms of a section prior to the principles.

The principles themselves, sometimes I think we're almost restating an ICANN recommendation, and one of the things I think we should be is at least consistent in our language, so that we don't start creating our own language for our own principles. If it's a principle that matches an ICANN principle, let's just leave it as the ICANN principle, rather than trying to create our own. So that I think once we take those ICANN core principles, write them down first, then look at additional principles. We're making clear that we're adding additional principles; we're not creating new versions of the same principle that already exists.

And I think we'll see that coming from the GAC. The GAC will have principles as well, and there probably also are likely to be slightly reworded versions of an existing principle. So I'd rather we just stick with the existing principle in the bylaws, not create a whole lot of different variations.

In the recommendations section itself, I think what Liz has tried to do is provide these in sequence, roughly along the lines of the way that the statement of work was developed, so we're making a question about whether to introduce TLDs, we're looking at string issues, we're looking at applicant issues, and we're looking at some of the contractual issues.

My comment that I've just sort of picked up that came out of the sections in -- that we had in Los Angeles, but currently we have recommendation 14C, which is talking about an objection process where members of an affected community -- let's say it was the banking community -- that a representative of that community feels that the applicant is not an appropriate body to run that. That, to me, is an applicant criteria, so I'd bring that up after Recommendation 8 that we insert that, because it's essentially part of the applicant criteria phase, which is different to a process that might be used for string contention, where you have two people that want to run dot bank and then there's some process for working out, well, which -- which is the -- you know, the most -- the organization with the best support.

So I want to separate. One is, one person applies for dot bank and all the banks think that's a bad idea, versus two people apply for dot bank and one has got all the banks in Europe in favor and another one's got all the banks in, I don't know, South America in favor, and there needs to be some way of resolution that contention. So that's just a different principle.

>> Bruce, in regard to that one, would 14B need to go with that?

>>BRUCE TONKIN: What I would be suggesting doing -- and this is -- and I'm just giving examples of the kind of editorial comments I'd give. But I'd probably try and combine 14A and 14B into one recommendation, which is just dealing with the process of string contention -- sorry -- yeah, contention. And 14C would become, effectively, an 8A for the moment. It fits in after 8. Because it's more relating to the applicant itself.

Now, in terms of the diagrams that go with this, I think we've now got a good diagram that deals with the steps that we're using to evaluate the strings and evaluate the applicants and we -- we finalized that diagram in Los Angeles.

I want to create a new diagram, this meeting, which will map out the process for how string contention is dealt with, because I think a diagram is a great way of focusing discussion. I will draft something on paper today and then get the staff to make that look nice on Visio or something, and then I'll present it in the new gTLD session tomorrow morning.

But I think getting a bit of a clear diagram around this string contention will then help improve the words, because then we've got a clear model that we're looking at.

Implementation guidelines.

One thing I thought might be worthwhile, to separate recommendations from guidelines, is maybe use a different numbering system for guidelines. So we might number the guidelines A, B, and C, rather than 1, 2, and 3, just so that we don't get confusion between a policy recommendation, which is effectively compulsory, and an implementation guideline, which is really giving guidance to the staff and the -- to the board for how a particular recommendation can be implemented. That's just a suggestion.

>>LIZ WILLIAMS: [inaudible]

>>BRUCE TONKIN: Yeah. Go ahead, Liz.

>>LIZ WILLIAMS: Just a quick question for you.

Was it your intention to formalize the implementation guidelines? There are some things -- and I'm not seeing Mawaki in the room. Mawaki's not going to come.

Victoria, would you mind just checking from the NCUC's perspective? There are some NCUC suggestions in there, in the implementation guidelines --

>>BRUCE TONKIN: So it's implementation guideline 13. Yeah.

>>LIZ WILLIAMS: -- guidelines 13, which were some suggestions that Mawaki had put together which were important to hold. Is it the group's intention to formalize those or leave them as just guidance?

Because the NCUC suggestions, for example, were not necessarily things that were supported by everybody, but I didn't think we actually needed that support, and we could just leave those as guidelines.

>> [inaudible]

>>BRUCE TONKIN: Yeah, go ahead.

>> [inaudible]

>>BRUCE TONKIN: Yes.

>>MARILYN CADE: I actually --

>>BRUCE TONKIN: Implementation guideline 13, yeah.

>>MARILYN CADE: Yeah. I actually would think that guidelines, although they may not be mandatory, they're going to be looked to by the staff with a great amount of favor, so I don't think we can have a guideline that has extremely limited support. Right?

So I think we have to, as a policy process, decide what weight a guideline has. Otherwise, the staff is going to be saying to us, "What's the purpose of a guideline?"

You know, I mean, a consensus policy is absolute, right? A non-consensus policy is a guideline.

>>BRUCE TONKIN: That's right. I think one of the things -- the question -- I looked at this as well, and I wondered whether -- if you -- if I take the second point there, "ICANN may put in place a fee reduction scheme for applicants from developing economies and make the financial and operational threshold for market entry easier," some of this is sort of coming up, I think, in some of the IDN discussions, and some of it becomes a bit interesting.

So if you're saying that a TLD is only for use within, say, a particular community and they're the only people that would be using it or it's sufficiently constrained, I think the argument that's being put forward is, that community -- you know, the electricity supply is only available between 9:00 and 5:00 and turns off overnight, or the -- you know, the -- they don't have air conditioning, so on a hot day, the computers don't work, whatever. And they might say, "Well, but that's our expectation. That's how we operate our economy. You know, we work around the fact that we only have electricity during the day. We only access the Internet during the day in our country."

Whether that's something that we accept as part of the ICANN principle of diversity or whether we're saying, "No, all systems have to operate at 99.99 reliability, you need to locate your name servers in a location where there is reliable power and reliable air conditioning and all the rest of it," some of those things, I think -- I think all we could do is perhaps -- it may be something that has to happen in phases, I think.

You know, you might say there's a first phase where we're initially opening up to new gTLDs, we have a fairly tight process in terms of meeting minimum technical standards, but then there's a separate process, obviously, that needs to identify that maybe later on, we are organizing potentially the use of a TLD by a community and people in the U.S. never would access that TLD because it's in a particular script or language they wouldn't use.

So I'm not sure -- they're almost opposing principles, in a way. The principle we've followed is, we're setting minimum technical standards, and then another principle is saying, "No, you don't need to have minimum standards because particular groups might not have the same expectations."

Marilyn and then Tony?

>>MARILYN CADE: Yeah. Can I just make a comment about that and ask if we might take a liaison question to the ccNSO and even to the GAC on this particular general topic?

So let me give an example.

I think in years past, there were certainly times when CC registries may have -- and Niue may be a good example. Any of the Pacific islands. The single biggest threat to the Internet is not the backhoe; it's the lack of electricity that gets knocked out by some kind of storm. Right? And so they generally have backup generators, et cetera, et cetera.

Over time, the cc's have really evolved toward a very high standard of reliability and security, et cetera, but many of the cc's are very small.

Perhaps we could actually learn something, you know, and take under advisement and come back to your point about stage. What's the general view of cc's that are operating registries, now 190 or so? Some use a gTLD registry as a back-engine. Others use a service that is redundant to their service that's located in another country.

Rather than our thinking we have to come up with the answer, maybe we could sort of enrich our understanding by getting some input from other communities who are presently operating registries in very diverse situations.

>>BRUCE TONKIN: Yeah. I would just comment generally from a technical point of view that when many of the ccTLDs started up, they did actually share each other's secondaries, so Australia, for example, has a secondary, I think, hosted by University of Berkeley just historically, because there was that cooperation around the fact that if our system -- and then we'd hold yours. So there was a lot of reciprocal relationships established with the ccTLDs, yeah. Yeah. Tony?

>>TONY HARRIS: Yes, I hope I'm not going off subject. I didn't get any sleep and I'm, you know, 24 hours with my eyes like this. But I think I heard you say something about for developing countries, this subject, there would be some special consideration economic -- economically and so forth, and I think in Los Angeles, a point I raised -- I hope it was taken into account -- was that if this is applied to a developing country, it should be a nonprofit entity because we could very well have offshore entrepreneurs landing, you know, in any island in the south seas and saying, "Look, I'm -- this is a small developing nation. I want a cheap way in."

And it's a business enterprise which could be anywhere. I think that should be considered, anyhow.

>>BRUCE TONKIN: Yeah. And so you're highlighting some of the inevitable problems when you start making exceptions. And it may be that the thing is to sort of learn from experience. So you may have a round, based the way we've described it, and then we assess whether the barriers to nations was actually stopping them or whether there was some other way of supporting that -- that group that wanted to put forward the TLD. So, you know, we -- I think the process has to evolve to some degree and we learn from the experience rather than necessarily watering down our recommendations at this stage.

So I guess coming back to I think what was -- was it Liz or Marilyn's question? -- about what sort of weight we give on that, I think you might have a guideline that ICANN needs to consider the issues around developing economies and diversity and assess whether, as an outcome of the round, there's some evaluation of that. But I'm not sure that in the first round, we're necessarily going to be able to implement particular IDs because, you know, it's still fairly early in the overall process. We haven't even got the rest of the process bedded down, and then we're putting effort into trying to come up with the exceptions.

But, yeah, I think, you know, rather than have a big debate on that now, I think people can do that on the mailing list and just sort of think about how -- whether they want to put something specifically as a recommendation, which is a consensus recommendation, or whether the better place is to improve the wording of this current guideline.

Okay. Moving through, in the discussion, one of the things that occurred to me -- I think there's been quite a lot of work there on some of the things to do with strings and various laws for what support those IDs. It did occur to me, though, when I read this document that because I guess most of the -- you know, a lot of the work is being done in the language of English, that the examples seem to have come from locations where documents tend to be readily available in English, so the European community obviously translates their documents in English as one of the languages. The U.S. is in English. Australia is in English. So the examples we've chosen in our current report are generally from areas where English is a very dominant language, you know, where Google very effectively is able to find the material, et cetera.

What I'd like to see in the final report, though, is that we do acknowledge the geographical diversity and include some specific recommendations from South America, Africa, other parts of Asia, when we're giving examples. So it doesn't change the recommendations, but I think we -- in our examples, when we sort of say, you know, "for example, there's a U.S. trademark law," "for example, there's an Australian trademark law," I think we should also say, "And for example, there's a trademark law in China," and "for example, there's a trademark law in, you know, Tiger" or wherever, so that we aren't just -- we are genuinely looking at geographic diversity.

Did you want to make a comment on that, Liz?

>>LIZ WILLIAMS: Yeah, just a quick one.

There's a couple of things that I will do from my network of experts in this particular area. Most particularly in Chinese-speaking environments, in Hong Kong and Singapore, and also because my particular expertise lies within the Japanese environment.

I will go away and look at that more robustly, to give a much broader perspective. And I think Kristina was actually going to ask a question about examples from our jurisdictions.

It's not about trademark law; it's about the ways in which people approach these kinds of issues, not necessarily about trademark law. But if you wanted to provide other examples, then do go ahead.

>>BRUCE TONKIN: And I guess particularly this is perhaps relevant to some of the constituencies, but the constituencies themselves are meant to be representing reasonably geographic diverse areas, so I guess what the staff might do is ask some of the members of council to be able to -- that have contacts in those regions to at least identify -- and I think what we need is references. It's not like we need a lot of material and we're not asking for legal advice here. We're just sort of saying where are some references of particular laws, so that we can incorporate them in the report. And I think members of the intellectual property constituency, you know, members of the business constituency, ISPs, should be able to sort of give at least some hints to staff of where to look for some of these things.

>>MARILYN CADE: And Liz, there's a new person here in the GAC from the -- from WIPO who is aware of the updates on the Madrid protocol. There's 91 countries that are members of the Madrid protocol, so...

>>LIZ WILLIAMS: Yeah. I saw them at breakfast this morning.

>>MARILYN CADE: Yeah.

>>LIZ WILLIAMS: The other thing that is also useful in terms of developing -- what we're trying to do is develop best practice and standards that are relevant. The OECD has many member countries that have useful information.

The World Bank, the Asian Development Bank, and others who do very large procurement procedures also have principles that are relevant here.

So -- and I have used the references to those in the PDP Feb '06 materials which people will have read almost a year ago now. So I'll go back. If anyone has any specific suggestions, just come to me, but that's the kind of material that I'll be using to put more meat on the bones of those things, to make it more global in its nature.

>>BRUCE TONKIN: The other comment, too, I think we've got quite a few examples around the "confusingly similar." Some of the other recommendations, I thought, we lacked some examples. So Recommendation 4 on "strings should not cause any technical instability," I think we need to include some examples there, and we need to word it appropriately, saying, "This is not a definitive list; this is saying these are examples that may be an issue." And we use the word "may," as opposed to "will" there, because obviously something like that would go through some degree of discussion.

But examples I would give would be like dot exe, for example. That may or may not be an issue, but at first glance, it's probably not a good idea to create a TLD for dot exe as the top-level name.

>>LIZ WILLIAMS: Bruce, do you want to do it around the other way? So for example, the dot net RFP, the dot org RFP and the existing registry agreements provide quite detailed stuff about technical requirements. Instead of using language that said "must not cause technical instability," I can look at Steve at the other end of the table here and ask for the way in which -- we might want to leave the recommendation the same, but we might want to have the discussion around technical stability on the basis of guidelines on the basis of existing protocols on existing standards.

>>BRUCE TONKIN: Yeah. But a lot of these things aren't -- there are not -- there isn't an existing standard on this sort of thing.

So I think you need to give some -- what I'm trying to do here is give clarity about what we mean by the recommendation in each of these cases, and we give some examples.

And the example I just gave, there isn't an RFC that says that, but most people in the technical community would probably call it a no-brainer, which is why it's not there. But I think we need to give some examples of ones that at least give people an idea of the sorts of things that wouldn't be acceptable.

So that was Recommendation 4 --

>>LIZ WILLIAMS: In that case, if you go on to Recommendation 5, which said the strings must not be a reserved word, I think then some language around the reasons why it mustn't be a reserved word, that some reserved words, if they were released, would cause technical instability. For example --

>>BRUCE TONKIN: Yes, that's one of the -- yes, yes.

>>LIZ WILLIAMS: So we can just link those three things quite closely together.

>>BRUCE TONKIN: Yeah.

>>LIZ WILLIAMS: There are other sets -- and I'm looking for Chuck. Where's he?

Chuck, in the reserved names report, it would be useful -- Chuck, if you can hear -- I can't see you, Chuck. Sorry, there we go.

>>BRUCE TONKIN: Yeah, he's there in the middle.

>>CHUCK GOMES: I was hiding.

>>LIZ WILLIAMS: Yeah, I thought you might have been because I'm just about to give you some work to do.

When we give the presentation on the reserved names group, it would be good then to draw out, for the purposes of the main report, why the recommendations have come in in the way they have, so that it means that when I write it, we can put the text around, "The recommendation says we'll continue to reserve geopolitical terms because it does, blah, blah, blah. We'll continue to reserve XE local host, an example, and HTML and others, because it may cause technical instability to release them.

So that text has to make its way from the reserved name reports -- reserved name report to -- to help with the main body of the report here.

>>BRUCE TONKIN: Okay. So then I think some examples around reserved words are good, and we certainly expect to get some input from the reserved words working group on that.

The section that we've got on legal norms regarding morality and public order, I think -- well, same comment about the string criteria there, but again, just putting some more examples of laws that relate to that that are, you know, in other parts of the world.

I guess you have one there, which is the U.N., but -- Convention on Human Rights, but presumably there's some others that we'd want to put in there.

>>LIZ WILLIAMS: That particular recommendation presented me with a lot of challenge in terms of writing about it because we had the great discussion about the status of the GAC public policy principles, whether they were draft, whether they were posted.

I've had a conversation a couple of days ago with Bill Dee, and I had a discussion with Suzanne last night. We're still in the situation where those principles are in draft, so having language around those kinds of things depends, in part, about what the GAC approach, final approach, is, because I wanted to be quite specific, and I'm trying not to have a blanket approach. I want to address things that relate to policy with the introduction of new top-level domains, not life, the world, the universe, and everything.

>>BRUCE TONKIN: Yeah. So the key message there that came out of Marina del Rey was, what we're trying to do is pick up things that are widely -- laws that are widely accepted around the world, I guess. And so I think if we can identify some examples, rather than that being definitive.

And I was thinking part of the objection process that we might look at, in terms of dispute resolution, is when someone says, "Hey, I'm disputing this particular string because I don't like it," and then they -- they also would need, I think, as part of that complaint process, to identify what laws cover that, so it's not just a subjective thing, and I think the onus on them, you know -- the onus on the complainant would also be to identify where that law resides in a number of countries.

So it's not just a case of saying, you know, "I live on this little island and I own the island and I've made my own law and, you know, I don't like this name." They'd have to sort of be able to show, yeah, that same law actually exists in a number of geographic regions, or whatever, and we use perhaps some of the general ICANN criteria we have there around geographic diversity, whether it truly is an international accepted norm, or whatever the wording we have in here.

>> Can I -- can I just make a comment to that?

>>BRUCE TONKIN: Yeah.

>> I did some work around this in relation to the controversial names issue for the reserved name working group and looked at other examples that may be useful here. The European Convention on Human Rights and so forth. And just examined a number of the legal issues. So it just may be worth referring to, if you're looking for --

>>BRUCE TONKIN: Yeah, absolutely. That would be great.

>> Thank you.

>>BRUCE TONKIN: Yes, Jon.

>>JON BING: Just a small point. You have the phrase "legal norms." Is that -- how much intention is behind that? Does it mean that if you have a norm which is not legal, then it falls outside? If so, we should comment upon that.

[Phone beeps]

>>BRUCE TONKIN: Yeah. Well, and I think that is a good point.

When I looked at some of the section about the "confusingly similar" and some of those points, or actually even in the section here that we have around those legal norms, I think it's recognized in some contexts -- you know, like I don't know whether they're -- you might have a law against certain types of drugs in a country, and therefore you could say that a TLD that's around an illegal drug, you know, could be illegal because it's related to the fact that the drug is illegal.

Then there's other things like I suppose objectionable swear words and things, and so the word itself may not be illegal somewhere as a law, but the principle of morality might be legal. So I guess we're trying to tie it down to something that if it's written down as a law, it's already gone through a pretty extensive public review process to become a law, and if it's a law in a number of countries, it's fairly representative of the public's desire because that law is across a number of countries. If you go outside the legal process, then it becomes a lot more subjective, I think, and so I think -- I think the intent is that it is based on some law.

>>TOM KELLER: So the question I would have, Bruce, is: How many laws do you need to fulfill that criteria? I mean, we had that with dot nazi. I think that was discussed --

>>BRUCE TONKIN: Yeah.

>>TOM KELLER: -- in L.A. I didn't participate on that. I just read that in the report and it would be interesting how that would be handled. I mean, that would be clearly against the German, the French law.

>>BRUCE TONKIN: Yes.

>>TOM KELLER: Would that be enough, in representing like, I don't know, 120 million people?

>>BRUCE TONKIN: Yeah. I gave that a bit of thought, Tom, and I was thinking let's say that word was in Chinese letters or characters or something, and therefore, you know, it might mean that. But I don't think the people in Germany or France would -- would be the target market, if you like. And so therefore, something like that, it's more a case, is dot nazi going to be marketed in Germany as a domain space and, therefore, impacts German registrants, or is it something that's only going to be marketed in China and actually means something totally different in China? So it would -- you know, that -- that's kind of some of the things I was thinking about on that. Mike?

>>MIKE RODENBAUGH: Yeah, Bruce. I mean, I would just say that as we've seen with many of the cc's, the original marketing plans don't exactly hold, and, you know, things change over time. So I'm not sure that you can assume that an application's criteria is going to hold forever.

>>BRUCE TONKIN: Yeah. So that -- but that may be something as part of an objection process.

So let's say the German government -- let's say someone did dot nazi in Chinese characters, just as an example. Let's say the German government objected to that on the basis that, you know, it's against their law. Then the applicant might say, "Okay. As a way of dealing with that objection, we agree that we will never market this in Germany, and the registrants that register in that domain space will not be able to use that name in Germany."

That would then be something that would go, in my mind, into the contract for that TLD, because it's used to obtain -- to overcome that objection process. This is sort of dealing with the issue that you were talking about, Mike.

So it's not a -- it's not just a case that they could change their policy some way; it would be a contractual obligation for them around that particular objection.

But I'm just throwing up examples here how you might be able to deal with some of those issues.

>>MARILYN CADE: Bruce?

>>BRUCE TONKIN: Yeah.

>>MARILYN CADE: I need to ask a reality question, however. When you say "not marketed," gTLDs are not necessarily only for the people who operate them; they are for the people who access the Web sites.

>>BRUCE TONKIN: Use them, yeah. I'm using "marketing" in a general sense. I'm talking about --

>>MARILYN CADE: Recruiting the registry --

>>BRUCE TONKIN: No, the registrants would not be able to use that name in that country either.

>>MARILYN CADE: Well, we're all recognizing that of course the names will resolve globally. These are generics.

>>BRUCE TONKIN: Yes.

>>MARILYN CADE: But we're saying that my defined -- my defined charter is limited to this particular defined space, and only registrants who come from that space could qualify to register that name.

>>BRUCE TONKIN: As an example, yeah.

>>MARILYN CADE: And so the -- so the Web site -- although we recognize the Web site is going to resolve and be accessible worldwide, which is of course the purpose --

>>BRUCE TONKIN: Yeah. I mean, dot mobi is an example, right? Dot mobi has conditions on what the registrant can use the name for.

>>MARILYN CADE: Yes, yes, yes. I just wanted to be sure that I understood, and that may be the way to address this because you're then in the bid, so to speak, in the application. The register -- the applicant for the registry string is aware of the -- these conditions and --

>>BRUCE TONKIN: Because essentially what you're saying in that scenario, because you can't -- the national law still holds, right?

>>MARILYN CADE: Yes.

>>BRUCE TONKIN: But what you're saying is, to that country, you're saying, "This is how we're addressing that legal issue that's related to your country. You know, we're not going to do this, we're not going to do that." Which they'll have to do anyway, by the way.

Avri?

>>AVRI DORIA: I mean, yeah, I think the approach you're taking is very good and that you won't want to impose one country's laws or even one group of countries' laws on everyone, and I think that the onus then is, yes, in the contract, as you say. And then if the government wants to go further about how those names resolve, I mean, we've seen no shortage of governments that do take measures in regard to their citizens using names or resolving TLDs that they don't approve of. That's not something for us to either approve of or disapprove of. It's just that is within their option, and they do take those options.

>>BRUCE TONKIN: Yeah. But taking something more extreme, let's say you had a -- let's call it a dot child sex or something, you might say that that's not something that's just confined to one country. That's -- there's something similar to that in a wide range of countries. And then on that criteria, you'd say no, that TLD is not allowed.

>>AVRI DORIA: Okay. Go ahead.

>>LIZ WILLIAMS: Can I just -- as I say, a lot of these same issues were looked at in some detail in connection with the controversial names, and I think it's very important. I wonder if the language could reflect that predominant here should be freedom of expression, you know, and that that must be very part and parcel of this issue.

And certainly the example that we see coming out of the human rights conventions is that freedom of expression must prevail, subject only to the law, of course. And then, you know, most nation states, of course, have content -- laws that restrict content that incites racial hatred, crime, and so forth. In so far as -- and you've already touched on that.

In so far as we're talking more sort of subjective criteria, there is, as you say, the concern that the nations with the most restrictive approach will drag everybody down.

So I would just sort of urge that, you know, perhaps some consideration should be given to making sure there's a focus on freedom of expression here, because that's your -- you know, it's a balancing act, and that's the way international law deals with it.

>>BRUCE TONKIN: It is.

>>LIZ WILLIAMS: And perhaps as -- I think you touched on this already. There's a criteria for really if we're going to sort of generalize across a number of nations' laws and say, "Well, this is common," that there needs to be a concern that it isn't most restrictive nations, who take the narrowest view of freedom of expression, that drags everybody else down to them, so...

>>BRUCE TONKIN: Yeah, that's right. So the very -- that's kind of why we're trying to use this language of international legal norms and things, so it's avoiding that exact issue. Yeah.

Avri?

>>AVRI DORIA: Yeah. I guess the point that I'd like to add on the dot child sex one -- and, yes, everyone comes up with the pedophilia --

>>BRUCE TONKIN: Yeah.

>>AVRI DORIA: -- is if the child sex is, indeed, not a problem, if that happens to be all the associations from the various countries, they're combating child sex and child slavery throughout the world --

>>BRUCE TONKIN: Yes.

>>AVRI DORIA: -- so there is no intrinsic necessary connection between any particular name and its use, any particular TLD and its use. So dot child sex could, indeed, be a very good TLD for those associations that make fighting child sex their goal.

>>BRUCE TONKIN: Yeah. So then their eligibility would need to be very tight. So in other words, you're saying there are laws against that issue, and then you're saying, you know, to deal with the freedom of -- I don't know whether it is a freedom of expression issue, but using your example, Avri, saying, "This is for the purposes of reporting offenses," or something, that that would then become a very tight criteria. It's effectively not an open TLD. You're contrasting it with, say, the rules for dot com, where anyone can register in it. Yeah.

But that's how you're getting -- basically you're saying we are compliant with the law, so there is law against that, and saying we are compliant with the law because this is a place for reporting crimes, it's not a place for promoting the -- the activity, I guess. Yeah.

>>LIZ WILLIAMS: Bruce, if I could -- oh, sorry, Victoria. Go ahead. I'll go after you.

>>VICTORIA McEVEDY: I'd just add to that. I think that -- justing supporting what Avri said, you know, perhaps the issue -- I mean, there's a question whether this should be dealt with at name level at all, string level, and you could just leave it to content laws, which are already fully effective subject choice of law issues, because in your example, it would depend on the content of the site as to whether or not it was a problem, rather than the string.

>>BRUCE TONKIN: It could, but I -- but I think also there's -- there would be an expectation from the community that ICANN itself is not being seen as promoting things like racial hatred, these various illegal activities.

So I think at least from the board's point of view and contractually, you would need to have something along -- maybe it's just as simple as saying, you know, "You can have this TLD, provided you adhere to content laws," or something like that. Yeah.

But then that's a clear statement that can be made as to, you know, "We've allowed this TLD but it's subject to this -- this condition."

>>LIZ WILLIAMS: Avri, just a quick follow-up question on your good use of strings.

One thing that I would like some more advice from the committee about is the treatment of opposition and the nature of opposition. So if we could just put that as a placeholder.

So, for example, www.childsex. Guaranteed, in an application process, that sting would be contested or be opposed by certain groups. One of the things that we don't have yet enough clarity around is the nature of opposition and how we treat opposition in an evaluation process.

And I raised that point, I think, with the reserved names guys when they were doing their report, and we need to come back to that because the -- for an implementation purpose, we really need some very specific written guidelines about "If you wish to object, these are the grounds on which you object, this is what you do, this is how you do," because that's as much a part of the application process as the applicant applying for whichever name they think is a useful representation of their community.

The other thing that we need to do is to think very seriously about the way in which we provide instructions to applicants through the policy that says a sponsored model of a top-level domain, in the example you've just given, is a very sensitive way of approaching it, but the nature of sponsorship and measuring support for sponsoring an organization is another very critical piece of the puzzle that I don't think is sufficiently resolved -- or it's not sufficiently resolved to my satisfaction, and that's not an -- that's neither here nor there, but I think we need to have a little bit more discussion because it will help Craig enormously in the development of a string contention plan.

>>BRUCE TONKIN: Okay. So other areas here -- and again, I think, you know, from an editorial point of view, taking another example, Recommendation 8, which is about applicants must be able to demonstrate their financial and organizational/operational capability, I think we've had a lot of discussion on that topic and the intent, and the intent mainly being, you know, do you have the ability to meet your obligations effectively to ICANN and to the community as described in the agreement. I think we need some more text there that clarifies that further, because I don't think we've really captured the meaning there yet in the discussion.

>>LIZ WILLIAMS: Bruce, on that, there was a lot of discussion about the appropriateness of it in the NCUC. Victoria, I don't know whether you're on top of Robin's things that she submitted in December, so perhaps if you're doing that in Mawaki's stead, perhaps you could have a look at that. And Avri also was a discusser of that. I need text around that.

>>BRUCE TONKIN: Yes. I'm asking for people to provide text.

>>LIZ WILLIAMS: Yeah. So it's not just -- not just me making it up. People need to justify their positions.

>>BRUCE TONKIN: Yep.

Then the other thing -- there's a few places here. Recommendation 10, which says there must be a base contract to -- provided to applicants again, I'm keen to have an actual example in there, which is sort of, you know, the draft contract as we currently understand it. And again, I don't see that that's a huge task, because we effectively have one that's been, you know, used for -- for the recent newly negotiated TLD agreements, or the renewals, at least. So we pretty much have a framework agreement, and I think we should take that -- that agreement, make any changes that the staff think are necessary, based on what we've got so far, and at least attach it to -- to this report, being very clear that it is draft, but at least I think we need to set expectations as to what that base contract is.

I made the comments before about string contention, having some diagrams around that. So those were all my kind of general comments. But -- so the gist of things is -- I'll just identify some areas that I think need some further work, but it's not just a case of going to Liz and saying, "Hey, go and study some more laws." I think I'm really saying to members of the committee that we should really use our own individual areas of expertise to provide some further text to strengthen the discussion in a number of places in the document.

Before we just close off on this, are there any other comments on the document itself, and format?

Chuck?

>>CHUCK GOMES: A question on Recommendation 13. It's on Page 11. Oh, that's -- that's the old -- I guess it's Page 11. I'm not sure. Anyway, it says, "Applications must initially be saved in rounds until the scale of demand is clear," and there is a reduction to zero of applications for the same string.

I don't understand that last part there: "There's a reduction to zero of applications for the same string."

>>LIZ WILLIAMS: Olaf can speak to that because that was his suggestion for improvements in clarity of the language, on Recommendation 13 on --

[Laughter]

>> Can I make a suggestion?

>>LIZ WILLIAMS: Oh, I'm sorry, I just put him on the spot.

>> Change it to "reduction to one."

>>LIZ WILLIAMS: One.

[Laughter]

>> Thank you.

>>LIZ WILLIAMS: Now, why didn't I pick that out?

>>CHUCK GOMES: But does that mean? I mean, in a round? There's --

>> Zero is round.

>>CHUCK GOMES: No, no, no.

[Laughter]

>>BRUCE TONKIN: I think probably in terms of -- I don't want to kind of debate the individual language, but let's sort of deal with the concept. The concept we're trying to get across is that one of the reasons why we needed to look at applications in rounds was that we also needed to look at contention, both in terms of multiple people wanting exactly the same string, also multiple people wanting strings that are similar to each other, and having a method of dealing with that contention.

But over time, where the -- you know, you're getting one application a week or something like that, and, you know, there's not -- the demand for the most -- let's call it the most popular strings has already been coped with, that it can be dealt with on a sort of first come, first served basis, and that's fairly similar to how most new gTLDs have launched at the second level. They have some process for dealing with the initial rush, and then over time, after that initial rush is over, it then just reverts back to first come, first served. So that's the concept. The language just may not be representing that concept.

>>CHUCK GOMES: How do you measure it, is what I'm getting at.

>>BRUCE TONKIN: Yeah.

>>CHUCK GOMES: So if we have a round and there's no string contention, from then on it's going to be first come, first served? Is that --

>>BRUCE TONKIN: That's -- that wouldn't -- are he talking about a guideline here or a policy?

>>CHUCK GOMES: This is a recommendation.

>>BRUCE TONKIN: Yeah. That's --

My view on it -- it's just a personal view -- is I think we're in rounds, and then, you know, we -- based on the evaluation of those rounds, we'd decide whether to stop having --

>>CHUCK GOMES: Yeah. Which, in other words, maybe you could just drop that last part.

>>BRUCE TONKIN: I'd make it more -- in other words, I'd make it more open, I think, yeah.

>>LIZ WILLIAMS: So then we need to amend the text that says -- that includes a piece on an evaluation.

>>BRUCE TONKIN: So where are you up to?

>>LIZ WILLIAMS: On Recommendation 13.

>>BRUCE TONKIN: You're reading from the actual recommendation text, aren't you?

>>LIZ WILLIAMS: Yeah, on the table.

>>BRUCE TONKIN: I agree with you there. Yeah.

>>LIZ WILLIAMS: Yeah.

>>CHUCK GOMES: I mean you could just --

>>BRUCE TONKIN: Yeah, I think we just need to improve the wording there. It's --

>>CHUCK GOMES: Yeah. Okay.

>>BRUCE TONKIN: Yeah.

>>LIZ WILLIAMS: Yeah.

>>BRUCE TONKIN: So that's an example of something for you to come back, Chuck, and say -- because you're on the committee. You understand what -- the discussions that have gone on as to why we're having rounds. In fact, there's a whole bunch of e-mails, I think, between you and I on this about a year ago. So I think we can just come up with some better language.

>>CHUCK GOMES: Yeah. In fact, you could probably just delete that last clause and it meets what we're talking about. "Application must initially be assessed in rounds," and then -- until the scale of demand is clear.

>>LIZ WILLIAMS: We'll stop at clear.

>>BRUCE TONKIN: Yeah, I think that's right.

>>LIZ WILLIAMS: Thanks.

>>BRUCE TONKIN: Yeah. Mike.

>>MIKE RODENBAUGH: Yeah. I'm admittedly newer to the process than most on the committee, but what does that mean, "until the scale of demand is clear"? What are we looking for there?

>>LIZ WILLIAMS: One of the challenges that we've had is designing a process that is scalable, repeatable, predictable, and becomes normalized. One of the things that we don't have is really good metrics about how many applications, how many there will be, what kind of applications, will they be sponsored, what kind of things will they need for assessment. And if you look at the implementation plan, it assumes a fairly generic list of things that are going to be fairly open, no necessity to say we're only going to assess 25 in the first round or we're only going to accept a hundred applications. So the scale of the demand is an unknown variable in the preparation of the implementation plan.

>>BRUCE TONKIN: Philip?

>>PHILIP SHEPPARD: Just on that point, before I make another one, the -- I'm not sure the edit suggested there is absolutely sufficient on Recommendation 13, if we take out the last clause, because I thought the discussion we had about rounds was actually based on two criteria, one of which was the simple ability of ICANN evaluation staff to handle volume.

>>BRUCE TONKIN: To manage it from a process point of view, yeah.

>>PHILIP SHEPPARD: Yeah. And the second was, what do we do about contention? What are you going to judge contention by definition in a rounds concept?

>>BRUCE TONKIN: Yeah.

>>PHILIP SHEPPARD: So we do need to capture those two concepts.

>>BRUCE TONKIN: Two reasons for doing that, yeah.

>>PHILIP SHEPPARD: And maybe that language is too precise, but I think it goes right in the right direction.

>>BRUCE TONKIN: Yeah. So the reasons need to be captured in the discussion, and then we need to specify the recommendation in clear text.

>>PHILIP SHEPPARD: Yes.

>>BRUCE TONKIN: So I don't think the wording is right.

>>PHILIP SHEPPARD: No. I agree. I think maybe that's a case, there again, where perhaps we have a simple recommendation and an implementation guideline which gives a bit more meat to it.

>>BRUCE TONKIN: Yeah.

>>LIZ WILLIAMS: Okay.

>>PHILIP SHEPPARD: And on that same point, I'm wondering, just to make Liz's life even more difficult, if it was possible in the table of implementation guidelines to have a specific reference back to the recommendation --

>>LIZ WILLIAMS: Ah. Yes.

>>BRUCE TONKIN: Yes.

>>PHILIP SHEPPARD: -- that applies, that would be terribly, terribly handy. I know sometimes it can be a bit more difficult because it may apply to more than one recommendation.

>>LIZ WILLIAMS: No, but it doesn't matter. We can redo the table in a different way and we could even be cleverer. Thank you for making my life difficult, Philip.

What I'll do is, core mission and value, which we want to reference very, very tightly, plus the implementation guideline to the right, plus the recommendation in the middle that says, "Recommendation 2, 3, and 4 relates to implementation guideline da-de-da-de-da."

>>PHILIP SHEPPARD: Yeah.

>>LIZ WILLIAMS: Not hard to do it graphically, and I think it's a good addition, so I'll add that in to the list of tables.

>>BRUCE TONKIN: Yeah, because it -- because the other suggestion I had, and I -- when I looked at this and I made this suggestion to Liz as well, Philip, that in addition to identifying the core values right up front in the document, I think at the recommendation level, we should quote the -- the mission and values that relate to that recommendation. Now, that doesn't need to be in words. It can just be, you know, Nos. 1, 2, 3, and 4, once we've not got numbered. And likewise, for the implementation ones, we can just say, you know, "Implementation Guide," and then, you know, "See Recommendation 3 and 4 that relates to that." So we're just -- so everything is tracked back to a -- to a source point, yeah.

Okay. Other suggestions on the document? Steve?

>>STEVE CROCKER: Yes. We blew past the original set of principles quickly, and I have a thought which relates both to that and to the current discussion.

In looking at the principles that are in the document, as compared to the principles that -- core principles for ICANN that you put up, I didn't see, in the principles listed in the document, any relationship to the noncommercial sort of benefit for various communities and various constituencies. So, for example, yes -- well, let's see.

>>BRUCE TONKIN: Do you want to start with a core value? That's probably the easiest thing.

>>STEVE CROCKER: Yeah. I'm looking --

>>BRUCE TONKIN: Maybe that first one? Hang on, I'll put it on the bigger screen.

>>STEVE CROCKER: Let's see. So you got the core values up there, and there was another slide on core values, I think either before -- well, let's see.

>>BRUCE TONKIN: So that's the mission?

>>STEVE CROCKER: No. Go forward a bit.

>>BRUCE TONKIN: Yep. So this is one on stability, one on innovation, one on --

>>STEVE CROCKER: Yeah. So creativity, innovation, flow of information.

>>BRUCE TONKIN: Yeah.

>>STEVE CROCKER: And on the next slide --

>>BRUCE TONKIN: Oops, sorry.

>>STEVE CROCKER: Oh, functional, geographic, cultural diversity, and so forth. Those I did not see -- those kinds of things I did not see reflected in the half-dozen principles listed in the -- in the document.

And then let me tie that together with the current discussion. The process -- yeah. So these six principles here seem to me very strongly commercially oriented, "Let's sell as many domain names as quickly as possible," with --

>> [inaudible].

>>STEVE CROCKER: Yeah. With a strong focus on the seller's side, if you will, as opposed to user's side.

>>LIZ WILLIAMS: Steve, during the week, I did a piece on posting to the GA list, which actually captured exactly what you've asked for, so I'll just bring it back into the -- and it didn't make its way back into the main part of the document, so I have that text.

>>STEVE CROCKER: Excellent.

>>LIZ WILLIAMS: Which is easy to put back in the right spot.

>>STEVE CROCKER: Excellent. And I obviously haven't followed all of this, so I may be overlooking something.

But I was also struck in the current discussion about your words of a predictable process, repeatable, and trying to size it and so forth. That has a quite good feel to it in terms of an engineering process, but doesn't speak at all to whether or not we have a sense of direction as to where we're trying to go.

Now, one could take the position from a policy point of view that says it's inappropriate for us to have any sense of direction; we should just have a repeatable process and wherever it takes us, that's where we go. But an alternative point of view is, this is the only opportunity to do the architecture, if you will.

Let me liken it to laying out a plan for a city where one has an opportunity to say, "Well, we want a certain shape to the city, we want to promote parks and schools and public functions and so forth," as opposed to, "Our job is to sell off parcels of domain -- parcels of land as rapidly as possible and we simply want an orderly process so that everybody lines up at the window first come, first served and we keep accurate records."

Washington and Los Angeles, two cities I've lived in, are prime examples of the differences in outcomes, depending upon whether you do or do not exercise any plans, for people who have ever visited those cities.

>>BRUCE TONKIN: or whether their plans were right, so...

[Laughter]

>>STEVE CROCKER: Well, Yes. Certainly one cannot do a perfect sort of thing, but there is also major differences in whether one does or doesn't do that sort of planning.

>>BRUCE TONKIN: Yeah. I mean, to use those city analogies, Steve, it's interesting that if I use Los Angeles, that's obviously designed around the car, effectively, whereas -- which has lots of freeways and things like that, but of course it hasn't scaled particularly well. And then other cities are sort of based around, you know, being highly compact, go up high, and have public transport that gets you around, so that they are both types of plans; they're just different.

>>STEVE CROCKER: Yeah. There are some other things going on. Anyway, that's --

>>BRUCE TONKIN: No, I like your analogy.

>>STEVE CROCKER: We get off into the thing.

>>BRUCE TONKIN: Yeah.

>>STEVE CROCKER: But, for example, just to take the bank analogy, what do we do if a company shows up and says, "I'm here to buy dot bank and I represent, you know, the Bank of Nowhereville and I want this and I'm prepared to pay my fee and I'm first in line"? Is there an opportunity or an anticipation that we're going to say, "Well, you know, that name probably is better used, if ever, for the banking community as a whole, and if they're not ready, we'll hold it in reserve"?

I'm not suggesting, necessarily, that that's the right decision, but I am suggesting that that class of discussion takes place now or never, and --

>>BRUCE TONKIN: Yeah.

>>STEVE CROCKER: -- if you don't do it now, then that opportunity gets lost.

>>BRUCE TONKIN: So that one actually is in the report, and so the way that's handled, Steve, is that a -- there's an objection process. So basically all the strings are published. So taking the bank example -- and that's from the Bank of Nowhereville or whatever -- ICANN publishes that this private entity wants to run the Bank of Nowhereville. There's an objection process where the -- the banking institutions could say, "No, we don't like that," and that would stop that TLD being applied for. Effectively, I guess it effectively parks it, and then there would then need to be a process to sort of get it live again at that point.

>>STEVE CROCKER: That's helpful.

>>BRUCE TONKIN: Yeah.

>>STEVE CROCKER: Let me just observe that's a reactive process, as opposed to a proactive process.

>>BRUCE TONKIN: Yeah. So the proactive process, then, Steve, is in explaining the process very clearly up front, because we've had this discussion as well, and that is that in the way we convey the -- the RFP in the application round, we're making it very clear and we're trying to do this diagrammatically, is basically what's going to happen if you attempt to do that. And there's a series of steps it goes through, and it becomes very expensive, basically.

So for something like that to get up it's saying, "Okay, because you've gone for dot bank, it's going to go through this process time line and you're going to have to pay more at each step and it's not going to be a simple path."

So you're trying to educate, I guess, as being the approach to it, to educate the applicants on the implications of what TLDs they go for, and that's why we're sort of pushing for examples. So on the technical ones, you know, the view could well be applicants sort of think, "Wait, you know, I'll create a dot exe. I can do all sorts of fantastic things with that." And we're saying, "Well, one of the tests we'll be applying is, will have that have a technical instability issue? Here's some examples of those." And the staff could also give advice to people very early on when someone approaches the staff and says, "Hey, we're thinking of having dot exe," and you say, "Well, I reckon that's probably going to fit into this criteria."

Did you get shocked?

>> Yeah.

>>MARILYN CADE: Can I get into this discussion before you close it out, please.

>>BRUCE TONKIN: : Sure.

>>MARILYN CADE: : Actually, it is a question I wanted to raise again because it is something that has really been on my mind recently and I'm glad that Steve Crocker is here -- sorry, it is Marilyn Cade speaking for the record.

That is the original purpose of creating the unique identifiers was about creating -- about creating a Web site address, right?

>>BRUCE TONKIN: : It was initially.

>>MARILYN CADE: : Guys, let me say this differently then. But the purpose of having a domain name and operating a registry -- let me go back to that, I think there is something here that I am sort of grappling with and that is, what is -- we talked about this. We went around the last time and talked about why are we introducing new gTLDs and we came up with a set of purposes for which we are introducing --

>>BRUCE TONKIN: : (inaudible).

>>MARILYN CADE: : Right. I think Steve is it asked a related question and I wanted to engage him a bit in that discussion.

Is it sufficient or is it the right reason to allocate a string to a single entity or is, in fact, should there be some common good, some public interest to the expansion of the space. Is there something inherent, so to speak, in the role that ICANN plays in allocating what is a managed resource. Whether it is a scarce resource or not, it is a managed resource.

Therefore, is there, in fact, some concept of operating in the public trust that most of us who founded ICANN believe very strongly in.

Some of us might think not everyone fully agrees with that but the missions and core values still support that.

Is there something to what we're doing that has this concept of public -- a limited public trust in the public interest. It has been an conversation that Avri and others have contributed to and I believe Tony Harris has contributed to as well.

I am wondering if we are capturing that underlying -- it is not that people can't make money, but should this --

>>BRUCE TONKIN: : The thing, I suppose, is to try to capture that from the mission and values and identify which one it is.

>>MARILYN CADE: : Right.

>>BRUCE TONKIN: : That's why I was saying let's go back and add those in and make sure our text is consistent with those.

But to answer Steve's particular thing that he was raising, in the discussion as opposed to the in the recommendations, one of the reasons -- because there is a number of different reasons a number of different people have put forward. One of the reasons was to accommodate both new ASCII and internationalized domain names to give users more choice about the nature of their presence on the internet.

In addition, users will be able to communicate in their language of choice and in a way that meets their community needs. That was kind of where some of those public benefit concepts have been captured so far.

What I'd prefer to do is to capture them using the language we already have around ICANN itself, if we can, and I think the one that's probably -- the thing is if I look at the core value that I have got up there now, it is talking more about participation as opposed to outcomes and maybe the core value itself is not very well articulated.

There it is saying we have participation from all these people and it doesn't explicitly say that what we are trying to do is an objective in terms of change is to make the Internet more usable by those people. That's not captured in the values at the moment.

This is more capturing a policy development process guideline. It is saying in policy development process we should have all these people involved. But there is not a guideline that says what's ICANN's strategy mission and what's its goal. I don't think that's captured in the bylaws at the moment.

>> : : I think what you've just said is more coherent and cogent than what I was saying before and I agree that's exactly where I would like to see some explicit attention (that was Steve Crocker).

>>BRUCE TONKIN: : If you want to suggest text, Steve, go ahead.

>>STEVE CROCKER: : I like what you said. Somebody else can capture that. I just wanted to stir that point for a minute. Thank you.

>>MIKE RODENBAUGH: : I don't I don't want to spend the rest of the morning debating policy items. So, again, editorial comments, to make the report better, what more content do we have in it? Go ahead, Mike.

>> MIKE RODENBAUGH: I do have various wording suggestions I gave to Liz. In the principal and in the recommendations, there is no specific mention about minimizing the so-called need for defensive -- or basically minimizing defensive and abusive registrations. I feel like that should be in here somewhere. I could read it into recommendation number 12, but I think it is not exactly intended for that or at least it is not clear. Rather than debating where it should go, I just would, I guess, lying to know if there was any opposition to the notion it should go in here as a principle and a recommendation and then we can put it in later.

>>BRUCE TONKIN: : I think the thing is try to capture in terms of perhaps the protecting rights of others working group and if the working group come up with some text and suggestion of where it should be go. I rather specify it more generally so it doesn't look like just trademarks because it is a more general concept about rights of others so you are not creating a process where to protect your rights you suddenly have to register all your names in the space, whatever those rights are.

>>MIKE RODENBAUGH: I guess that's sort of a general comment, is capturing a time before the PRO working group has gotten underway, so we need to account for that. Thanks.

>> PHILLIP SHEPPARD: Perhaps you are right in broadening that. The general concept is, to my mind -- hope all agree -- to avoiding bad faith. A mechanism would be what may be what Mike is talking about. But the guys who suffer are Internet users in this case, and that's also the bigger party that we need to try to protect.

>>BRUCE TONKIN: : What have we got about rights about others in here at the moment? That's recommendation three, I guess.

>>LIZ WILLIAMS: There is also placeholder text which Kristina and I have talked about on the list that will need to be completed.

>>BRUCE TONKIN: : Suggestions on where to put it and certainly the PRO group is due to finish in mid May. Is that about right?

>> We expect to have a first draft, I believe we said, April 21st. We will have something at that point.

>>BRUCE TONKIN: : At that point we will look at how incorporate that. Yeah, that would be good.

Any other comments? Steve?

>>STEVE CROCKER: I want to echo the concern about defensive registrations. I think that's an important point. More generally, with respect to outcomes, it would be interesting to measure at the end of the day whether or not we've created more problems or whether we've actually solved anything when we add more gTLDs and can we anticipate by evaluating our processes upfront what direction we're likely to head.

Let me raise the stakes yet another level. The discussions have generally all been around a -- to borrow some words, a orderly metered process, if you will. So many gTLDs over some period of time partly to stay within the resources that are available, partly to measure the process, from a marketing point of view, from an economic analysis point of view, I suspect that if one opened up the registration process for a much broader mass process of some sort, that the end point would be very different from the end point of a metered process that runs for a very long period of time.

Let's say you have two paths, both of which are going to get you, just for the sake of argument, 10,000 new top-level domains. One process is you open the gates and get there within some number of months. And the other process is you open a path that is very careful and you have 100 per year for 100 years. At the end of the 100 years, you have 10,000 new domains. I think the shapes of those two markets would be vastly different.

>>BRUCE TONKIN: : One of the things -- I like the first word you said which was around measures of success. One of the things I think in the round of 2000 is we never clearly established upfront how we'd measure whether that round was successful or not. One of the measures of success at a very superficial level is how many registrations have we got in each of those new TLDs. One of the counter arguments is if it is mostly defensive registrations, then it is the same domain name owner that happens to have that name across a number of spaces. You haven't really increased the utility, the Internet potential for something like that.

>>STEVE CROCKER: : Exactly. Or closely related, if the measure of success is large numbers of registrations, then, for example, my friend Cary here who runs dot museum was always destined for utter failure by any of those standards. And, yet, a contrary view is there is a small jewel for which it was important and is a good example of a use of a TLD for a purpose that cannot rationally be measured in terms of mass numbers but clearly has some or kind of value.

>>BRUCE TONKIN: : So I think it is worthwhile in this report. One of the things I guess I haven't done yet and I think it is fair enough we haven't done it because we are focusing on getting the processes and things right. One of the things we did with the transfers, we actually built in a review process.

Now, we haven't actually used that probably so that's another kind of GNSO reform issue probably.

But, generally, at the time of that transfers report, I put in there at that time that we should review the outcome of that work so that we originally put three-month intervals and the staff used some measures for whether that new transfers policy was successful and then we'd update the policy.

The reality is that because everyone is focused on these new topics like new gTLDs that transfers hasn't really had the attention that it needed.

Regardless of that, the concept was still right, I think, that we built in a process of evaluation into the policy as well. So we have got some specific points in time evaluating whether or not the policy was successful and we also identify, as Steve says, what are some of the measures of success. What does success mean in terms of the policy? Did we get it right or wrong? How would you even be able to measure that right now?

I think that's something that would be useful to put in the document in a separate section, I think, which is, I guess, about the review process, I guess, and how we would measure success and have a bit of discussion about that upfront. What I have seen happen with the 2,000 round, we tried to invent that after we had already done it and we should work out what we are going to measure.

>>MARILYN CADE: : Bruce, I might try to tie together a point Chuck was making. It is Marilyn speaking. And the idea of the review process. The issue of just cloning the name space where basically all that happens is famous and well-known grand holders or others feel compelled to buy defensive registrations. They don't use them, but they buy defensive registrations in a very limited sense. In some cases, some do use them. But for the most part, of the 600 or so domain names that AT&T holds, they are low in the instance compared to others who just do defensive registrations as a practice. That's not their philosophy. They recover names.

But the cloning of space does not expand the space. It does put money in the pockets of registries and registrars but it doesn't help users.

I think one point that was being made earlier is, you know, really we are trying to expand the space not because our job is to create commercial opportunities for registries and registrars. That's a side product, a good one, but that's not the purpose of expanding the space.

One of the measures, I think, ought to be is, in fact, used space or is it just cloned space? Just to a point, I agree that there may be a number of jewel registries that could be -- perhaps there is an extremely high value to having a number of registries that never have more than 1,500 or 5,000 registrations.

We need to think about that and what it means if there is a huge number like that.

There are lots of ccTLD registries that are at 5,000 or 10,000, and their goal is to be at 100,000 or a million and they think because of the size of their population that that will be -- that that's the optimum growth. I don't think we need to be thinking it's always 87 million per registry. But the issue of is it actually used space and usable space and not just defensive space, I think, has got to be one of our measurements.

>> : : Can I just ask a clarifying question there. What I'm hearing is there is two elements to the evaluation of the process. One is the evaluation of the success or otherwise, however you define it, of the string of the applicant. The other is actually an evaluation of the process itself. It is two very, very separate things. On the one hand, there is some objective measures that we can put in place but I need to capture that. So is that what the group intends?

>>BRUCE TONKIN: : There are two different things, yes. You could -- I think we might have already captured the concept of reviewing the process and things like processes, rounds, those sorts of things. I think what Steve and Marilyn is pointing ought about reviewing the outcomes from an ICANN policy point of view, what are we trying to achieve as ICANN. We trying to create cultural diversity and geographic representation. Let's put some measures to see whether we achieve that.

If we just go -- let's say we add Chinese names or something. Is it then just more people in the U.S. registering those names for defensive purposes or have we really got a whole bunch of people in China using them?

Mike? I should go back to this queue, sorry. I have got Mike Palage, Tony Harris. Let me just capture who else wanted to speak. I have Mike Rodenbaugh, Kristina.

>> And Philip.

>> And Susan.

>>BRUCE TONKIN: : Mike.

>> MICHAEL PALAGE: Thank you, Bruce. My comments go to recommendation number 20 which talks about the registries' use of ICANN accredited registrars. The basis of this particular principle or this recommendation is based upon the premise that it is needed to facilitate the stable and secure operation of the DNS. I think right now as you and, I think, Tom are aware there are extensive discussions on the registrar list regarding this topic in connection with the dot museum sTLD contract that is up for consideration at this time.

I strongly believe that registrars have served a very important part in the evolution of the name space. They've lowered prices. They've provided innovation. I think they are very important for enhancing competitions.

I guess my concern, though, is although I believe there should all be a strong presumption in favor of using registrars in gTLDs in the future, since we don't know what the particular business models of all of the registries yet to come to happen, I think there needs to be an ability for a registry to demonstrate they can provide secure and stable operations of the DNS and that their particular registry would not benefit by using ICANN accredited registrars.

Just to use two examples. Dot edu, this is a zone which has about 70,000 names that serves the educational community. Right now that backend is provided by VeriSign through a contract that has been executed by, I believe, Educause. Chuck, correct me if I am wrong. On that. In that scenario, they do no use any type of registrars. It is more, if you will, the registrants go directly to the administrator Educause which, then, if you will, make the changes in the database. There is also dot INT which has less than 1,000 registrations which ICANN currently administers and again they don't use ICANN accredited registrars.

I think it is important with regard to recommendation 20 that there be some acknowledgement that there could be the potential for a business case in which the registry operator might be able to demonstrate the ability to not have to use registrars. Again, I just say -- I am in favor of a very strong presumption with a high hurdle, but an absolute mandate, I think, is, in fact, not prudent because we don't know what type of business models might be coming forward in the future rounds.

>>BRUCE TONKIN: : Tony Harris.

>>TONY HARRIS: Getting back to the point that Mike Rodenbaugh made about defensive registration. I think that's a very important point, Mike. I have a few comments on that. I would say I think sponsored TLDs was one way of minimizing that because I don't think anyone can do a defensive registration in dot coop and dot museum. Some of those strings are really -- there is no risk there for a famous name.

And we have to realize that any place somebody who wants to do damage can get a domain name is going to set up a site, the site is going to be a red zone site. It is going to have a famous name which he will register, and then he will hold you up for ransom.

Really, considering the cost of -- per year of a registration, famous names of big companies would be foolish not to do defensive registrations on any string that comes up, in my modest opinion.

Another thing I think is getting to the validity and actual justification for a company to register several domains, there are companies and entities that may need to project more than one identity or one more target -- more than one target market, perhaps.

That's just a couple comments on that.

>> Thank you, Tony.

Mike?

>> MIKE RODENBAUGH: Thanks, Tony. Just following up on that, it is absolutely true. I use the example of Yahoo because I happen to work for them but certainly we have Yahoo.jobs and Yahoo.travel. We don't have Yahoo.museum, but in most domain spaces certainly were relevant.

I would just also like to add, maybe to principle 3, the notion of market differentiation because I think we've discussed that quite a bit. And it seems to me that fits in to the reasons why we want new TLDs. And the only other comment I would make is as to -- in terms of reference 1-6E which says essentially there is no compelling reason not to allow new TLDs. The one compelling reason that I see is the fact that they will not be differentiated and, in fact, they will cause a, quote, need for defensive registrations.

>> Mike, can I just ask you a clarifying question on principle 3? What might be better because it was quite a lot of discussion around the construction of that phrasing. If you wish, I can put some market differentiation text in the explanation for why the committee uses it, at the end, rather than amending the principle. I think the terminology and the reason for market differentiation is important but it also comes into the five reasons you just enumerated, the baskets of things we talked about in Los Angeles.

I can put that further down there rather than amend the text of the principle where it is not explicit enough for you obviously.

>> Personally, I think it is important to put it into the principle. I think the reason we want new TLDs is essentially to differentiate the name space that we currently have.

>> You and I can work later on to improving it to capture what you want, thanks.

>> Thanks, Mike. Kristina?

>>KRISTINA ROSETTE: : I just wanted to respond to those who have raised concerns about defensive registrations. One of the things that the PRO working group is planning to do is to seek informally input from the constituencies and their member groups and, in particular, one of the quantitative measures we're hoping to get back is information as to what extent companies are and corporations and entities are seeking defensive registrations. To the extent they have, are there certain TLDs that for reasons of the limited eligibility that they have decided that there is no reason for those and the like.

So I am expecting to have data on that. Given the time frame we are working on, it might not be to the same extent that we might otherwise have with a longer lead-in. But I do expect we will have some data. But I actually did have some other editorial questions that I wanted to just touch on very quickly.

And that is, I know that there was discussion earlier about incorporating the text or the principles in recommendation 14C elsewhere. I wanted to make sure I understand where that would go.

As it is set ought, you read it A, B and C and C and did are mutually exclusively.

>> : : Sorry. That is a last-minute thing. And in the next version of the report, if you have specific things, explanations that you want to give me for that, I'm sorry, it was a last-minute piece and I wanted to include it but I did not have time to write the text to given everyone the time to read in the report. That's the explanation. Sorry about that.

>>KRISTINA ROSETTE: : No, no, no, that's fine. Later on, in, I believe it is actually if we are talking about the implementation guidelines -- are we still just talking solely on recommendations?

>>BRUCE TONKIN: : What we are talking about is the report in general, what are the general things you want to see improved when it comes to specific language. I will not debate that it there. Just send them straight to Liz.

>>KRISTINA ROSETTE: : With regard to -- now I am not finding it. In the discussion relating to term of reference 3, and in particular recommendation 14 discussion, I am a little unclear as to where at the end of the day once you get through -- and if I guess 3 through 6, is the report taking position on auctions or is it seeking comment? I couldn't really get a clear sense as to what exactly --

>>BRUCE TONKIN: : I agree. Let's deal with that tomorrow. What I want to do is, I don't think we have it captured properly and I don't think it captured all the detail of the discussions. It is kind of a time thing. My thing looking at this is that Liz has put a lot of effort into the string criteria and getting all that up to date and just run ought of time.

>> : : Part of the issue, is the group -- we had discussion about auctions and other string contention -- resolution of string contention and a number of us are writing a book on what we can do. "Pistols at dawn" is not acceptable. "Coin Toss" might be. "Auctions" might be. It has to happen quick. It determines how we prepare the final recommendations, of course, and then it flows directly into the implementation plan. So I would urge you to complete that discussion tomorrow.

And if you wish, I can send you around the very slim little paper that I sent at the L.A. meeting about auctions and their user utility. There is plenty of that there. But we need to have a structured discussion about where you want to go with that.

>>BRUCE TONKIN: : I thought the discussion was complete after L.A. so that's where we have a difference of view.

>> I'm happy to represent -- if the group thinks they are finished then we need to improve the text as it stands. That's the tissue.

>>BRUCE TONKIN: : Exactly. To do that, I think the first step is to get a diagram to recapture the process and make sure we agree at that level and improve the text around it. That's what I want to deal with in tomorrow's session.

Susan?

>>SUSAN CRAWFORD: : Thanks. I want to allowed Bruce to point back to the principles that underlie ICANN's operation. I think the principles as drafted in the draft report are very well stated, so I want to support them. ICANN after all represents the global Internet community. That's our job here.

We really can't predict -- we can't pretend to predict in advance what the benefit of any particular string will be.

I hear Marilyn's statement that this is a managed process. It has been historically, but the scarcity that we seem to have in our minds about the TLD space is entirely artificial.

There are really two models of communications. You can in mind the idea of a newspaper or the idea of a broadcast spectrum. Spectrum traditionally has been managed as a public resource and managed to scarcity and that isn't what I think Marilyn and others had in mind.

The TLD space could also -- you could have in your mind the mental model of a newspaper and nobody has been in charge of newspapers. They are free to find their markets, free to speak to whoever wants to listen to them. This is not to say that we don't need to manage this process. We do because of limited resources within ICANN.

Of course, we do. And metered process makes a lot of sense. But the gatekeeper role here is artificial and we should be careful. In this room there are people who have expressed particular points of view about gTLDs for years but our role is to think about the greater global Internet community and not just to remember our particular constituencies' needs. I do think that the defensive registration problem, perhaps, paradoxically to people here who worry about it may be watered down by the addition of new TLDs, that as the TLD space becomes more like the world, the need to register every famous name and every TLD will be reduced. The market will differentiate itself as it does in real space.

This is a very complex world. And we have -- we should be very humble about our role here in managing things.

So principles of ICANN support the introduction of competition on every level. I want to support the idea of perhaps diversity in business models for recommendation 20 if we're working on that to allow different registries to experiment.

There is a lot of experimentation in the cc space with how they work with resellers and registrars. I would like for us to take advantage of that for new gTLDs.

Just a brief comment. I think we need to be humbled. I think metered is fine. I appreciate pointing back constantly to ICANN's core values and applaud the job that Bruce is doing here. Thanks.

>>BRUCE TONKIN: : Thank you, Susan.

We have Philip Sheppard.

>>PHILLIP SHEPPARD: Bruce, thank you. I just wanted to go back to the discussion we had about measurement of success and I wonder if we're asking under recommendation 8, that applicants must be able to demonstrate financial and organizational capability. The one thing that might help ICANN in terms of measured success is if you were to ask in the application process the question of the applicant, what is your measure of success for the TLD because that would then cumulatively be billed to an assessment, whether or not there has been success with those individual applications.

So that would be my first suggestion, an implementation guideline would be a specific request in the application process to ask for measured success for the applicant themselves so they would assess that themselves in whatever way would suit their market or idea.

>>BRUCE TONKIN: Let me get that cleared. You are saying as part of the application process --

>>PHILIP SHEPPARD: : It wouldn't a criteria. It would simply b saying, fine, you are applying with a gTLD but tell us, by the way, what would be your measure of success? I think that's a reasonable question.

>> So let's get clear what you mean because I think it is a good suggestion. Do you mean at the end of their application form did you read this, like filling in the U.S. immigration from. Two minutes for collecting the information, three minutes for understanding it. Did it work for you or they (multiple speakers).

>>PHILIP SHEPPARD: : Measured success of their TLD.

>> They self-select and they state what they think their success is or the Galatian community has their own name and it is all for free and it is beautiful.

>>PHILIP SHEPPARD: : Our measure of success is --

>> 50 million names.

>>PHILIP SHEPPARD: : -- we put dot com out of business in two years.

>>LIZ WILLIAMS: Watch out, Chuck is beside you.

>>PHILIP SHEPPARD: I was looking the other way. Or my measured success is I captured 80% of my niche market for that particular community I am going after.

>>LIZ WILLIAMS: That fits into things that demonstrate their operational capability to run a registry and they are being quite self-aware and self-critical about what they think they are doing.

>>PHILIP SHEPPARD: : I think this would be very useful information, of course -- if we are saying we want to ourselves make an assessment subsequently of what has been the measure of success of this whole process. I think you need that basic information.

>>BRUCE TONKIN: : I think we need to specify, as Steve Crocker has suggested, some overall objectives and some measure whether we met those overall objectives. That's one thing.

An individual TLD level, I am trying to understand where you are going with that. I think suggestive measures of success I think would be useful as input into that evaluation. You are not talking about doing it contractually, that they contractually go through some review?

>>PHILIP SHEPPARD: : It would not be a basis for making an award --

>>BRUCE TONKIN: : A decision. You are saying we collect that information, like collecting a name and address, we are collecting some other information which we then use in the review process.

>>PHILIP SHEPPARD: : Yep, yep. The second point I had just followed on from Mike Palage's comments that stems from recommendation 20. I think the point he is making perhaps needs to be split into two because one thing, of course, is the existing policy with is a separation of registry and registrar. And the second, to my mind, is if you then say this should always be used for accredited registrars.

Now, to my mind there may be more debate going forward over the first of those about separation, historically, it was for very good reasons, competition.

The second of those in terms of accreditation process of registrars, regardless out how pathetic our current process is, is something that, I think, is worthwhile. And I think those two points, I think, are separate.

>>BRUCE TONKIN: : Okay. Chuck?

>>CHUCK GOMES: I would like to follow up on both Phillip's comments there. I think his idea of asking applicants to define what they believe are the measures of success for them are very practical and valuable idea. It will be very hard for us to apply criteria to all business models. That doesn't mean we shouldn't try. I am not suggesting that, but they should be very well prepared to define what they think is success and communicating that in their application, not that they are going to be measured in that other than the fact that we asked them for that data and they supply it, I think that's a very simple thing to do and one that could be very useful going forward. It doesn't mean we have to limit ourselves to what they have to say, but I think it is useful.

With regard to the requirement for registries to use ICANN accredited registrars, I wanted to communicate to the group that in a meeting about the registrars ExCom and some registries on Thursday morning over breakfast we are going to talk about that idea, just between registries and registrars to explore that.

Because there are a lot of new people in the new meeting here let me be very, very clear that the registries' issue has never been for larger TLDs not to use ICANN accredited registrars. There are some special circumstances and in some business models of smaller registries that create some unique situations.

It is very important that people remember that.

VeriSign is not trying not to use ICANN accredited registrars. Please understand that. There are some special needs and we want to -- we want to talk about that. So we are going to talk about it with registrars.

And one of the issues -- and this has been on the registrars' list in the last day or so is that our agreements as registries don't allow us to be a registrar and, yet, when we talked about this almost a year ago in this group, when I raise the issue, the response was you can just become a registrar. We can't.

By "we" I don't mean me, VeriSign or the larger registries but, rather -- so we're working it maybe with the registrars on Thursday we will come back with some information that will be helpful.

>>BRUCE TONKIN: : Thanks, Chuck. Mike?

>> Actually, I am going to go off on two other subjects very briefly. If (inaudible) wants to address this, I am glad to let him go ahead.

On principle number 2 on IDNs, I think the word should be "should be" that we -- some new gTLDs should be IDNs rather than -- if anyone has an issue with that, then let's hear it.

My other point is actually a question about implementation guideline number 11 and perhaps The reason is we don't really have much explanation for the implementation guidelines as set out and we will -- I am sure we will. It says ICANN should take a consistent approach to the establishment of registry fees. I'm just frankly not clear what that means.

>> Consistent meaning appropriate to the size of the business model, yeah? Kurt is here. We were talking about that in Amsterdam when we talked about registry fees. So we can -- the implementation guidelines are designed -- will have text around them to explain them and to explain why they are written in a particular it way. Sometimes some of the implementation guidelines are pseudo recommendations that didn't have get enough majority support because the recommendations that are from one to 20 including the ABs in the middle are things that seem to have majority support of the group. The implementation guidelines from the NCUC was included in the original text, did not have the majority support straw poll kind of thing so it was moot in the implementation guidelines. If you want more clarity around the text, that would be helpful, especially on something as important as fees.

You knew about that because of the work on the Feb '06 thing, which was a very large piece of work on the February '06 PDP thing.

>>BRUCE TONKIN: If there are majority support, things coming out of the Feb '06, whether we use similar wording. I think the way I would answer that there are two approaches here. It can be a commercial negotiation between ICANN and the registry operator to how much ICANN thinks it can make out of that particular registry operator. That's one approach.

Or there is some published approach as to how the fees would be specified. A registry that has five registrations, for example, may pay maybe a lump sum. They pay ICANN $10,000 a year because they have five registrations.

Whereas, a registry that expects to have 200 million registrations, they are more likely to say, We want a per registration fee. We think we should be paying as much as 100,000 to ICANN. Divide 100,000 by the 200 million registrations and that's how much we pay.

Obviously, different models but I think the concept behind the discussions when we talked about this item was that ICANN has a published method for setting the fees for the applicant and that's published prior to entering into this process.

Because obviously it is going to affect you quite substantially if you find that I have just got this business model where I was hoping to give 200 million registrations away for free. ICANN says after the fact we will change it to $100 per registration. You need to know that upfront in a consistent way. That's the intent behind that.

Werner and I think we --

>>WERNER STAUB: I have one small and one bigger thing. The small one is about recommendation 8 and 9. I believe it would be good to work them in the context of the TLD applied for not in the absolute fashion. That is, at the end for the purpose of the TLD applied for, when we talk about financial and organization capability or technical capability because it is not quite the same depending on the TLD that is being contemplated.

>>BRUCE TONKIN: Say that again, Werner, I missed that.

>>WERNER STAUB: For recommendations 8 and 9 which are about organizational capability -- sorry, 7 and 8, technical capability to add the phrase for the purpose of the TLD applied for. This is not the same depending on the TLD.

Let me also address the question of differentiation in terms of less than the developed economies because, of course, it should be seen in the content of the specific TLD applied for.

The other thing I wanted to go back to briefly what Steve explained about the merits of the metered process.

I think he was absolutely right. There should be some method of actually gaging appropriate timing to the applications.

However, if this is done with the concept of what is called of what is called numerous clauses, in Europe, which, as we say, we have so many applications per unit of time that may be submitted, what we actually do is we create competition that should not exist.

We create competition because cobblers and bakers or blacksmiths against whatever, butchers or something, people who should not compete against one another.

If a TLD is about dot bank and another one is about dot museum, they quite frankly have nothing to do -- they should not keep against one another for a slot in the application phase.

The numerous clauses concept, which is something we had in 2000, where we people who had nothing to do with one another, we basically -- they were actually pushed into antagonism against one another. This is very, very unfortunate and something we should not have.

On the other hand, if we give people incredible ways to put in their application when they should, then they will probably do so because actually launching a TLD is quite a bit of work which is why I come back to the, first of all, puny vocabulary problem. Let's rather use the word "cycle" than the word "round." A round has a problem that you do not know whether or when the next round comes.

A cycle implies this runs at the regular pace. And these people know that they can submit applications in the next cycle, which they probably have good reason to do so then they will consider this.

However, if you say these are rounds and we will possible repeat it but you don't know when, everybody will be in the position where we have to say we have no other possibility to send it now because after that, who knows what's going to happen. Look at the track record that we've had up to now. It takes four years. Now it is increasing the timing between launches.

>>BRUCE TONKIN: Let me just comment on semantics between "round" and will "cycle." Because you can have a "regular cycle" and "irregular cycle." You are basically talking about regular rounds. In fact, what you are talking about there is a schedule. We are trying to capture that in the implementation guidelines. I think you have made that point before and I think we need to capture it in the implementation process that he we are announcing here is the schedule, here is the dates. Just like the ICANN meetings move around a little bit but pretty much there is a schedule out to did 2012 probably.

>>WERNER STAUB: Indeed. It did he designed at least in the way that the initial start date is announced with four-month waiting period, actually we don't just announce one starting date. We announce two of them, the sub is he consequent one also.

>>BRUCE TONKIN: That sequence is subject to change. The point you are making if people can see it is a sequence and it is roughly six-month intervals, whether it happens on July or August in a particular year doesn't really matter.

Okay. Olive? Sorry, Victoria?

>>VICTORIA McEVEDY: I am sorry to take you back. you may have already covered this. I am wondering if Liz can help with recommendation 14C and how that's supposed to relate to recommendation 6 which I spoke about earlier about my freedom of expression concerns regarding morality and public order.

>>LIZ WILLIAMS: Obviously, there is a concern there that one section of our community can suppress any application and, therefore, suppress someone else's freedom right to express themselves if it is a different view. I am wondering if that's supposed to be the procedure before that recommendation.

>>LIZ WILLIAMS: One of the great challenges that I have had is thinking about opposition, whether it is opposition from our government or opposition from a ticked off other applicant who didn't get their application in on time or whether it was from an aggrieved party that can send 50 million e-mails to their local congressman.

We need to think about not just contention between application but there is also opposition to it. From a staff evaluation point of view, what will we do with that opposition? Within 14C, we need to think seriously about it. We need to think seriously about the nature of opposition and what it means in the string contention process because there has to be some language around that and we don't have it yet.

>>VICTORIA McEVEDY: I guess the constituencies' position would probably be the opposition would need to be based in law. I don't know whether language --

>>LIZ WILLIAMS: Send me the words.

>>BRUCE TONKIN: That's not quite actually the intent. Maybe talk to you a bit off line, Victoria, explain it is not in the right in this document. It needs to be part of the applicant criteria. The concept, it is established institutions. It is not related to -- let's say it was, gay, right. It is not related to whether some group doesn't like gay because they are the opposite of that, right? It is basically saying that someone wants gay and we the group that represents all the gay people in the world, if such things exist, it is a different thing. It is not related to recommendation 6 in any sense.

It is purely related to -- the example we were discussing is the bank is the example, not the morality issue. If it is a bank and there is established institutions around that, that's what 14C is relating to.

>>VICTORIA McEVEDY: Will any of these recommendations then apply to sex? Any of 14, the 14 --

>>BRUCE TONKIN: No. Six is purely a string criteria, whereas the other sections are related to the two separate things. The 14C is effectively -- would come after 8. It is related is that applicant the appropriate applicant to run that institution or TLD. Examples are bank, police, government. They are constitutional names.

Whereas, the other parts of 14 are related to if two people apply for the same name, how would you resolve those. So they have already passed the string check.

You are already allowed to have the TLD.

>>VICTORIA McEVEDY: Thank you.

>> Bruce, would you put me in the queue.

>>BRUCE TONKIN: Olof, you have had a comment?

>>OLOF NORDLING: thanks. I have tried to make some recommendation out of 13 and I fail. I see what is probably the initial statement, it must be -- the application must initially be assessed in rounds until the scale of the amount is clear. I think there should be a full stop after that.

>>BRUCE TONKIN: We went through this.

>>OLOF NORDLING: The second is either a snippet from 14 or each round continues until there are no applications left or zero applications for the same round.

>>BRUCE TONKIN: Don't worry about it. We are going to reword it. We have already discussed that wording is not optimal.

Marilyn?

>>MARILYN CADE: My question is generally related to the question of the contested issue being about a country name, a geographic name, a name -- 14C is about cultural language community economic sector, I am losing track of where we addressed the idea that the contention --

>>BRUCE TONKIN: 14C is not about contention. Forget 14C for a second.

>>MARILYN CADE: I understand. Let me just ask my question differently then. The question is right now in the reserve name category -- and I think we'll see in our discussion with the GAC perspectives about the fact that certain names such as the name of a country -- and I will use China as an example where the country has laws that establish who can use the name of the country and under what circumstances. South Africa does as well. Not a lot of countries but some do.

Where do we capture the idea that the -- there will be -- is that expected to be in a dispute, someone raising a dispute?

>>BRUCE TONKIN: If I could take the floor, this is questions of clarity to understand what you are asking. Are you saying if it is a reserved word, is there a way of getting it off? Is that the essence of your question?

>>MARILYN CADE: It is actually a reserved category, I hope. We have yet to see if it is a reserved category. I hope it will be a reserved category as opposed to a specific word.

>>BRUCE TONKIN: Let me just -- because this is where -- it is not in the report because I don't think we have come to any views on this. You are saying if there was a reserved word related to a country name, is there a mechanism for that country to then use it?

>>MARILYN CADE: Or for that country to give permission to allow a name to be released. So I think there is a real example in the consideration of geo cities names where everybody is very aware that there may be or will be a number of applications. There are some countries who will have a position about whether or not city name can be released to anyone other than a governmental Constitution. There will be other governments who have other philosophies.

But the category won't have a one-size-fits-all answer. That may be true of regional names as well where some people say I am a region, the ACN region and others say only the U.N. regions are regions.

>>BRUCE TONKIN: Yeah. It is not captured in the report because I don't really think we've had a detailed discussion about geographic names. If the geographic name was a reserved word like you can't have it at all, there is a mechanism for it. The other area where this overlaps is what's going on with the ccNSO, particularly with respect to IDNs is because it is effectively a similar topic. I don't think it is a debate we've had and I don't think -- and I think we need to get input from the GAC and others what they think is appropriate and consider how to address it.

>>MARILYN CADE: Let me ask my followup question. We will have time to discuss the reserve name report and maybe I can save it for then because I think it will be a robust part of our discussion with the GAC.

>>BRUCE TONKIN: I think we have probably covered this document enough for the minute, and the process is outlined that we will announce for people to provide editorial comments to Liz and the editorial was both in terms of improving the drafting of recommendations in a couple areas as well as particularly strengthening the discussion.

We have certainly run over time on this topic. I was hoping to cover the document in about an hour, but we -- as the nature of these things, everybody wants to debate the detail.

We do need to get the reserves names working group to report to us, we also have a lunch with the GAC in half an hour.

So the question is how best -- and we haven't really had the discussion on dispute resolution processes that I wanted to have as well. So the question is how best do we use the rest of our day? We do have an allocation of time for the Feb '06 task force of three hours. Avri, do you believe you need three hours for that?

>>AVRI DORIA: I don't know. I kind of hope not. It could happen. Just like -- we basically have to go through the reports that's the draft final and, okay, there are no comments to look at so that should take very little time which is one of the things I wanted to do during that meeting is go through any of the comments.

I don't know what issues will come up as we saw with your going through something that should have taken an hour, it took almost three.

>>BRUCE TONKIN: Yes.

>>AVRI DORIA: I wanted to make sure that we do have a chance to go through the report because the next time we look at it we should be voting on sending it off to the council so this should be among the last times we talk about it.

>>BRUCE TONKIN: All right.

>>AVRI DORIA: I hope not.

>>BRUCE TONKIN: It is hard to suggest this, but, I guess, let's assume -- do you think you can cover most of it as an objective in about an hour or so? If you go longer, you go longer.

>>AVRI DORIA: Call it two hours, yes.

>>BRUCE TONKIN: That would be three, four, five.

>>AVRI DORIA: If I say basically we would use one hour for discussing comments and we have no comments to discuss, so take off an hour.

>> Bruce, if I understand T the meeting this afternoon for Feb '06 PDP is a task force meeting, is that right?

>>AVRI DORIA: Yeah.

>> Does that help in what we need to do?

>>BRUCE TONKIN: I guess it is overlaps of room. I guess I want to spend more time --

>>AVRI DORIA: It is also largely the same people.

>> And I can't be in two places at once. That's the issue, Chuck. I can't be in two places at once. Not today, tomorrow, no problem.

>>BRUCE TONKIN: Maybe we will try to convene this group again at 4:30 and we will just sort of try and compete with Avri's space. We can lien on people and tell them to be quiet in Avri's meeting.

>>AVRI DORIA: I have the two hours but a half-hour before it is over you will start standing up, are you done yet?

>>BRUCE TONKIN: That's right. Just like in a restaurant when you are trying to get a table. To just kind of kick that off, maybe -- do you think -- I am conscious of people have not had a break. I am proposing we work through because we are tight for time.

Chuck, do you think you could perhaps give an overview of the reserved names work and then we will discuss it this afternoon? In other words, if you can give 20 minutes of a summary of what's in the report, what are the basic outcomes and then we can have question time this afternoon. Is that feasible?

>>CHUCK GOMES: Sure. I am not going to give a full overview. Don't expect that because it will take more than 20 minutes. There are too many reserved name categories.

What I will do -- if you have the document in front of you, it probably would be helpful if you thumb through it and I will give page numbers and so forth as I go through. What I would like to do first is just go through the recommendations where we essentially came up with a final recommendation. There is lots of them where we didn't that require more work which was no surprise. We knew that going in. But if you will go with me -- starting out with page 17. We did make a specific recommendation with regard to the use of symbols. So you will see table 4-2 on page 17 and we recommend that the current practice be maintained so that no symbols other than the hyphen be considered for any use at any level otherwise technology permits the use of symbols. Nothing revolutionary there, I don't think.

If you then go to the next page, in the middle -- most of table 4-3 contains recommendations that still need more work. In fact, all of them do except for the last two that the group didn't even focus on at the third level. But the -- thank you, Marilyn, for doing that.

The -- if you look on page 18, the second level ASCII, the group did make a fairly specific recommendation there. The work that's needed is a little bit different than just with regard to the recommendation depending, of course, how the council reviews it.

With regard to second level, single character names in ASCII, letters and numbers, the recommendation is that we recommend that single ASCII letters and numbers be released at the second level in future TLDs and those currently reserved in existing TLDs should be released.

This release should be contingent upon the investment of an appropriate allocation framework. It is not totally done because obviously there is a contingency put in there that an allocation of framework would need to be developed.

>>STEVE CROCKER: Excuse me. Why?

>>CHUCK GOMES: Why not?

>>STEVE CROCKER: That the answer?

>>CHUCK GOMES: I am just asking that question. The group didn't see a reason to continue reserve those. I am just sharing the decision by the group in that regard.

>>STEVE CROCKER: Wonderful.

>>CHUCK GOMES: It's a recommendation that's being put forward by the group for consideration by the council and the new TLD group.

>>STEVE CROCKER: Thank you.

>>CHUCK GOMES: In Table 4-4, the top-level ASCII -- this is for two-character reserve names, letters only. We recommend the current practice of allowing two ASCII names at the top level only for ccTLDs remain as it is today. This is an important one for the ccNSO community as I think everybody knows.

If you go to second level ASCII, two character names again, we recommend that registries may propose release of two-letter and/or number strings at the second level providing that measures to avoid confusion with any corresponding country codes are implemented.

A standardized approach should be used which ensures consultation with appropriate parties including the ccNSO and ISO 3366 maintenance agency and where secured stabilities are identified use the RSTEP process, registries approval process.

Going then to Table 4-5. With regard to tagged reserved names --

>> Sorry, Chuck, before you go on, or Bruce, are you taking questions now?

>>BRUCE TONKIN: No.

[ Laughter ]

>>CHUCK GOMES: Let me point out that I made clear we would probably need a lot of time to go over this in advance because -- I knew -- you can imagine what we went through as a group.

Table 4-5, tagged reserved names. I apologize for not having very much time to talk about this because it is a technical requirement but for the sake of time, I will let you do your reading and you can ask me questions offline or any member of the group, if you'd like.

At the top level for ASCII -- and actually IDNs are really not applicable in this particular case so you'll see that it's marked as N/A.

But for top level, our recommendation is as you see there: In the absence of standardization activity and appropriate IANA registration, all labels with hyphens in the third and fourth character positions -- you see a couple of examples there -- must be reserved.

For each IDN gTLD proposed, applicant must provide most the ASCII compatible, the ACE form of an IDNA valid string, the A label as discussed in the latest document on that -- and in local script form -- Unicode form of the top-level domain U label.

The -- I probably should just make a brief comment on that. In the absence of standardization activity and appropriate IANA registration, the thinking there was -- is that in the future there could be other uses of reserved names where tags could be used to identify a category so rather than just leaving it wide open just for IDNs, so that qualification was put in there.

At the second level, just a rewording to the current requirement and the added wording is in italics, you will see it similar to the top level, in the absence of standardization activity and appropriate IANA registration all labels with hyphens in the third and fourth character positions must be reserved.

Right now, for example, if you look at the note, names starting with XN-- may only be used if the current ICANN IDN guidelines are followed by a gTLD registry. Understand that XN-- can be used even though there is a general requirement to reserve the character-character-dash-dash string in the beginning.

For any registries that will register names at the third level, we recommended same requirement as at the second level occur there. Right now, there are just two of those. There could be more in the future. Dot name and dot pro actually do names at the third level. So they should reserve those as well, any new registries that would come on board.

Table 4-6. Recommendations regarding reservation of NIC, WHOIS and WWW for registry operations. For top-level ASCII, we recommend that those names, NIC, WHOIS and WWW be reserved at the top level.

Top level for IDN, a recommendation -- and this was basically through advice from some IDN experts don't try to translate those into Unicode versions for various scripts. Order reserve any ACE versions of such translations or transliterations, if they exist.

The thinking there it was just going to get to be a complicated mess if you try to do that.

Second-level ASCII, the following names must be reserved for use in connection with the operation of the registry for the registry TLD: NIC, WHOIS, WWW. That's wording just like it is today. The requirement would stay the same.

And it also -- the current language also says registry operators may use those. So I won't read that verbatim.

And, again, same thing for third level, if it applies to a particular registry going forward. Those are the only ones that we did not recommend further work for. There is obviously some that get very complicated. The other categories -- let's see. How am I doing timewise?

Let me take two minutes and very quickly point out the categories where additional work is needed. Table 4-1 on page 13, paging up to the beginning of this section, more work is needed with regard to ICANN and IANA-related reserve names. If you read some of the statements below the table in that, you will get a sense of where some of the discussion went with regard to that and why we weren't able to do that one with a final recommendation.

Table 4-3 we already hit at. There is still a lot of work that needs to be done in single character and two-character names.

Table 4-4, the two characters reserve names, again, there is more work needed to be done in several categories there.

Then going on to table -- skipping clear over to page 26, table 4-7, that's recommendations regarding reserve gTLD strings. Most of the gTLD registry agreements require them to reserve other gTLD names at the second level. And more work is needed there. There was -- we weren't able to reach rough consensus on that.

Skipping over to table 4-8, controversial reserve names. What I am going to suggest that you do there is -- in fact, I see I skipped some that we made a recommendation on this category. I will go over that in a second.

I will leave it to you to read through the top ASCII suggestions there. Marilyn made a little bit of reference to that a little bit of ago with an approach that's under consideration. More work is clearly needed there and, of course, we need feedback from the GAC and others.

But if you do look at the second level and the third level for that category there is a recommendation I forgot to mention.

Processes, if any, to deal with controversial names at the second level should be left to the discretion of the gTLD registry operator with the exception that registry operators must comply with applicable local laws and regulations. And that same thing for IDNs there and then same thing at the third level for that.

That's probably about all I have time for, Bruce. Do you want to entertain any questions or --

>>BRUCE TONKIN: I look sort of 15 minutes or so. Do you have this in a presentation format, by the way?

>>CHUCK GOMES: I do have a presentation form for all of the recommendations that I have on my laptop.

>>MARILYN CADE: Bruce, can I just challenge that? We are actually supposed to meet the GAC at 12:15. Could we spend a few minutes organizing ourselves so people know what to expect in the GAC meeting and come back to the discussion --

>>BRUCE TONKIN: This afternoon essentially.

>>MARILYN CADE: Yeah, yeah. I think this is a very important meeting for us and a good opportunity. If we could focus on the GAC for a few minutes.

>>BRUCE TONKIN: I think, Chuck, on the reserved names thing, I do think we need to spend more time on it, as you pointed out. I am just wondering the best way to structuring that extra time which will be later this afternoon.

I think it might be helpful if we have kind of a presentation format that just sort of says here is the recommendation and then we go, yep, we understand what that means. And just kind of take so questions. What I want to do is get an idea of what the level of support is or what the further work is we think needed on top of those. And I think we need -- we are not going to have time to do that in the council meeting later this week at that level of detail.

So I would prefer what you have done is given us an overview which is fine, got people thinking. If we can do more in presentation format or you can move your PC up here or give it to me on a tag and I will try to work through it with you and just sort of get a sense of which of these recommendations are pretty solid, that we want to really present later this week in the more public forums or which recommendations do we really think need a lot more work.

>>CHUCK GOMES: Do you want me to spend you the presentation?

>>BRUCE TONKIN: That would be helpful, yes. Or just put it on a thumb drive.

With respect to the GAC lunch, that's going to be held -- jade -- in some room called jade which I gather is on this level. It will be a round-table format and so that means there will be a number of round tables and there will be -- what we are trying to do is come up with a rough seating plan that gives a mixture between committee members and GAC members on each table.

What the -- the general format will be have lunch, have a bit of a discussion over lunch and over half an hour or so in a fairly informal manner. Just ask the GAC members what sorts of things they have been discussing, what are the sorts of things they are having trouble reaching agreement on, convey to them some of the things we have been working on, et cetera. That's kind of down at the individual table discussion level.

Towards the end of the lunch, I will ask the GAC chair, I think, of the new gTLDs which I believe is Bill Dee (phonetic), to present to us what the current status of their principles are and what I will be suggesting to him if there are some principles that haven't reached agreement on, then that's fine.

But we should ask them to at least present the principles where they think there is a fairly high degree of support, pretty similar to the way we run our processes.

In other words, they might have a document with 20 points on it and have got agreement on 18 and still debating the last two. I will be asking them to at least present to us the 18 they have reached agreement on and then I will respond with the recommendations that we have that relate to what they have because in many cases I think we are pretty consistent or if they have got a principle that's sort of diametrically opposed to what we have, I will then say that's what we have. It seems to be substantially different from what you proposed and we need further discussion to try to resolve. That's roughly the format.

Who have we got -- Glen? How will the people know how the seating allocation works?

>>MARILYN CADE: There are two glasses. Glen will offer you have a colored token out of one glass and you will -- the GAC will be taking a similar colored token out of another glass and each table has a tent card on it that has a token that matches the color. There will be roughly nine or ten of you at each table. Half GAC, half of you. And we made provision for accommodation for 70 people. So it will be roughly a mix.

Bruce and -- Glen will take of Bruce, Ambassador Karklins, Sharil, Bill Dee and Suzanne so they will be seated closest to the podium at the front of the room.

The rest of you are in round tables. The acoustics are very good, but during the portion in which the presentation and discussions are going on, you will really need to be quiet because there are no wireless mikes but the acoustics are very good. We did a test in there this morning.

The lunch will last roughly from the time you go in until 1:00. At 1:00 everyone is expecting the formal discussion to start. And there is accommodation for -- we accommodated for, I think, seven or eight ICANN staff and Susan, as well, for you in the head count.

>>BRUCE TONKIN: Thanks, Marilyn.

I will close this session now and the new gTLD session will aim to meet in this room at 4:30 today and stand over those that are still in the room from the previous meeting. And we will try and use a bit of time at the end of the day to go through Chuck's working group report in more detail.