GNSO Working Session Saturday 27 October 2007 >>AVRI DORIA: Good morning. Everybody sitting here? We're quiet. It's 9:10, which is a really good time to start a 9:00 meeting. This is an open GNSO Council GNSO meeting. My name is Avri Doria. I'm chairing. What I'd like to do when we start is have everyone go around and introduce themselves. I know that's sort of a little unfair because later people will come in and they'll have gotten in without having to introduce themselves, but it's still a useful thing, I think, to have done. First, I'm going to go through the agenda, though, and let people know what is in store for us today. We have a -- we're starting out this morning talking about the IDN ccTLD issue, specifically the GNSO response and a discussion about some of the ccNSO proposals that have come out lately, a discussion about our response in view of those, how we want to approach it. So as I say, this is a meeting for discussion, so we won't be voting on anything today, but we'd certainly like to discuss all the details of everything. We have a coffee break. Then we'll go into talking about the rights protection mechanism. There's been a working group working on that, and they'll sort of talk through the work they've done, and will talk about how everything proceeds with this. This is work relating to the new gTLD discussion. There's a lunch break. In break, with some of our previous meetings, it's -- it's actually a lunch break where people go away and have lunch. We're not having lunch brought in. That didn't really quite work right. People always had other things they wanted to do. How do you have an open meeting and a closed lunch without being mean to people? And so it just -- it was just something that we just decided, "No, we'll have a lunch break," and a lunch break in the middle of a long day is not a bad thing. In the afternoon, we're going to start off with a lot of WHOIS discussions. First, we're going to go through the WHOIS discussions about the constituency statements, community comments, getting comments, making sure we understand people's comments, going on from there. We have another coffee break. Then we have the second part of the WHOIS discussion, where we'll get a report on some of the studies that have been initiated, where they're at. And we'll have also have a report from Steve Crocker, who will be coming in to talk about the SSAC report on the WHOIS spam study. Then -- and this one was not in the previously released schedule, but we'll also have a discussion on inter-registrar transfer policy. We've had an issues report. We have a requirement for making a decision on a PDP on the table for that one too. One of the three decisions we have on PDPs to make in this meeting or shortly thereafter, so we'll spend an hour talking about that. And by 7:00, we should be ready to break for the evening. We have nothing planned for this evening. I'll just -- huh? Well, thank you very much. On Sunday, just to go through our schedule while a few more people drift in, tomorrow morning we start -- we have a discussion on -- and all of our meetings are open, this time. We haven't planned any closed meetings. GNSO reform discussion. The reform document came out, a draft of it came out from the working group. The board governance working group, working group on GNSO reform. I keep getting the name -- anyhow, Roberto Gaetano and some of the group members will be coming in to discuss the report, comments back and forth. Again, a coffee break. I love coffee breaks. Then between 11:00 and 12:00, Doug Brent will be coming in to have a discussion on the strategic plan with the GNSO. We then go into a final prep for the meeting of the Monday workshop. Now, that's not a closed meeting, but it really is a meeting about details of preparing for that six-hour workshop that will be held on Monday, so if people want to stick around and listen, okay. It's -- I'm not declaring a closed meeting, but it's really for the panelists and the council to make sure that we know what we're doing for the Monday afternoon. >>CHUCK GOMES: And staff. >>AVRI DORIA: And staff. Sorry. And staff, especially. Thank you, Chuck. Then I've left a spot open between 2:00 and 3:00. We have another lunch break. Again, a real lunch break. Then between 2:00 and 3:00, for any other business that sort of comes up, things that have been missed, it -- I don't know what's in that spot yet. Then we have some preparation for the GAC meeting, and coffee break. We go into the GNSO/GAC meeting, which is also open. Monday, just want to point out the thing that's relevant is that we've got a -- the workshop on the -- the GNSO workshop on new gTLDs which goes from 1:00 until 7:00. It's a six-hour workshop. There will be two breaks during it. One thing I was asked to announce for GNSO members, staff and board, there will be a board dinner Monday evening at 8:00 in plaza, and we'll basically be talking about what comes out of that workshop but it will also be open for people to talk about what people talk about. Tuesday is the constituency day. I won't go into that. Wednesday we have our open council meeting. We're trying that slightly differently, based upon comments and recommendations we got last time where we'll try to go topically, where we report on what's happening. We have open discussion. Then we go into council discussion and a vote, if it that's what we're doing. And that was sort of a recommendation we got at the last open meeting. I'm not sure how it will work. I'm not sure anyone is sure how it will work. We're going to try it and see if it works. And if it doesn't work this way, that doesn't necessarily mean we'll go back to the old way. We may just look at how to tweak this so that it does work. But anyhow, we'll be going through the IGO, DRP, domain tasting, WHOIS, IDN, and then the registrar transfer policy update should actually be more of taking a vote on it, if that's what we've decided to do. And then on Thursday, we have a meeting -- a discussion on input from the other meeting. Sort of a wrap-up and going on. So that's a quick view of where we're going with the GNSO over the course of the week. I'd like people to introduce themselves. I guess I'd start with Norbert down at that end and we'll go around the table. Please introduce yourself, say whether you're GNSO Council, what constituency, where you're from, and then I also want to get the people sitting around the edge. I don't know if we've got a microphone for around the edge. I sort of asked for one, but if not, just walk up to the table and grab a free microphone and speak your piece. And that will be the same thing for during the meeting, if someone wants to go. Norbert? >>NORBERT KLEIN: My name is Norbert Kline. I am a GNSO Council member. I am sent here from the noncommercial user constituency. I work in Cambodia since 17 years, and that's it. >>AVRI DORIA: Thank you, Norbert. >>BILAL BEIRAM: My name is Bilal Beiram, with the B.C. constituency. I'm with the Talal Abu-Ghazaleh organization. We're based in Amman, Jordyn. >>AVRI DORIA: Thank you. >>CHUCK GOMES: Please -- oops. Is that on? Please speak a little bit closer to the mic, so that you can be heard. Now, do we have anybody on line? >>AVRI DORIA: I'll ask at the end. >>CHUCK GOMES: Okay. >>AVRI DORIA: I don't know if we have anybody on line. We'll ask. Do we have anyone on line? >>GLEN de SAINT GERY: Not yet. >>AVRI DORIA: Not yet. >>CHUCK GOMES: Okay. But when they do, it's very hard for them to pick up conversations if people aren't speaking into the mic closely. >>MIKE RODENBAUGH: Mike Rodenbaugh, councillor from the business constituency. >>JON BING: Jon Bing. I'm a noncom member of the GNSO. >>ALAN GREENBERG: Alan Greenberg. I'm the liaison to the GNSO from the ALAC. >>MARGIE MILAM: Margie Milam with MarkMonitor, and I'm with the registrars constituency. >>MARILYN CADE: My name is Marilyn Cade. I'm a member of the business constituency. >>TONY HOLMES: Tony Holmes from the ISPCP. >>BRUCE TONKIN: Bruce Tonkin from Melbourne IT, which is a member of the registrars constituency, and I'm also a member of the ICANN board. >>OLOF NORDLING: Olof Nordling. ICANN staff. >>DAN HALLORAN: Dan Halloran, ICANN staff. >>KARLA VALENTE: Karla Valente, ICANN staff. >>CARY KARP: Cary Karp. I represent the -- I'm one of the representatives of the gTLD registry constituency on the council. >>AVRI DORIA: I'm Avri Doria. I am a NomCom appointee to the council, and its chair at the moment. >>CHUCK GOMES: Chuck Gomes, from the gTLD registry constituency. >>DENISE MICHEL: I'm Denise Michel. I'm ICANN's vice president for policy. I'd also like to take this opportunity to announce that Liz Gasster, who has been working temporarily with the GNSO, has joined ICANN's staff permanently. She's our new senior policy councillor for the GNSO. She'll introduce herself down here. [Applause] >>DENISE MICHEL: And Liz -- I now have moved from Brussels back to California. I'm based in California, and Liz is based in D.C. currently, and the rest of the GNSO staff is in Europe. >>KRISTINA ROSETTE: Kristina Rosette, IPC representative to the council. >>EDMON CHUNG: Edmon Chung, gTLD registry constituency. >>CRAIG SCHWARTZ: Craig Schwartz, ICANN staff. >>ROSS RADER: Good morning, everyone. I'm Ross Rader, registrar rep to the council from North America. >>JEFF NEUMAN: I'm Jeff Neuman with NeuStar. I'm on the -- I'm in the gTLD registries constituency. >>LIZ GASSTER: And I'm Liz Gasster, new ICANN staff. Thanks. >>WERNER STAUB: I'm Werner Staub. I work with the secretariat of CORE in Geneva. >>ELMAR KNIPP: Elmar Knipp, also from CORE, observer. >>DIRK KRISCHENOWSKI: Dirk Krischenowski, dot Berlin, also observer. >>AVRI DORIA: Okay. Yeah. Now for the people around the edge, please. >>PAUL LECOULTIE: Paul Lecoultie, CORENIC -- >>AVRI DORIA: Yeah, I asked for one, but -- >>PAUL LECOULTIE: -- and member of the registrar constituency. >>MARCUS FAURE: Marcus Faure, surprise, also with CORE, executive committee. >>MATTHIEU CREDON: Mattheiu Credon, dot bzh project, observer. >>STEVE DelBIANCO: Steve DelBianco with the business constituency and Netchoice. >>LAURIE ANDERSON: Laurie Anderson, GoDaddy.com. >>LISA VILLENEUVE: Lisa Villeneuve. I'm with Go Daddy. >>PAM BUNN: Pam Bunn, GoDaddy.com. >>AVRI DORIA: Thank you. Yes. Maria? >>MARIA FARRELL: I'm Maria Farrell with the ICANN staff. >>MARILYN VERNON: Marilyn Vernon, ICANN staff. >>SUE JONKLAAS: Sue Jonklaas, ICANN staff. >> >>LYNN GOODENDORF: I'm Lynn Goodendorf with InterContinental Hotels Group and I participated recently in the WHOIS working group. >>SUSAN CRAWFORD: I'm Susan Crawford. Nominating committee. Member of the ICANN board. >>CLAUDIO DiGANGI: Claudio DiGangi with the International Trademark Association and the intellectual property constituency. >>HENRIK ERKKONEN: I'm Henrik Erkkonen with Nictrade, a Swedish registrar. >>ARTUR LINDGREN: Artur Lindgren, Nictrade, Swedish registrar. >>AVRI DORIA: Okay. Thank you. And welcome, all. Okay. Now, we'll go into the first item on the agenda, which was a discussion of the IDN ccTLD, our response. Chuck will basically lead this -- this discussion. Did you want me to put -- [Speaker is off microphone] >>CHUCK GOMES: No, that's okay. Now, let me let people know, first of all -- no, I didn't, but I'll handle it another way. There's a printed copy, not red-lined version like I have here, of the draft comments that we're going to go over in this session, so if you didn't pick one up at the table, the title of it is "GNSO Comments in Response to the ccNSO/GAC Issues Report on IDN Issues," and several months ago the council decided to form a small group that would develop some draft comments in response to the ccNSO/GAC issues paper on IDN TLDs. As most of you recall, the ICANN board in its meeting in San Juan in June asked that quite a few different ICANN organizations submit comments by this meeting here, the annual meeting, and so that's what this is all about. The GNSO providing comments to that issues paper from the GAC and the ccNSO. The members of that group were Tin Tan Wee from the NCUC, Bilal Beiram from the BC, Mark McFadden from the ISPs, Sophia Bekele as a NomCom rep, Yoav Keren -- is Yoav here? I didn't think I saw him, so -- and he is from the registrars. And we had excellent staff support from Olof Nordling. Did I -- I don't think I left anybody out. Hopefully I got everybody on that. The -- just to lay the groundwork a little bit, there -- if you look at the document, there are four key references that are there that I'll call your attention to. Obviously, the issues report from the ccNSO and the GAC. No. 2 is the board resolutions in regard to this topic. No. 3, the outcomes report of the GNSO IDN working group. That's a very important one, because we make reference to that throughout the draft comments. And then also the GNSO reserved names working group final report, and again, we do make references several times to those comments, so we pulled from work that was already done in drafting these comments. Now, my plan of attack on this, if no one objects, will be to mainly focus on the executive summary, and then if there -- and we'll take one item at a time in the expect summary and see if there are any comments, questions, et cetera. If we need to go further into the document on any of those topics, we can do that. Now, the basic document is divided into two parts. Section A basically addresses the questions from the issues report related to whether or not there should be an interim approach to IDN ccTLDs, and to be very brief on that, I think most of you are aware of the fact that it has been proposed in the ccNSO that so as to get some IDN ccTLDs going more quickly while additional work is being done that possibly each which would that's interested could be given one IDN ccTLD in the nearer term. And later in the agenda this morning, we'll talk about a couple documents that Avri distributed in that regard. The ccNSO hasn't made any final decisions on that. They're working on that. So Section A just talks about that, and we'll look at that briefly. Most of the document actually goes item by item through the issues raised by the ccNSO and the GAC, and provides draft comments -- and I say "draft" because the council has not approved these comments yet, and possibly that will happen this week. Now, let me go through the bullet points in the executive summary one at a time, and I'll open it up for questions or comments, including disagreement of any of the statements. The -- the working group developed everything in here as consensus, and things that we couldn't reach consensus on are not in here. And certainly I encourage those who are on this little working group to join in and clarify anything if I miscommunicate. No. 1, IDN TLDs, that includes ccTLDs and gTLDs. And let me comment on that, just to be clear. This issues paper is really about IDN ccTLDs, but the statement that we included here, we believe, applies to both. So IDN TLDs should be introduced as soon as practicable, after technical requirements and tests are successfully completed. Any discussion on that? [Speaker is off microphone] >>CHUCK GOMES: Excuse me? [Speaker is off microphone]. >>AVRI DORIA: By the way, when you do want to make a comment, do make it to the microphone and do give your name again, even though we may remember, there's a recording, there's a transcription, so it will be important to get people's names again. I probably won't keep giving my name because I'll keep talking a lot. >>CHUCK GOMES: Thank you. And is it fair to assume if there are no comments that there's general support for the idea that is communicated? Anybody disagree with that? That's okay? Yes. Kristina? >>KRISTINA ROSETTE: I just have a clarifying question. Is that subject to the finalization and approval in whatever form of the new gTLD policy, or is that independent of it? >>CHUCK GOMES: Well, this particular statement I don't think needs to be dependent on that. Obviously, for gTLDs nothing would happen until the new gTLD policy is implemented, in particular with regard to IDNs. Now, it is possible that in the final rollout of the new gTLDs, that decisions could be made -- I'm not advocating this, but decisions could be made to delay IDN TLDs later than ASCII TLDs. So I don't think there's necessarily any dependence here, but it is fair to assume that before it would ever happen in gTLDs, we would need that policy in place. That was -- that was a long answer to a short question. >>AVRI DORIA: I don't know if this was in your question, but if the question contained, "Can there be IDN ccTLDs before there's a new gTLD policy," I would say they're not dependent on each other. >>KRISTINA ROSETTE: Oh, no, no, no. No, I understood. I was trying to get clarification as to whether you could have new IDN gTLDs before there's a formal adoption and implementation of the new gTLD policy. >>CHUCK GOMES: No. >>KRISTINA ROSETTE: Okay. >>CHUCK GOMES: That was a lot shorter answer that time, wasn't it? >>KRISTINA ROSETTE: What? >>CHUCK GOMES: My answer was a lot shorter that time. [Laughter] >>CHUCK GOMES: Okay. No. 2 -- yes. Mike. >>MIKE RODENBAUGH: Sorry. It's Mike Rodenbaugh. Just on the process issue, you started to go into asking whether, you know, silence, essentially, on any of these appointments means assent of the entire council and I -- >>CHUCK GOMES: And I'm not asking for a vote. Thank you -- >>MIKE RODENBAUGH: No. I understand that. I just want to make sure that we do have a time to, you know, consult with councillors and constituencies before we come back to this and consider anything final. >>AVRI DORIA: Right. But I would recommend if there is any issue with wording and such and if it means that Chuck needs to pull up his version of it, because I've only got a PDF version of it up there, but if we get to any point where people say, "Well, that's close but..." this is a good time to discuss the issues in detail. But, no, it is not a vote, and silence is not a positive vote. >>MIKE RODENBAUGH: Okay. Thanks. >>CHUCK GOMES: Ultimately, I would expect that the council will take a vote on whether to submit these comments to the ccNSO, GAC, and the ICANN board, since the ICANN board requested them. Okay? Thanks for asking. That's a good question. Dirk? >>DIRK KRISCHENOWSKI: Chuck, to be coming to the time line of the introduction, when do the GNSO Council expect just -- just a guess when the first ccTLD IDNs will be on line? >>CHUCK GOMES: Well you want to talk? Go ahead. >>AVRI DORIA: I don't think we have a guess. I -- I mean, they haven't made -- the ccNSO hasn't made their decision yet on any of this. I think they're close, but as far as I can tell, no decisions have been made, and I certainly wouldn't want to have the GNSO making guesses about when they might do stuff. >>CHUCK GOMES: Now, when we go -- just one second, Bruce. When we talk later about a couple documents that Avri distributed to the council regarding what the ccNSO is doing, in those documents -- which I'm sure we won't go through in detail, but you can see that they've mapped out a plan for dealing with the working group for the broad issues, what their -- which they're anticipating may go several years, and then the interim approach of possibly assigning one it would, you know. So -- and I think, as I recall, one -- that's going to go for a ways before they actually would do anything. But I think we'll maybe answer that question better when we get to that. It's not definitive there either, but they have mapped out a plan. Bruce. I'm sorry. >>BRUCE TONKIN: Yeah. I think I was just going to just comment more or less on what you've said. I mean, is it worth presenting what the ccNSO is looking at, maybe? Because I don't think anyone would be aware of that. That should have got a document for discussion at this meeting which sets out their time frame. But if I understand it correctly, basically they're proposing effectively a fast track and a slow track. The slow track is going to be multiple years, and the fast track I think they're hoping to have a recommendation by the June meeting of ICANN for their process for what they call the "fast track" as to how to let some IDN ccTLDs be created. >>CHUCK GOMES: Yeah. And they haven't -- and correct me if I'm wrong on this, Bruce, but they haven't officially decided to do the interim approach yet. That still has to be decided. But they have got a plan that would be -- their target is by June of next year, if they decide to go that route, to have a plan in place. Now, when would they actually be implemented? I don't think that means June. >>BRUCE TONKIN: I mean that's six months after that. >>CHUCK GOMES: Werner. >>WERNER STAUB: We are, of course, all concerned in the context of the IDN ccTLDs that this might delay the process, and the fast track is certainly a good idea, but the fast track can become a slow track if it is abused or if it basically gives possibilities for people to jump on a bandwagon where they shouldn't be. This is why I think everybody should be, in the wording of anything related to a fast track, say that it must be based on manifest need, not basically just one for each ccTLD. Basically just because it's a French-speaking country, that they create something that happens to have an accent on some letter somewhere. There is no need for that specifically. Whereas there are other cases where there is urgency and there is manifest need, most people can understand immediately. [Speaker off microphone] >>CHUCK GOMES: Mic. >>BRUCE TONKIN: My understanding also is that the ccNSO has formally asked the country code managers to actually state what they believe their need actually is, to try and understand that, because that's part of their input to that decision that Chuck is talking about, as to whether they will go ahead with a fast track. They're also consulting with the GAC on this, I believe, so it's a -- it's a -- this is kind of the very early stages, the beginning of the week, where this is going to be an ongoing topic and I think what Chuck is trying to do is, as part of their deliberations, provide an opportunity for the GNSO to provide some input as well. >>DENISE MICHEL: And if I may just add a couple more process. So the ccNSO and the GAC will be meeting at several points during this week to continue to advance there what they're calling the interim approach, and the intention here, and they'll be providing more in public information on this. The intention here is to have a very tightly scoped round that would allow a very small number of IDN ccTLDs to move forward and to use what's learned from this very limited round to inform the more long-term policy development process that they're about to engage in to provide an overall policy for IDN ccTLDs. >>CHUCK GOMES: Thank you, Denise. Okay. Moving on to No. 2. Neither the introduction of IDN gTLDs or IDN ccTLDs should be delayed because of readiness of one category, but if they are not introduced at the same time, steps should be taken to ensure neither category is disadvantaged because of a delayed implementation. Now, before I open it up to discussion on that, if you haven't already read the full draft comments, we talk in the comments about a recommendation from the GNSO IDN working group in this regard, and the extent of it was that the -- you know, if, for example, gTLD IDNs happened before ccTLD IDNs, it could be that a gTLD IDN might preempt one that could be used for ccTLDs. So it was the opinion of the small working group that probably we should work on that issue to make sure that if one category goes before the other, that we try to put procedures in place to minimize any conflicts in that regard. And so that's at least partially what is being stated here. Questions or comments? Okay. No. 3: If ccTLDs are not ready to offer IDN ccTLDs as early as the GNSO is ready to offer IDN gTLDs, procedures should be developed to avoid possible conflicts. And so you can see the relationship between those two recommendations. Any questions or comments on that? Yes. Olof. >>OLOF NORDLING: It was Dan, my friend here. >>CHUCK GOMES: Oh, it was Dan. >>DAN HALLORAN: I guess it is on both two and three. Hasn't the GNSO already put in procedures such as if somebody applied for a gTLD that matched the name of a country and the country -- and the government of that country didn't like that applicant giving that string, it could object? And that would be a procedure that would minimize the conflict with someone giving out a string that might match the name of a country? >>CHUCK GOMES: We have, or at least those are recommended. Obviously, they haven't been approved by the board yet. So there is the dispute procedure that's being proposed for new TLDs that would allow a community to challenge a gTLD that was proposed. In addition, we're recommending that two-letter ASCII top-level names be reserved so that's another protection, okay? Now, that doesn't really apply to IDNs except where they might be two letter, okay? And I suppose that might be possible, I don't know. I haven't looked at the whole list. So there are some things, but the thinking of the IDN working group -- I don't know if there is anybody here from that working group that would like to comment on that. You are welcome to, if you'd like -- would be that there may be other cases that aren't necessarily covered by those. In fact, it might be better in some cases not to wait for the challenge process but maybe -- this is me speaking just off the top of my head right now. I am not necessarily advocating this, nor has anybody else said this. But maybe there might be some additional reserved names categories. If the ccs, for example, have not decided how they're going to allocate the names or assign even in this interim approach or the long-term approach, there could be some categories like maybe even country names. We did not reserve country names in there. So does that make sense? >>DAN HALLORAN: I guess, the only comment was just you make it sound like work was to be done in the future but, in fact, you have already done some work along these lines. >>CHUCK GOMES: We have done some. The thinking was there might be -- more work might be needed in that regard, okay? Okay. Olof? >>OLOF NORDLING: Just to expand on that in the reserved names working group, it was discussed at length what to do with two-character IDN strings. While there was a conclusion that wouldn't be specifically reserved but there would be -- there was a provision -- decision would have to be taken on a case-by-case basis. And I think that's very appropriate related to this particular issue. >>CHUCK GOMES: You're talking about the second level? >>OLOF NORDLING: No. >>CHUCK GOMES: The case-by-case was the second level. >>OLOF NORDLING: On the top level. >>CHUCK GOMES: We did not reserve -- we did not recommend reserving two- character names for IDNs like we did with the ASCII, that's correct. It did need to be looked at on a case-by-case basis, yes. >>OLOF NORDLING: I think this is such a case. >>CHUCK GOMES: Yeah, that's right. Good, thank you for adding that. Marilyn? >>MARILYN CADE: I think you've covered my question, Chuck. But it did have to do with the issue of countries represent their names in a variety of ways. And how is that -- so that is being dealt with by -- the point being it is up to the country to object if they feel that the characterization, if I could use that word loosely, of the next ccTLD instantiation is in violation of some concept that the country has about how their name is represented. >>CHUCK GOMES: You want to jump in? >>AVRI DORIA: I think the objection is if a gTLD is applied for, that they believe is inappropriate or they object to because it is what they want for the ccTLD, then there is the objection procedure. I don't think the objection procedure has anything to do with the application for a ccTLD. >>MARILYN CADE: But ccTLDs, of course, have different relationships to governments, right? Some governments have direct oversight. They have laws. Other governments have a more collaborative approach to the relationship with the ccTLD manager. So you could envision an environment where a ccTLD -- and that's the other clarification I wanted to raise. We're talking about the present ccTLD managers applying for a second characterization of a cc string as opposed to someone else in a country applying to have a competing ccTLD string in an IDN, right? >>BRUCE TONKIN: I'm not sure about that. >>AVRI DORIA: Need to use the mike. >>MARILYN CADE: That was what I wanted to understand. Because I think in that case I think you could see -- I think this is a question for the GAC, by the way. I think you could see a political situation emerging. >>BRUCE TONKIN: I think, Marilyn, my read of it is certainly the -- that's the perspective of the cc managers, that they are applying for another cc. But I don't believe that's necessarily going to be the perspective from some of the GAC members. So I don't think that's decided yet. >>MARILYN CADE: Thank you. >>CHUCK GOMES: Okay. Going to number four, if any IDN ccTLDs are introduced that will function as de facto IDN gTLDs, then the technical, financial and operational requirement should be similar to those for an IDN gTLD to ensure that there is no unfair advantage. Kristina? >>KRISTINA ROSETTE: Can you just give us a couple of examples of what you have in mind? >>CHUCK GOMES: In the working group -- obviously, I think everybody is aware that there are ccTLDs today that, basically, are operated like gTLDs, very open and so forth. If there are any IDN ccTLDs that are proposed within the ccNSO and those are going to function, basically, like gTLDs, then the recommendation is that those should have similar operational and technical requirements to gTLD IDNs. >>KRISTINA ROSETTE: And will the determination of whether they will function that way be made based on what the applicant says or -- >>CHUCK GOMES: That's a good question. That's a good question. That would have to be work that would be done. I suspect they didn't expect our comments to get that detailed. A lot of these things would result -- to make them happen would need additional work, probably coordination work between the two SOs. Edmon. Okay, Mike was first. Mike? >>MIKE RODENBAUGH: I'm unclear, why are we not recommending that IDN ccTLDs need to be country codes, not -- or related to a country name? At least put that sort of limitation on it rather than leaving it up for any country code to propose any new string. >>CHUCK GOMES: I don't think this is about proposing a new string. If they were, it would come under, I believe, the new gTLD process. >>MIKE RODENBAUGH: It is very unclear. I don't see any limitation or proposed limitation that a cc be limited to a country name. >>BRUCE TONKIN: (inaudible). >>MIKE RODENBAUGH: Point eight? That's exactly my question was. I didn't feel like four and eight were consistent. >>BRUCE TONKIN: (inaudible). >>CHUCK GOMES: Bruce, we need you to use the microphone. >>MIKE RODENBAUGH: How is four even an issue if you have that limitation? >>CHUCK GOMES: Well, let me give you an illustration. Let's take the country code XY. Nice safe one, right? >>MIKE RODENBAUGH: Not from Yahoo's perspective. [ Laughter ] >>CHUCK GOMES: I'm sure it's not. Let's assume that's -- and there is some IDN version of that that the ccNSO decides on, but that little country, XY, decides not to operate that as a -- what we might call a more traditional ccTLD but to make it totally open, unrestricted in any way just like dot com, okay? What this recommendation is saying then -- not that they're proposing a string -- they're using the string that would be approved within the ccNSO for their TLD, for their ccTLD, okay? But they're using it just like a gTLD. That's what makes it a little different than ate. But Bruce is right, eight has a nice connection there. >>MIKE RODENBAUGH: Okay. >>EDMON CHUNG: I'm curious how you would determine, like, the de facto. You mentioned about it being open and unrestricted. The way I sort of see it is that a lot of ccTLDs operate that way, anyway, even though it is sort of still a ccTLD. Wouldn't it be more appropriate to sort of mention something like taking on a secondary meaning? The types where -- a situation where the TLD actually takes on a secondary meaning beyond the country itself. That really becomes, you know, much closer to the issues or the kinds of things that we want to enforce as a gTLD. >>CHUCK GOMES: I don't think that the working group really meant that in what we're saying, although I suppose that could be applied here. It was more a usage of the ccTLD that we were talking about. Part of your question, I think, is very close to what Kristina said in terms of how would that be determined. And that's a very valid question and I don't know the answer to that. That would require some work. >>KRISTINA ROSETTE: Alan, were you next? >>EDMON CHUNG: I think it is really important without that at all, I'm just saying de facto doesn't quite mean anything and I think it would be quite strange if you say -- if you only use the argument that it is open and unrestricted because really a lot of ccTLDs even functioning pretty much -- we would really call a ccTLD, still is operating as a relatively open and unrestricted ccTLD. You know, I'm not comfortable with that sort of recommendation if we're saying with the argument that this is an example of a de facto gTLD. >>CHUCK GOMES: Obviously, one of the concerns of the working group in this -- and this didn't come from me. This was actually proposed by other members of the working group and supported by the full group, though, is the whole competition issue. Obviously, gTLDs have contracts. They have requirements. They're much more controlled within the ICANN world than ccTLDs are. And the concern here is that there be a level playing field, that the gTLDs not be disadvantaged because they have to sign ICANN agreements that are much more involved in terms of the requirements and so forth, that they would not be disadvantaged by competition from the ccTLD world, which I know you understand. Now, while we listen to Alan, why don't you think about maybe a way of rephrasing this that might be better if there is one, okay? Alan, sorry to keep you waiting. >>ALAN GREENBERG: From the sense of the conversation, I think we're talking about examples where a TLD will be opened up for second-level domains where there is no real connection with the country. That is, they are either in it to make money and they plan to sell domains at a real low cost and hope to sell a lot of them. Or as a random example, the domain happens to look like some common short-term acronym like TV. I'm not sure we can ever come up with a definitive way of doing that, although the intent is honorable. I'm not sure we can specify it tightly enough to say you cannot get into a domain if you do not have a specific and direction connection with that country. I suspect we have many top-level domains right now where that's not the case and it is not clear where we can enforce it, especially since ICANN does not have agreements with many top-level domain ccTLD owners and will not have agreements with the IDN ccTLD operators either. >>CHUCK GOMES: This isn't saying they couldn't get the ccTLD IDN, okay? What it's saying is if they do and they are going to operate it that way, then they should have comparable requirements to gTLD IDNs. That's what this is saying, okay? >>KRISTINA ROSETTE: I mean, I think Alan and I are going in the same direction with this in that I think it is an important point but I think it is one we have to define and delineate pretty clearly because I think as a basis point we really are not going to have anything to go on except what the applicant claims it will use it for. We've already agreed in the gTLD context that there will be no revisiting how a gTLD is, in fact, used regardless of what the applicant has said in the first instance, so I don't think we can take a contrary view here. So while I think the intent is a good one, I think we really do need to come up with a way to be very, very specific about what it is that we would consider to trigger those requirements. >>MIKE RODENBAUGH: I just go back to why are we not specifically encouraging that that not be allowed as a practice. I'm sorry, my pretty strong preference would be that we say that ccTLDs need to relate to the country name and other strings are gTLDs essentially. And then I think we are never going to get away from your problem that China, for example, the Chinese government can some day decide to sell their TLD to a China plate manufacturer, I guess. There is nothing we can do about that. >>CHUCK GOMES: Mike, let's jump to number eight and we can cover that later because, I think, to deal with your issue, eight deals more, in my opinion, with what you're talking about than number four. But let's do that. >>MIKE RODENBAUGH: To me they are just not consistent. >>AVRI DORIA: Werner, you had a comment. >>WERNER STAUB: Yes, actually. Essentially, whatever we can say to the ccNSO about how they should or how governments should treat their ccTLDs, it is just like a kid saying to the parent, you know, they should be treated equally. You cannot decide. So it is just a statement. I think there is no point of us getting any further with that, just to say it would be unfair. What else can we say? >>AVRI DORIA: Well, I guess, as the GNSO making recommendations to the board, we can certainly -- it's not just the kid saying, "We want you to be fair." I think we can make recommendations to the board that some things be allowed and some things not as a new policy is being put in place. So I think that if we come to a point that there is a strong support for saying, you know, it should not be allowed as the GNSO's recommendation, then we could certainly pass that on to the board and say that. And how it gets worked out is another issue, but it certainly is a statement. This is not us making policy. This is us going to the board and saying, "Listen, you asked us a question as to our viewpoint on these things. This is our viewpoint." >>CHUCK GOMES: Alan? >>AVRI DORIA: Alan and then Ross. >>ALAN GREENBERG: From a personal point, I strongly advocate that we somehow get ccTLDs -- IDN ccTLDs out there quickly. I think the gTLD process is going to take a lot longer than we're estimating. On the other hand, we have to be aware of the pitfalls that are there. If some country comes up with an IDN ccTLD which visually looks like a circle, the letter O, it will overlap with the potential making availability of the single-letter gTLD in the future. Is that going to be a problem? Should we stop it from happening because their national country script makes their country name looks like the single letter O or that's the abbreviation they use. There are all sorts of pitfalls. All we can do is raise them and make sure someone knows about them. I still think it is a good idea to go ahead with it. >>AVRI DORIA: We had Ross and then Jon and then Dan. >>ROSS RADER: Just quickly. I don't know if the GNSO is in a position to be making recommendations on ccNSO policy. However, I think we're in a position to express our opinions on that and, perhaps, the structure of the document could somehow be altered to separate the opinions from the recommendations. I think the view of the gTLD community is on the subject is probably valuable for the board to take into consideration but we may want to tie in the document a little bit to take that into account more clearly. >>CHUCK GOMES: It is tied up because one of the questions that they ask later -- I don't think this is one of the ones in the executive summary because it seemed like a pretty straightforward answer. It is the answer you just gave. They asked who should be making these policies. And the response in this document is the ccNSO should, they're the policy making body in consultation with their members and the GAC and so forth. So that is addressed in the full document because they ask that question. >>AVRI DORIA: Jon. >>JON BING: Thank you. Speaking out of the depths of my ignorance, there is probably a good reason why they are different, to take into account of the operational requirements between the ccTLDs and the general TLDs. But if they (inaudible), then, of course, the problem will go away. It seems to be the difference because there needs to be a reason and not harmonization. Thank you. >>AVRI DORIA: Dan. >>DAN HALLORAN: Thanks, Avri. When I read number four, it is not clear to me exactly what the GNSO means. Let's say that it turns out that there are some IDN ccTLDs that have very limited technical financial and operational requirements from ICANN. Is the GNSO then saying that IDN gTLDs should have that same low level of requirements? Or are you saying -- >>CHUCK GOMES: That is not -- was not the intent of the group in this regard. It was the other way around. >>DAN HALLORAN: Number four is just saying there should be a level playing field. >>CHUCK GOMES: The assumption was that our requirements are not going to be reduced. But if ours aren't reduced and theirs are minimal, then it does not create a level playing field. >>DAN HALLORAN: There is an assumption there that IDN gTLDs will have similar requirements to gTLD and you think that the ccTLDs should have the same kind of requirements, too. Not that you want to lower -- >>CHUCK GOMES: If they are operating like a gTLD, that was the assumption of the group, yeah. Now, in response to the statement that Ross said -- I think Ross partially answers the concern, Kristina and Edmon, that you were raising. It is not our place to make policy for the ccNSO. Therefore, for us to try to work out how this would happen, we could certainly provide some input as they're developing policy and work with them on it. But for us to actually tell them how it should be done probably doesn't work. The reason I wanted to go to number eight, let's read that one right now. IDN ccTLD strings should be meaningful to the local community and should represent in scripts of the sovereign government's choice a meaningful representation of a territory's name in the selected script. The thinking here is the IDN ccTLD process should not be a means of getting a gTLD. So they should be related to the country, to the territory. Shouldn't just be an open opportunity for -- to get a gTLD in with IDNs without going through the new gTLD process. >>MIKE RODENBAUGH: I appreciate that. I would definitely change "should" to "must" in eight. I do like the limitation to territory's name. What I'm concerned about in particular, I could envision languages, for example, Korea saying that they own the Korean language and won't allow anybody else to have a TLD in Korean script that relates to the word "Korean" instead of the country name "Korea" for example. >>CHUCK GOMES: Norbert? >>NORBERT KLEIN: The problem is that in some countries there are two different official versions of the country name, a short and long one. Like in Cambodia, Cambodia is one official name and Kingdom of Cambodia is another, both accepted by the government. And I don't know whether it would be possible to recommend to use the shorter form, if possible. The same is true for North and South Korea, there is Hanguk and Minguk. >>CHUCK GOMES: Don't you think that's going to be a decision for the ccNSO and the local government? >>NORBERT KLEIN: Yes, I think so, but whether it would be possible to recommend to use the shorter one just for practical technical reasons. >>CHUCK GOMES: Keep in mind -- I hope you all have read the full documents here. But most of the statements are in response to questions that the ccNSO asks. So one of the problems of going through them in an executive summary like this, you don't see the context of the question. So to the extent that a recommendation like that fits in response to one of the issues that they raised, I think that would be fine. What I would ask you to do, in looking at the whole document, is see if there is a place where that would fit. In going through these numbered items here, you're not seeing where they fit relative to the issue that they ask questions on. And so if it fit in one of these questions, I personally wouldn't have any problem with that. But take a look at that and see. I am glad you brought that us, because you are seeing these points in isolation, not in the context of the questions that were asked by the ccNSO and the GAC. >>AVRI DORIA: As you go down, you will often see the answer that you see there. This question should be answered by the ccNSO and the GAC and related governments that are currently involved in the... "This question should be answered," you will see that often. That's what's not showing up in what's on the board at the moment. So I think there is no real recommendation in this. It says long name, short name. It is "significant to." What's "significant to the" is their business. >>CHUCK GOMES: One of the things I would sincerely request before our official meeting on Wednesday is that anyone who has not read the full comments draft do so because without that -- and we don't want to go through it all here. That wouldn't work in a big group like this. But it is very important that everybody read the full document. Now, back to Edmon, did you come up with anything on number four? >>EDMON CHUNG: I just sent it to you actually. I will read it. It is still stuck in my out box. I don't why I can't send things here. >>CHUCK GOMES: Yeah, I didn't get it. You want to read it? >>EDMON CHUNG: Just a suggestion would be if any IDN ccTLDs are introduced that may be perceived to function as de facto IDN gTLDs such as a proposal of a name that may take on a secondary meaning which is generic in nature, then the technical, financial should -- whatever -- should be similar to following the sentence. >>CHUCK GOMES: Any comments on that? Olof, could I rely on you to -- you don't necessarily have to get it down. He will send it via e-mail. Make sure Olof gets that as our staff support person on this, that would be helpful. >>OLOF NORDLING: May I just briefly comment upon that because that goes actually straight into the requirement in eight. >>EDMON CHUNG: It doesn't quite. It doesn't because it takes on a secondary meaning. The case of, I guess, China is maybe sort of an example where TV is problem the best example. TV does mean Tuvalu but it takes on a secondary meaning and general nature and that's really what we're most concerned -- I think, we're most concerned about. >>CHUCK GOMES: So, in other words, an IDN TLD that meant television? >>EDMON CHUNG: In that case, in that particular case -- >>CHUCK GOMES: Has a generic meaning. >>EDMON CHUNG: That's just an example. And I think taking on a secondary meaning is really the main -- at least from my point of view is the thing that we want to say, if such a case happens, perhaps, we need to take a different approach as to, you know -- >>CHUCK GOMES: The TV is not a good example in this case then because, I think, eight would cover that one. If a TLD in an IDN language was television, it seems like eight covers that. >>EDMON CHUNG: No, it doesn't. >>CHUCK GOMES: Television related to a country or territory? >>EDMON CHUNG: But it doesn't in a sense that TV does also represent Tuvalu. >>CHUCK GOMES: TV does but the IDN version that may be allocated to Tuvalu -- >>EDMON CHUNG: Happens to also mean TV, you're saying? >>CHUCK GOMES: I understand the hypothetical, but it seems to be very hypothetical to me. Am I wrong on that? >>EDMON CHUNG: Let's take -- >>KRISTINA ROSETTE: Let's take TM. >>EDMON CHUNG: If the word itself, if the phrase itself -- I mean, in IDN happens to take on a different meaning, just take something else, radio. Let's say some country's name in its IDN form happens to be radio in -- I don't know -- Korean. In those cases, we should take a different approach or at least suggest -- at least take a second look at it before, I guess, just allocating -- or suggest at least as an opinion. Let's say -- I don't know. I am just making this up. Let's say Philippines, the Korean version of Philippines happens to be "radio" in Korean. This would be an example. >>CHUCK GOMES: Tell you what, I don't want to spend any more time on this because we have a lot more to cover, but see if you can come up with a real example instead of hypothetical examples. I think that would really be helpful. >>EDMON CHUNG: Okay. >>CHUCK GOMES: Okay. Now, that doesn't mean we can't consider some changes to the language that you're proposing but let's not spend any more time on this one right now. >>EDMON CHUNG: Yeah. And I can probably come up with one or two in Chinese. >>CHUCK GOMES: That would be very helpful, okay? >>OLOF NORDLING: Before we leave it, since I'm sort of in the drafting position here, I still want to make clear whether we're looking for sort of a -- avoiding unfair advantages and such, or whether we're actually adding a requirement on the string itself, because then we're into 8, and then, I mean, basically we would delete 4 and make an additional requirement on 8. So I mean, I -- I want to make that clear, what we're doing here. >>EDMON CHUNG: Well, at least it would be the intent is not that case. I think the -- at least my intent is to raise a particular -- raise a particular item. We mentioned de facto IDN gTLDs, but I think I wanted to probably go a little bit further, what we mean by that, and give one sort of example, and the example being that the name chosen happens to be a generic term. >>CHUCK GOMES: Again, without belaboring that, I'm going to turn it over to Cary, but let's see if you can come up with some real examples, because the hypothetical, I don't think, helps us very much here. >>CARY KARP: In this case, the real example isn't going to help us one little bit either. We are constantly tripping over issues that are sovereign decisions here and if there is a process that's invoked that results in a national government being permitted a new it would label which is one of its local representations of the country name, if that happens to be "radio" in some other language, what do we do? Tell the government, "Sorry, you can't use your name?" >>EDMON CHUNG: Again, I'm not suggesting that. I'm not saying sorry. But, you know, in those cases, shouldn't we take a second look at it or we should do nothing and just -- >>CARY KARP: The moment a decision is left to a national government, it's not our business anymore. We can't then override that sovereign judgment. So it makes absolutely no sense, splitting hairs about recommendations that are intended to address that kind of situation, because that kind of a situation is just beyond our ability to manage. >>EDMON CHUNG: So you're pretty much suggesting taking 4 completely out then? >>CARY KARP: There are several points in this thing that I would be content taking out, but I'm saving my comments on the ones that should be out for the ones that I want out, not the ones that you want out, but I agree -- [Laughter] >>CARY KARP: Yeah, there are more things here than need to be. >>EDMON CHUNG: But what you just mentioned really should -- you know, what you just mentioned really, you know, should take No. 4 out, and also I think, you know, going back to Ross' suggestion, we really should separate some -- almost thoughts rather than some sort of recommendation, and this probably is one of those that should really not be - - you know, at least not so high up and also not so -- >>CHUCK GOMES: So what you're suggesting is we shouldn't have an executive summary? >>EDMON CHUNG: No, no, no. Have the executive summary but probably out of all these points, separate into two chunks. You know, one of which, the first three are, you know, harmless, somewhat, and, you know, then -- then the ones that we're really suggesting some -- some opinion, like this case where, you know, it may function as a de facto gTLD. These type of things as I think what Cary mentioned is that this is completely out of our scope, sort of -- may be out of our scope once we say, you know, "Governments, please suggest," right? Once we say that, according to Cary, you know, it is out of our scope what they then decide. We're saying that what they then decide, we're going to take another look at that. Is something that's, you know, probably a no-no in -- in a lot of cases. And those types of things perhaps we should, you know, separate in a different section -- not different section, but still in this executive summary, but at a different paragraph. >>CHUCK GOMES: Keep in mind that the ccNSO and the GAC asked us for this input, so I don't think we're stepping on anybody's toes by giving it. So we have to be careful there that our input has been requested. So I think it is -- there's nothing inappropriate about the input. Now, whether or not some things may be put lower in the list or be organized differently, that's something we could -- we could do. Again, if you read the whole document, you will see over and over again comments made with the involvement of the local government. I don't know how many times that was repeated in -- in answers to questions that they asked, so there's full respect for the sovereignty of the governments. Alan? >>ALAN GREENBERG: A lot of the discussions we're having are ones that we should have had two decades or so ago, but we didn't. They're less relevant here, in that if some country comes up with a local script rendition of what they believe their name is, it might have spoofing implications if it looks like something else, but nobody is going to be able to type that in without the right keyboard and character -- and knowing the character set, so we can't have another dot tv, because almost it may look like some word that has applicable across the world, it's not likely to be usable other than in cases where you only click on it as in a spoofing type situation. So it's not really as widespread a problem as it -- as it was two decades ago when we came up with the -- with the current ID -- TLDs. >>CHUCK GOMES: Thank you. Let's go to No. 5. "If an interim solution whereby each ccTLD would be granted one IDN ccTLD in the near term to get the process started faster results in meeting the user needs sooner, we support it." In other words, we're saying we support this interim approach if it -- because a general belief of the working group that developed this was: Let's meet the user needs with regard to IDN TLDs, whether it be gTLD or ccTLDs, as soon as we can, because they've been screaming for it for a long time, it's a real need, and if the interim approach helps that happen a little bit faster, we support it. That's basically what this is saying. Comments or questions? >>AVRI DORIA: I see none. I would suggest moving. We've hit, what, I guess 6 points out of 17 with about 15 minutes left to go on this session, so... >>CHUCK GOMES: Okay. You want me to move quickly. >>AVRI DORIA: I want you to move. No one asked any questions, so... >>CHUCK GOMES: Okay. No. 6 "the user experience is one of the fundamental motivations for deployment of IDNs and should therefore be a guiding principle in implementation decisions." You're going to have to respond quickly. I'm going to move right on. No. 7: "Any IDN ccTLDs added should be done for the sole purpose of benefiting the applicable local ccTLD language community or language communities, as applicable." Mike? >>MIKE RODENBAUGH: Why local ccTLD community, I guess? And I guess I see later where it might not be limited to local. I'm just curious as to how -- why that? I mean why would it not benefit the language community outside of that territory as well, I guess is the point, and how do you deal with that situation? >>CHUCK GOMES: That's a good point. [Speaker is off microphone] >>CHUCK GOMES: Which many do. So you're suggesting maybe deleting the word local. Anybody see a problem with that? Jeff? >>JEFF NEUMAN: Not a problem, but the ccTLDs use local Internet community all the time. That's their words, so I don't see why this is a controversy. I think it should just be left. If you look at every one of the ccTLD documents, they say "local Internet community." >>CHUCK GOMES: Okay. Any other thoughts on that? All right. No. 9: "If there are multiple official scripts used in a territory, the best user experience would be to provide IDN TLDs in all of those scripts, where feasible." Cary. >>CARY KARP: Brief comment. I don't think there's a government in the world that has official scripts. They have official languages and the languages dictate the scripts. >>AVRI DORIA: So it would be "if there are multiple scripts used officially in a territory"? >>CARY KARP: Yeah. >>AVRI DORIA: So you're just moving the word "official." >>CHUCK GOMES: Well, what I did is changed scripts to languages. Should I not do that? If there are multiple official languages used in a territory? >>AVRI DORIA: No. Trying to keep that definition straight between scripts and languages. >>CHUCK GOMES: So tell me what you said again. >>AVRI DORIA: Basically if there are multiple scripts used officially in a territory. >>CHUCK GOMES: Oh. Gotcha. I wasn't quick enough. >>AVRI DORIA: Sorry. >>CHUCK GOMES: All right. >>AVRI DORIA: Ross? >>ROSS RADER: I really don't mean to devolve to this level of detail, but I'm always confused by the language that GNSO uses because it doesn't always map to the language that other communities use. So when you say, Cary, that the -- you're not aware of any governments that have scripts, they have languages, typically those languages are represented by language codes, and governments are well aware of those language codes. Is that what you're referring to or not? >>CARY KARP: No. If -- if a discussion is entered into with a government about what it is that they officially -- I'm just -- it's on now. Okay. A government will tell you what the official language is in which they do business are, and those languages are represented in scripts, no question about it. But if you make reference to official scripts, the governmental reaction is, "What's an official script?" >>ROSS RADER: So, you know, to use the Tuvalu example, again I'm certain -- well, it's a small government so they may not actually get to this level of detail but I'm certain that they must realize that their official language code is ISO639-2. >>CARY KARP: We've left that realm. We are talking about extensive designators for national identity. >>ROSS RADER: Yeah. >>CARY KARP: And there is no give tent to ISO3166 for these. So governments are going to say, "We wish to have the following label associated with our -- our national domain." And we know what our 3166 code was, but we're not talking about that anymore. >>ROSS RADER: Yeah. We'll -- let's grab it over coffee. >>AVRI DORIA: Yeah. >>ROSS RADER: Thanks. >>AVRI DORIA: Yeah. >>DAN HALLORAN: So just to caution that there's a huge difference between a script used officially and an official script and official language. Just speaking locally in California and the United States, there is no official language, and I think if I want to go vote, I could vote in like probably a dozen different scripts. I could ask for a ballot in Persian or Spanish or -- >>CARY KARP: Those are languages, not scripts. >>DAN HALLORAN: It's a script used officially. Well, they're in those scripts, the ballots. Those are scripts used -- the proposal is to move officially after -- >>CARY KARP: Yeah. But you are asking for a ballot in a language, not in a script. If you ask for a Persian ballot, it's going to be in Persian script. If you ask for a Spanish ballot, it's going to be in Latin script. >>DAN HALLORAN: Right. Different points. I agree with yours. My point was that Persian script is used officially in California. Persian is not an official language of the United States. Neither is English. >>CHUCK GOMES: Kristina? >>KRISTINA ROSETTE: I just wanted to make sure that there isn't any risk that with No. 9, we're going under-inclusive. To the extent that there would be a script that although not an officially used one is, in fact, one that would appeal to the local ccTLD community. >>CHUCK GOMES: Okay. Norbert? >>NORBERT KLEIN: I assume that Tin Tan Wee was part of this drafting. In spore, there is -- one of the languages is Chinese but there are two versions of the Chinese script at present, and, therefore, I think it is important to note what is in this wording. I think it was done very carefully. >>CHUCK GOMES: Werner? >>WERNER STAUB: I mean, we might just -- if there's a problem with the word "official" add a definition somewhere in the document and say official means whatever is accepted in court and by Parliament. >>CHUCK GOMES: I have a question for everybody. Forget about the technical wording for a moment. Is there any disagreement with the intent of this recommendation? The intent being that, you know, hey, if there's more than one language used in a place, we think it -- we'd go a little bit further than just supporting one of those languages. The intent, again, was to support all users that could benefit from it. >>WERNER STAUB: I think there is, but just one question: There is precisely there a problem. And you see there are countries, for instance, have been dominated, colonized by foreign powers for some time. What is a colony of that foreign power still in the country, they're not recognized by those who basically took back, so to speak, the control of the country, but they would then finally -- find it extremely unpleasant if suddenly somebody said, "Now, the script of that foreign power should be used," you know, as an official script because it's been a minority in the country. So that's one of the political things that we get into. >>CHUCK GOMES: Keep in mind we're not going to be making these decisions. We're providing some input in response to questions that they asked, and what we're suggesting is, hey, if you can do it in more than one script, supporting multiple languages, we think that's a good idea. Dan? >>DAN HALLORAN: So just to -- it's the same point I just made that you have to be careful about scale because there are literally dozens of scripts used officially in California, probably hundreds in the United States. And there's no official one. So you have to be careful that it's -- is it good that the United States should get 200 new TLDs and all these local scripts because they're used officially? Just it's a -- it's a practicality question. >>CHUCK GOMES: Jon? >>JON BING: Yes. Just a minor point on this official script. There is two ways, in this -- what the usually script or official language means. One is the language in each state is required to make available its material, like statutes, legal decisions, regulations, et cetera. The other is the languages which are permitted to be used, for instance, before a court of law and so on, using translators. In the latter respect, there will be rather many official languages. In the former respect, those which are required to be put out in the government's documents, there usually is very, very few indeed and they are usually flowing from the Constitution. Thank you. >>CHUCK GOMES: Thanks, Jon. What I'd ask you to do, in between now and our meetings later in the week, when we may talk about this again, is think about whether this one should just be deleted or reworded, and if reworded, how should it be reworded. And we won't try and do that here. No. 10: "Confusingly similar strings should be avoided." Mike? >>MIKE RODENBAUGH: Again, I think the verb should be "must" and I think that we ought to be tying -- saying exactly what we mean. Confusingly similar to what? I think to be consistent with our new it would principles, it should say "confusingly similar to any existing it would." >>CHUCK GOMES: Let me comment. You've made that comment before. I'm not sure that it's our place to tell the ccNSO and the GAC what must happen. We're not in a position of authority. Now, if we were writing a contract, yeah, I would agree. But that -- I think that's why we used "should" instead of "must," because we're just providing input to them. They're going to have to decide what "must" be. But I'm open to other thoughts on that. >>MIKE RODENBAUGH: Okay. Well, I understand what you're saying there. We can't demand that they do anything. But it's our recommendation that it must be is what I would put -- the way I would phrase it. And of course 11 has "must" and I saw "must" in here a couple other places. That's why I've been calling it out. >>CHUCK GOMES: Okay. >>KRISTINA ROSETTE: I think it may be an easy way to take care of what Mike's saying is to have some kind of acknowledgment that, you know, these are merely recommendations so accordingly, we have not used "must." In which case where we have, we need to take it out. And that instead, you know, our strongest -- most strongly worded recommendation is indicated with a "should." >>CHUCK GOMES: Yeah. The more I -- the more I see this, I -- the more I'm wondering whether the executive summary causes more problems than it does help. The idea was, a lot of people aren't going to read the whole document, so provide something easy, and what I'm discovering is that it's so easy to take these statements out of context of the question and issues that were raised that maybe one of the things we should consider is not having an executive summary. But we can -- we can talk about that. All right. Any other -- >>CARY KARP: Yeah. >>CHUCK GOMES: Oh, I'm sorry. Cary. >>CARY KARP: I certainly think we should have an executive summary, and I had understood the present discussion to be one of seeing to it that that summary is as useful as it can possibly be, and streamlining verbiage is a normal part of the editorial process. So the notion of combining points here and eliminating points here is, I think, entirely consistent with what we're supposed to be doing right now. >>CHUCK GOMES: Okay. Thank you. >>AVRI DORIA: Okay. What I'd like to -- okay. We've hit 10:30 now. Now, we obviously have not made it through all this. There's obviously language editing that needs to be done to this. What I'd like to quickly do is go through the others and just have people raise the objections without going into discussions so that we get them all on the table, and then I'd like to perhaps during the coffee break find out who would like to work with Chuck and Olof in terms of, you know, a smallish group of people, and I have a really good idea of who they might be -- [Laughter] >>AVRI DORIA: -- that would like to work sort of, you know, off line on wordsmithing. So if we could go through quickly now and just find out which ones have issues so we're all aware of which ones have issues, and then get a wordsmithing group -- small wordsmithing group together to do work. Because we did have a working group do the -- the answers, but the -- the summary was -- was not a working group process, so... >>CHUCK GOMES: Okay. And we'll do that. We'll get that -- get the volunteers at the end of the -- quickly going through this. >>AVRI DORIA: Yeah. Over the break, we'll do that. >>CHUCK GOMES: So anybody else have concerns on 10? Is it just the wording on that? Okay. 11: "Measures must be taken to limit confusion and collisions due to variants." That was straight out of the IDN working group recommendation. No. 12: "Consideration should be given to whether or not adding an IDN ccTLD increases the possibilities of (1), whoa, graphic spoofing (2) creating TLDs for little demand except for defensive registrations and (3) adding a risk of TLDs being used for political ends. >>AVRI DORIA: Cary. >>CARY KARP: I suggest deleting 3 there. "Political ends" are value judgments. What one government regards as a laudable political end, another government might regard as repugnant. >>CHUCK GOMES: Okay. Edmon? >>EDMON CHUNG: No. 2 also seems strange. For, you know, maybe a small country, then what are we really saying? You know, are we saying that a small country should not get an IDN ccTLD? >>CHUCK GOMES: Okay. All right. Going to 13: "Variable strength length would seem like the right approach for IDN ccTLDs." That's consistent with what we said in the reserved names working group. >>CARY KARP: I think we can drop that one. What alternative is there? >>CHUCK GOMES: Well, I understand. Cary, again, they asked the question. >>CARY KARP: Okay. >>AVRI DORIA: Right. It was a question. >>CHUCK GOMES: It was a question they asked. >>CARY KARP: Okay. >>CHUCK GOMES: And we're absolutely saying yeah -- and you're right. They have to. >>CARY KARP: Why don't we say that, then? >>AVRI DORIA: That's what it says. >>CHUCK GOMES: Good point, good point. I think that would be probably a pretty easy change, and you're right. >>CARY KARP: It is the only approach. >>CHUCK GOMES: We were maybe trying to be too tactful and -- >>CARY KARP: Yeah. >>CHUCK GOMES: No. 14: "A suitable process for consultation, including with relevant language communities, is needed when considering new IDN gTLD strings." No. 15: "Where script mixing occurs or is necessary across multiple levels, registries must implement clear procedures to prevent spoofing and visual confusion for users." This, again, comes from the RN working group, or not the RN working group, the IDN working group. Yes. >>EDMON CHUNG: Sorry. I was just a little bit too slow. It's not working. Anyway - - >>KRISTINA ROSETTE: Why don't you use this one? >>EDMON CHUNG: The one before -- it's also not working. >>AVRI DORIA: The whole side is not working. Too many of us on? >>EDMON CHUNG: There you go. I don't understand why No. 14 is there. It's only good gTLDs, it's not about ccTLDs at all. Did I miss... >>CHUCK GOMES: It should say it would strings, I think, not -- yeah. Good catch. Yeah. No. 15 -- let's see. We did 15. 16 is: "It would seem prudent and sensible for ICANN and a prospective TLD registry wishing to deploy their TLD in a given script used by another country to approach that country and/or the local language community in question to vet their intent, particularly from the point of view of viability and marketability." Notice that, again, here it does just use "TLD" and that was intentional. >>AVRI DORIA: Cary? >>CARY KARP: I suggest deleting this entirely. This means that North Korea has to ask South Korea and vice versa. It means Iran has to ask Iraq and vice versa. These are politically absolutely unthinkable demands. >>CHUCK GOMES: Okay. Any -- No. 17: "IDN ccTLD operators should be required to follow the ICANN IDN guidelines just like gTLD registries that offer IDNs." Okay. I guess we're looking for volunteers. >>AVRI DORIA: Right. Yeah. And -- right. Thanks for going through that, and thanks for the discussion. I think we got rid of at least one, got rid of a couple sub- bullets, and I'd like to now go into coffee break, but let the group of people, you know, get together with Chuck, to say a few people. It shouldn't be too many. If a bunch of you in the group all have the same point of view, well then pick one of you to sort of -- and it's a wordsmithing on this, on the expect summary, and not so much the responses, but if it does affect any of the responses, then make sure that the two correlate. And we're obviously going to have to talk about this some more again. >>CHUCK GOMES: So see me before you head out on break. Okay? >>AVRI DORIA: Okay. Thank you. [Break] >>AVRI DORIA: Hello. It is now 11:00 so we are going to try and start up again. We seem to have a few fewer observers for this one than the last one. We are going to start talking about -- we have got now scheduled between 11:00 and 12:30 to talk about the work that's being done on rights protection mechanism and, I guess, Kristina will start talking a bit about what the ad hoc group or working group has been doing in that regard. This is in terms of creating -- I guess we called it an implementation agreement about possible rights protection mechanisms. And then Mike is going to sort of take us through the work that is being done. So, Kristina, it is yours. Mike, you will want this, right? >>MIKE RODENBAUGH: I don't think so. >>AVRI DORIA: I thought you said you had slides. >>MIKE RODENBAUGH: I can't find them. >>AVRI DORIA: You can have it if you have slides. I don't have slides. I do have your documents that I can put up if that will help. >>KRISTINA ROSETTE: All right. While Mike is finding his slides, I will just actually give a little bit of lead-in as to where this group came from. Its origins really were an outroot of the rights protection mechanism working group about which I made a presentation at our meeting in San Juan. The purpose of that working group was to really examine what had been done in previous gTLD launches with regard to preregistration rights protection mechanisms that were designed and intended to prevent and protect -- well, to prevent abusive registrations during those initial start-up phases to look at, perhaps, what best practices might be and whether or not to recommend best practices. Ultimately, there was no -- I think if you really broke it down, you would probably come up with a recommendation that there should be rights protection mechanisms you had support for. There must be -- and you had kind of alternative views that there may be, and if you wanted to merge the two, you could come up with "should." Where we left it after that meeting is one thing that might of value to registrants or potential applicants for new gTLD would be to have a document that would lay out what had been done in the past in a very kind of narrative form and to just highlight some of the key issues that those applicants might want to consider if they were going to adopt an RPM and, if so, breaking it down even further what additional considerations they may want to take into account when deciding which of the various models that were out there. The idea was that this would be a document that would be made available to applicants along with the RFP, really as kind of an optional measure. At the outset, we had hoped that we could also have a component that would really reflect the experience and the expertise of the registries that in the past had implemented these mechanisms. And the ad hoc group, I think, got started. The ad hoc group on implementation of rights protection -- I don't even know what the exact title was. I hope you do, Mike. We got working shortly after San Juan. At this point, I will turn it over to Mike. >>MIKE RODENBAUGH: Gee, thank you. So I guess since San Juan, there's been five or so -- six, seven people in this ad hoc group, primarily from the IPC and then myself. I think Mike Palage was also on it but hasn't appeared much. But anyway, we have had between one and three people calling up on our calls. And it seems like we were tasked maybe with more than -- bit off more than we could chew, perhaps. I understood the mandate of the group was to draft detailed Rights Protection Mechanism proposals that could essentially be adopted wholesale by new TLD operators. We were looking at specifically a standardized sunrise process because, of course, we've seen every new TLD a different sunrise process, which is quite confusing and difficult for businesses to deal with each time. We're also looking at mechanisms to curb abusive registrations, things like anti-phishing suspension plan by registries. Things like a rapid take-down proposal that was proposed by ICM. These were the ideas. We realize there is a problem. We want to give new TLD operators some guidance as to how to address the problem. But the reality is it is a lot of work to come up with these detailed proposals. And few of us on the call, I think, maybe one by one and gradually came to the conclusion that we were likely banging our head against the wall to come up with detailed proposals that probably weren't going to be adopted anyway. So I think, at least I will speak personally, I felt it is like to engage the council and see if we really have buy-in for these sorts of ideas because, of course, they're addressed not just to problems in new TLDs but the existing problems that we have in -- not just in new TLDs but the existing problems we have in existing TLDs. Cybersquatting is rampant. I think the overall feeling of the ad hoc group was we should try to focus our efforts on getting something that's mandatory and that has buy-in from people rather than develop some pie-in-the-sky ideas that probably wouldn't going to go anywhere. I'm hopeful that today we can have a discussion about what potential next steps are and a discussion even on a concept. Do people agree there is a cybersquatting problem out there? I feel like I talk one by one to councillors and other folks and they look me in the eye and say, Yes, it is something we really ought to deal with but the fact is on a policy level we haven't taken really any steps to deal with it. So I don't know really where you want to take the conversation, Avri. I would really love to get people's thoughts on is there a cybersquatting problem and should we do something about it. >>AVRI DORIA: I guess your option of going through the work you've done to date is not something -- >>MIKE RODENBAUGH: Unfortunately, there is not a lot of work done to date. There is an anti-phishing registry suspension plan I can go through, some high-level details. >>AVRI DORIA: I think it would be good to go through what you have got just to give people sort of a view into things. I think it would be good to go through that since that's sort of the work item we have on the table. Then if, indeed, there is a proposal we need something more, then, yeah, we should talk about that after. And then we have a bunch of -- Yes. >>ROSS RADER: I think the most important question Mike had asked to this point is one of the scope and mandate of this working group. That's unclear for me right now. It might be helpful if we could actually tie this conversation back to the original chartering statements. I didn't follow the work of this group in any way and I'm not quite sure where it got its start. It would be helpful as me as a councillor to understand that before we engage in the rest of the discussion. Then, perhaps, we can take a look at these other documents in that light. Is that a fair -- >> JEFF NEUMAN: I would also kind of object to going through the anti-phishing working group document. I am actually a member of the anti-phishing working group but this document has not been run through the registries. Some of the registries have made comments to it. But to present it to the GNSO at this time as some official position or paper is just kind of -- Registries are meeting with the APWG this week to discuss it. I think I to bring it up to the GNSO Council level would not be the most responsible move at this point. >>MIKE RODENBAUGH: I have an outline of it. I wasn't going to go into a great detail. People have the document. I haven't represented that it's agreed by anybody in any way. But I think it might be useful to just kind of highlight what we were talking about with that plan because, at least in my mind, it can be adapted and morphed over time as something that can deal with the cybersquatting problem as well consider. >>KRISTINA ROSETTE: Can I actually just back up and answer Ross's specific question ? Back in -- as I said, this was really kind of an offshoot of the fact that there was no, quote-unquote, agreement among the working group participants -- when I say "working group" I mean rights protection mechanism working group -- that would be a rights protection mechanism that would be made mandatory or the requirement of having one would be part of the RFP. And as a result of that, there were a group of people who had been involved in the group that felt strongly that at a minimum this information should be made available. The ultimate in terms of what was ultimately sent around to everybody in trying to get participation identified the objective as to produce a reference implementation document on a range of rights protection mechanisms which new gTLD applicants may consider in the application process. It is really intended to come up with -- And the document you have got here is really a very rough draft, at least to the extent it talks about, quote- unquote, sunrise, which was not the only rights protection mechanism that was under consideration. Ultimately, the idea was there would be something comparable if you wanted to kind of take the IP claim process that had been created and implemented by Jeff and dot biz and kind of set that out in terms of this is what it was. This is how it worked. Based on how it was implemented, these are considerations that you might want to think about if you were going to do this in terms of this is what people got confused about and this is what we ended up changing, da-ta-da-ta-da-ta-da. I think, ultimately, you ended up with a couple -- it was really kind of the perfect storm of nobody -- I was not willing to leave the group after what I went through with the last group. No one else really wanted to leave the group. We didn't really have any staff support and you, basically, had a bunch of people who were truly, I think, came to the conclusion that why are we going to spend all this time banging our head against the wall. We personally think it would be useful. It is still up in the air as to whether the IPC is going to just take this on as its own project and make it available or whether it is going to be pursued by some of its other member organizations. But in terms of kind of answering your question about scope and what the intent was, the idea would be that ultimately you'd have a document like this that would go out to applicants with the RFP saying, Here are some reference implementation materials that you may want to consider when putting together your application. >>AVRI DORIA: That was one of the decisions that the new gTLD committee came up with, is there will be nothing that's mandatory but if the people that think that something like this should be included, it will be included and they should go produce such a document. So there was no real chartering. It was people who think some things are important, yes, produce it and it will be included as a non-mandatory reference material. >>JEFF NEUMAN: When did the anti-phishing creep in? >>AVRI DORIA: I guess the group that was writing it decided -- This is something, therefore, something for us to discuss. The group that was writing rights protection mechanisms decided that phishing was somehow relevant to rights protection mechanism. I'm not commenting one way or the other because I haven't really thought about it all that seriously one way or another. That's what they made -- the view that the procedures they wanted to offer included that as one of the possibilities and that's one of the reasons why we're talking about it. Yeah, Ross. >>ROSS RADER: So then maybe if I could resummarize what I am hearing and feed it back to the group so that I can understand what you all understand. I should be looking at these documents that we've been -- that have been tabled here as proposals coming from a sector of the community that they wish to have the larger community consider as possible matters of policy at some point? >>CHUCK GOMES: I want to correct you on one thing. Not policy but alternatives that new gTLD operators could consider using in their proposal for a new TLD. Not required, not policy. >>AVRI DORIA: I go one step further in the answer, if I am understanding things correctly, that what we asked for was certainly not policy but what Chuck said. I get the impression that there are still people within that group that would like us to consider these things as policy and not just as voluntary possibilities. >>ROSS RADER: So to play back one more time, we have a big thick document here that's saying to potential applicants, Here are some things you need to consider when you fill out your application and run your registries. We have the smaller document from Mike describing a possible go-forward on new policy development? I think I heard him specifically say that. >>MIKE RODENBAUGH: I think what you're missing here -- maybe, I'm not sure. But when whole discussion, this working group and all came out of the new TLD process. The group was very engaged in a whole bunch of different principles and issues around confusingly similar and morality and whole bunch of other things. I think there wasn't really the appetite to deal with rights protection mechanisms as a potential mandatory situation either from any group because from our perspective, the people who would push such a thing, it's not dealing with the problem. The problem is now in existing TLDs. >>ROSS RADER: I'm not looking to hear the merits of whether or not this is a good or bad plan. I'm just trying to understand what we're looking at. You're proposing that we go through this presentation and read this document and understand it from the context of policy that we may want to implement in some way, shape or form in the future? >>MIKE RODENBAUGH: I think that's true. It is a start. >>ROSS RADER: Okay. >>MIKE RODENBAUGH: I have two slides overview of this document if it would be useful. >>ROSS RADER: I just wanted to ground that because I wasn't quite sure. Thank you. >>AVRI DORIA: To make sure I'm still understanding, the other document, the thick document, is the first draft, albeit incomplete, of the document that would go along with the RFP as not something you need to consider but something that you might want to consider. >>SUSAN CRAWFORD: Avri, can I ask a question? The new gTLD process is very focused, appropriately, on predictability, the standardization, all of that so that applicants face a common interface when they are coming into the process. How does this implementation document square with that? If it's not mandatory, what does that mean? Will an applicant have to be concerned if they don't do it, they won't be selected? Is that at all a concern? No? Well, then what, I'm trying to see is how it squares with the standardization. >>CHUCK GOMES: Thanks, Susan. The thinking is -- I mean, there is lots of flexibility in the new TLD process as proposed for applicants to propose various approaches to lots of issues with new TLD that aren't necessarily requirements. Nor would they be evaluation criteria. So there is no intent at all to evaluate new TLD applications on which rights protection mechanisms they may use or whether they use them or not. But by putting the -- some alternatives out there and then, of course, they can think of new ones, they are not restricted to those alternatives, it was just to give some ideas that they could consider as part of theirs. And the former chair of the new gTLD committee wants to speak. [ Laughter ] >>BRUCE TONKIN: I don't really want to talk as the former chair. I just really want to ask a question because I feel like Ross, I am trying to get my head around what the logical steps are. The previous rounds for new gTLDs have actually required an applicant to state in their application what mechanisms they're going to use to protect the rights of registrants typically during start-up. Then each of those proposals have proposed different approaches to doing that. And the latest version that we're seeing now is from dot Asia which has got kind of the sum of all the other ones that have previously being proposed-type approach. So then what I'm asking, I suppose -- I think it is probably a little open. I just reread the new gTLD recommendations today and there is nothing in the core recommendations that's requiring the applicant to state upfront what the mechanisms would be. Perhaps, this is a question for Dan. The only area that you could consider that would be that there's a section there saying they need to be able to show their organizational capability, whether that would be one of the things you ask. Dan, do you have a feel, what's the staff read in the RFP document for the registry operator to state whether they would have some mechanism to do that? >>DAN HALLORAN: I guess I would like to go back and probably look through the documents and consult on that. I think -- I'm not entirely clear if -- let's say the GNSO has 19 recommendations. Is that meant to be the end all, be all of all the considerations? We do have prior -- I don't know what you call them -- policies. Let's say go back to 2000 where the GNSO or the GNSO said take into account protections of the rights of others. Does that mean since it wasn't one of the 19 things that got picked up this time we should discard that and consider it operational? I guess I'm not sure is the current answer. >>BRUCE TONKIN: To respond to what you're saying, I think what the GNSO is saying, these are the consensus recommendations for things that we want to have. But it's also not explicitly stating. I guess, there are things that staff could choose to put into a document based on previous practice that we haven't explicitly disallowed. >>DAN HALLORAN: Is one of the 19 recommendations -- sorry, Avri. >>AVRI DORIA: Sorry. I think at least the understanding I had was certainly we weren't grandfathering in all of the policy considerations of the last round. And I think that -- and correct me if this is my misunderstanding. This is while you were still chairing the committee, that we made an explicit decision to not recommend a specific requirement for rights protection mechanisms at the second level and that we did make a recommendation that an implementation agreement or an implementation -- what was it - - guideline -- reference would be included of possible ones but that at that point when we were talking through the recommendations of the rights protection mechanism working group which hadn't been able to conclude that there should be, the committee had sort of followed that same line of thought and said there is no "should" to it but that they will be given this reference document with the RFP without a normative statement saying they ought to do it. So it is voluntary. >>BRUCE TONKIN: Basically, what you're saying is the committee and the council decided not to make any recommendation that there was a requirement to have a rights protection mechanism. Is that correct? >>AVRI DORIA: At the second level, yes. >>BRUCE TONKIN: At the second level, yes. And then there was a view that there were -- from my memory at the time, the people that had been involved in producing that working group report had wanted to actually go and put something on the table to say here's what we think is a good implementation and then the idea was, okay, work on a reference implementation that could be included. The only thing I was clarifying, trying to understand from the staff, you're saying that's just a document that is then taken as read for how to build a registry-type document because there are IETF RFCs on how to set up geographic distribution of name servers, for example, so it would be read in the same light of that, it is like an informational document, presumably. Is that a fair summary? I think I was just trying to understand what the context is. So then what role do you see the GNSO Council has with the reference implementation? Do you see the GNSO Council approves that as being a reference implementation or is it merely -- in other words, what status does that document have? Is it a document that's got some imprimatur from the GNSO saying this is an implementation, in other words, it is like a sign-off ? Or is it a document produced by some individuals or the intellectual property constituency. I think that's partly of what Ross is saying. At the end of the day, what status does that document have? >>AVRI DORIA: I think comparing it to the RFC type of -- it is an informational document, I think, that the council needs to say, yes, that's acceptable. It doesn't make it a policy but it has to find the document an acceptable reference, you know, implementation so it doesn't say things that the council in general is not comfortable with. For example, including a statement saying you must include one of these, for example, to jump quite roughly that if this reference implementation included a statement, you must pick one of these for your application to be considered, that would be a reason why the council would say, no, that's not an appropriate document. But I don't believe it is being -- at least it hasn't been recommended as a normative statement that says you must implement one of these. >>BRUCE TONKIN: It is not a consensus policy. >>AVRI DORIA: It is not a consensus policy. >>BRUCE TONKIN: But it is -- >>AVRI DORIA: There is a consensus policy -- >>BRUCE TONKIN: Possible implementation. >>AVRI DORIA: And the consensus policy does include attaching this to the RFP. >>BRUCE TONKIN: Ross, what was the situation with transfers? I am just trying to remember. That's probably the other time when we did that. In the transfers document, there was a reference implementation of the transfers policy. So the transfers working group actually approved that as a possible implementation. Is that how that was presented? >>ROSS RADER: No. Actually, the -- this is going back to things that I had written off as completed so my memory might be failing me. The reference implementation was tabled initially as a discussion point for the working group to use to drive discussion of the policy. It was made very, very clear that, at least at that point, that the role of the council and the working group was not to in any way deal with the implementation details. That was a matter for the contracted parties to sort out for themselves based on the policy and their best legal advice, best corporate advice, et cetera. We did include the evolved form of that original reference implementation as an appendix to the policy recommendations. But it went no further than that. It went no further than that. In other words, the final report of the working group presented to council and ultimately the board did include those supporting materials, but it was not circulated in any way beyond that. For instance, it didn't go out to the registrar community as a suggestion of possible activity associated with implementing those policies. >>BRUCE TONKIN: So it became part of the working group report, right? >>ROSS RADER: Correct. >>BRUCE TONKIN: Yes. Just trying to understand what status you would end up giving the document and, therefore, what process you would want to use to give it that status. You are saying it is a GNSO Council reference implementation or is it a particular working group implementation? >>AVRI DORIA: I believe that it would end up at the end of the day a GNSO Council reference implementation, assuming it is acceptable to the GNSO Council. >>BRUCE TONKIN: (inaudible). >>CHUCK GOMES: Right. I think that is necessary for it to be attached to the RFP. >>BRUCE TONKIN: I would think so, too. >>CHUCK GOMES: Even though it is just some ideas for it to be attached to the RFP, I think the council would need to act on it. >>BRUCE TONKIN: Yeah. >>ROSS RADER: What's the timeline around completing this document? I don't know who I am directing that question to. >>AVRI DORIA: It would have to be -- since it is to be attached -- >>ROSS RADER: You don't have to answer it. >>AVRI DORIA: Do you have an answer? >>ROSS RADER: I am looking at the chair for parliamentary reasons. >>AVRI DORIA: The answer that has been sort of out at the moment is it has to be able to come out with the RFP and one would have to backtrack off the schedule of the RFP to give the council enough time to approve it. >>CHUCK GOMES: As you'll see on Monday when Kurt presents -- maybe you have already seen it if you have looked at the workshop slides for Monday that have been distributed to the council -- that the timeline -- estimated timeline that staff has put forward -- Craig, jump in if you need to -- it probably would be needed in the what? Early springtime, beginning of third quarter, something like that? Excuse me, beginning of second quarter, to play it safe to be attached to the RFP; is that right? That all could change so don't hold the dates firm? >>CRAIG SCHWARTZ: That sounds about right. >>CHUCK GOMES: Now, keep in mind we need to back off of that any action that the council would need to take to say, yeah, we're supportive of attaching that. I think the council has is already kind of supportive of that attaching that, depending on the language Avri was talking about. >>AVRI DORIA: I think the council is supportive of attaching such a document. Obviously, the "such a document" needs to be seen and talked about. >>JEFF NEUMAN: So I'm going to be a little bit of a hypocrite here because I was initially on this group but just through time constraints and others, there is only so many groups that you could participate in. But I think at this point, the document is really just a intellectual property constituency. Four people that wrote this document, not to down play their work. >>MIKE RODENBAUGH: That's true. The document has been reviewed by a whole bunch of anti-phishing vendors. You had input from a whole bunch of different vendors, not just from the IP side. >>CHUCK GOMES: I want to clarify something. >>MIKE RODENBAUGH: It had review and input from Edmon on the registry side quite a bit. >>JEFF NEUMAN: I'm sorry, I am talking about the big document. >>MIKE RODENBAUGH: This document is a skeleton. It is a shell. It has hardly any content. >>CHUCK GOMES: Thank you. That's what I wanted to clarify because what I heard you say, is you really didn't do what you were originally going to do. >>MIKE RODENBAUGH: Right. >>CHUCK GOMES: Is that correct. Of setting out some different ideas that could be done, that you stopped? >>KRISTINA ROSETTE: We started to. I mean, there is some material in here. The primary focus at this point, at least the section that's most developed, is about sunrise. And as to it being, you know, an IP group, you know, anybody who wants to join it is welcome to. And I don't think you can criticize -- >>JEFF NEUMAN: Let me finish my statement. I'm sorry. My ultimate point was if this is intended to go to the RFP, I would, basically, encourage the council to encourage more people to participate in this group because at this point I wouldn't even go so far to make the statement that this should be included with the RFP. I'm a little hypocritical because I was on that group but haven't found the time to participate but I will. >>CHUCK GOMES: But what I'm hearing is that that document -- they're not even I'm telling you claiming that that document is ready to be a reference implementation. They didn't go as far as -- >>JEFF NEUMAN: Right, but that's what the discussion has been. That's why I'm making the point because the discussion from you guys and from Bruce and from others is that the understanding was this document would be attached to the RFP. >>AVRI DORIA: Not this document. >>CHUCK GOMES: Yeah. >>AVRI DORIA: A document that that is the first draft of. Now, I need to perhaps put this in, so that -- that it is me that specifically asked the group to take what they had and put it out so that we would have a base level with which to look and see where we were at, and they were really quite emphatic about, "It needs more work" and so I think the conclusion that you bring up that, "Hey, this needs more work" is really quite good. >>JEFF NEUMAN: I'm not -- right. >>AVRI DORIA: Ross? >>ROSS RADER: Mike's just itching to get his slides out so I'll ask my last question on this point. Is there any -- will this ever be a real reference implementation, in the truest sense of those words, or is this really a -- and was it intended to be a guide or a primer to the legal considerations related to implementing the GNSO's policies? [Speaker is off microphone] >>CHUCK GOMES: I don't think I understand your question. >>ROSS RADER: In other words, the question is: Will the scope of this document -- will the contents of this document move outside of legal considerations related to policy or -- >>KRISTINA ROSETTE: I'm not sure exactly what you're asking. >>ROSS RADER: This document, as I read it, was written by lawyers for lawyers, and -- you know, let me think about the question, reformulating the question. So it may not be my last question. [Laughter] >>AVRI DORIA: Questions with in the truest sense of the word in them always concern me. >>KRISTINA ROSETTE: Just to clarify, I mean, the goal of the document is to be extremely narrative in the sense of, "This is what's been done in the past, this is how, generally speaking, it has been implemented. If you want to implement something like this, based on the experience of the registries that have done it, these are some things you may wish to consider." Kind of very not -- not at all, you know, prescriptive. You know, in other words, "You must have an RPM and it must have and it must look like this." That's not the intention at all. And frankly, as a practical matter, you know, the document really in a lot of ways isn't worth doing unless there's participation from the registrars and registries. You know, because they're the ones who implemented it. The last go-round. They're the last ones who are in the best -- I mean, I can tell you from a trademark lawyer perspective what the problems -- or what problems my clients had with previous RPMs, but, you know, that's kind of the tip of the iceberg with regard to implementation, and I think everybody in the group recognizes that. So, you know, as far as I'm concerned, I would love to see, you know, ten registrar and registry representatives on the group. >>AVRI DORIA: I had Craig and Dan or did I have Dan and Craig? >>CRAIG SCHWARTZ: Let Dan go first. >>AVRI DORIA: Okay. >>DAN HALLORAN: I just wanted to support Ross' comment that this is written only so that lawyers could understand it, and I want to draw your attention to Page 8, consideration 5.1, which reads "blah, blah, blah, blah." [Laughter] >>ROSS RADER: Which means? >>AVRI DORIA: Craig, aren't you're glad you deferred to Dan? >>CRAIG SCHWARTZ: Yes. [Laughter] >>AVRI DORIA: Did you have something to add, Craig? >>CRAIG SCHWARTZ: Yeah. I guess that I did, and that is, I -- this is the -- this conversation is the first time that I'm hearing about attaching anything to the RFP in terms of these RPMs, and Avri is looking at me very cross-eyed right now. You know, the recommendations are the recommendations and the guidelines are the guidelines, and staff is working on the implementation plan now. But I -- I didn't -- I don't recall hearing that there would be this type of document attached to the RFP, but just a means as a -- to serve as a reference guide on what options would be available to applicants who -- to applicants in the round. >>AVRI DORIA: Okay. I guess, yes, I must admit surprise at this being the first time you've heard of it. I know that I've spoken of it several times in meetings I thought that you were at but I apologize for not mentioning it. However, it certainly has been discussed as that, since well into the committee, and it's something that I know that I've kept bringing up every time that the RFP has come out, that this would be something that was sent out with it. Now, whether "sent out with it" is the same as "attached to," I don't know. You know. >>CRAIG SCHWARTZ: That sounds -- >>AVRI DORIA: Right. >>DENISE MICHEL: Yeah. And to clarify, it's not that the implementation team wasn't aware of this effort, but as you can appreciate, the board will officially approve the report and direct staff to implement the report and the -- so all of the implementation directions flow from that, and so, you know, implementation -- the implementation staff obviously is not, at this point, taking action on evolving discussions about whether this is a resource document, whether it might be attached to the RFP. It's on -- you know, it's an ongoing discussion within the council. So I think when the council finishes and comes to a conclusion on what this document is, and how it would recommend it be used, at that point it's appropriate for the implementation staff to look at what their role is. Right? >>JEFF NEUMAN: Yes. Just to jump on, I guess, what Craig said, I guess being a non- council member, it's certainly not what anybody outside the council that I've talked to understood as being attached to the RFP, so maybe that's just a communication issue or, you know, maybe there's been discussions within the council. But the community as a whole, from the people that I've talked to both in my constituency and others, did not understand that to be the case. So that's, again, just a -- maybe a communication issue. >>CHUCK GOMES: Yeah. And I think you're right. There's some communication issues here. But part of it is because there was work that was being done, we were waiting to see what came out of that. And I think some of us hoped that maybe we'd have something by now, before even the board acted. But that's okay. I mean, it still could be done. We certainly could have communicated it better. But -- but Avri's right. I mean, this -- the whole intent after the one working group on rights protections did not come up with a requirement -- a recommendation for a requirement, couldn't reach consensus on that, that the -- how we responded to that was the idea, "Well, what about a reference implementation that could go along with the RFP?" That clearly did happen. Now, we haven't made any final decision to do that. I think Denise comment is well- taken, that if we get to a point where we can do that, we would take action, but it's probably because it's kind of in flux while some people work on it. >>JEFF NEUMAN: But to give some background, there -- there was a reason why the group -- and I was in that group -- came to the conclusion that there should be no recommended approach. So to create one kind of almost -- I don't want to say "ignores" because not the right word. It's just not taking into context why the group came to that decision. >>CHUCK GOMES: I don't think they're related. >>JEFF NEUMAN: So -- but again, I was one of the people, by the way, that did support the creation of this reference document. I just wanted to bring it back into context. >>CHUCK GOMES: Okay. >>AVRI DORIA: Ross. >>ROSS RADER: I figured out how to ask my question, I think. [Laughter] >>ROSS RADER: Is it the -- will this document always be limited to dealing with the implementation of rights protection mechanisms or is it intended to be a broader reference implementation? >>AVRI DORIA: I -- okay. Those that are writing it perhaps should define, but I thought it was the first. >>KRISTINA ROSETTE: Yeah, it's intended to be very narrow. >>ROSS RADER: Thank you. >>AVRI DORIA: Okay. So I guess the question is -- okay. Wait. [Speaker is off microphone] >>MIKE RODENBAUGH: I guess -- I mean, it's intended to be very narrow in that it only is addressing rights protection mechanisms, but the potential range of rights protection mechanisms is actually broad. Okay. Thank you. And I guess I would kind of commenting to kind of keep the flow of the conversation going. I mean, I feel like this document is not to get ready by the springtime. I don't think there's enough people interested in making it ready for the springtime for new TLDs. I think we need to refocus and try to come up with solutions that address existing TLDs and new TLDs equally. >>AVRI DORIA: So I guess I -- I don't know where hands are basically here. Two things in that proposal is: One, that Craig is right and there really is no document to go along with the RFP; and two, you're coming close to suggesting that we would start a PDP process on rights protection mechanisms? I mean to put it in those terms, is that what your -- and that that would apply to all gTLDs, both new and old? >>MIKE RODENBAUGH: That's correct. >>KRISTINA ROSETTE: Well, hold on. I mean, you know, I just -- I don't -- I don't think that we necessarily agree. I mean, I think if this -- if we can get -- if there can participation from the people on the front line of implementation, then I think it's a valuable document. But, you know, in all likelihood, if it's just a bunch of trademark people kind of saying, "This is how we would describe it," you know, I'd rather bill some time, frankly. [Speaker is off microphone] >>AVRI DORIA: Okay. I'm not quite sure where to go with this now. I mean, we basically -- are there other opinions? I guess we've got two -- we've got two opinions at the moment on -- one is, it's worth doing if we can get more people to do it; and two, it's not worth doing it, we should do something broader that is a consensus policy. So I'd hear like to hear some other people on that particular dichotomy. Ross? >>ROSS RADER: I'm happy to take a position on this. I think we've seen this with other discussions inside the GNSO whereby we keep doing work because we can. I think at a certain point, you need to recognize that there may not be agreement on the details, and if there isn't, that you need to kind of put tools down and go focus on something where you can find agreement. I'd have to say, you know, shock and horror, I would agree with Mike that there's probably better things to do with our time than try and herd the cats together and make them agree, because I -- I don't know if we can do that at this point. >>AVRI DORIA: Do you agree with Mike on the second part, that we should be thinking about something that looks kind of like a PDP consensus policy across all gTLDs on rights protection mechanisms? >>ROSS RADER: Yeah. I just -- I'd mentioned to Jeff that I agree with the approach and I'm -- we'll see if we agree on the implementation or the -- the recommendations. But yeah, no, I think the approach is sound. >>OLOF NORDLING: Thanks, Avri. I just wonder if we have based this discussion on exactly the same assumptions, because either this document was intended to be sort of a reference document, not being even an advisory but, rather, to simplify life that they would be able to draw from past experience, without it being any recommendation whatsoever. And then the other extreme is that we -- we have strict proposals that this -- these are good ideas and I wonder where we -- where we really -- if it's the first case, which I tend to remember that we agreed upon, well, it's not an advisory, as such, but just a reference document. And maybe that could simplify to see if we have the same assumptions about what we -- what it is. That may simplify our choice of direction for what to do with it. >>AVRI DORIA: Any other comments on that? I mean, I thought we had gotten to -- and I think that's part of the dichotomy that we've got is some people are happy with a reference document that was what was originally agreed upon, and some people want more, believe that more is needed, and some people probably are in both camps, that believe that having at least a reference document is good, but in the best of all possible worlds there would be more. And just as a council, I guess we need to figure out, you know, where we want to go with this. I mean, we're not going to make a decision on it today. There's sort of a default decision on the reference document, if it doesn't exist, it won't be approved to be -- to go out with the RFP. So that's one thing. In terms of a -- in terms of a consensus policy, if there's a motion within the council or from some other body that says, "There should be an issues report on rights protection mechanisms," then it falls into staff's lap to produce an issues report and then we vote on whether we do a PDP on it after that, that that's another possibility. As I said, we're not definitely going to do that vote today, because we made a decision as a council that only on Wednesday would we vote on things, and I don't even see fitting this into the schedule on Wednesday. It's -- you know. But -- so I'm really looking -- a couple people have spoken, and I don't want to say you can't speak if you've already spoken, but some of the folks from the council and otherwise who haven't spoken on this, I'd really like to hear. Yes, Jeff. >>JEFF NEUMAN: Sorry. I have spoken, but, you know, I think this group came out of the PRO working group, the protection of rights of others, and I agree with Mike that there are certain things that may need to addressed in certain policies but things like anti- phishing working group, that doesn't fit within the definition that the PRO group came up with with rights protection mechanisms. I'm not saying that it shouldn't -- anti-phishing shouldn't be dealt with, but this group, this ad hoc group, was instructed by the council, for rights protection mechanisms, I'm assuming, in accordance with how that determine was defined in the PRO working group final document. Not -- you know, not a broader definition of that. And so I'm personally surprised that anti-phishing came up in this context as a rights protection mechanism. >>MIKE RODENBAUGH: I think I'd just refer you back to the terms of reference for the ad hoc group. It was definitely broader. >>AVRI DORIA: And I guess that that would then come out in two places. One, if the reference document is written including the anti-phishing, then the council would have to decide whether that chapter belonged there or not in its decision to move the document forward, and if we go to the -- the idea of creating a new consensus policy, that would be something that would be written up in the motion on the issues report and then we would follow through on it -- on whether it was an issue that we asked for comment on, and then, you know, the whole process. So -- >>JEFF NEUMAN: I guess my point is that should be treated separately than the introduction of a sunrise and a -- or IP claims or another mechanism at the startup. >>AVRI DORIA: No. I understand. >>JEFF NEUMAN: Not that it shouldn't be dealt with, but I think it should be dealt with separately. >>CHUCK GOMES: Can I make a suggestion? >>AVRI DORIA: Sure. >>CHUCK GOMES: Let me make a suggestion. First of all, I think we need to, sometime this week -- not necessarily this morning -- decide whether there's going to be broad enough participation to warrant coming up with a reference implementation, like you suggested. If we're not able to get broad enough participation, I heard some people say that it probably doesn't work, so I think sometime this week, we need to decide whether there -- and it doesn't have to be people that are in this room. We can enlist other people, and I strongly encourage that, that are in our -- in our constituencies that have more time, maybe, than some of us do, that could work on this. But I think before the week's over, we need to decide whether that's feasible or not, which means we need volunteers. That's totally separate from whether we consider doing a PDP or maybe more than one PDP on rights protection or anti-phishing or anything else, but I think we need to -- we need to get that resolved, because if that doesn't start soon, it's going to be irrelevant. >>AVRI DORIA: I'm not sure that I agree that we need a decision. We've had a decision before. What we really need to do is see if people actually volunteer to do it. >>CHUCK GOMES: That's what I thought I said. >>AVRI DORIA: Oh. [Laughter] >>ROSS RADER: I think there's a bit of a flaw in the logic, though, around enlisting more support for this -- for the drafting of this report. I wasn't involved in the original, and so I'm going to make some statements based on what I'm guessing happened. But I'm guessing that there were two or three different stakeholder groups -- factions, if you will -- within that group that didn't agree on what the right outcome was, and they were, therefore, unable to come to any sort of consensus and didn't agree to anything. So whatever the status quo was kind of got through. But to go back now and ask those groups that didn't agree in the first place to come together to work together to flesh out an implementation report on the details that they didn't agree with -- on in the first place might be asking a bit much. And of course that's all predicated on my guess of what happened, but I -- even if it is the will of council to move forward with this, I don't know how realistic it is, in other words. >>KRISTINA ROSETTE: I mean I would just kind of go back. This is not proscriptive. It's not prescriptive. It's a, "If you want to do this, here's what you might want to think about." Which is a completely different thing than, "You must do this, and this is what it must look like." And so that's where I think we're kind of diverging. And, in fact, there was at the outset interest from five constituencies and volunteers from five constituencies in working on this. So I -- I could see -- I think what -- I think where -- again, where I think you and I diverge is that, you know, this is not a kind of "must." This is not even a "should." It's more of a "may." And to me, that really makes the difference. >>AVRI DORIA: Bruce? >>BRUCE TONKIN: Just listening to it a little bit further, I'm just trying to get the context again. If you read the GNSO improvements report, one of the things it talks about is that the council is more of a management group and what the council decides is when a document comes before council, has it gone through, you know, extensive community review and that kind of determines its status. So there are probably a couple of options with any of these documents. One option is, it is a document from a group of named -- let's sort of going go in steps. It could be a document from a single individual and you see that quite common when John Klensin writes a lot of documents as an individual, his view on IDN. He writes it up as an informational RFC, or draft, and so it's his view. Then you might say, "This document is the view of a group of named individuals," so it's person A, B, and C that support this document. The next level up could be that there's some institutional support, in that this is a document from the registry constituency or this is a document from the registrar constituency or the IPC constituency, which would imply it's gone through some sort of process and some sort of vote. Before it becomes a council document, I would then be thinking that each of the constituencies or -- it's had fairly wide stakeholder group participation in the creation of that document and then the council, looking down on that, says, "Well, this document has had input from quite a wide section of stakeholders, and we're going to endorse it as a council document." So I think those are sort of your range of options. And then coming to Ross -- to the level of volunteers, if you like, if each of the -- if the registries, registrars, IPC, business constituency, several others, have each worked on the document and produced the document, I think at that point it's at a point where the council would endorse it as a council document. There's, of course, nothing stopping it being released as a document from an individual constituency or even from a group of individuals, but there obviously needs to be identified as having that status. So I'm just trying to give you a sense, there's a range of statuses a document can have. It's not an all-or-nothing. You know, it can go anywhere from being an individual's view to a constituency's view to ultimately being a council view, but any of those options is acceptable, I would think. >>AVRI DORIA: Olof, had you wanted to make -- or no. Okay. Jon? >>JON BING: Thank you. In my naive mind, the starting point is that this is meant to be a factual document, which is only declaring or describing what already exists. If that is the -- if that is correct, there can only be two reasons for not including it in a report from the council. One is that it fails to meet the minimum standards of quality that the council wants to be associated with. Or that there is some policy reason for the council to suppress the information. And that, I would be -- be surprised to find that we would like to admit that we have not an open information policy. So therefore, we are left with the -- in my mind -- rather simple question: Are we able to get the quality of the factual discussion of this paper as sufficiently well to pass it on. That could be done, as Bruce just pointed out, by numerous ways, but the objective is, of course, to have a factual description that can help the other more normative processes later on. Thank you. >>AVRI DORIA: Thank you. Yeah, I think that that's -- that that's actually a very good way of putting it, and part of, I think, the issue is to get that basic descriptive document written is, we didn't have a sufficient level of volunteering to get it done at this point. >>BRUCE TONKIN: I'm a little lost there because if it's descriptive of facts, I thought there were a range of different ways of doing it. I thought the reference implementation was saying, "Here is a preferred implementation from that group" or "a best practices implementation." That's a bit different, to me, from a statement of facts, which would be, "Here's how dot biz did it, here's how dot Asia did it," and so on. That's basically a summarization of implementations. >>CHUCK GOMES: I think that's -- the latter one is the one that was intended. >>BRUCE TONKIN: Yeah. >>CHUCK GOMES: IRA here where some examples of how rights have -- attempts have been made to protect rights." And so, you know, it is several that you could choose from, or you could create your own like that. >>BRUCE TONKIN: Yes. >>AVRI DORIA: Mike? >>MIKE RODENBAUGH: Yeah, that was the work of the PRO working group is to accumulate all this factual information. It's just been regurgitated here. The point of the RPM ad hoc group, as I understood it, was to go beyond that, take that factual information and come up with template policies that new it would operators could implement. >>BRUCE TONKIN: That's what I thought. >>CHUCK GOMES: No policies. >>JEFF NEUMAN: Right. It was supposed to be, you know, if another group wants to do -- say in IP claims, you know, it was supposed to be taking the facts of how it was implemented, along with recommendations of how it can be improved upon, and come up with, you know, "Here's a good way to do IP claims in the future if that's what you want to do." [Speaker is off microphone] >>JEFF NEUMAN: Right. That's, I think, the original intention is that's the next group that does the sunrise, here's all the lessons learned and here's ways to address those lessons that were learned. >>CHUCK GOMES: Really, the -- as I understood it, and I wasn't involved in either one of the groups, but the intent was to really put some ideas on the table and let's -- I think it's a good point, lessons learned and so forth, so that it helps those who are introducing a new it would in designing their processes. >>MIKE RODENBAUGH: That's absolutely correct, as to the sunrise period but, you know, that only takes it to -- through the sunrise period. We got to deal with policies that then go from land rush and -- and beyond, is my main point today. >>AVRI DORIA: Anyone else want to comment on this? I mean, in terms of looking on how we proceed, I guess Chuck is right in one respect, is if there's a group of people that really do want to finish this document and really do want to carry through with that, consider it worth doing, then I guess we need two things. We need to know who they are or where they're going to be recruited from, and then we need to see some sort of plan to make it happen. And then in terms of the other thing, do we need a broader policy? Then basically, I guess, you would have