ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

>>BRUCE TONKIN: Okay. Let's get started and the purpose of this discussion is, I guess, to understand the current work of the reserved names group and sort of put it into context of the new gTLD work.

So the first point I don't actually understand, I must admit.

Chuck, you may need to explain this slide for me a little bit.

So firstly, this is ICANN/IANA reserved names. So the way you've structured it, that's essentially the heading, is it? And these are the recommendations under that heading; is that correct?

>>CHUCK GOMES: That's correct.

>>BRUCE TONKIN: Do you want to just take us through the slide, then, so I understand it?

>>CHUCK GOMES: Sure. What I tried to do at the top of the slide is give you as much information as would be helpful.

Keep in mind you're not going to see all the information. In most cases, there may be minority statements that are included below the table in the report in the recommendation section.

And of course, with each category, there are full reports in one of the appendices that talk about more details.

I probably should have referred that to Steve Crocker when he asked me the question this morning when he asked me why, because there's a lot more information in the reports.

This particular category is one, as I mentioned this morning, that cover -- I guess it was in the GAC meeting, that actually covers all levels in the existing agreements. Okay?

And there are two reserve categories there: The ICANN names, ASO, GNSO, ICANN, interNIC, ccNSO. There's actually three agreements, I think, that still have the DNSO and don't have ccNSO, but those will be changed when their agreements are revised.

IANA names you can see there. I won't read through them all. The one that is kind of unique is the one example because it is actually a word that can be translated, transliterated or whatever we want do with it whereas the other ones are pretty much abbreviations or unique terms that may not translate well or for IDNs.

Now, in this particular category, it was quite interesting to refer to, and I almost commented on this but time really ran out in the GAC session, but Bill Dee made the comment about ICANN being able to reserve names for itself, and the GAC's not and so forth.

Interestingly enough, that was essentially the issue that came up in the subgroup that was working on this category, or in other members of the group; okay? Tim denton. Is Tim on the phone?

>> I'm just sending a note (inaudible) now.

>>CHUCK GOMES: Tim actually did the work on this but some of the feedback we got from members of the group had to do with the same concept. Should ICANN be able to reserve these names? Should the names for the IANA be reserved? Why should they be able to do that and other organizations, whether they be governments or NGOs or businesses and so forth?

So we were unable to reach any final consensus on this particular one. That's why you see, for the top, second, and third levels ASCII, we recommended more work on that category.

Now, for IDN levels --

>>BRUCE TONKIN: Chuck, so I can just clarify, I suppose what's confusing me a little bit, and it's probably just because I'm not capturing the detail in the report, but I guess what you're saying is those are currently reserved -- You're saying that in the contracts, it does cover top level as well. So you're saying that's a statement of the current --

>>CHUCK GOMES: Yeah.

>>BRUCE TONKIN: -- situation and then more work would be recommended to change --

>>CHUCK GOMES: The table itself is the recommendation part.

What I tried to capture very briefly at the top is the current recommendation requirement, although up there I don't show the levels. I'm telling you that it is -- it says all levels.

>>BRUCE TONKIN: Okay.

>>CHUCK GOMES: Right now. So that would already cover the top.

Yes, Marilyn.

>>MARILYN CADE: Chuck, for all of us, because we are working from a report and we are looking at your PowerPoint. So just, I would find it helpful if we just -- and for purposes of making sure that we reference back and forth, because your PowerPoint is what you are going to use, I assume, on Wednesday morning?

>>CHUCK GOMES: That's probably up to Bruce, but yeah.

>>MARILYN CADE: So we probably ought to cross-reference and make sure -- which Chuck Gomes very good. That's a good suggestion and I actually had intended to do that and forgot.

Where I am at in the report, keep in mind I am really at section E in the report, which is the reserved name working group recommendations.

Now, there's a whole bunch of recommendations. In terms of the main body of the report, you can see it's about the first 40 pages or so; okay?

And the biggest section is the recommendation section because there are multiple recommendations for each category of reserve names.

So if you go to the very first category in section E, which starts on page 12, you'll quickly come to the ICANN and IANA reserved names.

Okay. Now, associated with those recommendations, as well as the roles that were in section D, okay, is a report by the subgroup that worked on that category, in this particular case it was Tim Denton, because we didn't get any other volunteers although other people contributed in the overall process.

So if you go down, then, and ignore the table numbers at the bottom of the front of your document, because those didn't work correctly, but on page 14, you can see ICANN and IANA related reserved names, page 14 of the document has the full report of the group on that.

Now, did I lose anybody?

And I apologize for the complexity, but there are so many different categories. And within each category, there are subcategories, which level, whether it's IDN or ASCII.

>>BRUCE TONKIN: So I guess one of the things is to try and work out what is resolved and what's not resolved, and actually kind of almost build the reserve word list at the top level.

So I guess what I'd like to see is in one place, I suppose, in terms of the current recommendation or current status --

>>CHUCK GOMES: The ones we actually made recommendations on?

>>BRUCE TONKIN: The way I kind of look at it is, if you look at the schedule we currently have in the agreements and we look at this category which is the ICANN/IANA reserved names, at the moment you are effectively recommending no change. Is that a correct statement? In other words, more work would be needed if you wanted to make a change. So right now, you're saying status quo.

>>CHUCK GOMES: No, we're not saying status quo.

We're saying more work is need before we can say status quo or anything different.

There was not -- We did not reach consensus in the group to keep the status quo.

>>MARILYN CADE: Chuck?

>>CHUCK GOMES: Go ahead.

>>MARILYN CADE: It's Marilyn.

I might say, maybe it would be helpful, you sort of made reference to this, but unless you've just spent the past few weeks meeting weekly, biweekly, and bi-daily on the work here, it may not be clear that the groups, and all of them, I think, it's fair to say, have done a huge amount of research. In some cases, the analytical and research process has been done by Tim or by Patrick, but in many cases it's been done by individual members of the subgroups, then in coming back together in trying to discuss, analyze, and debate the recommendations.

We're probably, if I were to roll out a time line, I would say we're at about the three-quarters mark, and we need to spend, for most of these recommendations, for most of these we need to spend the next 30 days and try to get to agreement.

So I'm going to use this as an example.

After feedback from the technical community and from some others during this week's process -- I don't want to lose Bruce on this.

Can we just check and see if Tim is on the phone?

>>CHUCK GOMES: Tim, have you joined us?

>>AVRI DORIA: When he joined before, he joined rather audibly.

>>MARILYN CADE: Can you call him? Yeah.

I'll say this and then -- Bruce, I just -- sorry, I just want to be sure that Bruce heard this.

Bruce, during this meeting, I expect we will hear some feedback from members of the technical community and from others about, you know, you may be being a -- we may be being a little irrationally exuberant about how quickly change can be absorbed by the community in some of these areas.

When I wrote the statement of work and Chuck contributed very heavily to that, the statement of work assumed that we might not be able to unreserve everything. Even if the recommendation is unreserve, that there was a recognition that we may not be able to unreserve by the time of the launch.

>>CHUCK GOMES: Right.

>>MARILYN CADE: And inherent in the work of the groups is an assumption it may be possible to unres- -- reserve a category across all new gTLDs, and later that category could be released. The question of how --

>>BRUCE TONKIN: Yeah, I think that's exactly right. I guess why I am pushing on some of these points I'm trying to see in the time frame the outcome.

So basically we are trying to work towards a process that allows ICANN to launch TLDs. We are saying that a policy recommendation is going to be a reserved word list, and we're saying there already is a reserved word list at the second level and we are considering whether to add some of those into the top level.

And in some cases there are already rules about what is not allowed in the top level and you have given me examples.

>>CHUCK GOMES: But also, for the new TLDs, there are implications at the second level for them in terms of the contractual conditions, like you said earlier today.

