GNSO Working Session Sunday 22 June 2008 Afternoon Session >>CHUCK GOMES: Okay. We're going to go ahead and start. I'm going to give Avri a break so she can work on a presentation for later. And then she'll pick up when I have to leave in about an hour or a little less from now. Oh, yeah. Okay. Our topic during this session has to do with the IDNC and -- so IDN ccTLDs. And a couple purposes specific for the meetings today and tomorrow. In the GAC meeting, the joint GAC meeting with us at 4:00, that is one of the topics. And in our meeting later in the week, on Thursday, over lunch with the ccNSO -- oh. Was I looking at a different agenda? >>AVRI DORIA: No. Sorry. One of the things I had said earlier -- maybe this was when you were out -- since we didn't cover Jon's paper before lunch, we moved it to first thing after lunch. >>CHUCK GOMES: Okay, I missed that. I'm sorry. No, I wasn't, obviously, or I wasn't listening. That's a possibility, too. So let's talk about Jon's paper. Jon, would you be so kind as to share the main points of your paper so that we can maybe use that as a takeoff for discussion? And by the way, his paper relates to this topic of IDN ccTLDs. So it fits very nicely. Jon. >>JON BING: Thank you. It is a very modest effort to sum up some of my own doubts at the earlier stage. And there are by no means any original thoughts in it, but there is a point of concern. In the -- introducing the new top-level domains, there has been talk over fast track. And there's also been mention of the possibility of the CC domains being given perhaps one shot each for fast-track additional domain. This is commented in the bullet point just being circulated. And I won't say anything more about this. But my discussion presumes that there is -- is a start of CC new domains before the PDP is fully developed and adopted. And it has been mentioned that the possibility may be of a two-year period to go before a PDP is fully adopted. When it's adopted, it will be given a retroactive action or force through the contractual arrangements, which makes the contracts dynamic. And that retroactive force presumes, however, that there is a contract which may make -- may implement that action. And here is where my doubt comes in. Because, first, if the CC domains are given an additional domain, that may be used perhaps in a different way to the typical use of a CC domain today, which is noncommercial use. There certainly are different examples of commercial use, also CC domains. And my suggestion is that the fraction, the number of such examples, will increase by launching of the new domains. They will then have certain advantage in working for two years, or a period before the generic top-level domains are launched. And in that time, they may get the certain advantage in the marketplace. Then comes the PDP and wants to take retroactive action and coordinate the field. And that presumes that the CC domain is bound to implement such -- such a policy. And as you know, there are several CCs which do not have any proper contractual relation with ICANN. This is explained by several ways, one of them being that the relation between the CC domain and the former system is traditional and old, and therefore it has been difficult to introduce the ICANN regime fully over these rather independent domains. And they are also noncommercial to a large extent, and have a tradition within the Internet community. But if they -- this has led them not to have the contractual framework in place. And there is also argument -- in my mind, very weak argument -- that there are sovereignty issues at stake, that a country or nation cannot contract with a private organization like ICANN. I think that is a false argument. But it has quite often been referred to. This -- >>CHUCK GOMES: Jon, would you go over that last point just a little bit again. Restate it. >>JON BING: Sorry, yes. You'll excuse me if my language -- >>CHUCK GOMES: That's okay. I just want to make sure that everybody gets that. >>JON BING: The argument is that the nation is a sovereign nation, and if it makes a contract, it has to make a contract to another body in the international public law domain. And it is not seen by someone that ICANN, being a private organization under state, U.S. state, law, belongs to that domain. As I said, I think that is a false argument, because it is quite usual that the registry is in the private domain as an operator with telecommunication service. >>CHUCK GOMES: So what you're saying, then, is the argument that we've heard often that it's not possible for a government to enter into a contract with ICANN in this specific case, if the government's involved in the IDN ccTLD, that that argument is a false argument? >>JON BING: Yes, it is -- I see it like that. If you take the very similar situation in telecommunication area, there's nobody making the argument that a country can't, for instance, enter a contract with AT&T because AT&T is in the private sector. And, obviously, the telecommunication operator in the country usually would also be in the private sector, though the country may have some control over such an important national resource. >>CHUCK GOMES: Thank you. Adrian, did you have another question? >>ADRIAN KINDERIS: Adrian Kinderis. I think that it's more of a -- it's not whether you can have an agreement. It's -- from what I understand now, it's more of what is the nature of that agreement. I believe that, for example, Saudi Arabia have overcome the issue of dealing with "the government" or the U.S. government as such, but now it's more of, well, what sort of agreement are we signing. So I think it's -- I don't know that you can necessarily look at it and say whether a government -- or whether an entity will sign a contract with the U.S -- you know, seen as the U.S. government or with ICANN in that way, it's more of what sort of an agreement will they be signing. >>CHUCK GOMES: Go ahead. >>JON BING: Thank you. Yes, that's certainly -- certainly one possible way of looking at it. I think there is a lot of -- there are several false versions of this story being discussed. So I'm not quite convinced that this is the basic reason. But in the context I'm presenting it here, it's only to emphasize that it may be a reluctance to enter into the contractual arrangements with ICANN necessary to make the PDP adopted retroactive. And if that is the case, you will have the possibility of arising two different regimes for the new top-level domains, one governed by the PDP, and one not governed by the PDP, but being more or less let on its loose. And, therefore, this may, if you want to be dramatic about this vision, it may sort of pull the system apart, because there will be different regimes, different law applied to different domains, and the whole structure of ICANN may be under such tension that it may tear apart because of this dynamic elements. I'm not saying that it will happen; I'm only saying that this was one of the reasons I'd like to make this note, in order to draw attention to that possibility and have -- share that view, simply. >>CHUCK GOMES: Let me interrupt you again. I think, Carlos, did you have something? >>JON BING: I'm finished. >>CHUCK GOMES: Oh, you're finished. >>CARLOS AFONSO: It's Carlos Afonso, from NCUC. Just some quick comments, and confirming what Adrian says. And I really believe that in this case, it's not a matter of you can or you cannot enter into an agreement with a private entity. But it's much more an issue of the contents of this contract. For example, this is something very related to arbitration. From what I know, in Brazil, that's the case, the Brazilian government cannot enter into an agreement with arbitration clause, because there are some indisposable rights that cannot be subjected to arbitration. So maybe this is just one example of a certain number of clauses that could not be -- could not be contemplated in agreements with states and private companies, which is an example. >>CHUCK GOMES: Thank you. Anybody else have a question or a comment? Tom. >>THOMAS KELLER: Yeah, I guess the comment I would have is that I find it kind of strange that we should start treating the CC space now in different levels, actually. So you have the old ccTLDs, but only a few of them have contracts, and they were actually bullied into contracts at a time when they had redelegation going on, but most of the major ccTLDs don't have any contracts. And I don't see why we should enforce now contracts on them to have some kind of a process established with them. First of all, it kind of achieves problems with the incumbents. And on the other hand, they can join the ccNSO and I guess these registries, or the new ones, would join the ccNSO and then they're bound by the scope of the ccNSO PDP process. So I don't see anything being torn apart, or whatever. The GNSO and the gTLD world was always totally different to the CC world, and you don't see that change in the future. >>CHUCK GOMES: So you don't -- if I understood you correctly -- just a second, Tim, you're next. So you don't -- I just want to clarify what Tom said. So you don't think we ought to push the contract issue with ccTLDs? Is that what I heard? >>THOMAS KELLER: Yeah, absolutely. >>CHUCK GOMES: Tim? >>TIM RUIZ: I have a little different view. Actually, the exact opposite view. [ Laughter ] >>CHUCK GOMES: Just a little. >>TIM RUIZ: My concern is, once we, you know, allow these IDN ccTLDs, then it's not the ccTLD space anymore. You know, it's beginning to expand. They're being given, you know, first opportunity at this particular market with IDN TLDs. And then they're going to be doing it without any, you know, agreement with ICANN or the similar, you know, consensus policy restrictions, whatever, you know, use of accredited registrars and on and on, that the gTLD space is required to have. So, you know, I don't understand why we would hand them all of this on a silver platter without any expectations that there's some agreement between them and ICANN that's going to bind them to something at least this -- the results of the PDP, if not even more. >>CHUCK GOMES: Thank you. Olga. >>OLGA CAVALLI: Thank you, Chuck. This is Olga Cavalli. First, I would like to commend Jon for his document. I think it's very good, and it raises some concerns that we already talked about in the summer with our drafting team for the responses to the GAC and ccNSO. From my perspective, I think it's -- I think that we already have two regimes. So I agree with Jon, but I think it's happening today. ccTLDs have a different regime than gTLDs. And I'm not sure if this is fair for both parties. Thank you. >>CHUCK GOMES: Jon, go ahead. >>JON BING: Thank you. Yes, my point was only that for the new round, I want to ensure that there was a contract in place which made the party obliged to take on the results of the PDP. I -- I find that, as a lawyer, I'm fascinated by the way ICANN is being constructed, and occasionally, I find that my fascination is not really appreciated outside a circle of people who think in legal terms. But this is an international organization which wholly is based on the contracts with ICANN. If one of those chains -- links in those chains is broken, there's absolutely no authority in -- formally that ICANN has. That is completely different from a usual international organization, where a treaty will communicate some of that sovereignty on the nation into the treaty organization, which then can be -- the treaty organization has an authority which flows from the sovereignty of the nations, and they can use this authority to regulate the space within the treaty boundaries. Such is not the case of ICANN. ICANN has to say that the reason that you have to do this is that we have a contract, and that contract is linked into this contract and all the way back to the original contract with ICANN. And if you're not making that this is -- is very, very clear and certain, one will have problems. And, of course, these problems will become more severe as time goes on and as the number of parties expand. And that is exactly what is happening now. We're expanding the number of parties by a factor of some rather large factor. And the administration of the contractual system will become a critical factor in making the domain name system a unified system, in my opinion. >>CHUCK GOMES: Thank you. Cary. >>CARY KARP: I move with some degree of discomfort, but, nonetheless, between the camps here. I spent the morning with the GAC. I spent yesterday with the ccNSO. And here I am now, and in my chest beats the heart of a gTLD registry operator. But I note from the CC perspective the essential difference between CCs and Gs have nothing to do with the strings of their origin. It has to do with the fact that CCs do not exist by contractual obligation to ICANN, and the Gs do. And they expect that to be grandfathered into this fast-track process. They're talking about IDN ccTLDs for one reason, and one reason only, and I think it behooves this organization to be very keenly attuned -- this group to be very keenly attuned to the nuance in that. >>CHUCK GOMES: So I think the question that we need to discuss is, where do we go with this. And in terms of our discussions with the GAC and in terms of our discussion with the ccNSO later in the week, as well as in meetings with regard to IDN ccTLDs that are occurring at other times this week. Jon, if there was one or two points out of your paper that you think we ought to put forward, what would those be? >>JON BING: I think the essential point is to make sure that there is a contractual arrangement with any organization setting up a new CC -- a new top-level domain, that there should be a contractual arrangement with any setting up a new top-level domain, whether CC or generic, and that that contractual arrangement made the organization obliged to take on the result of new PDPs. >>CHUCK GOMES: So what -- the key element of that contractual relationship, then, would be to ensure that they abide by the ultimate CC PDP; is that what you're saying? >>JON BING: Yes, I'm saying that they abide by the outcome of policy development processes within the -- within the -- >>CHUCK GOMES: So in the case of the Gs, it wouldn't be that process; it would be our own processes; correct. Cary and then Adrian. >>CARY KARP: The documentation that underlies the fast track recognizes need for some contractual instrument. It's just that this instrument is not going to be based on G boilerplate, it's going to be based on the minimal extension of the CC basis of existence into the ICANN-sanctioned realm. And the whole PDP thing has also been very, very cautiously thought through and thought about. And it is the essence of the fast track that it terminates the moment that the actual PDP has been conducted, that it's a fast track somehow bypassing the policy-making process that provides the legitimacy for suggesting anything in the first place. So it's very intricate. And the document does touch all of the points that are being raised here. But, again, touching them from considerably different perspectives from the ones that we've got in mind as we discuss this. >>CHUCK GOMES: Thank you. Adrian. >>ADRIAN KINDERIS: Yeah, Adrian Kinderis. Maybe I can help understand what I need to get out of this. If it can be explained to me what we're fearful of, contract or no contract, say there's nothing. If we can lay out on the table as a group what we're fearful of, maybe we can understand, you know, why we need to push for a particular position. Is that going back too far? Is that a lack of understanding? >>CHUCK GOMES: No. I think that's very valid. And Jon, at least indirectly, in his paper, hit on that a little bit when he was talking about a first advantage. And whether it's a first advantage or whether it's an advantage because of less stringent contract conditions, that's a competition issue. And so I think that's really the basis. And what we need to do as a council is to see if we have a unified position. Now, we have a unified position in our response to the issues paper. And, in fact, if you -- everybody should have a copy of that at your table. And just -- not a copy of that. Excuse me. A copy of, I think, 11 bullet points that I took out of our executive summary that seemed to be particularly relevant for our discussion today. And if you look at the very last bullet point, it says, "ICANN should have a contract or some other form of agreement with the IDN ccTLD operator that includes appropriate technical, operational, and financial requirements." Now, that's a lot more than what Cary was just talking about, and even what Jon was talking about. And I fully appreciate Tim's position, 'cause, you know, as a gTLD person, I'd a lot of to see them have all the requirements I have. I don't think that's realistic. And we have to decide, do we want to be realistic and propose something that might work but -- or hold fast on that position where they have all of those elements in their contract. Okay. Who was -- I think I saw some -- oh, it was Tim. Thanks, Tim. Edmon was in my way. I couldn't see. >>TIM RUIZ: Yeah, I don't disagree, Chuck, that -- you know, about being realistic. And maybe the approach would then be that there's some sort of -- and I think it's kind of hinted at in what we've recommended up until now, that there's some kind of fast track for the existing gTLDs, so that there's some balance there at least giving them the opportunity to introduce, you know, TLD IDNs in their name space, as well as the ccTLD name space, can keep that par time wise. >>CHUCK GOMES: Thank you. Cary, go ahead. >>CARY KARP: It might be worth noting along that line that the entire discussion in the CC context derives from the fact that there's some notion of natural language nexus attaching to a domain that's supposed to represent a territory or some government entity. And there's been some equivalent discussion on the G side of this, but it's been extraordinarily nonfocused, very, very sweeping, very, very broad, and easily dealt with on that basis. And there are, in fact, equivalent arguments that can be leveled towards the CC approach, but nobody's leveling those arguments. And the question is if this raises run or if it's high time for the Gs to see if there is some defensibly arguably principle that might justify a G fast track parallel to the CC fast track. >>CHUCK GOMES: I don't see any other hands, so I'll take this opportunity to comment. I believe in our paper we said exactly that thing. We said that if there's a fast track -- I don't know if it was this exact words -- if there was a fast track for Cs, then the Gs should be able to do that as well. I think the underlying principle there is that neither Cs nor Gs should go before the other, just to keep it a level playing field there. >>CARY KARP: Well, the point that I think probably needs to be noted here is that nobody -- when it was agreed that there might be a principle that the Cs can evoke, the Cs went ahead and really drafted what they regard and what appears to be a compelling argument for implementing that. And on the G side -- >>CHUCK GOMES: For implementing what? >>CARY KARP: This fast-track thing is just about to become reality, to be implemented. And the Gs are still talking about the fact that there actually might be reason to want to have a G fast track as well. So there's a huge distance out of the gate that the other guys are at this moment. >>CHUCK GOMES: Well, I'm not sure that we need a fast-track in the G's, because we have got a process that is -- implementation is being worked on, and it suits the IDN TLDs as well as it does the gTLDs with the possible exception of anything that we think is a prerequisite with regard to technical standard. And I know that's another debate issue that we won't get into here. So, you know, how do you fast-track the new gTLD process? I don't think that can happen. We would all like to do that. I could take a raise of hands right now and everybody would probably stand up instead of just raising their hands, we do that. The point is -- and by the way, when I look at the document, Cary, and I would be curious to get your reaction on this, what I see is there's an awful lot of implementation work to do with what they are proposing as the fast-track as well. So we may not actually be that far apart in terms of -- and in fact, ICANN's document in this regard kind of hinted at that, that probably they are going to happen about the same time. Do you think I assess that incorrectly? >>CARY KARP: I think there is significant enough likelihood that you may have assessed it incorrectly for a plan B to be kind of something we might want to yank out of a sleeve, yeah. >>CHUCK GOMES: And I'm all for that, because I -- and in my opinion -- I'm sorry, as Chair I shouldn't be talking so much, but as -- in my opinion, we need to stake that -- that is one point we need to take out very clearly. And I think there's a way that we can do that that shows that we are not trying to have an advantage ourselves. In my conversation with Suzanne Sene, who is the GAC representative in the council on this issue, she -- I told her, I said I think if you translate what we said in our paper -- in our response to their issues paper, you can conclude that we really don't think that either side should go before the other. They shouldn't go before us; we shouldn't go before them, unless one side particularly decides to do that. >>CARY KARP: Well, I'm not sure I have heard the same thing being said from the other perspective. >>CHUCK GOMES: You mean from the CC perspective? >>CARY KARP: Yeah. >>CHUCK GOMES: No, I'm not either, Cary. No, no, I agree totally. And that's ground we need to cover. I am with you all the way. Let me be quiet and let some other people jump in. Who else would like to enter this discussion? Mike. >>MIKE RODENBAUGH: Is it a discussion about any of these bullet points or just -- >>CHUCK GOMES: Well, we're kind of transitioning from -- that's a good question. It's a transition from Jon's paper into this. And his paper really relates to this. So not any of the bullet points. We should, for a moment at least, try and focus on the contractual issue, which was a key element of what Jon's paper dealt with. And what -- what he and -- and some of you missed what his discussion -- hopefully you read his paper. But key point there is there needs to be a contract with ICANN for the IDN ccTLDs to ensure that they follow the -- ultimately follow the -- whatever policy is developed by the -- in the CC PDP. It's going to take a couple years; okay? Some people have advocated for more -- more elements. In fact, our statement advocated for more than that in a contract between CC's and -- or IDN CC's and that. Was there another hand? Kristina. >>KRISTINA ROSETTE: I am having a really hard time with this. And here is why. From a substantive perspective, I agree with Jon that there should be, in the ideal world, if I ran it, that there would be a contractual relationship. But the concerns I have are, first, even if you say, okay, there's really no -- or the claim basis in international law for not entering into that agreement is not as strong as everyone would like you to think, I mean, let's be realistic. To me, I keep coming back to these are the governments. Whether it's directly or indirectly, these are the governments. So whether there is a valid basis for international law for them to say we're not going to enter into these agreements, the fact of the matter is it's up to them. And so if you have that -- In the other context, I also see a concern about the possibility of almost a kind of slippery slope. That if we say, okay, fine, you have to have or agree to enter into a contract with ICANN with regard to this aspect, I anticipate that there would be a concern that, okay, if you say that, then the next step is to go something more broadly along the lines of what we have suggested and so on and so forth. And what I am really ultimately having a hard time getting is how likely is all of this to really happen? And by continuing to pursue it, are we jeopardizing or undermining our future relationship with the ccNSO on other issues? >>CHUCK GOMES: Thank you. Avri. >>AVRI DORIA: Yeah, I would like to ask a question, I guess. And with all due respect to governments and their ability to do things, if there is a basis in international law for some sort of agreement, you know, whether it's contract, whether it's arbitration, then is it -- why is it well, their government, so it's up to them, if there is a basis in international law. If there isn't a basis in international law and governments do have a right to do exactly as they please, then of course you're right. But I don't understand why, given that there maybe a basis in international law to require such a thing, it is purely up to them. >>KRISTINA ROSETTE: What are we going to do if they say, "No, we don't want to." I guess that's what I keep coming back to. Even if there is a basis, what's ICANN going to do? You know. >>CHUCK GOMES: Well, of course they can do what they did to the new gTLDs when they -- and I'm not saying -- I am not advocating this, please. So get my qualification there; okay? What did they do to the new gTLDs, the first seven? When they sat down to negotiate and they wanted certain things and were told, if you want to get in the root, you will do this. So there is actually something ICANN can do. I am not advocating that position, but that's probably the only thing that they could literally do. Cary. >>CARY KARP: Two other factors. Contracts are foreseen in the fast-track documentation. And they all address issues of stability and security, all the kinds of things that might disrupt the stable operation of the domain name system are being very, very carefully tracked. And sure there is going to be a contractual instrument obligating any prospective operator to all of this stuff and again it's provisional. This is just to get some IDNs in the root. And when the CC PDP is complete, that will be the end of the talk of this. But there is the other recourse that they have, and that's if ICANN says, "No, sorry, you are not going to accept our contractual terms," they can send their Ambassador to the United States Department of State and wonder what on earth is this all about? Is it really true that the United States government is the only up with that can order things into the root? What about the rest of us? And I don't really know what an entity that exists by virtue of a Memorandum of Understanding with the United States government is going to do about what a cabinet secretary might decide. So it's -- it's a different situation. >>CHUCK GOMES: Okay. We need to keep this moving because we haven't got a whole a lot of time and we do need to be prepared for at least the GAC session today, but really also for the ccNSO session later in the week. Edmon, did you have anything to say on this as one of our representatives on the IDNC? >>EDMON CHUNG: Sorry for coming in late. Actually I was tied up. Did we talk about the IDNC generally yet? But we were focusing on Jon and the previous GNSO comments; right? >>CHUCK GOMES: I guess it depends what you mean by "talking about the IDNC." >>EDMON CHUNG: Specifically IDNC final report and, you know, the -- I guess the issues there, or whether we want to -- >>CHUCK GOMES: We talked about that in our last meeting; right? >>AVRI DORIA: Yeah. But one of the things that was on this agenda after Jon's paper was the IDNC ccTLDs and basically overview of the IDNC key issues which of course then does run into the outline you wrote of where the presentations were. But Edmon was going to give a sort of update on where that's gotten to because it's now in its final draft, and to what degree they cared about the GNSO's issues and how successful he was, et cetera. >>CHUCK GOMES: So would you like to do that right now? >>EDMON CHUNG: How much time do we have? >>CHUCK GOMES: Can you do it in five minutes? >>EDMON CHUNG: Okay. I will do it in five minutes. I guess if you haven't looked at the draft final report, do do that. I guess the -- we did have a final meet -- well, a committee meeting, a work group meeting yesterday, I think it was yesterday afternoon. And there are a couple of important changes from what was posted. The most significant change is the removal of the -- what is called the LEAP, L-E-A-P, Linguistic Experts Advisory Panel. Originally, the concept was to have the LEAP be a sort of experts' group to determine whether an IDN string is meaningful and representing the territory and is appropriate. But I think that has been a concern all along, actually, from my point of view, because it really puts a lot of burden on ICANN to create that group that would actually try to make determinations of whether an IDN string is a -- you know, is a meaningful present representation of the territory name. So in one sense, it's good that I think, you know, the group actually came to some sort of consensus to remove that, but it also brings up another issue which that was probably the -- >>CHUCK GOMES: Let me stop you a second. To remove what? >>EDMON CHUNG: The LEAP. One of the -- There were two committees -- >>CHUCK GOMES: I understand that. I am very familiar with that, but you are saying, then, that that has -- a decision has been made to remove that? >>EDMON CHUNG: There was consensus around the room yesterday to remove it completely. And in replacement -- What is that? >>AVRI DORIA: A complete consensus or remove it completely? >>EDMON CHUNG: Remove it completely. >>AVRI DORIA: Okay. >>EDMON CHUNG: But in replacement, what's going to happen is that -- because this is -- the whole process of the fast-track is imagined to be a three-stage. First stage is preparations within the territory. And by eliminating the LEAP, actually they have put the onus back into stage one, which means the country or the territory has to provide some sort of evidence from an international body like UNESCO to say, you know, this is -- you know, this is a relevant and appropriate name as an IDN TLD string. >>CHUCK GOMES: And who are they providing that evidence to? >>EDMON CHUNG: To -- it would be -- The concept is that it would be included in the application, like an application form or whatever. And eventually submitted to the board. >>CHUCK GOMES: So in other words, it would be a process where it's put into the board's lap to make the ultimate decision, something that we tried to avoid because we knew the board didn't want that. So -- Is that correct? >>EDMON CHUNG: In essence, it is still in that concept currently. And a lot of the discussion, actually, on this particular point is being characterized as implementation issue. And it really -- with this report, I think most people speaking on the topic, actually not including myself, felt that it was outside of the scope that -- about this implementation issue. And basically there is an application process with certain information, and that goes ultimately to the board and the board makes a decision. If the board wants to do some due diligence, it's entirely up to the board and the ICANN community to decide at that time. My personal view, I think we should have some sort of process in place before we receive those applications and have to deal with it. But the group's view is that that's outside of the scope of the IDNC working group discussion. >>CHUCK GOMES: It would be handled in the implementation work. >>EDMON CHUNG: Correct. >>CHUCK GOMES: So what you are suggesting could actually be implemented. It's just they are not assuming that responsibility. Is that a correct interpretation? >>EDMON CHUNG: That could be a correct interpretation. The way that it's characterized is that the IDNC will create a process that -- to accept applications for fast-track IDN ccTLD. Ultimately, that application will go to the board. It is then up to the board to decide whether or not any due diligence needs to be done. There's a technical committee. That is still there and technical checks and all those kinds of things are done. But ultimately, whether the string itself is appropriate and the board feels comfortable with it, that due diligence process, the group feels is outside of the scope of the work group. >>AVRI DORIA: Can I ask, do they feel it's only outside the scope of the work group? Or do they also feel that any of that work is outside the scope of anyone outside a particular country? >>EDMON CHUNG: Let's put it this way. They feel -- I think most people in the group feel that it's outside of the scope of the work group, and ICANN board can decide to do some due diligence. However, they do caution that if ICANN chooses to do that, there may be other, you know, ramifications or.... So.... >>CHUCK GOMES: Let me just take a pause here. I know Adrian is in the queue and Cary is in the queue. Do you want to jump in at this point or let Edmon continue? Adrian, were you next. Cary. >>CARY KARP: A little extension about this because I know a little about UNESCO's intentions here that weren't entirely articulated during the course of the meeting. There are two components of this process. The one is the selection of the name, what is the proposed string. And an awful a lot of attention is being focused on that. And the, what I have would have regarded equally sensitive issue, is who is going to be operating the registry is not -- this -- I suppose there are things to it that remain to be considered. But this language advisory thing was intended to be invoked in situations where a string is being requested that does not appear on the U.N. list of country names and recognized short forms of those names. If the requesting entity wants something else, then it needs to be verified somehow that this, indeed, is a legitimate, well -- easily recognized representation of the name of the country although it doesn't appear on any if it's on the list, it's okay, preapproved things. And there was some question about on what authority would this be made. And the role of UNESCO is not going to be to assess the legitimacy of the request, although it sounded that way. It will be to broker contact with an organization that is capable of assessing this. So UNESCO will be a clearinghouse, but will not be the authority that makes the pronouncements. And what ends up being done with this is, indeed, the board's business. Who else's is it going to be? >>CHUCK GOMES: Would you like to continue, Edmon? >>EDMON CHUNG: I have three more points I want to cover. The first one is, as I was saying, with the LEAP removed, in one sense it was a weak link in terms of the process. But it also removes the only area where the ICANN community would have been able to, quote-unquote, "intervene" in the process in the selection of the string, which brings me to the second point which is the continue to maintain that there shouldn't be a comment period or any type of objection mechanism. And from our point of view, that's an area we should address. And then finally, after much discussion, they finally include -- the final report, you can see, actually included some alternative positions, alternative views on issues, including this receiving comments, including the having a legal arrangement. And as you can see, most of those were drafted by myself. So most of the alternative views have been mainly from ourselves. One final point, which I felt was quite interesting, is that from the guiding principles in the final report, you will realize that it was -- there was no mentioning of IDNA compliance or IDN guidelines compliance or security and stability of the Internet. I tried very hard to have that as part of the guiding principle but was -- you know, was turned down. Ultimately, they are going to add some additional description, I think in front of -- at the introduction to address that issue, but those are not part of the guiding principles. I wasn't quite sure why they are not, but that is the case. And also, in the -- >>CHUCK GOMES: So what you are saying is that security and stability is not a guiding principle? >>EDMON CHUNG: They understand it as an overarching requirement and not a guiding principle. But it's not written in the guiding principle. So one final point is that the enforcement of the IDN compliance and -- IDNA compliance and the IDN guidelines compliance, they finally agreed to add a part in that. So the only part that is being added is a ccTLD -- IDN ccTLD manager will have to comply with the IDN standards and IDN guidelines. Not just comply at the application, but continue to comply. And the "continual" word was added in response to the issue about enforcement. And that was the subtle but critical change, I guess, to try to address that issue. >>CHUCK GOMES: Thank you. Anybody want to ask any questions of Edmon or make any comments on that before we continue and maybe expand to looking at all the points? Eric. >>ERIC BRUNNER-WILLIAMS: Thank you, Chuck. Eric Bart Boswinkel. I must have spaced out for a moment. Who are "they" in this? >>EDMON CHUNG: Sorry, the working group. >>ERIC BRUNNER-WILLIAMS: The IDNC working group. >>EDMON CHUNG: Yes. >>ERIC BRUNNER-WILLIAMS: Thank you very much. >>CHUCK GOMES: It seems to me, and others may have a different approach to the suggestion and I am certainly open to that, but it seems to me it would be very helpful if considering the points from our issues paper, and you have a document there with at least 11 of those, and considering the points that Edmon made, that it would be very helpful for us, not only in the continuing part of this agenda item but in the next one, to decide what are the most important points that we would like to communicate to the GAC and to the ccNSO. And I think Kristina's earlier comments are a good guide for us in the sense that it's wise, I believe, for us to present them in a way that is realistic of the situation we have and thereby increase the effectiveness of us working together to get a solution that we're all comfortable with. Maybe not perfectly comfortable, but at a reasonable comfort level. And so Edmon has identified several points. There's points on the bullet sheet, the one-pager that you have in front of you from our issues paper. Do you have a question? >>AVRI DORIA: Yeah, I wanted to ask a question -- >>CHUCK GOMES: Go ahead. >>AVRI DORIA: -- related to -- and I'm not sure -- this is an issue that came up this morning. Tina is here, it's an issue. I don't know where it relates to the fast-track and the mentioning of IDNA and all of that. And I was wondering, did the fast-track ever get into or has -- one of the things that has come up a couple of times and hasn't been clear to me is whether fast-track needs to wait for the new IDNA protocols coming out of the IETF or not. And that's -- Before getting into all of our responses and concerns about things, I think that's still a pending question that I don't know the answer to. Did they deal with that at any point? >>CHUCK GOMES: Yes. >>AVRI DORIA: I know it came up at some point as a possible question. >>EDMON CHUNG: It did come up in the last teleconference and it was addressed and the clarification is yes, they will wait for -- will wait for the publication of the -- what they are calling IDNA 208. >>CHUCK GOMES: I'm going to jump in. Tina just informed me that she has to leave in about five minutes, so maybe it would be a good opportunity to let her -- yeah. >>AVRI DORIA: (Inaudible.) >>TINA DAM: All right. So just on that topic. So what happens if the protocol revision is not done? Will we still implement IDN ccTLDs or IDN gTLDs or both or will we not; right? So we took a look at that and did like a quick analysis on, you know, is it at all feasible to have anything in the root that is IDNs if the revision of the protocol is not done yet. And the overall answer is that, no, we can't. We've got to have the protocol finished. Because that is the only way -- You know, we need to have that protocol revision done because that is the basic decision point on whether a character is valid or not. And that does not only count for things in the root. So it also goes towards, well, what kind of second-level domains can be registered under these top-level domains? And I understand that we have that today, because we have second level registrations as IDNs under the current version of the protocol, which is fine. But with the -- but adding top level to it and adding potentially millions of registrations under those, well, that's going to be just an increasingly bigger and bigger problem to fix in the longer term. So the overall decision has been, no, we can't have IDN TLDs in the root unless the protocol is done. However, it's also understood that that protocol revision is not finished yet, and it has been anticipated to have been finished at this point in time and it isn't. And there is no fixed deadline for it. So we could potentially see a situation where ICANN would be put under some political pressure to allowing IDN TLDs in the root under the existing protocol while waiting for the new version of the protocol to be done. And if that happens, and I think, you know, from a staff perspective, we are just going to wait and see. We are going to follow both how the protocol revision is going and we are going to follow how the fast-track and the process for new gTLDs is going. And if it looks like any of these are not lining up in time line to be ready at the same time, well, then we are going to initiate some project that has to do with, well, what kind of additional limitations can we put up for strings at the top level? And if it's possible to go ahead and find some way of doing a review of the draft version of the protocol and using that for implementation. But overall, the protocol has to be done. But we're willing to go ahead and do some additional work if it is not done. So, you know, it's a little premature to -- I heard all the discussion about who goes first and second and all of that. And I think from a staff perspective, we're just trying to keep track of the deadlines and see, and if it looks like everything is happening around the same time, then everything is good. And if suddenly things are starting to get sidetracked on different issues, well, then, we don't want to have been in a position where we have made any promises on anything going first or second. But it's -- So that's where it stands now. So I understand that's not 100 percent clear, but it's where we are. >>AVRI DORIA: We have a question. Eric wanted to ask a question on that. >>ERIC BRUNNER-WILLIAMS: Thank you, Tina. Eric Brunner-Williams again from CORE. Has the prefix changed? >>TINA DAM: No, so the prefix is still XN dash dash. And I don't expect it to change, but, you know, I can't speak on behalf of the IETF. >>ERIC BRUNNER-WILLIAMS: Yes or no is fine. Is any codepoint range preserved? >>TINA DAM: Reserved for -- >>ERIC BRUNNER-WILLIAMS: Preserved. Is every codepoint changed between the old spec and the draft -- >>TINA DAM: In terms of whether it's valid or not valid? No. >>ERIC BRUNNER-WILLIAMS: Yes. So if the prefix hasn't changed and there are code ranges which are stable, that is, the same in both the existing standards and in the drafts of this working group, then the statement that none can be considered until it is finished is because there are some outside of that code set. >>TINA DAM: The reason for it -- The reason for that decision is that -- and it's an interim decision; right? Because what I said was, well, if we further down the road -- >>ERIC BRUNNER-WILLIAMS: I'm just looking for the technical issues here. If the prefix changed, of course, then everything would be invalid. If the prefix is the same, then the next question arising, which code ranges are subject to change. And if the existing ones are not subject to change, but only new ones are subject to change, then we know that some codepoints are actually usable in the present. Whether or not we use them is a different question. But the technical question is whether or not existing names are backward-compatible. And if the answer is, there are some which are not, then the next question is, are there some that are? >>TINA DAM: Well, there's two problems with that. And one thing is that, right now, or, you know, maybe not in the last few days, but in the past few weeks, things have changed. You know, things have changed. So different working groups in regions, such as, for example, the Arabic working group, have looked at what the IETF is proposing and looked at, well, what is protocol valid and what is disallowed per the protocol. And they've come up with suggestions for changes for that and exception rules and so forth. So I -- I can't see how ICANN can say, you know, "Even though it looks stable now, but it's not finalized, it's not going to change in the future." So that's one thing. And the other thing is a -- a problem with that, is that it's not just what goes in the top level. It is what goes under that as well. And nobody says that just because you're in a range that, yeah, it looks like it might not change for that -- for those particular codepoints that are represented as the top-level string, well, then what about everything that wants to be used -- that the operator or the manager of that wants to use under that string? And then we suddenly start having these kind of problems of registrations that at least the application developers feel forces them into making adjustments to their implementation of the protocol. And then they're not compliant with the protocol. Then users get more difficult experiences and issues. And then we have the whole thing around again. So the first preference is to get the protocol revision done and get it done once and for all, and then do the implementation. >>AVRI DORIA: I just wanted to mention, in terms of your questions, asking has the tag changes -- has that changed, is without the IETF process having gotten to its last calls, to its whatever, one actually never knows what the answer to that is. It certainly seems that the working group is tending towards, no, it doesn't change. But how would one know until it's gotten to RFC? >>CARY KARP: There are two things, I think, specifically address what you're looking for. The one is that the new protocol is intended to operate on Unicode character properties, which are not defined for the unassigned codepoints in the Unicode chart. And this is just gray territory at this point. We have no idea what's going to happen there. And it is also true that there are codepoints which are permissible under the current protocol that will not be permissible under 2008. And as Tina points out, the likelihood of this impinging upon the selection of TLD labels is negligible. But it makes it impossible to authorize the operators of those domains to accept any kind of registration, because who knows what's going to happen on lower levels. And it's not necessarily the second; it could be the third. And I don't think the first thing a new TLD operator would appreciate needing to do, especially if it's one of the first of the IDN ones, is having to vacate a whole bunch of registrations three weeks after they were accepted. So it's -- it has to be on hold. The selection, this process of designating desired labels and putting them forward certainly is not contingent upon anything that's likely to happen with the protocol revision, but actually acting upon that, turning the domains on, is just way different. And, again, it's the unassigned codepoints in the Unicode chart that are the real key issue. >>ERIC BRUNNER-WILLIAMS: So just to be very clear, the expected set of strings which we are discussing here for ccTLDs that have some correspondence to ISO 3166 entries that exist presently, there is no known instance where this is an issue in the -- that is -- I'm looking for a justification for not adding the strings that we expect into the root. And I don't hear that there is a justification for that alone. The justification arises from adding an unbounded number of strings in second and third-level domains, and this has to do with things which haven't been discussed, such as by directionality as well as the unassigned codepoints. So this group, fast track itself, is really considering merely the entry of strings into the root, not the rules for the entry of strings into subordinate domains from that point. Those are separate policy issues. Now, we may choose to have the same mechanism for defining what's valid and what's invalid independent of where in the name space hierarchy the string is located. But to withhold allocation at the top level because we cannot make complete rules for allocations at subordinate rules, even though we're completely capable of making allocation rules at the top level, is a policy choice that I don't think we've been very clear about. So my question is, do we have any reason, any concrete reason that we can point to that says we can't proceed with the addition of entry of strings, some that we know, some that haven't yet been identified by people who might be proposing strings for ccTLDs that aren't present in this room or no one's talked about much, but given this bounded by 1,000 number of strings, is there any technical reason why these can't be added to the root today? Thank you. >>TINA DAM: Well, so I thought I'd just answered that. But I am sure that we could find a number of IDN strings that could be inserted in the root without problems today. But that's not the problem; right? So how do you allow delegation of some of these with the risk that the protocol is going to change, and we just had the discussion of the legal arrangements and so forth. You know, how do you put something like that out to ensure that operators are, you know, waiting -- I don't know, it doesn't make any sense to me. How can you -- Yeah, you -- So you can put things in the root. You can find some things that you can put in the root and it will not have a problem. I'm sure we could find some. But you can't have registrations made. And the IDNC did not have any discussions about legal arrangements making sure that things are managed in terms of registration policies and so forth. So then, I guess, we're going to have to deal with that instead. Now, in terms of that protocol revision, the group that is working on that in the IETF is very well aware of the fact that it is anticipated and that these TLD allocation processes are underway and being developed and implemented, and that they need, and the broader community needs the protocol revision to be done. So I think, you know. If it's a big problem, I think we need to go into more details of it. But I think it's okay to say, overall, we really need the protocol revision to be done, because otherwise we can't be 100% sure that what we put in the root will be stable, and we can't be sure that what is put underneath that in the zones are stable. However, we're willing to take it up at a later stage if it looks like implementation of these processes are going to be done before the protocol revision is being done. And, you know, that's kind of like what you have to do when things are running in parallel. I mean, you -- I mean, I'm not saying that nothing can proceed under fast track on the gTLD process until the protocol is done; right? Everything is running in parallel. I'm just saying we're keeping an eye on it. If it doesn't look like it's getting end at the right time, well, then we need to put some additional measures into place. And, yes, I'm sure that if that was the case, we could find some strings that we could put in the root without problems. But I'm not sure that we could allow for registrations under them. And then we need a mechanism for that. So that's as -- you know, that's as good as it is today. >>AVRI DORIA: Okay. Edmon. >>EDMON CHUNG: Speaking about parallel process, I missed one point on the IDNC final report, which was added in after the last teleconference, which is, there is a -- I think there is consensus around this point, which is to initiate an RFI process, a request for information process, so that interest -- basically, expression of interest by ccTLDs -- well, territories -- to have an IDN ccTLD in the fast track. So that would probably even start soon. Perhaps Bart can enlighten us with that. If we do get through this final report and it goes to the board and then the staff starts the implementation, the RFI could potentially start. And that actually would help identify some of the issues that you mention as well, I think, Eric, in understanding what strings are going to be proposed as well. So there is some parallel process ongoing, I think. >>AVRI DORIA: Any other questions for Tina, since -- Yes, Yoav. >>YOAV KEREN: When did the IETF work on this revision of the IDNA start? When did start the IETF work on it? >>TINA DAM: So That depends on what you mean by -- You asked when it started? >>YOAV KEREN: Yeah. >>TINA DAM: So the working group was formed -- is it a few months ago or something? >>YOAV KEREN: I'm just saying that, because we should bear in mind that, if I'm not wrong, the first protocol that was published in 2003 took -- I am not sure, I think it was two to three years, maybe three years of work. So just want everyone to hold in mind that we won't be held hostage with this thing, and we'll wait another three years for -- you know, for moving on with the IDNs. We have been waiting for ten years. So, it's about time. >>TINA DAM: So -- >>CARY KARP: If you want an unpleasant response to that, and this revision started as something that was supposed to be a very, very streamlined modification to the preexisting protocol to serve one purpose, and one purpose only, and that was vitally important. And that is that the current protocol is locked to what is now an obsolete version of Unicode. And it has to be possible for new scripts as they are added to Unicode to be available for IDN. Otherwise, what are we doing here? And there was one way to do that, and this was sketched in an informal effort that was brought into -- that came into existence last summer. And it was migrated through a series of informational documents into the open purview of the IETF, resulting in the chartering of a working group a month or two ago, which will be meeting in Dublin for the first time. There are two two-hour sessions scheduled. And there are three conceivable outcomes. And I wouldn't bet money on any of them. I know what you hope. Yeah. The one is that, indeed, this will prove to be reasonably straightforward and simply get done as first envisioned. The second is that, within the context of the working group charter, there will be this huge fight and who knows how long it's going to last. And the third is that the charter is simply rejected, that, sorry, this is just a fundamentally flawed approach. We are going to have to change the prefix, as a minimum, and there may be a completely new solution to this, in which case we'll just have to live with the old IDN until that's been done. So either it's going to be mercifully brief, painfully protracted, or unimaginable. Yeah. [ Laughter ] >>YOAV KEREN: Well, I'm worried of two of these scenarios. Yeah. >>TINA DAM: So what I said is, no, we don't want it kept -- we don't want to be kept hostage of that. Now, our first wish is the protocol will be done first and then implementation. If that can't happen, we're going to have to figure out some interim approach. So we're going to have to let -- we're going to have to let these processes move forward, and we're going to have to let the IETF move forward and meet in Dublin in July. And then we'll see how far it is. Yeah, I mean, I hope it's going into last call soon, obviously. I mean, we can't keep -- But, so it's -- >>AVRI DORIA: Eric, did you have a last comment? Because I do want to move on from this to the other stuff soon. Thank you. >>ERIC BRUNNER-WILLIAMS: Yes. Eric Brunner-Williams again from CORE. Cary, you've identified the key requirement, that is, shifting from one version of Unicode to version-independence. Where I have a profound concern is the process issue. I can't identify a statement -- and perhaps it happened while I was having an elder moment -- but I can't identify when the GNSO or when ICANN sent to the protocol supporting organization a statement of that requirement, that that requirement originates from this body, because it is controlling this body. Our actions on this issue are being constrained by the outcome of some external organization. And where did we say that we wanted this done? That's what I'm looking for. Where did we say that this is a requirement originating from the domain name industry? >>CARY KARP: To the best of my belief, this thing originated in the IETF itself. I can give you the name of the guy whose idea it was. >>TINA DAM: Are you asking why the revision was started? >>ERIC BRUNNER-WILLIAMS: I'm asking a process question. I'm asking, where did the GNSO, or where did the ICANN board originate a request to a third party for this particular work item to be undertaken which would be -- >>TINA DAM: The protocol revision? >>ERIC BRUNNER-WILLIAMS: Yes. Which would condition this body's function. >>AVRI DORIA: I'd like -- First of all, I mean, any protocol that is the IETF's protocol, if they want to change it, for whatever reason in the wind they catch they want to change it is there -- >>ERIC BRUNNER-WILLIAMS: Excuse me, Avri, we use WHOIS -- (Multiple people speaking simultaneously.) >>ERIC BRUNNER-WILLIAMS: And that's been obsoleted. It's been obsoleted by them. >>AVRI DORIA: Yes, I know that. But if we wanted it changed, if we wanted WHOIS changed -- okay, it's obsolete. It wouldn't happen -- then we might write an Internet draft that requests -- There is no requirements -- as you know, as well as I do, there is no requirements process for an IETF change to a protocol. I mean, at the most, another organization writes an Internet draft suggesting something. So the GNSO, as far as I know, never wrote an Internet draft saying, "We think these changes are a good idea, and put it in." There is no requirement saying. But there is a notion within the IETF that if you want to change to their protocol, individuals go to the IETF suggesting changes to their protocol. >>CARY KARP: Just imagine what happened if ICANN went to the IETF and said, "You guys are going to have to change your protocol." Or I came to the IETF and said, "Sorry, you guys can't change the protocol." What's the real issue here? >>TINA DAM: Just to be more specific, it was RFC 4090 that stated that the protocol needed to be revised. And that RFC has -- is listing a number of different issues and problems and discussing different solutions to it that, yeah, then -- it was an idea at first, and then it ended as an RFC, and then the protocol revision started. >>ERIC BRUNNER-WILLIAMS: Yes, but that's an IAB document that became an RFC. That's not something that originated from ICANN. >>TINA DAM: It doesn't have to originate from the ICANN board or the GNSO. I mean, the GNSO could probably ask the IETF if they would take on the -- a revision of something or a new protocol of some sort. But it certainly isn't something that's necessary. That's not how the processes work. >>AVRI DORIA: And we certainly new when the IAB draft was being -- and last call and could have and perhaps some people actually did comment. Kristina. >>KRISTINA ROSETTE: I don't want to be rude or offend either of you. But I'm a little concerned that we're going to go into this meeting with the ccNSO and we haven't really had a chance to prepare. >>AVRI DORIA: I want to move. Yeah, I wanted to thank Tina. And -- thank you. Okay, yeah, we've got -- yes, Adrian. >>ADRIAN KINDERIS: I believe I was in the queue before I left, and I came back to the same conversation. So I assume there's been no further questions regarding this stuff before. >>AVRI DORIA: I'm so sorry. I missed you being in the queue. >>ADRIAN KINDERIS: No. Chuck was -- it's Chuck. It's typical. [ Laughter ] >>ADRIAN KINDERIS: I -- just going back to what Kristina was sort of -- where we're circling back to, my original question was, what do we fear. And all I've got so far is, first to market. I just wanted to put it back out there, if that's all it is. Because I just want to have a reason why, when they come back, why do we have a problem with that or why do you think we need it? They can say, well, because we think you guys are going to be first to market and we don't want that. What else have we got to come back with, if we need anything? That's -- I mean. >>AVRI DORIA: Did we want to get into fears and trepidations at the moment? Or did -- I mean -- >>ADRIAN KINDERIS: I -- just because I thought that's where we were -- in our preparation for the meeting with the ccNSO, surely these are the sort of things we want to know about and get a collective consensus on. >>AVRI DORIA: Okay. We've got, first of all, two meetings to prepare for at the moment. One with the ccNSO, and then the GAC one, which is the most immediate of those meetings. Certainly, I see Edmon's hand up. >>EDMON CHUNG: Just quickly respond. Are you talking about, like, IDNC, the fast track, what we have a problem with? Or the contract -- contractual relation, those -- >>ADRIAN KINDERIS: Contractual relations, initially. >>EDMON CHUNG: I guess, from my point of view, it's not really about who goes first. It's great if they go first, because they will be testing out the market. But it -- from my point of view, the really -- the meat of it, why I'm concerned, why I'm doing all these things, is trying to make the process a -- actually, a safer process for ICANN overall, because right now, I mean, my point of view, if we go forward without any type of relationship between ICANN and the ccTLD, fast-track IDN ccTLD, there are risks involved with ICANN as a -- overall. You know, they won't be able to -- the CC PDP later on, I think Jon made a very good point, if they don't -- if those that went through this fast track didn't then agree to the CC PDP, then the whole ICANN structure, you know, somewhat falls down. And also the enforcement of IDN compliance and, you know, IDN guidelines compliance, I think those are, for me, that's really the risk factor for ICANN in general, rather than -- >>ADRIAN KINDERIS: If I may retort, to play devil's advocate, surely their (inaudible) is going to be, "Well, TLDs exist now that don't have agreements with ICANN and there's no chaos theory there." >>EDMON CHUNG: The only difference is IDN. We just had a very long discussion with Tina here why we have to wait until the IDN protocol and everything is done to introduce. Same issue, you know, like if there's no commitment from the ccTLDs to abide by those guidelines and protocols, I think there's a certain level of risk for ICANN in general. And that -- and in terms of the legal agreement, my point of view, a simple exchange of letters would suffice. And it's not legal agreement at all. But at least there should be some form of understanding between the two -- the entity that gets the IDN fast-track TLD and ICANN to say that, okay, we won't do something stupid, essentially. >>AVRI DORIA: Tim, and then (inaudible). >>TIM RUIZ: But I think there are, though, at least to some on the council, and certainly some within the constituencies that are concerned about this first-to-market issue, you know, registrars are commercial enterprises, registries are commercial enterprises. This is a serious issue. First to market is a huge advantage. And so, you know, to say, well, -- so I don't want to come into this, it's just an issue of one or the other, that both have weight, we're concerned with both, and we'd like to resolve both. That's would be my preference. >>AVRI DORIA: I don't quite want to move to the ccNSO/GNSO meeting, but Chris does happen to be here, so asked to comment on, I guess, the contractual issues specifically. >>CHRIS DISSPAIN: Are we having a meeting this afternoon? >>AVRI DORIA: No. We're having one Thursday. We have one with the GAC this afternoon. >>CHRIS DISSPAIN: You scared me. I might be able to help, sort of from a practical point of view, just to give you a little bit of background. On the first-to-market issue, I'm not aware of a single ccTLD who has any concern whatsoever about things happening at the same time. I don't think there was -- has ever been an intention to rush through so that an IDN ccTLD would be appearing before the possibility of an IDN gTLD. Now, having said -- So certainly from a practical point of view, our understanding is that both of the processes would open or both of the calls, whatever you want to call it, would open at the same time. I can't speak for how long it would take each of the applications or whatever you want to call them to be dealt with, and I don't know whether they're going to be batched or not batched. But it's certainly not intended that -- from the CC side that there's -- that the IDN ccTLDs would be opened before the gTLDs. And, in fact, the timeline that I've been working on has been that things would, hopefully, be tied up by Cairo, and then, you know, there's a call for -- call for applications is made in whatever, Gs or Cs. In respect to the contractual situation, let me tell you two things. Edmon may have mentioned this or not. I asked -- suggested to the working group that we should put in a clause in the report which said something like, "Whilst the working group believes that there is no fundamental -- with the exception of abiding by the IDN protocols, et cetera, there's no difference between an ASCII ccTLD and IDN ccTLD, the working group recognizes that there are some IDN-specific issues which would probably require the ccTLD -- IDN ccTLD delegate to enter into some sort of arrangement, agreement, whatever you want to call it, with ICANN to cover those issues, and the working group recognizes the existence of accountability frameworks and sees that they could be built on, you know, as a possible methodology for this." My understanding from -- I won't -- wouldn't go so far as to say the majority, but certainly a large number of my ccTLD colleagues, is that they accept that there is a need for some sort of written thing. The issue is government. The GAC representatives on the working group were adamant that the working group should make no statement whatsoever about contractual arrangements, because of, of course, we are a sovereign territory, blah, blah, et cetera, et cetera. So this may give you no peace of mind, but the view that I've personally taken is that I would be very surprised if the ICANN board were to not insist on there being some form of written arrangement between the IDN ccTLD manager and ICANN. And what it is is a matter for negotiation. But I wouldn't put too much worry in the fact that it's not in the report. It's not -- It's certainly, in the CC community, pretty much accepted that this is likely to need some sort of agreement. So I hope that gives you a little bit of background. And if you have any questions, I'll be happy to answer them. >>AVRI DORIA: If there are questions, although we definitely have Thursday, and what we've got now left is 15 minutes to prepare for our next meeting -- I thank you, Chris -- I would -- unless there's an emergency question, as it were, Adrian, because we do have several hours together on Thursday. >>ADRIAN KINDERIS: No. I realize. I think -- all I was going to say is I think what Chris said with respect to the GAC is that the -- looks like there's a fair bottleneck, or at least problem there. So that's maybe the -- >>AVRI DORIA: Yeah. >>ADRIAN KINDERIS: -- the lading that we need. >>BART BOSWINKEL: From drafting the report, I think -- and that's maybe something you want to consider -- if you want to have, say, an opinion, or even in the communiqué of the GAC that they oppose any legal arrangement. In this way, it is still open, and it is far easier for the board to go down the path of implementing an agreement. One of the things you don't want is explicit opposition to a legal arrangement. And that is -- that's the reason why we came up with the solution. We will not put anything in the report, although everybody is aware and we had the discussion. >>CHRIS DISSPAIN: The last thing you want is the GAC saying specifically, "We don't want contracts." That's the last thing you want. So that's -- we've dealt with it the way we have on the basis that it will get -- you know, it'll be dealt with in the washup, hopefully. But if we push it now, then they will say -- there will be statements that there are no contracts. >>ADRIAN KINDERIS: So in preparation for our meeting with the GAC, is that something we want to avoid? >>AVRI DORIA: So, basically, to prepare for talking to the GAC, we must not talk to them. >>ADRIAN KINDERIS: That's what it sounds like. >>AVRI DORIA: And that brings me perfectly to where I wanted to be, kind of. I started to put together slides. And then all of a sudden I realized that I really didn't -- no. Thank you. But thank you to both Bart and to Chris for coming in and helping. And I look forward to the longer meeting where we can talk about things. I started to put together slides, as I've usually done, and then realized I had almost nothing I wanted to say on those slides, partly in the same sort of anything I say in the slides that, you know, "This is a GNSO council position," opens up an ability for a resistance to it. So I did put together some slides. I don't know whether it's even worth using them, but I'll show you the ones I put together. I put them together during the last meeting. So how do I get to the next one? Oh, next slide. Excuse me. I don't know how to use my own machine here. >>AVRI DORIA: Okay. That was the first slide I had. And that struck me as almost the only slide I really wanted to show. Because I mean we had reports in this meeting and I heard them elsewhere that the GNSO doesn't care about the GAC. Now, I don't need to put that slide up, but perhaps it's a good thing to get on the table and sort of say, yeah, we do care. Now, do we care to the extent, perhaps, that they would want us to care? That's a difficult question for me to answer. You know, certainly, though, within the WHOIS, the GAC has been treated with the same weight as any of the constituencies, as any other of the comments. And so that was a slide that I thought I would show. I don't know what people think. The topics that were on the agenda were new gTLD policy implementation; the IDN ccTLD deployment, the PDP and fast-track; and the ICANN GNSO WHOIS study group report. I put together quick slides on each of those. I will show you what I have got and then we will decide whether we just talk or have slides. On that one -- actually, I never added anything on that one because we were still talking. So I never added any content there, and perhaps this group can tell me whether there is any content. You know, the maximalist position is to show Chuck's page. Showing Chuck's page certainly goes against the advice we just got of don't put it all on the table because then you provoke resistance. The minimum is to add something in there basically that says, you know, we're interested in listening, and leave it at that, you know. We are interested. We are listening. You know? We are participating. I'm not sure what more one would say. Yes? >>ADRIAN KINDERIS: Are you asking the question? >>AVRI DORIA: Yes. At this point we have 15 minutes to either have slides or not, and I think at this point -- >>ADRIAN KINDERIS: Maybe someone knows the GAC better than me, but is that valid what Chris said? I mean, do we need to not talk about the war, for those of you who know "Fawlty Towers"? Why can't we -- I would be one to put it out there, but -- >>AVRI DORIA: Certainly I have this, and I could certainly put up this and we could walk through it with them and have an interesting discussion. That's Chuck's basic key points from the document. I don't know if people want to do that. Yes, Mike. >>MIKE RODENBAUGH: I don't understand why we wouldn't want to do that, why we don't want to be open with them. Obviously these things are all open, these issues are all going to come out. Why not get them out there? >>TIM RUIZ: I agree, but maybe it could be done in a different way. We don't have to come out and say we think there ought to be a contract. But the two primary issues, it sounds like, is, one, making sure there's going to be some technical adherence to whatever the IDN standards are, and, two, there will be some commitment to following whatever the PDP comes up with at the end. So we don't have to mention contractual, but what the concerns are. >>AVRI DORIA: So if -- I mean, because at this moment I don't have time to write all new slides with key points on them, if I was to use Chuck's outline here, Chuck basically put together the key points. Now we have this last one. I could certainly just quickly edit this one to make it say "should have some form of agreement." >>ADRIAN KINDERIS: Great. I think that's better. >>KRISTINA ROSETTE: Or understanding, because I think they use that -- >>AVRI DORIA: Should have an understanding. >>KRISTINA ROSETTE: (inaudible). >>AVRI DORIA: Understanding with the IDN ccTLD operator that includes appropriate technical and financial requirements. And perhaps -- So what I could do in that slide is just point to -- where am I? Is just point to our things. Yes, Adrian. >>ADRIAN KINDERIS: This meeting is open; right? At the moment? This meeting is open at the moment and being documented. >>AVRI DORIA: Yeah. >>ADRIAN KINDERIS: I just wonder how much the GAC are going to be reading. Yes, it pays to be diplomatic, as Tim just said, when we talk about this stuff. But if they wanted to do their homework, they can see we are talking about this stuff anyway, so I agree with Mike. >>AVRI DORIA: Okay. Does anyone disagree with showing the points? Yes, Kristina. >>KRISTINA ROSETTE: I think if we show the points, I think I would feel pretty strongly about having that last point, kind of stay away from the word agreement, stay away from the word contract. Because -- >>AVRI DORIA: Do you have any objection to changing that, Adrian? No, so that wasn't what you were referring to. >>ADRIAN KINDERIS: No, that's not exactly what I was referring to. Not that specifically. I was more saying that just be aware that our conversations are open, so it's not like we are in a war room here coming up with a secret document. >>KRISTINA ROSETTE: But I think it's qualitatively different from the perspective of governments. That if we walk in there as the GNSO council and say, here, that we kind of put them in a position where they then have to respond. And I think we don't want to do that right now. >>AVRI DORIA: Okay. Perhaps it's good to go through these quickly and see if there's anything said in a way we don't want to say at the moment. >>MIKE RODENBAUGH: I have one. >>AVRI DORIA: You have one, yes. >>MIKE RODENBAUGH: It's the ex sum 8 bullet point, about the strings should be meaningful to the local community and should represent, in scripts of the corresponding country's choice, a meaningful representation of the name or abbreviation of the name? Where did that come from? That seems new to me. I thought we were pretty clear in our first interaction with the GAC that it needed to be a meaningful representation of their name. Now you are throwing in abbreviations as well. Does this mean that Tuvalu gets television, essentially, in every script in the world? That can be read this way. Or this can be read that way, more appropriate. >>AVRI DORIA: At this point we don't have a whole a lot of time to talk about it so I can just remove "or abbreviation" -- >>MIKE RODENBAUGH: I would prefer you did that. I don't know where it came from. >>AVRI DORIA: Yes, Philip. >>PHILIP SHEPPARD: Avri, is this not intended to be a factual -- This is a summary of what we already agreed. >>AVRI DORIA: It is, yes. >>PHILIP SHEPPARD: It is either correct or it is incorrect. >>AVRI DORIA: I believe it's correct. >>PHILIP SHEPPARD: If it's correct and this is open, the message to the GAC surely is, "We are in discussion with the CC's about these issues. Our current thinking looks like this. Be delighted to hear from you, what your reaction is to our current thinking." Isn't that it? I mean, to do anything more strikes me as being deceptful, and that's not exactly what we (inaudible). >>TIM RUIZ: Don't they already have this or is this something -- >>AVRI DORIA: This is very much an abbreviation. >>TIM RUIZ: Okay. >>ADRIAN KINDERIS: They have got the long-winded form. >>AVRI DORIA: What? >>ADRIAN KINDERIS: They have the full document. >>AVRI DORIA: The full document is out. >>TIM RUIZ: So it's abbreviated. It's not stuff added -- >>AVRI DORIA: This is the key points. There's nothing new in this. Okay. And then key point reference. Okay. And then the next slide that I had was on the new gTLD policy implementation, there's not much we can say. Policy still waits approval, staff in the process of developing a proposed implementation. And then are there GAC -- are there GAC issues for the GNSO? And just basically ask that question. I don't know what more we can say on that one. So that was my slide for that one. And then on the ICANN GNSO WHOIS study group, you know the first draft of the report represents a split viewpoint. Really not much to be gained from doing more -- not tests. I mean tests, studies. And studies should be done -- should be done and offers a categorization of various study proposals. I don't know why I had "test" in my mind. And then council currently discussing a way to proceed. Because we -- we're working on motions, but I think that's where we are at the moment. And so we are interested in their take on it all. Is there more we can say there? And so that was pretty much my set of slides. >>TIM RUIZ: May I just -- >>AVRI DORIA: Yes. >>ALAN GREENBERG: The second dash bullet I don't think parses. >>AVRI DORIA: You're right. Studies should be done and report offers a categorization of various study proposals. >>ALAN GREENBERG: Say "the report" to show it's a noun, not a verb. If "report" is a noun and not a verb, put "the" in front of it. >>AVRI DORIA: Oh, thank you. >>TIM RUIZ: This is Tim. >>AVRI DORIA: Yes, Tim. >>TIM RUIZ: Just quickly, if it comes up in regard to our giving them equal weight for their report in that, I think that's good, but perhaps it could be mentioned that the one thing we felt was missing was the hypotheses, and that that would have helped if we would have had that. >>AVRI DORIA: Right. And the way I was thinking of mentioning that if it came up is not, "Hey, guys, you should have given us hypotheses," but "The lack of hypotheses gives us more work to do in order to include your recommendations." So it's not trying to say you didn't do what you should have done, but rather to say by having done it the way you did, we have some work to do to be able to include it in the same way. Yes, Liz, and Philip. Sorry. >>LIZ GASSTER: This is actually a question more to the folks who opposed future studies, but the way you had it listed there, I just wondered if they would prefer an additional phrase that explained why no further studies should be done. Because it's left hanging there to wonder why. >>AVRI DORIA: Okay. Did I want to put that on a slide or -- >>LIZ GASSTER: Good question. I just raised -- >>AVRI DORIA: Or is that something that would come out in the discussions? So I would only have bullets and not have -- tried to commit quickly complex reasoning to slides. I am really just trying to put down a couple bullets that we can then go around the table and discuss. Yes, Philip. >>PHILIP SHEPPARD: I also have a comment on the WHOIS slide. We have to be careful not to misrepresent the status play. There were a number of members of the GAC who participated or agencies of government who participated in the original WHOIS working group which called for studies. So there is an expectation, probably, in that body that studies will be happening, included, indeed, their own specific request. I think we may need to explain to them a little also where GNSO council was on studies, the composition of this small group, and who said what in that small group. I think that level of detail is necessary in this case so as to give the full picture. >>AVRI DORIA: I'm not quite sure I understand. How would you change -- Or to put it bluntly, how would you change the slide with three minutes to go? >>PHILIP SHEPPARD: You need to explain who said viewpoint one and who said viewpoint two. Representatives of constituency X said viewpoint one. Representatives of viewpoint two were so-and-so. We need to explain that level of detail. And give them the number of people who were on that small study group. >>AVRI DORIA: I don't quite understand. >>PHILIP SHEPPARD: You don't need to put it on the slide. You can do it verbally, if you want. >>AVRI DORIA: Okay. I will have to make sure I have that in front of me so I have got that right. >>PHILIP SHEPPARD: You can just read off that chart with the purple heading that's on the report. >>AVRI DORIA: Yeah, okay. Okay. >>TIM RUIZ: (Inaudible.) >>AVRI DORIA: Yeah, the report is -- again, it's public. So, yeah. Okay. I'll make sure -- in fact, I'll probably have that in the background so I can pull it up. So that's a bare set of slides. I think it's just meant to have something to frame the conversations around. And I think that mostly you guys should say what it is you want to say. Anything else before we close this one? About that? And in terms of the ccNSO -- I have a feeling that that meeting on Thursday could be relatively informal. I mean, and just sort of get in the conversations. We've got, you know, several different topics. Just to point out the topics that we have on that agenda was fast-track and their alternatives, you know, the meaning of the noncontroversial in the fast-track, because that came up, but that may not have a lot to be talked about. The technical, operational and other conditions of fast-track approval on a focus on the similarities and differences between gTLDs and ccTLDs. Then discussion of the following: A very small number of ccTLDs seem to have expressed an expectation that they be consulted for any application for a gTLD in their language. Is this expectation broadly shared? And are these ccTLDs aware of and engaged in the IDN processes. And then 5, how the ccNSO and GNSO could communicate and work together more effectively and regularly. Same question we had with the ALAC this morning, is how do we keep it from being just every once in a while we get together, and other than that, sling stuff over the wall at each other. So with that, at exactly 3:45, this one is closed. Thank you for the two days. And we'll meet over in -- what? Picasso? Which is like two doors over or something, at 4:00 or whenever they open the door and say they are open and ready for us. And for council members, a reminder that we have the 7:00 dinner. And for council members, where is that 7:00 dinner? In Giacometti which is on plan B. So thank you, everyone, for a wonderful two days. [ Applause ]