>>BRUCE TONKIN: Yes, yeah.

And so I think in terms of reserving something, from an engineering point of view, I suppose, but you're probably better off if you are uncertain about something than to not unreserve it, if you know what I mean. Because once it's gone, it's gone. And bear in mind how we talked about rounds in the GAC meeting.

We could well decide, if I just use that example, I said round one is first of January and round two is first of July, you may well decide that because we haven't reached agreement on something like this, we leave dot ASO reserved for the first round. And based on further dialogue with the community we might unreserve it for the one after.

But you can't go back. You can't say I haven't decided, so I'm going to unreserve it, and then we subsequently find there's a problem.

>>CHUCK GOMES: Yeah. We're not saying unreserve or reserve here. We're just saying more work.

>>BRUCE TONKIN: What I'm trying to say is --

>>CHUCK GOMES: I understand perfectly what you are saying. In fact, I actually made that suggestion --

>> Tim Denton has joined.

>>CHUCK GOMES: Tim, is that you?

>>TIM DENTON: Hi, yeah.

>>CHUCK GOMES: Welcome. Guess what we're talking about.

>>TIM DENTON: Well, I figured, eh?

>>CHUCK GOMES: ICANN/IANA names. One of your favorite categories, I know.

>>TIM DENTON: Indeed, indeed.

>>CHUCK GOMES: Anyway, Bruce, I actually did -- I'm very comfortable with that approach, by the way. Myself, personally. And I suggested to some of the sub working groups that they could actually make a recommendation like that, let's stay with status quo until more work is done.

That, at least at this point, was an accepted -- And part of the problem, too, is at the very end we had limited time to debate as a full working group on all of these. We had to go fairly quickly.

But in the -- If it's extended, I think a good target would be, in cases where we can't reach rough consensus, is to use an approach like you are suggesting. Okay?

That's my personal opinion. I'm not speaking for the group.

>>BRUCE TONKIN: I understand it's your personal opinion. And I guess what I'm trying to do is I am trying to fairly rapidly incorporate this work into the new gTLD process.

>>CHUCK GOMES: I understand.

>>BRUCE TONKIN: And also be able to communicate it to people.

And I can just tell -- I know if Mr. Crocker was in the room, for example, he would have -- if you are saying we're going to unreserve it, he would be saying why.

>>CHUCK GOMES: And I would say why not?

>>BRUCE TONKIN: I know you would.

>>CHUCK GOMES: I could have responded much better, I know.

>>BRUCE TONKIN: I know that. That wasn't a very good response, by the way.

>>CHUCK GOMES: I'm very aware of that. His question caught me off guard.

>>BRUCE TONKIN: But leaving that aside, so I'm trying to kind of end up with being able to communicate where we're going with the reserved word group and the outcomes in such a way that we are presenting them positively.

So we are saying the reserve word group recommends the following for the new gTLD process, and then there are these other things we haven't decided yet.

But we have to be able to -- rather than saying we have these reserved words and more work is needed, I think I would say these words are currently reserved. We haven't yet reached a conclusion to change it yet. So that default stays there.

>>MARILYN CADE: I will just say, Bruce, that actually I think -- and I happen to be one of the proponents of conservative, because I understand the roadblocks ahead on all categories if we're irrationally exuberant.

So I tend to be conservative and suggest that continuing to reserve the IANA or the ICANN or the whatever and other names at the top level is probably going to be needed.

I think we need to make a distinction between where the working group can actually propose that it can show documentation, that it has taken consultation with technical experts, and it has been able to actually robustly consider and could conclude a better -- a more well developed recommendation on a category. And the category that you're mentioning, which is one that this is going to be both a political discussion, a technical discussion, a policy discussion. And for that category, it is staying -- we're not saying more work in the short term. We're saying it's in reserve status through the launch process. We have to examine how, if we -- how, if we could ever unreserve that category.

And I think those are two different categories.

>>BRUCE TONKIN: And it's being able to present that, I think, in terms of presenting this in a public forum, we have to preface it with some of this context we're talking about, I think.

It's in the context if I did have to launch by first of July '07, what would be in that document context, is what I'm thinking about now.

Obviously there are a lot of things that will be identified in your work where need to think about it and probably be conservative where there is an issue like that, rather than the other way around.

>>CHUCK GOMES: And are you suggesting, then, in presenting it there that I should actually, even though the working group hasn't suggested that your suggestion --

>>BRUCE TONKIN: Maybe that's my context to give, if you like. I agree, I'm not trying to put words in your mouth as a working group. I'm just trying to put it from the point of view of --

>>CHUCK GOMES: I understand.

>>BRUCE TONKIN: -- at a new gTLD committee point of view, I'm trying to say what's -- what (inaudible) might come from your group that allows us to action it.

>>CHUCK GOMES: That makes sense to me.

>>BRUCE TONKIN: Avri.

>>AVRI DORIA: First I should preface is by saying I don't intend to be the most conservative around on these sort of things.

I think even when you talk about status quo, you've got a status quo at the second level, and beyond you don't have a status quo at the top level.

So I think the idea of saying you're keeping the status quo at the top level --

>>BRUCE TONKIN: I think in that case, that is the status quo on the top level.

>>AVRI DORIA: Well --

>>CHUCK GOMES: For that category, there is a status quo at the top level.

>>AVRI DORIA: At the top level.

>>CHUCK GOMES: Yes. Because for this category we're talking about right now, it's for all levels.

>>AVRI DORIA: Okay.

Because I really do think it's already covered by your other -- the other rules within the new TLD process that basically says, you know, if somebody applies for something where there's another community that it applies to. So, frequent, if somebody applies for IETF that isn't IETF, it's not something that would happen.

So I mean, it's all well and good to say you're going to maintain the status quo there, but I don't even see why it's necessary.

>>BRUCE TONKIN: I'll tell you the actual answer on this particular question, because I think Chuck posed a question as to why that list exists, and I did actually ask the general counsel's office. And the reason why, because some people have said how come you can get dot ICANN reserved but I can't get dot Microsoft reserved? And the answer to that is that ICANN, one way or another, can be involved in the dispute resolution process.

So because it can't be both the judge and jury, it's basically preempted it effectively.

Whether you agree with that decision or not, but that was why.

>>AVRI DORIA:But that doesn't explain LACNIC, IETF, et cetera.

So that may explain ICANN in that list, but it doesn't explain the whole list.

>>BRUCE TONKIN: That could well be true. But that's the rationale. That was the rationale for that original list.

>>AVRI DORIA: Well, it's inadequate.

>>BRUCE TONKIN: And I'm not trying to justify it, but that's why they were thinking. These are terms that in some way relate to us as the Internet. And I guess they also have the contract for IANA, and that involves there.

>>CHUCK GOMES: See what I had to deal with?

>>BRUCE TONKIN: Sorry?

>>CHUCK GOMES: See what I had to deal with?

[ Laughter ]

>>AVRI DORIA: And you said it wasn't that bad.

>>CHUCK GOMES: It wasn't, but I'm not going to say that here

[ Laughter ]

>>BRUCE TONKIN: Philip.

>>PHILIP SHEPPARD: Thanks, Bruce.

Just a couple of points. I think one phrase that we could perhaps steal from public policy work which could inform both this item and others, is that of the precautionary principle, which is another word of expressing conservativism but is actually more of a public policy term, and I think that's what we're saying here.

>>BRUCE TONKIN: Basically, if I can pick that out because it might be something we want to get into the new gTLD report. It's almost a part of the discussion, I suppose, around reserved names, but around that concept that where a name is reserved, it may not be reserved for all time. But a conservative approach as we start expanding the space.

Some words to that effect, because it's not like we're trying to -- it's natural that the system will evolve, and it could well be -- because I think in a number of these areas, it might be coming out of the GAC.

The other area it might come out of is the ccNSO. And the ccNSO may say, we're creating a table of two-letter codes for different languages, or something.

And so we -- Until that table is created and there's some certainty, it might be best to say we're going to reserve two-letter codes till such time that there's a definitive list of the new ccTLDs. And at that point, anything that's not on that list is allowed.

So those are kind of a --

>>PHILIP SHEPPARD: Exactly.

>>BRUCE TONKIN: That's where we liaison with the other groups.

>>PHILIP SHEPPARD: Would flow from such a principle. Exactly.

The second point I was going to make, we're talking certainly in this case about a trivially small list of potential domain names compared to the expanse of the human imagination going forward. And we're also talking about things in our global principles about competition and added value and making it a good space.

So I think it's -- The harm that we -- potential there and the intellectual arguments we're having about whether ICANN should or shouldn't I think is almost irrelevant compared to the scale of what we're talking about that is going to be allowed versus what isn't.

So I think that's just a point also worth reporting.

>>BRUCE TONKIN: I want to come back to your earlier point, too, about the ccNSO and some of the other elements.

But the other thing I want to do is avoid other processes becoming critical path for the launch of new TLDs.

So I don't want to end up with a situation where it says until we've decided what the new country code versions are, we can't launch. And so wave to wait two years or three years or five years for them to work that out.

I'd rather sort of say, okay, we may well reserve some category in some way --

>>PHILIP SHEPPARD: Yeah.

>>BRUCE TONKIN: -- that deals with that until they then resolve that and then we then open up that category again. As an example. I'm trying to get a way of thinking about it so we can incorporate there's more work to be done but we are using the precautionary approach, saying if you are going to come up with something for two-letter codes, we'll separate that out because we need to do more work on it. But we keep it separate from the launch of the new gTLDs.

>>PHILIP SHEPPARD: Absolutely. Because to my mind, the short version of this eminent report is the black list of reserved names, huh?

>>BRUCE TONKIN: Yes.

>>PHILIP SHEPPARD: That's its ultimate objective, and we all recognize that that list may change subsequent to more work, but it ain't changed for the launch of the next process.

And the third point I was going to make I think is the discussions around why it's being reserved to me struck me as being in the blindingly obvious category, which is to avoid confusion. And I think that's probably worth recording as well. And if anybody wants to argue against that, please, let's hear the arguments, but there's nothing else, is there?

>>BRUCE TONKIN: Which arguments are you talking about? The ones on the screen now?

>>PHILIP SHEPPARD: The reason those ICANN/IANA names are reserved was the avoidance of confusion. We're talking about we need to get documented proof to these institutions as to why they are reserved. I mean, come on. Let's just recognize why they are reserved and move on. Or am I missing something?

>>MARILYN CADE: If I can comment to Philip. I don't think you aren't missing something, Philip. I think one of the challenges, we are all volunteers and everybody was coming at doing this research from their own particular perspective, sort of like of the nine blind men and the elephant, so the issue that, in fact, some of these were pragmatic, practical decisions that were made by the ICANN staff or by Jon Postel or by somebody else. You know, there's not necessarily a lot of documentation.

People made decisions so that the introduction of new gTLDs could proceed or ICANN could get launched, et cetera.

To Philip's point, the fact that some of these decisions were made for practical reasons, just because they would cause confusion, doesn't -- I tend to agree with you, there doesn't have to be an RFC that says that or a long established set of legal decisions. We need to move forward with pragmatic decisions about what we can do in order, to Bruce's point, in order to not forever hold up the launch of the next round.

>>BRUCE TONKIN: Okay. Let's get to the next category.

So --

>>CHUCK GOMES: Bruce, we should look at IDN there real quickly because we did make a recommendation there.

And what it we basically said is that for all of them, except for example, there shouldn't be any attempt to try to translate them and reserve an IDN version in different scripts.

Now, it could be down the road that maybe some scripts, that's appropriate for. That could be dealt with on a case-by-case basis.

Example is somewhat unique because it is a real word so there may be a need to reserve that in scripts.

Now, we didn't make that a specific recommendation there with regard to example, but that could easily be done.

>>BRUCE TONKIN: Okay.

>>CHUCK GOMES: Okay. That takes care of that one.

>>BRUCE TONKIN: Use of symbols?

>>CHUCK GOMES: This one was in the overall category -- covered in the overall category of single and two-character names, and basically just recommending what already is happening, and that is that the only symbol that can be used is the hyphen, until such time that technology permits other symbols.

This is particularly interesting with regard to IDNs and symbols, but this one I don't think we really had any controversy other than wording it the way you see there.

>>BRUCE TONKIN: So by symbol, is just so that I understand this clearly, because you are distinguishing a character in a language, are you, from a symbol; is that the intent here?

>>CHUCK GOMES: Yeah.

>>BRUCE TONKIN: Like, another language can look to me like a symbol because I don't translate it. If I look at a Chinese character, that is a symbol for me, because I can't read it.

>>CHUCK GOMES: I understand.

First of all, from the ASCII point of view, we're talking about anything that is not a letter or a number, okay? It's more complicated to communicate that with IDNs -- is Cary in here?

And, of course, it varies by -- it varies by script, varies by script. But the whole -- you know yourself that the topic of symbols in the IDN discussions that have been going on have been -- has been quite lively.

>>BRUCE TONKIN: Yeah.

>>CHUCK GOMES: Is that a good enough answer?

>>BRUCE TONKIN: I just sort of can see how this could be read in different ways. That's all.

>>CHUCK GOMES: Oh, it could be. No doubt about it.

But I think that one is -- right now, I don't think that they -- anything is allowed besides the dash in the DNS. So this is consistent with what's practiced now.

>>BRUCE TONKIN: And you're talking specifically about the DNS, not the translation of that in a the browser world; is that right?

>>CHUCK GOMES: Right.

>>BRUCE TONKIN: That becomes a bit more constrained, because even with IDNs, you're just putting in the ASCII character set.

>>CHUCK GOMES: Exactly.

So -- and I think I understand your concern now even better.

>>BRUCE TONKIN: Well, just when I read that, it could be read as though you're not allowing IDNs. But you're talking specifically about the -- at the DNS level.

>>CHUCK GOMES: Yes.

Okay?

>>BRUCE TONKIN: Okay.

>>MARILYN CADE: So can I just ask, so are you suggesting we -- do you think we need to fine-tune that in some --

>>BRUCE TONKIN: I think the language needs to be improved. I understand the message that he is trying to convey.

>>MARILYN CADE: That's what I understand.

And, Chuck, I'm surprised you haven't asked the chair of the council to submit language to you.

>>CHUCK GOMES: Would you do that, Bruce?

[ Laughter ]

>>CHUCK GOMES: Okay. I wrote myself a note on that, Bruce. Okay.

So I don't think -- well, I was going to say I don't think that'll be too hard. When you really get down to it, sometimes it is. But, yeah, we'll take a crack at it.

Okay. Now, this is -- as you can see, we've just covered the one category, symbols. There's going to be several tables with regard to first one- and two-character top-level domains, because they each present some different variables.

For one-character ASCII names only, okay, which is a -- 36 combinations, 36 different possibilities, top-level ASCII, we're recommending further work to confirm that there are no technical reasons not to have single-letter or number TLDs.

And, again, you're hearing all of this in a very small little context.

The group really did talk about, you know, like, for example, numbers at the top level, there could be some problems because of software maybe thinking that it's an I.P. number that's coming or something because of numbers. But we didn't confirm that.

But the committee did a lot more than what you're hearing today, okay? This one needs more work.

>>MARILYN CADE: Chuck.

>>CHUCK GOMES: For top-level ASCII.

Yes, Marilyn.

>>MARILYN CADE: Chuck, I just need to report out that on the report on page 1, just because people will reference it, the examples are wrong. It is dot EG -- sorry. It's dot G dot A, not dot A dot biz. So you should just take note of that so when people ask you about it, it's not confusing.

>>CHUCK GOMES: Okay. Thank yous. Okay.

>>BRUCE TONKIN: So let's just sort of go through our previous discussion in this context a little bit more.

So what are we really recommending from a process point of view?

So using this sort of conservative approach, you'd almost in the first round reserve single characters at the top level, wouldn't you? Given that you run short of --

>>CHUCK GOMES: I think that's a wise approach, okay. The working group didn't get that far.

It would be very -- if we do continue, I'll be more than happy to put that idea forward. Like I said, I did kind of put it forward in a couple cases. But, yeah, I think that would be a reasonable approach.

>>BRUCE TONKIN: Because effectively saying because you don't know what the technical implications are of having dot 1 as one of the characters. So I could have dot 1 and dot 2.

>>CHUCK GOMES: And you could also have confusability of dot 1 and dot L.

>>BRUCE TONKIN: That's another sort of issue.

>>CHUCK GOMES: I'm just giving examples.

>>BRUCE TONKIN: I'd say let's be conservative until we know about that a bit more.

>>MARILYN CADE: Bruce, it's Marilyn. I might take issue with the way this recommendation is worded, as Chuck knows, because I had a more conservative wording in mine.

But the wording is an effort to show a compromise.

My discussions with technical players does not indicate that there -- that we are going to shortly resolve concerns about numbers at the top level or even letters at the top level. And there's a variety of discussions that need to happen. They have not happened yet. But very short conversations with a few of the technical community indicate strong resistance and concern that has to be understood.

I don't see us getting that done by June.

>>CHUCK GOMES: No.

>>MARILYN CADE: And so my own view about this is, at the top level -- and I think Ovistrok (phonetic) hopes to have a written document from Steve Bellovin that can be available in the next two or three weeks that would help to explain some of the concerns at the top level.

But there are -- so there's issues there.

>>BRUCE TONKIN: Yeah. So the way I'd be wording it is something like -- it's sort of there have been some issues raised, or there seems to be concern in the community about this, so at this stage, we recommend it be reserved, is kind of the wording I think we want to look at.

>>MARILYN CADE: Mm-hmm.

>>BRUCE TONKIN: So something along the lines of saying, "Until we get clarity on that, we're going to reserve it."

>>MARILYN CADE: Mm-hmm.

>>BRUCE TONKIN: But we put it in the new gTLD context, in that that's round one, and in six months' time, in round two, after that discussion has happened, we might release that restriction.

But it's kind of trying to get that flow rather than just a statement saying, "We recommend further work."

>>CHUCK GOMES: Right.

>>BRUCE TONKIN: Because what does that mean? I've got to launch on the 1st of July. What am I going to do?

>>CHUCK GOMES: Gotcha.

And, by the way -- I'll let you jump in in a second, Liz -- but I think that with regard to the possibility of the working group doing another 30 days' work, I think we ought to pick items to work on that there's a reasonable chance that we could make some progress. Items like this I don't think should be included in that. And instead, the working group should come back with wording like you just suggested in that regard for the short term and the first launch or however long it goes.

>>BRUCE TONKIN: Okay.

So let's just take a queue.

>>CHUCK GOMES: Yeah, Liz, and Avri.

>>BRUCE TONKIN: Okay, Liz, and then Avri.

>>LIZ WILLIAMS: Chuck, just a question on that particular set of recommendations.

Is it something that you wanted to -- remember this morning we were talking about the evaluation phase, that it would be -- Would you like a list created that says, after the initial evaluation phase from cycle one, we would consider the inclusion of these outstanding pieces of work?

>>CHUCK GOMES: Well, I don't think we necessarily need to wait to start that. Obviously, it's going to be resource-dependent.

But some of this work could be started whenever we're -- we think it's appropriate to start it. In fact, I think waiting until the evaluation of the first round, then you're going to be right back where we are on this one and you just repeat the cycle.

So -- okay?

>>BRUCE TONKIN: Avri.

>>AVRI DORIA: Yeah, I think that goes a lot to what I was going to say, that I think part of what needs to happen is that you also need to actually request these technical analyses or technical tests to make these determinations.

I think -- I mean, my technical view on a lot of these things is that it's speculative. They don't know, therefore, they're cautious. But I think that we need to get beyond the, "Well, we think it might be a technical problem," to actually, you know, doing something concrete to determine whether there is a technical issue or not.

>>CHUCK GOMES: And I think it's incumbent upon us as council to take some action in this regard, not that we have to do the work.

>>AVRI DORIA: Right.

That was the other piece that I was going to add, is that I think part of the extra work that's needed from the RN working group on this is to actually construct the statement of, what are we actually asking for technical information, technical test, technical confirmation on and to basically build a coherent request of what it is we want an answer on. And how that works.

So I think that's where the additional work that the group needs to do, because at the moment, we're sort of waving our hands and saying, "We've heard there might be a problem."

It sounds almost like U.N.-speak, or GAC speak, "Well, there is some concern in the technical community that."

Well, let's nail it down and find out what it actually is and make a concrete request for that information.

>>BRUCE TONKIN: Yeah. I think one of the things that needs to be viewed on a lot of this technical work -- and I see this happening all the time with IDNs -- is there needs to be an element of what I'd call risk assessment.

Because with technical things, you can almost do anything to prove that such and such is possible. You know, you can create the right boundary conditions for a particular thing to occur. But you've also got to say, well, not just that, you know, it's possible for this piece of software running on this type of machine, which is a tape drive of the 1960s, it won't work, and therefore, we can't do something. I think we've then got to put it in the context of likelihood. Because some of the issues that have driven some of the decisions that Marilyn's talking about, those decisions were made 20, 30 years ago. I mean, equipment, software, is vastly different. And the likelihood of some of the scenarios that were originally envisaged is now extremely low. It's still technically possible. There's obviously a one in a million chance.

But if you take, for example, other industries, let's say the drug industry, if you're languaging a new drug, let's say it combats some form of cancer, you can almost be guaranteed that it's going to have some side effects and may kill people for some other reason. But what -- they're making a risk assessment and they're saying, okay, by introducing this change, you know, we save, you know, 80% of the people with cancer. There's still a one in 10,000 chance that some people will die from whatever drug this is. And it's a risk you're taking. So I think there's got to be that element when we're looking at some of the technical tests.

>>CHUCK GOMES: Okay. The second-level one generated the exchange between Steve and I this morning that everyone enjoyed.

The -- This is one -- what I'm going to share now my own personal feeling. It's not the committee's feeling. Okay?

It's my personal feeling that before you ever get the single character at the top, even if it's just letters, if you're going to do it, you ought to do it at the second level first maybe and do it in stages like that. I think that's a very practical way to deal with this.

But we didn't get that far in the group.

Certainly the whole -- the committee -- the group recognizes the need for allocation method on this one.

Now, is this something that the working group could get resolved? I suspect we'll have different opinions.

My own opinion, in the 30 days, I think it would be probably pretty hard to do.

>>BRUCE TONKIN: So this one is something that's very similar to the discussion we had in the GAC that the French representative, Bernard, was making. But it's probably very relevant here, because you'll get similar arguments.

I could imagine that the personality of, say, Steve Crocker, which is really the decision you were getting, is, he's actually doing a risk-benefit analysis, which is slightly different to risk. He's essentially saying, okay, there may be a risk of some technical problem with that single letter. Can you explain what the benefits are.

So the example I was giving in the cancer scenario is somebody could well take a drug because they think it could well cure their cancer. It may cause some side effect, but they're prepared to take that risk because there's a benefit. And I think maybe what the group would need to think about, not necessarily the reserved names group, but those that are suggesting releasing those names, can at least articulate their benefit as well so that you've got a bit of a balance, there's a benefit, and the potential risk.

But I think to get by perhaps some of the technical community, because the technical community in many cases, and particularly older members of the technical community, are by nature probably pretty conservative. And I think if they can say, "Okay. There's a clear benefit. I think that's worth taking the risk," versus the answer you gave, which is, "Why not?" probably won't carry any weight. So it's just -- it's advice, if you like.

>>MARILYN CADE: Bruce, can I get in the queue on that?

>>BRUCE TONKIN: Sure.

>>MARILYN CADE: I've talked to a number of the technical community about this issue for some time.

I think that, first of all, there has been confusion caused, and in some cases we -- I think we need to be very careful we don't add to the confusion. But there's been confusion caused by not being very clear that there's a difference between single characters at the top level and single characters at the second level. And the word "characters" sometimes get confused with letters. And some in the technical community will think that you mean to bundle -- we mean to bundle numbers, symbols, and letters as opposed to just address letters and numbers. I have to work on this myself.

So there's the confusion of between first level and second level I think we need to be careful about.

There's also the confusion about are we trying to address symbols, which some in the technical community continue to have concerns about legacy software implications. And to the very point that Bruce is making, say, "You need to do the risk assessment to say, if 20% of the -- you know, if you're going to have a 20% failure, does that matter? And if you're willing to live with 20% or should it be only 5%?"

On the single-character issue, the concern seems to be more like this: You only get to allocate it once, so be sure that you're being thoughtful about the allocation.

I would say that there's actually a lot of similarity to the fact that you can actually only allocate ATT.com once, and then you can only allocate ATT.biz and ATT.info. But you're also allocating ATT, because ATT has a brand relationship to the string. It isn't that there are going to be a lot of other people who are going to be able to get or qualify for that second-level name.

But I think we have to answer the questions about allocation. Because that's what I'm hearing primarily from the technical community, about the letters, that it's primarily a question about allocation at the second level, not a technical question. Most -- Clearly, the second -- the letters at the second level work. They work in the ccTLDs. They work in the gTLDs. We've seen that. There are six of them that work.

So I think it's much more an allocation issue and one that I don't think we'll get do it in 30 days. But I think in 30 days possibly subgroup and the working group could make some proposals on how to get to an allocation process or consider whether, over time, the staff could be tasked to put forward allocation ideas.

>>CHUCK GOMES: As you can see, we didn't do any work at the third level. But, again, although there's only two gTLDs now that register names with the third level, there could be more in the future.

And that's probably -- If you solve the problem at the second level, you're probably pretty much home free at the third level, whenever it's applicable.

>>BRUCE TONKIN: Okay.

This is the IDN.

>>CHUCK GOMES: Okay. I didn't even notice the change. Blank.

One-character IDN names. Again, we're recommending further work at the top and second level.

I think this is an area where -- And as you can see by the recognition -- by the recommendation, that we really need some IDN experts working with us closely on this. In fact, it may even be wise to form a little small group of IDN experts that would tackle this one rather than even the working group doing it. That's my own personal thinking. I haven't discussed that with the group.

But -- Because when you're talking about single character, what does that mean when you're talking about IDNs?

>>BRUCE TONKIN: What I suggest you do here -- and I think this is important to try and cover in terms of examples, particularly on the slides -- that why don't you give some examples of single-character IDNs and what it actually looks like in the root. Because I don't think people -- I don't think there's wide understanding of that. So choose -- get one of your Chinese speakers on your reserved names group to just choose a Chinese character that means something to that community and then what the XN-- equivalent is. Because I think it's quite different to this slide, where you actually literally are talking about a dot A or a dot B.

>>CHUCK GOMES: Yeah.

>>BRUCE TONKIN: Whereas here, you aren't. You're actually talking about an XN-- something or other, which gets interpreted by browsers and things as something else. And very different software application impacts.

>>CHUCK GOMES: Okay.

>>BRUCE TONKIN: So I think, you know, those on the group probably know this. Certainly IDN people know it. But I don't think the community generally understands what's meant by that.

>>CHUCK GOMES: And, again, third level we didn't address. But that would fall out, I think, if we get past second.

>>BRUCE TONKIN: And my comment about this is similar to the comment about the other thing, that this might be a game where you recommend a conservative approach to start with in terms of your resolution of it.

>>CHUCK GOMES: Okay. Two-character ASCII names. There are 1,296 combinations of those. And at the top level, letters only, ASCII, okay, we recommended that, as you heard earlier today, that the practice remain the same, that those be reserved for ccTLDs only.

Okay?

At the top-level ASCII one letter and one number or two numbers, this is similar. And more work's needed with the technical community and so forth on that one.

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

>>MARILYN CADE: Chuck, it would be worth noting, though, at the second level, I think it would be worth noting, Bruce, in the presentation to the public what the current practices are and where we're recommending consistency. And I see Patrick has his hand up on that topic.

>>PATRICK JONES: Just to add that that is a recognition of the current practice and what is currently in all of the gTLD registry agreements.

>>MARILYN CADE: And it seems to me that's helpful, because for the GAC purposes, that's going to make things more understandable to them that we're recommending the continuation.

I have -- My experience in talking about the top-level ASCII issue here is that the country code -- many of the country code managers will be very excited about any change in the present status. So I think that's another group that would be helpful to note that we're recommending the continuation of an existing --

>>CHUCK GOMES: At the top, yeah.

>>PATRICK JONES: Just to add briefly, that second-level ASCII recommendation also follows the language that the GAC itself approved in 2001.

>>CHUCK GOMES: And third level, same as the last couple, we didn't address -- get that far.

>>BRUCE TONKIN: So, again -- this is one -- I'm just trying to think in terms of an approach going forward.

I suppose both of those, taking the top two rows there, letters only and then letters and numbers, so with letters only, you're recommending keeping those reserved. At the second level, you're saying you haven't decided yet.

>>CHUCK GOMES: Second-level --

>>BRUCE TONKIN: Sorry, not second level. I meant second row, one letter and one number.

>>CHUCK GOMES: Top level.

>>BRUCE TONKIN: Again, maybe the conservative approach to start with is just basically reserve two characters rather than distinguishing letter and number for the moment.

>>CHUCK GOMES: For second level?

>>BRUCE TONKIN: Top level, I'm talking about.

>>CHUCK GOMES: Top level, okay, mm-hmm. So, basically, just reserving two character names at the top for right now.

>>BRUCE TONKIN: Yeah, as a starting point.

>>CHUCK GOMES: Yeah, including the number/letter combinations.

>>BRUCE TONKIN: Yeah.

>>CHUCK GOMES: Yeah, that seems like the conservative approach, yes.

>>BRUCE TONKIN: And then -- so then the next level you're saying, second level, we recommend may propose release much the --

>>CHUCK GOMES: Which is really the way it is now.

>>BRUCE TONKIN: Yeah. And then you're not addressing -- all right.

>>SUSAN CRAWFORD: Let me make sure I --

This is Susan. Are you suggesting that two numbers also be reserved?

>>BRUCE TONKIN: Yes.

>>SUSAN CRAWFORD: Would that be the approach this.

Because the reason for the two letters was to avoid confusion with the country codes, but that same reason doesn't seem to exist with the numbers.

>>CHUCK GOMES: There are some other reason that is come into play. Confusion with I.P. addresses.

>>BRUCE TONKIN: I.P. addresses.

>>SUSAN CRAWFORD: Okay. Just checking.

>>CHUCK GOMES: No, it's a good question.

Two-character IDN names. Further work with experts, IDN experts in particular. It's not unlike the single-character issue, the same way.

>>BRUCE TONKIN: Yeah, so --

>>CHUCK GOMES: And that's not something we're going to make progress on in 30 days.

>>BRUCE TONKIN: No. And this is, again, one of those, I think I'd take a conservative approach rather than the --

>>CHUCK GOMES: Mm-hmm. Now, for the sake of the introduction of TLDs and assuming that IDNs roll out at the same time, we're going to have to get a better understanding of what that means, what two characters means and so forth.

>>BRUCE TONKIN: We do.

And, again, for this one, I'd put some -- as soon as you get to the IDN issue, put some examples of what it looks like at a display level and what it looks like in the DNS.

>>CHUCK GOMES: Mm-hmm.

>>BRUCE TONKIN: Just make it clear what it looks like. Because they're two different layers completely technically.

>>LIZ WILLIAMS: Chuck, just before you go on, I'm sensing that there is going to be some utility in a set of correspondence to the various chairs of the supporting organizations and advisory committees about particular portions of the work that we're moving ahead on.

And I wonder if -- of course, we need to do that in terms of the status of the final report to let people know formally what we're doing rather than just sort of briefing stage.

But there's a set of things that you've come up with in your reports that really do need to be directed to the GAC or to the CCs or to the technical community that require their specific comment.

>>CHUCK GOMES: Mm-hmm.

>>LIZ WILLIAMS: So that's a job of work that I would put together for me in terms of drafting that correspondence to make sure that we have a comprehensive record of things that we've sought advice on, so, for example, Steve's not here, but we need to send things to the SSAC, get security and stability issues for particular kinds of things. And we need to send them that. So maybe we need to do that formally. And I can do that after this meeting.

>>CHUCK GOMES: Yeah, I think you're absolutely right.

>>WERNER STAUB: I just think it's important in this context to differentiate even the asking of the question on the basis of script. It is not quite the same thing to have an IDN graphic two-letter IDN, as opposed to Cyrillic or Greek two-letter IDN or, again, in another language, such as Arabic. It's absolutely, you know, unrelated in terms of what kind of issues there are associated with it, depending on the scripts.

>>CHUCK GOMES: Yeah.

>>WERNER STAUB: So if the question is asked, well, just are two letters okay, or not okay, then the thing is going to go around in a spin, because if it wasn't precise enough, it would have to be asked in the precise context of the given script.

>>CHUCK GOMES: This was very difficult to deal with because of the complexity that gets involved there and the different scripts.

>>BRUCE TONKIN: Yeah, I think -- some of the things on reserved, just another layer of thinking about it, I think Philip made the point right up front about one of the reasons why some things have been reserved is to avoid confusion, I think you're saying, Philip, is kind of one of the guidelines.

I think confusion occurs at two levels. There's human confusion and machine confusion.

And so some of the issues are related to machine confusion. And, you know, I gave the example of a dot EXE as a domain name could well confuse machine software. And then there's human confusion.

So two-character IDN names probably -- may not be an issue at all at a computer level, because, you know, when you look at the XN dash dashes and they're relatively long names, they're quite differentiated, but they can be confusing at the human level.

So it might be well worth the reserved name group perhaps recognizing some of the types of confusion, I suppose, that happen. They're not just at the human -- they're human and computer. They're two different levels. And I think in some of the testing that happens to resolve some of these questions, you actually have to clearly identify, I'm doing a technical test with a range of different computing software to see if a range of issues arising at the computing level. Or is the issue residing -- because it's not actually a technical test at all, it's a human test. I've done a focus group or something and invited 20 people off the street and 19 out of the 20 had a problem with this. Kind of different level of testing, I think.

>>CHUCK GOMES: One of the things we're going to have to be careful of is to make sure that what the working group is tasked with, an additional 30 days is realistic. Because you can just see what we're coming up with here.

>>BRUCE TONKIN: Yes.

>>CHUCK GOMES: And a lot of what we're coming up with require a lot of behind-the-scenes work. And we're not going to be doing anything about it now, but we have to be cautious.

>>BRUCE TONKIN: And I think what I've been getting towards is, here's a set of stuff that we want to be careful of and we want to reserve the first round. And this is the top level. And here are some issues that were raised, but there's not strong support around those issues, and so we're not making a recommendation in that regard.

So I've seen, for example, ideas of putting in famous trademarks and things like that, which is nice as an idea. But I don't think that has strong support, and it's not something that I'd be kind of doing in terms of a new gTLD report.

But concepts around character confusion and the fact that a lot of these are based on some original decisions in the technical community, I don't think I'd suddenly overturn those decisions.

I think I'd start conservative in that area.

>>CHUCK GOMES: No, I'm with you on that.

And as far as like you mentioned strong trademarks, I think we've got a process in the new TLD process to deal with that already.

So -- And whatever the -- I don't know if the pro working group will do something there, too, but we've got the challenge process for those.

>>BRUCE TONKIN: Okay.

Tagged domain names.

>>CHUCK GOMES: Okay.

Tagged names. Let me know if you need me to explain the tag. Hopefully by now, everybody in this room understands what that is.

Bob Connelly had suggested we should say with hyphens in both the third and fourth character positions to make it even clearer, which is fine.

There's no IDN implications here, because what we're talking about is the DNS and what goes in the DNS. So that's why you don't see any IDN recommendations there.

So I can read these, if you want, but is there any -- Are there any questions about these?

We added some qualifying language because we had the debate in the working group, both in the subgroup and then later in the full group, about the issue of, okay, you don't need very many tags for IDNs. Why are we reserving them all?

And there may be only slight chances that the tag will change. So you could even reserve a subset.

But it was pointed out that it is possible that tags could be used for other reasons besides IDNs. And hence, you see the language there.

We're not restricting the use of tags for IDNs. Certainly that's a real live issue for us now. But hopefully that language is good for the future, too, in other applications.

Any questions, comments on that?

>>BRUCE TONKIN: I like your second point there. I think that's a good one.

So basically, in terms of the publication process, you'd be publishing both forms, essentially.

>>CHUCK GOMES: I'm sorry, I didn't hear that.

>>BRUCE TONKIN: The second point there, you've got for each IDN gTLD proposes, the applicant must provide both the ASCII compatible form and in local script, Unicode.

>>CHUCK GOMES: And that's a recommendation we got from the expert consultation we did with Cary and RAM. Tina was involved behind the scenes. She wasn't able to participate in that call because she was traveling, but that was what they suggested.

>>BRUCE TONKIN: I'm not sure that everyone would understand that, though.

>>CHUCK GOMES: Yeah, it's a tough one. I'm not sure people are going to understand a lot with IDNs

[ Laughter ]

>>CHUCK GOMES: But, yeah. Certainly, Mr. Chairman, if you can suggest improved language in that one, I invite it.

>>BRUCE TONKIN: Well, I suggest -- yeah, that's classic language you will get from the technical community, which is nice. But I'd put some examples. So in the one above you gave an example, and I think that helps clarify the language. But in your point two, you don't have an example.

So I suggest you give one.

>>AVRI DORIA: Putting an example is good but I wouldn't recommend changing the language at all.

>>BRUCE TONKIN: That's what I'm suggesting, Avri, yeah. I like the language because it's precise but I don't think most people would understand that language, so I think it needs an example to clarify that.

>>CHUCK GOMES: Good suggestion.

Anything else on tagged?

Okay. NIC, WHOIS, www.

There's a unique quality of this reservation requirement.

The three strings there are reserved for registry operations. They are not just reserved in the sense that they can never be used. Okay?

Just to clarify that for you.

And at all three levels, we recommend that they must be reserved. And that we don't try to translate them, and then reserve IDN versions of them.

And again, that came from discussion with IDN experts in that regard. And they made it very clear that the complexity, or even the -- whether it was even realistic to do, of trying to accomplish that would be something that would be horrendous.

So that's the basis of that recommendation.

>>PHILIP SHEPPARD: Chuck, in your discussions, did you get an answer to the question why www, for instance, but not ftp and others?

>>CHUCK GOMES: You know, we didn't specifically explore ftp but we talked a little bit about http -- oh, you did in the -- I don't know.

We looked at http, https and html, and we found out -- we found some places where they are registered.

>>MARILYN CADE: At the second level.

>>CHUCK GOMES: Yeah, second level.

>>MARILYN CADE: In two, I think maybe three instances. But that doesn't answer the question of whether they should be reserved at the top level. And I think, Philip, is that what you were asking?

>>PHILIP SHEPPARD: Exactly.

>>CHUCK GOMES: We did not pursue that.

>>MARILYN CADE: I'll just say that the earlier discussion about being pragmatically conservative -- I'm sorry, there was a different phrase for it.

>>PHILIP SHEPPARD: The precautionary principle.

>>MARILYN CADE: Yeah. My own view is we may want to revisit that at the top level. It may be one of those things which just ends up causing endless debate from some in the technical community and not from others.

>>CHUCK GOMES: Yeah, I'm not sure that it would be realistic for us to visit that, but it's a good point.

>>BRUCE TONKIN: So from a new gTLD process point of view, I would take (inaudible). I can't think of what the software implications of that would be. It's probably not an issue. But if it was an issue, then that would be raised by the public and then evaluated by that technical evaluation.

>>CHUCK GOMES: It could be challenged, yes. Good point.

>>MARILYN CADE: Yeah.

>>BRUCE TONKIN: Thinking technically just very quickly off the top of my head, http wouldn't be an issue but html would be. But just giving you an example. I can explain simply why that's the case, but it comes down the way those words are used by software.

>>MARILYN CADE: At the application level.

>>BRUCE TONKIN: At the application level, yeah. It's a software issue rather than a human issue.

>>MARILYN CADE: Bruce, could I ask a related question? This is a topic that I'm wondering if in the introduction it's not worth having a couple of sentences on. And that is the reasons that names may need to be reserved may be for technical reasons, political reasons, or because of incompatible interactions with applications.

>>BRUCE TONKIN: Which is technical.

>>MARILYN CADE: Which is a technical issue.

But it may -- You know that. I think there are many people, many lay people, who would think that that's a -- it's a sub-element of a technical issue. But it's at the application level, not at the DNS level.

>>BRUCE TONKIN: Correct.

>>MARILYN CADE: So I'm wondering if it might be worth the group just having a short introductory paragraph that sort of the explains the three or four reasons, the general categories that we are considering reserving names.

One of which is political, one of which is technical.

>>BRUCE TONKIN: Sure, yeah. I think that's kind of what Chuck is trying to do anyway, is break it up into categories.

Avri.

>>AVRI DORIA: This is a question. I guess I've heard a couple of times the reasons why dot html might be a problem, dot XML. Are we saying everything that is an extension of dot, something that is an extension that sometimes means kick off a program to some piece of software is, indeed, in that category?

>>BRUCE TONKIN: I think what I'm --

>>AVRI DORIA: Because that's where I haven't been clear, because there's a lot of those extensions.

>>BRUCE TONKIN: That's right. And this currently comes down to aligning some of these things with perhaps the string criteria in the new gTLD process.

But we've talked about some things that are reserved in the sense that you can't have it because it's widely accepted that that's going to be an issue.

And then we've talked about processes where a name can be disputed based on one of these. So they are two separate things.

So the reserved word list, I guess you are saying, this is where the communities reached a view that this particular string shouldn't be allowed.

And then there's other categories that we haven't thought about.

So what I don't think we should be doing is trying to create a list of everything you can think of that can cause a technical problem.

I think where we know it causes a technical problem and it's tested, it should be on the reserve list.

But where we don't know, that's then subject to a process, so using the does exe example, if I was a staff member and somebody was proposing that, I would say most likely that will fail when it goes through the technical step.

If it did get proposed and it went through the technical step and that technical committee says no, it's not allowed because of these reasons, at that point I would add it to the reserved list.

That's kind of the way I would see that from a procedural point of view.

So I'm not trying to create a list up front of all possible extensions that might have an issue with software.

But I'm saying once you have proposed something like dot EXE or dot XML and it goes to that technical group and they have done some testing and they said yeah, the likelihood of an issue is high, they say no, you can't have it, and at that point it gets added to the reserved names list for the next round, essentially.

>>AVRI DORIA: But the issue, then, is that there would be technical testing to prove it was harmful or to prove that it hit -- if you are setting up, let's say, a risk ratio --

>>BRUCE TONKIN: Yeah.

>>AVRI DORIA: -- a risk-to-benefit ratio, you're saying that when somebody applied for it, it would require testing and not just someone saying, gee, you know, I think dot EXE is a problem.

>>BRUCE TONKIN: I don't know that I would go quite that far, Avri, because you want to have a process that's timely and cost effective.

So I think what we're talking about there is it's going to a panel of technical experts and that panel as a group is making a decision.

So yes, there might be an element of that panel using judgment. I'm not sure that I'm going to say they have to kick off a six-month project to do technical testing.

I guess it just depends on a case-by-case basis. I'm just trying to think that through.

>>CHUCK GOMES: Bruce, you may want to, in that case, rather than just saying if it was stopped in the new TLD process because of technical reasons, you can't go on for six months to do a test then.

But before it's added, that may be the time to do some more testing before you actually add it to the reserve list.

>>BRUCE TONKIN: That's fair. That could be a way of looking at it, yeah.

Yeah, there's different -- one is kind of a fast check process, and you are trying to have a process for speed.

>>PHILIP SHEPPARD: I think that suggestion is probably right. Should we, therefore, capture a comment somewhere in this report in recognition that this list of just three strings is by nature incomplete, and that our vision of the process going forward is the one you described? I think that might be useful clarification.

>>BRUCE TONKIN: Yeah.

>>PHILIP SHEPPARD: Because my instinct at the moment I read that was why just only those three?

>>BRUCE TONKIN: My first comment on that, just in terms of where this goes, this isn't actually about technical issues. These aren't saying you can't have these words. These are reserved for registry operation. So this wouldn't be the appropriate place in the report to do that.

But I'm more picking up on Avri's concern that she was giving the example of the say the dot HTML which is currently not reserved, by the way, and I am not suggesting it has to be put in the list. I'm just saying how would that be dealt with in the new gTLD process. It would be dealt with by the string criteria check on technical issues.

And then the second part of Avri's question was should it be on a reserve list or not. And I'm saying I don't think we should spend hours debating what those words should be to add to the list, but we perhaps have a process for, after a it's gone through the new gTLD review, perhaps there's some further tests or whatever that are done and then it can be added to the reserve list.

>>AVRI DORIA: By I way I want to comment I wasn't saying I think they should be on the reserve list. I was saying what made those two different from the 2- to 300 other extensions that we use to kick off a program.

>>BRUCE TONKIN: Which two are you saying?

>>AVRI DORIA: The EXE, XML.

>>BRUCE TONKIN: They're not. I just picked two examples.

>>MARILYN CADE: Can I ask a clarifying question? You were talking about reserving -- are we talking about at the top level?

>>BRUCE TONKIN: Yes.

>>MARILYN CADE: Because here, of course, we're addressing all together top, second and third level. And that would still be --

>>BRUCE TONKIN: You're not, actually, here.

>>MARILYN CADE: The following names must be reserved: Dot NIC, WHOIS --

>>BRUCE TONKIN: So that is a --

>>CHUCK GOMES: Is there questions about the top level? Should they not be reserved there? I would think, again, the conservative approach is yes.

>>MARILYN CADE: I just wanted to be sure -- As you know, I fall into the conservative approach. But I just wanted to be sure everyone understood that. Because --

>>CHUCK GOMES: Mm-hmm.

By the way, just a kind of side observation, I think it's kind of a little positive affirmation that we're finding some use of the processes we've talked about setting up for challenges and so forth, even in our discussion here. That's a good sign, I think.

>>BRUCE TONKIN: Okay.

This is a hot topic. We have not much time left today, but I thought we might as well kick this one off.

How many more have we got? Can we quickly go through the rest?

>>CHUCK GOMES: We're getting there.

You have controversial is the last one.

>>BRUCE TONKIN: Let's hear what you have to say about geographic, and then let's hear what you have to say about controversial.

>>CHUCK GOMES: Okay. And I'd like, at some point, would like to talk a little bit more about the other names at the second level, too, because there's some debate whether that's even in the task of the working group because those names are not in the appendices.

>>BRUCE TONKIN: Let me give a time check.

I personally have a commitment at 6:00, and I can't go on for too much longer but that doesn't mean you can't just continue chairing the meeting if you want to go through those other categories.

>>CHUCK GOMES: Everybody else okay with that?

>>BRUCE TONKIN: How many people would like to stay on for another half hour or so to go through this report?

>>MARILYN CADE: What time is it now?

>>BRUCE TONKIN: It's 6:00.

>>CHUCK GOMES: And if we don't, Bruce, I guess the question is asked, when do we do it?

>>BRUCE TONKIN: That's obviously the next part of the question, yeah.

>>MARILYN CADE: Could we do tomorrow morning at 8:00 a.m. for an hour before --

>>CHUCK GOMES: Did you see how many people were here at 9:00 a.m. this morning?

>>MARILYN CADE: I was here.

>>CHUCK GOMES: You and me tomorrow morning at 8:00?

[ Laughter ]

>>MARILYN CADE: So here is the proposal. Chuck and I will be meeting here tomorrow morning at 8:00 a.m. to make final decisions.

Do I see the hands of anyone who wishes to join us?

[ Laughter ]

>>CHUCK GOMES: Sorry, Bruce, we kind of threw off. Was there enough people that can't continue that we....

>>BRUCE TONKIN: Just ask the question again. Put your hand up if you want to stay on for another half an hour for Chuck to present that. Who is available for the next half hour. Just put your hand up.

>>CHUCK GOMES: Not many, so it doesn't make sense to continue.

>>BRUCE TONKIN: So that then puts me into the next part of when we reconvene, I guess.

It's a real struggle, actually, because we've got the IDN stuff, we've got --

>>CHUCK GOMES: Disputes.

>>BRUCE TONKIN: Yeah.

>>CHUCK GOMES: And the geographic and -- Let me encourage people, if you would, please, if you would read the geographic and geopolitical reservations and maybe a little bit of the background, the background is very helpful in both of those. It's not brief in either case, but it would really be beneficial to read those. The controversial and this one.

And that would probably make our time, whenever we find time, go a little bit more efficiently. Because there was some really good thought and research done on both of those categories. I was very pleased with the work that was done by the subgroups in those, and they are recognized at difficult categories.

So take a look at that, and then maybe we could start off with questions instead of trying to, you know, repeat it for everybody.

>>BRUCE TONKIN: Also, just as a matter of interest, a show of hands, how many people in this room are members of the pro working group tomorrow? How much overlap is there?

Four people. Because the other option is we go in parallel with that meeting tomorrow. That's from 4:00 to 6:00.

>>CHUCK GOMES: That's not a bad idea.

>>MARILYN CADE: (inaudible).

>>CHUCK GOMES: That's okay with me.

>>BRUCE TONKIN: I think what we might try and do is use that session for some of the new gTLD.

>>CHUCK GOMES: We'll need another room. Or shall we just do different sides of the table?

[ Laughter ]

>>BRUCE TONKIN: That's right.

>>TIM DENTON: It's Tim here, Bruce. Tomorrow, you are thinking of what time?

>>BRUCE TONKIN: Well, there's two suggestions, or probably a combination of the two. I think there's a benefit starting earlier tomorrow morning. We have a new gTLD session starting at 9:00, finishing at 12:00. I would propose we start at 8:30 if we possibly can. That will probably mean we actually start at 9:00 but that's better than starting at 9:30. So if we can aim for 8:30 as a start time for tomorrow morning.

Then we've got sessions on WHOIS from about 12:00 to about 3:00 or 4:00.

So I am suggesting that we use some parallel time between 4:00 and 6:00 for further work of the new gTLD committee, which would include partly this.

>>TIM DENTON: And that will be up on the phone in so I can get in?

>>BRUCE TONKIN: That's right.

>>TIM DENTON: I cannot guarantee my presence at the equivalent of 4:30 my morning.

>>BRUCE TONKIN: That's understanding, Tim.

>>TIM DENTON: I did this morning, but it was a half an hour of silence.

>>BRUCE TONKIN: It's especially hard when we are doing stuff a little bit dynamically. But I will talk to Glen about how we can arrange a separate room.

>>TIM DENTON: I'll hear from somebody.

>> (Inaudible).

>>BRUCE TONKIN: So wouldn't Marilyn be from the business constituency?

>>MARILYN CADE: I've got to be on a plane.

>>BRUCE TONKIN: And you have no one else?

>>MARILYN CADE: To do what.

>>BRUCE TONKIN: I'm not trying to make decisions at these meetings. I'm just trying to have a dialogue.

>>MARILYN CADE: Just ask me the question again.

>>BRUCE TONKIN: The question -- Mark has just raised it's an issue for the business constituency because he would be involved in the pro working group and wouldn't be available for --

>>MARILYN CADE: I can be on the phone until probably 6:00. My plane doesn't take off until 7:00. I can be on the phone. That's not a problem. But --

>>BRUCE TONKIN: Or you and Philip split your time, one of you on the pro group and one on the gTLD.

>>MARILYN CADE: Neil (inaudible).

>>CHUCK GOMES: First of all, Mike has been involved in these categories within the working group so I think he is well educated there: Obviously it would be nice to have his contributions. But probably there will be enough people to cover that. And I know Philip is really capable of reading those and getting a good grasp of them.

>>BRUCE TONKIN: I'm just trying to make the most use of the time we have available.

>>CHUCK GOMES: That's why I'm suggesting, I think it's still probably the best thing we have to work with.

>>BRUCE TONKIN: Yeah, okay.

So we'll try and make use of the time 4:00 to 6:00 for the new gTLD stuff and the pro thing, work in parallel.

>>CHUCK GOMES: And of course we need to get word out to a lot of people who aren't here, so I'm sure Glen will do that.

>>BRUCE TONKIN: We will put that out on the appropriate list so we don't get in trouble.

And I also have a start tomorrow morning of 8:30 a.m. And for those here, to communicate to your colleagues that were planning to turn up tomorrow morning. And I will put IDN on the mailing list. But I think that's the best we are going to be able to do.

It's just going to be a struggle all week, I think, to try to give enough time to the --

>>CHUCK GOMES: By the way, your 8:30 time, remember we lose an hour tonight.

>>BRUCE TONKIN: Thank you, Chuck, that's a very timely reminder.

So 7:30 tomorrow morning.

[ Laughter ]

>>AVRI DORIA: Don't say that. 8:30.

>>CHUCK GOMES: That's what it means.

>>AVRI DORIA: It won't be that tomorrow. It will be 8:30.

>>BRUCE TONKIN:But for those who choose not to change their watches, it will be 7:30. It is 7:30 relative to the time now.

>>MARILYN CADE: I think I did daylight savings time already, so I'm practiced.

>>BRUCE TONKIN: Okay. Well, thank you all and thank you, Chuck, for all the work the working group has done on this.

>>CHUCK GOMES: And let me tell you, it really was a team effort. We couldn't even have come close if there weren't a tremendous number of people who worked long hours.

(6:06 p.m.)