ccNSO Members Meeting Afternoon Session ICANN Meeting 27 June 2007 San Juan, Puerto Rico >>CHRIS DISSPAIN: Well, good afternoon, everybody. And welcome back. Thank you for being so prompt. There are some other people to come, but we have the usual time constraints, so we will get started. Just before I do, an apology to those of you who are listening or watching online. I have yet again by reminded that if people who speak could introduce themselves before they actually -- can you not hear me? >> No, I can. >>CHRIS DISSPAIN: Okay. -- if they could introduce themselves before they actually speak. So I'll try and remember on the basis that you will try and remember as well. If you use the microphone, please say who you are. The first session is a presentation from Jim Reid on the DNSsec signing the root. And it's basically an explanation of RIPE's concerns. So, Jim, over to you. >>JIM REID: Thank you very much, Chris. I hope everybody can hear me. And everyone out there on the Internet who's listening can hear me, too. Before I start, I would like to say that I'm speaking here as a representative of the RIPE community and I'm not speaking here on behalf of many of the other hats that I wear at this particular ICANN meeting. I'd like to say thank you to the ccNSO for giving me this opportunity to come and explain on behalf of the RIPE community why we have arrived at the position we have and the statement that's being sent into the ICANN executive and why we have reached that particular position. All of this discussion came out of a very interesting presentation given to the RIPE DNS working group at the meeting in Tallinn back in May. At that meeting was a presentation from TeliaSonera to have some kind of centralized repository for DNSsec keys. And there was a suggestion being made in that presentation that wouldn't it be nice if the RIPE NCC could actually operate that trusted key repository or centralized repository. And the obvious criteria that drove that were that whoever was going to act as that repository or centralized resource of DNSsec keys, it would have to be a trusted part of some sort, it would have to have good operational experience and have some understanding of basic DNSsec principles and security considerations, all that fine stuff. And also be neutral and not have some vested interest behind it, say, for example, being enthrall to a commercial company or organization like that. So the obvious fit in some respects there would be RIPE NCC, because it's a neutral body, it's strictly neutral. It's got lots of operational expertise as well as having a lot of expertise with DNSsec, and is running large server infrastructures as well as running the Internet registry for Europe, the central east and middle Asia. The working group discussed for considerable length after this presentation about what could and could not be done or what should and should not be done. And the working group was almost split down the middle. Half the working group felt that, yes, there was a need for a trusted key repository. The other felt that there was a bad idea because by having such a trusted key repository, it would take pressure away from the people that really should be trying to drive forward security and deployment, namely, the root and the TLD operators. Because if those guys don't sign their stuff, then you've got to go and do something else. And if you pry something else, then you take the pressure off those guys to do what we all hoped they would do. The other half of the working group felt that maybe a working -- even if such a trusted key repository was created, that perhaps it would not be appropriate for the RIPE NCC to do that, because it would be an example of potential mission creep. The NCC extending its remit beyond its core role with address management in the RIPE region. So the working group was kind of stuck for a while on what we could do to progress things. What was felt was we would form some kind of ad hoc task force inside the DNS working group to deal with the fact we have this split in positions and report back to the working group at the next meeting in October in Amsterdam. So the concerns that were expressed during the discussions about where we should have trusted key repositories or ultimate key repositories was that this would encourage more and more ad hoc solutions. It's more like chewing gum and bits of solutions, duct tape solutions if I can use an American analogy. So you have potential solutions for things like DLV, DNSsec, (inaudible) validation or whatever is going to be the next good or bad idea that comes along after DLV if this stuff rambles on and on and on. And, of course, just taking the classical model that's now in place, is you have to embed a trust anchor, a trusted key into your name server in order to do DNS validation. That's what people like myself do, because we have got some delegations in .SE, the Swedish signed, so we embed the trusted key for Sweden into a new server configuration so that we can validate the signed responses that come back from signed delegation in dot SE. That's acceptable on a very short-term basis, but it's not scalable. As more and more TLDs go down that path, assuming they do go down that path, we have more and more trusted keys put into name server configurations. How do we keep them up-to-date? What happens when those keys change? How do we make sure they all reflect reality? Likewise, if people start going down the DLV route, how many trust anchors are we going to have and which ones do we recognize and what happens when another one pops up? And so it goes and so it goes. And, of course, once all these different or diverse potential solutions or operational hacks take place, kludges, as I would call them. You have interoperability problems and confusion. How do I evaluate something and sign this DLV key when I don't do anything with DLV, but I recognize the top-level domain key for Sweden, for instance. It gets very messy very quickly. So if we go -- having this proliferation of ad hoc solutions is not a good thing. So this is also potentially troubling and also destabilizing. And, of course, the other concern here is that by the adoption of these ad hoc solutions, we take the pressure off those that really should be trying to lead the charge for DNSsec deployment. For instance, if I can get my domain names signed, my dot com domain names signed, and I can get a signed delegation for it sort of through the DLV mechanism by having a trusted anchor somewhere else, that takes pressure off VeriSign to sign dot com, because one of the customers is saying, I want it signed but I can't get my zone signed from you but I can get it signed from somebody else. This is not good, because the more and more people like me and others who are interested in DNSsec deployment go down that path, there are less and less voices putting pressure on VeriSign to say, "Sign your zone, please." And, of course, this problem is as the DNSsec installed base starts to go elsewhere, this then means that those people who are perhaps at the leading edge of DNSsec deployment then gradually disengage from the whole policy development process. They can get their needs met elsewhere, so why should I bother coming to ICANN meetings or RIPE or anything else to discuss policy stuff because nothing is happening there. My needs are being met elsewhere. I don't need to engage in the policy stuff anymore. And that's also bad and that's also destabilizing. So the consensus with the working group did eventually reach was that we didn't want work-around solutions. We thought it's time to put a bullet through a head, and we wanted the real thing. That means we sign the root and we use that as a trust anchor. Then everything should flow from that point. And it was felt that a public statement was necessary in this particular point. And the working group also felt that that particular statement should come from the whole RIPE community and not just from the DNS working group, although the working group was the source of it. So the working group did come up with a statement expressing concern at the lack of progress in getting DNSsec deployed and calling on ICANN to expedite matters. At this point, we're saying we want to see the root signed. We're not necessarily making a statement about who should sign the root. We just say, "Please, ICANN, solve the (inaudible) problems that are preventing the root from being signed." That's technical speak for political and bureaucratic programs that are not technical in nature. So we're saying, please solve this stuff. Technically, it can be done. There's no technical impediment to getting the root signed. There are a lot of legal and policy and political problems. ICANN, please solve them. Get the root signed." That statement was unanimously proved by the DNS working group and then was passed at the closing plenary of the RIPE meeting itself at which we requested their endorsement. We got unanimous support from the RIPE 54 meeting. So this is a unanimous statement on behalf of the RIPE community. We sent a letter to Vint Cerf and Paul Twomey expressing those concerns. And the guts of this letter are on the next slide, which is actually the statement that was agreed by the DNS working group and endorsed as a statement of the entire RIPE community. And I will read this. The lack of progress towards the deployment of DNSsec is undermining the stability and security of the Internet. Operators and implementers are compelled to adopt ad hoc, short-term solutions which will create long-term problems. The RIPE community urges ICANN to speed up and improve its efforts to get the root zone signed. That's it. I will now take questions. >>CHRIS DISSPAIN: Okay. First of all, before we do anything else, are there any -- Mr. Crocker. Please come to the microphone, sir. >>STEVE CROCKER: (inaudible). >>CHRIS DISSPAIN: You have, Steve. You have. >>STEVE CROCKER: I'm just -- I'll be neutral. The very -- >>CHRIS DISSPAIN: You need to say who you are. >>STEVE CROCKER: I'm sorry. I'm Steve Crocker. I'm chair of the Security and Stability Advisory Committee. At the very beginning of your talk, Jim, you talked about the need for a secure trusted repository for keys. Only TLD keys or all levels? >>JIM REID: There was a discussion about keys in general, not necessarily TLD keys. I think the initial motivation from our friends from TeliaSonera was that they would like to see a wider distribution of the key for ISE, because what TeliaSonera and other ISPs in Sweden want to do is they want to do DNSsec validation, and they feel there's a need for a more centralized repository for keys and they can be used for other TLDs if and when they come on stream with DNSsec signing. >>STEVE CROCKER: Othat would result in a repository for dot SE and siblings? >>JIM REID: Not siblings. Well, siblings in the sense of other TLDs. >>STEVE CROCKER: Other TLDs. >>JIM REID: But not delegations of dot SE. >>STEVE CROCKER: Not to argue, but just to make sure we have clarity about the point, so some of us, Russ Mundy and I in our operations have each signed, each have ours signed. But they're down below, they're second-level. And those would not be -- those are not what would be envisioned would be in the repository? >>JIM REID: Well, possibly, perhaps, maybe. It depends. Because there wasn't really any clear statement one way or the other -- >>STEVE CROCKER: Possibly? It depends? How many -- how many -- >>JIM REID: The issue, there was talk of a trusted key repository without really stating explicitly what was meant by that trusted key repository. So maybe (inaudible) of a DLV type key or a number of DLV type keys as well as keys for TLDs. >>STEVE CROCKER: Aha. All right. And that was the proposal. And the next thing that, I think, we saw was that RIPE then sent a letter to ICANN saying -- >>JIM REID: That's correct. >>STEVE CROCKER: -- not -- implicitly saying, please not us. Let's just escalate this right to getting the root signed. >>JIM REID: Yep. >>STEVE CROCKER: Okay. >>CHRIS DISSPAIN: Steve, can I -- may I make a suggestion, if you don't mind? Would you be prepared to come up here and sit up here? Because I suspect there will be questions for you as well as Jim. >>STEVE CROCKER: Sure. >>CHRIS DISSPAIN: Thank you. And I'm -- in fact, one of them is from me, because I want to make sure I'm completely clear about this. If I understood what you said properly -- and I understand how -- in my limited understanding of how this works, if you don't sign the root, then there needs to be a repository for each TLD that is signed. But if you sign the root -- it kind of gets more difficult as you go down the layers; is that basically right? >>JIM REID: That's pretty much it. If we have the root signed, there's essentially one trust anchor. That's speaking in DNSsec jargon here, so I hope everyone understands the term. The trust anchor is the key -- this is the key which I trust and I can validate everything from this key for other parts of the domain name space. So, obviously, if we have a trust anchor, let's say, for dot SE, that means we can use that to validate all domain names under dot SE which have been signed. If, on the other hand, we have a trust anchor which is set at the root, that means that potentially everything underneath the root can be validated, because, presumably, the key for the root will stay in the key for dot SE, which signs the delegations for SE and so on. >>CHRIS DISSPAIN: Steve, is that right? >>STEVE CROCKER: Well, the -- I think the issue is perhaps broader than that in the sense that -- I'll just -- it's easy to take my own situation as an example. So we have Shinkuro.com, and we have it signed. COM is not signed. Even if the root were signed, there would be a gap between the root and Shinkuro.com. And that gap would be at com. So getting the root signed would not provide a chain all the way down to us. >>CHRIS DISSPAIN: No. But wouldn't -- that's correct. But presumably what it would mean is that when com fills in the gap. >>STEVE CROCKER: When -- >>CHRIS DISSPAIN: Then you don't have any more -- in other words, the gap needs to be filled in the middle rather than being filled at the top. >>STEVE CROCKER: Yes. >>CHRIS DISSPAIN: And if I understood one of Jim's points, is that by not signing the root, you're discouraging people from signing their TLD, because there's no authoritative single key at the very top. >>JIM REID: That's. Right. And it's also taking pressure off them a little bit, too. A TLD operator can reasonably say, well, if a parent zone, the root isn't signed, then we don't really feel there's much need for us to do anything now. We'll wait until the root's signed and then we'll start considering DNSsec deployment criteria, which is a kind of reasonable position to take. >>STEVE CROCKER: Go ahead. >>RUSS MUNDY: Russ Mundy. I want to clarify the technical answer to the question you raised just a little bit ago in as much as you -- if I understood what you asked correctly, is a repository necessary if the root isn't signed. From a technical point of view, it's not necessary for the technology to work. From an operational practicality point of view, it's probably necessary, simply because of the quantity factor. And as more and more zones are signed, then whoever wants to verify those zone contents have to have a trust anchor for each of those. >>CHRIS DISSPAIN: Right. And that could be the same trust anchor for each of them. But it would mean that you have to keep fiddling with it because you have to keep adding things, presumably into it. >>STEVE CROCKER: Same repository. >>RUSS MUNDY: It could be the same repository. Now, if a repository is established for a functionality of this nature, a part -- a very critical part -- of that repository to make it a valid, useful repository is that each place that it would draw the trust anchor from -- Shinkuro.com, tislabs.com, a TLD, there would have to be a relationship established that is trustworthy from both a recognition and an ongoing technical perspective so that the repository itself would have a secure way to make sure that they were getting the proper information and that it were up to date. >>CHRIS DISSPAIN: So having the root signed means that you've only got to go to that -- it all stems from there, and it makes it much easier. >>RUSS MUNDY: So if the root is signed, it essentially eliminates the need for these type of solutions. >>CHRIS DISSPAIN: Okay. >>STEVE CROCKER: Well, -- >>JIM REID: I would like -- >>CHRIS DISSPAIN: Steve was next. >>STEVE CROCKER: So I'm happy to let you go. But there is a point that I want to drill down into this very carefully and that I think is important in this discussion. But let me hold back and -- >>JIM REID: Thank you, Steve. Just what Russ was saying about a key repository. If hypothetically the RIPENCC was to operate one of these trusted key repository resources, this could also be potentially destabilized in other ways because then it could encourage others to operate their own key repositories. And then we have a mesh of these things and some of these could have different keys or not all holding some of the keys, it just adds more to the confusion, creates even more potential interoperability problems. If that respect, even if there's a central repository, unless it's got some official blessing and endorsement, we could have that be yet another contributing factor to confusion and more interoperability problems. >>RUSS MUNDY: Yes, that's correct. >>STEVE CROCKER: So let me come back at this in -- First of all, I think in some respects we know a little bit about each other's positions here, and having spoken each of us on this subject before. There is certainly a very strong common agreement that getting the root signed is a good thing and that it would be a big step forward. So what I'm about to say I don't want to be misinterpreted as different from that, but I do want to bring out a very specific and important nuance in all of this. If the root is not signed or for however long -- we can put it in sort of "when" rather than "if" terms. For however long the root is not signed, it creates the requirement to have some other way of getting access to the keys for those top-level domains that are signed. The number of top-level domains, as we know, in aggregate is fewer than 300. So in the extreme, we can imagine that 300 top-level domains are signed and the root is not signed, and therefore whoever wants to get access to all of those keys has to go find a trust anchor repository that holds those 300 keys. And I'm using 300 as an upper bound for the total number of top-level domains at the moment. So the signing of the root from an engineering, from a -- an operational perspective, reduces the load of keeping track of things by a maximum of 300. In contrast, any respectable top-level domain is vastly bigger than that. Com is 60-plus million. Dot SE is 600,000, I think, some number on that order. Dot NL is two and a half million and so forth. So if there are enterprises, second-level domains, which are signed in any significant number below some TLD that is not signed, keeping track of those keys is, per force, a much more significant challenge. So the -- if one looks just at the pragmatics of how you keep track of keys and where the leverage is, the lack of a TLD being signed is much more likely to have a much bigger impact in terms of having to keep track and create need for a registry. Now, in contrast, the point that you made, Jim, about motivation and about a signal, which is a political statement, in effect, is extremely important. I think we're in very strong agreement there. So the fact that the root is not signed removes the global signal that it's time to get on with DNSsec. And if the root were signed, that would be a positive statement to go forward. So I think there really are two dimensions or two aspects of getting the root signed. One is the overriding political statement that says, "This is the time to do it and we should do it and let's get on with it." And the other is the operational aspect, for which we have a relatively good understanding of what the impact is. But that kind of impact is in contrast to the very substantial impact of, say, not having com, net, org -- here's Peter, so DE, UK, and so forth. But the big TLDs, when they're signed, will have a very big positive operational impact, I think. And that's the distinction I want to make clear. >>CHRIS DISSPAIN: Okay. >>PETER KOCH: My name is Peter Koch. I'm speaking as Jim's partner in crime and one of the other chairs of the DNS working group at RIPE. And I want to emphasize on what Jim's message actually was. So maybe I can do this dance as well. So we should remember that RIPE is representing the addressing community. So the organizations represented in RIPE, apart from the fact that everybody can be part of RIPE, but people in the room usually come from ISPs. So they are facing the other side of the DNSsec scenario; right? They are operating the resolvers. And here you should read the word "demand"; right? So they're expressing a demand for DNSsec there. And they, at the same time, have an expectation, and the implicit expectation was that other TLDs and, most notably, ccTLDs, at least as expressed by the Telia folks who brought this forward, that these TLDs will go ahead with DNSsec deployment, and what they -- at the same time, what they said was -- and this is what Steve emphasized, "Well, we're going to do this for our local community, so we at the Swedish ISPs are probably going to take care of the Swedish keys and keep track of it, key rollover and so on and so forth. Maybe we're going to do that for ! our neighbor countries, but we're not going to do that worldwide, let alone for all the second-level domains." And the second-level domains were not on the plate at that session. The point is here, we have a demand expressed by ISPs. And the ISPs say, we're not going to do this all ourselves. We want someone to collect the keys. And the natural point, of course, is the root, because then we have one trusted key to enter and can go forward with this. So this is not to say TLDs cannot proceed with implementing or deploying DNSsec in their TLD before the root is signed. This is saying the resolving site wants a central trust anchor, which is slightly but importantly different. >>JIM REID: Could I make just one quick addition to Peter's comments? This is Jim Reid again. One thing that Peter and I did discuss before I gave this presentation was some statements that I should have made, but didn't, and Peter kind of touched on it a little bit, is that at that the RIPE community is drawn from everybody who uses the Internet or operates networks in the RIPE region, which is Europe, Middle East, and central Asia. So this is all the ISPs, telcos, Internet exchange operators, academics, researchers, all the people that have got vested interest in operating and running these networks. We see the need for secure DNSsec, we want to use it, but we are being hampered with using it because of the lack of having to have centralized key repository, potentially, or at least having the root signed as an enabler to see other things going around. And of course if the root is then signed, that gives them stronger ammunition to go back to their organizations and say we need to start gearing up for DNSsec deployment, we have to understand what the technology is all about, we might start trying to switch on DNSsec validation in our name servers and get operational experience with it. >>ANTOIN VERSCHUREN: Hi, my name is Antoin Verschuren. I missed one point here because it's basically only a technical discussion right now, but if you have a central repository of keys which does not lie with IANA or the root zone, you come to a point where you ask yourself the question "who should I trust?" Should I trust the root zone or should I trust the repository? And basically, I would like to have only one trust anchor that I should trust. >>SABINE DOLDERER: My name is Sabine Dolderer. Here as a private person. I have one question, I'm a little bit puzzled about the discussion because I heard at the RIPE meeting all the ISPs and telecom operators are saying that they are looking forward and have a tremendous need for wanting a trust anchor. And knowing a lot of ISPs, I know that they usually don't want to have one single point where everything hangs on. Because that's ultimately also is a single point of failure, or could be a single point of failure, and is possibly the single point of failure. And was there a discussion about the risks associated to this one single point of -- single trust anchor? And how the single trust anchor can be secured in a way that it is not be in the long run the potential single point of failure? >>JIM REID: First point I would like to answer that is there was not a significant discussion in the DNS working group about the risk aspects of having a single key repository, and that's something that the task force will be looking into in preparation for the report they will be producing in a few months time. But the comment about single point of failure in this context is perhaps a little bit, I will say overstated because fundamentally the root is a single point of failure because there is only one of them. So it doesn't really matter how we get around that problem. The way we deal with that as far as the root is concerned is we have 13 root server operators running on different hardware, different software platforms, different operating procedures. And it may well be that if someone decides to go down the trusted repository route, perhaps there will be some type of diversity there. And if we did go down the route of having more than one trusted repository, that will certainly eliminates your concerns, Sabine, about single point of failure but it will introduce new failure modes now because of potential interoperability problems and conflicts between those particular key repositories. >>SABINE DOLDERER: I agree with you on that that the root is maybe a single point of failure, and we are trying very much to have it as stable as possible. But the question is does it make sense to improve yet another function, which is even more significant -- a significant change, actually, to the current system? Which adds even more, let's say, problematic cases or scenarios. >>JIM REID: This is a very good point, Sabine. This is Jim Reid for out on the Web land. But to go back to the statement Antoin just made before you, he is saying he wants to have just one trust anchor. And the problem is then what happens is if these trust repositories start to merge, who do you then trust? Do you trust your trust repository or do you trust the root or do you trust some TLD? >>SABINE DOLDERER: Yes, but I think the discussion is really interesting, if we were to have a discussion how to set up the system. And I'm not sure that the discussion has yet begun. >>CHRIS DISSPAIN: Thank you. Russ. >>RUSS MUNDY: Russ Mundy again. Just a response to Sabine there in terms of having multiples. There is -- multiple in terms of repository for keys. There is nothing inherent in the DNSsec technology that would prevent another entity from establishing a repository and especially if there were going to be some particular trust relationship in a segment of the hierarchy. That -- so the theory that some folks have discussed is that within certain zones, there might be a higher confidence level in the trust anchor for a particular TLD than they would even have in the trust anchor for the root. And so for the operation of things associated with that TLD, they could obtain their trust anchors from another location. So it is one of these things that's technically possible in the design. It's still only been randomly discussed at times. But if operationally it becomes a desirable thing, I see no reason at this point that would prevent it from coming in to use if that was the right answer. >>CHRIS DISSPAIN: Bill. >>BILL MANNING: Bill Manning. Russ, I am going to echo that, to the degree that not only has some technical possibility been discussed, there are a few people who have implemented it. And generally people trust places where they have business relationships. So one would expect that if you were coming from the U.N. that you would have a trust anchor for the U.N. issued by some party that you trusted there, as well as from the ISP that you get business with, and probably the root. And maybe from the regional registry where you get your addresses. So multiple trust anchors is a viable construct, particularly if you think about real-world business. And it's not so much that you trust the root. It's that you trust how get your service from. >>CHRIS DISSPAIN: Thanks, Bill. Sabine did you want to say something else? You are done? Okay. Steve, are you.... >>STEPHEN CROCKER: Yeah, maybe I'll add one point. The analogy or comparison has been made with the root service. Let me comment on two aspects. The -- Who was it? Antoin made the point that he'd rather trust the root, I think, than the trust anchor repository. I think we all agree with that. The problem that we're wrestling with is until it's possible to get keys into the root zone and get the root zone itself signed, we don't have that option. So it isn't a question of trusting the root or trusting a repository. One has to trust the root for the content of the entries, as we do today, and then potentially trust a DLV or some other trust anchor repository for the keys associated with those zones. The second point that I would like to make is the question of reliability and stability and so forth. For the root zone, as we know, there's been multiple operators and replication of the servers, and so that we have a very robust and well-oiled, worked-out system. If a trust anchor repository is put into service, my feeling -- and this is -- let me label this clearly as my personal opinion, is I think it would be good to have comparable technology applied. That is, multiple copies of the server. And hopefully, a sufficiently transparent operation by one or more operators. RIPENCC is clearly trusted, but possibly other operators or a combine of operators, so that it has all of the credibility and all of the transparency that one would hope for it. So I would like to see -- if we are going to go down that path, I would like to see a substantial praying that people can feel comfortable with, no matter which part of the world or which organization they are coming from, rather than one from a particular operation. And let me add that to the extent that it's helpful, I would be prepared to put some of my own time into helping with that. >>CHRIS DISSPAIN: Okay. We're coming to the end of this session, but I have just -- it's maybe a slightly unfair question, Steve, and if it is, you will doubtless tell me. But it seems to me we had a discussion about whether RIPENCC's concerns about putting people off by not having the root signed or real or not real, et cetera, or whether, in fact, it makes any difference, et cetera. But if you just take the simple request -- >>JIM REID: I'm sorry, I must interrupt here. This statement came from RIPE, the community, not RIPENCC, the organization. >>STEPHEN CROCKER: Excuse me. >>CHRIS DISSPAIN: I apologize. I have no idea what that means, but I'm sorry. It seems to me that the nub of this is to, irrespective of whether it has to be done in order for there to be -- for people to embrace DNSsec or it doesn't have to be done, the nub of this is a request from RIPE saying that ICANN speed up, improve its efforts to get the root zone signed. And my question is, is there a process in place or is there a process being put in place to deal with getting the root zone signed? Or are we just effectively talking in a vacuum right now because there's nothing -- There is no committee discussion, whatever, that's actually dealing with how do we get the root zone signed? >>STEPHEN CROCKER: Are you able to transcribe that chuckle? >>CHRIS DISSPAIN: Steve Crocker chuckled. >>STEPHEN CROCKER: Yeah. You pose an either/or type of question of is there -- and I will emphasize, put a bit of spin on this, is there a well-defined process that's going to lead to a conclusion or is there the absence of all process in which case we are just talking into a vacuum. And I think the accurate answer is it's neither of those extremes. There is no well-defined process. It is also the case that the question has been received and is getting some attention. So what happens in a situation like this is there's kind of a generic process of taking that query and getting people to talk about it and sort of ginning up a process, if you will, so it's kind of a meta process, in geek terms. Although I sit on the board and although I chair the Security and Stability Advisory Committee, I'm not really in a position to speak for ICANN on this respect, except to a limited extent as an observer. I can tell you that that letter obviously came in and has been posted on the Web site. Everybody can see that. And I, too, have asked roughly the same question. And so what's going to happen now? And the answer, and Kim -- who else from IANA is here? Correct me if I'm wrong but the basic answer is, an agreement to focus some time on it and some -- I'm not even going to be specific about when, but soon, if it hasn't happened already, an internal discussion about what to do and then there will be discussions that proceed further from that. >>CHRIS DISSPAIN: Do you want to quickly just say yes or no, Kim? (Laughter.) >>KIM DAVIES: Sure, yes. >>CHRIS DISSPAIN: Well done, Kim. Yes and no. Excellent. >>KIM DAVIES: That sounds about right. >>CHRIS DISSPAIN: That sounds about right. Excellent. Well, unless there are any other questions, I'd like to thank you, Jim, very much indeed, and Steve, for being prepared to sit up here, and actually Russ as well for helping us. So you thank you all very much. [ Applause ] >>CHRIS DISSPAIN: Okay. Lesley, you are on. The next session is on ccNSO participation, and Lesley is going to chair that. And we have Jacob as well and Save. >>LESLEY COWLEY: Good afternoon, everyone. I am Lesley Cowley, manager of dot UK, Nominet. This session is about participation in the ccNSO. And by way of introduction, the desire to increase ccNSO participation was really -- it's been around for a while but I think it was first formally identified in the ICANN strategic plan process, and also more recently it was highlighted in the region's working group discussions that we covered this morning. And as we well know, there are over 240 CCs, but even four years of setting up the ccNSO, only 58 are members. And this is a concern for a number of reasons. So this afternoon, I'd like to try to lead a discussion about what barriers there are to greater participation, or what issues would people like to see addressed that maybe could help resolve this problem. And we're going to start the session with some input from Jacob and Save who, as ICANN regional liaisons, have discussions with managers who maybe aren't all here in this room today, and who share with them their thoughts about participation in ICANN and the ccNSO. And then we are going to open up the session for discussion and comments. And so I need you to start thinking about what you are going to say. Otherwise, it could be a very quiet afternoon. Okay? So be prepared to make inputs. If you're a ccNSO member, what encouraged you to join? If you are not, what would you like to see fixed that might enable you to join. So I give you pre-warning of that. Otherwise, we could have a quiet day. Firstly, then, over to Jacob. Thank you. >>JACOB MALTHOUSE: Thank you, Lesley and Chris for giving me this opportunity to speak today. It's been a long week, so I will ask you to bear with me. Can I just, starting out, get a show of hands how many people are here from the Caribbean in this session? Yes, there they are. Excellent. So you can correct me if I'm wrong on anything in this presentation. So I'll start by just giving a little introduction to my job, and then talk with you about some of my thoughts that I've had during the past 18 months, traveling around the region, and just some observations. And hopefully we'll start the discussion. I really see my role -- and I have to credit Save for this phrase as "ICANN at your doorstep." We're really there to assist in working with ICANN on agreements and IANA interactions, to help explain the ICANN model, including the ccNSO, and the benefits of being a part of that model. Currently insuring the Caribbean, the trends are strong towards accuracy, stability, and security. And the challenges include policy development, economic structures and opportunities, understanding the ccTLD global political economic dynamic. And understanding accepted global norms where those might exist. Going forward, I'm really looking forward to working in an increasingly dynamic ccTLD environment. There's a lot happening in this space. A lot of groups sort of gearing up, tremendous growth year on year in the number of names. I'd like to better understand the human resources at the Caribbean's disposal at a global level, including groups like LACTLD, CENTR, APTLD and other established groups. And I'd like to understand the role of the GAC and ALAC in particular with regard to ccTLDs in the region. And I understand that's also an evolving process. I think to borrow a term from my last job, one of the key things here is cross-fertilization and synergies. And that could include things like seeing the ccNSO continue to foster intra and interregional networking. Voice and video networking. Frequent, a bimonthly conference call that could be open to anyone who is interested, could be at a regional or a global level. In-person presentations, so people actually coming into the Caribbean to share their expertise and their knowledge. I think a partnering or a mentoring program would be a fantastic avenue to help increase and foster participation. As well, brainstorming groups to build scenarios around single or multiple failure events. Conflict risks and plans for managing those risks. Also, there is a dearth of information, as far as I can tell, on statistics, and it would be fantastic to see a quarterly briefing that presents a comparative analysis of size, growth rates and infrastructure setups at the ccTLD level globally. I think a biannual or quarterly newsletter giving an overview of some key policies, perhaps the ccTLD case study or an analysis and impact of various policies that would be distributed globally would be fantastic. And I have a whole laundry list of here of other things that I think would be great to see that leans more onto the documentation side. But I think the essence and the value of meetings like this is the human interaction and the continued growth and development of human interaction on a day-to-day basis, in person, on the islands in the Caribbean, between the Islands and globally will Gabriella really go a long way to foster participation. Which is really based, I think, fundamentally, on friendships between people collaborating to achieve a greater goal. And that's all I have to say, and I thank you very much for the opportunity to speak today. (Applause.) >>LESLEY COWLEY: Thanks, Jacob. Thank you, Jacob. So if I can just summarize what you were trying to say, you were saying that maybe improved communication might encourage greater participation? >>JACOB MALTHOUSE: Yeah. And distinct from e-mail and publications. I really mean that human voice and in-person interaction that builds friendships and lasting relationships. I am really fond of saying it takes a network to run a network. And I think that really is critical. And those networks are evolving in the Caribbean and they can be strengthened globally through this forum. >>LESLEY COWLEY: So it's also about really increasing what the ccNSO can offer to other CC managers. >>JACOB MALTHOUSE: Absolutely. >>LESLEY COWLEY: Okay. Save, can you give us your thoughts? >>SAVE VOCEA: Hey, just from what Jacob has said, I think in the Pacific Island situation it very much mirrors some of the smaller countries in the Caribbean. I just wanted to raise here that in the Pacific Islands model, there's about 23 island countries there. And out of the 23, there's about 13 Island countries that have outsourced their registry services to a registry either overseas or someone outside of their country. Now, there's only about six registries that are either ISPs or telco that are running their own registry service on Island, and three are also universities and one at the government level. So when we talk about participation here at the global level in ICANN, I seem to see that we look at the other registries that are overseas to look at their issues at the global level. So even at this week's meeting, I was looking around and trying to identify who is here representing other Island countries. I could see like there's at least 11 Pacific Island countries that are represented somehow either through their association with other international registries. At least there's three from the Pacific who are here, Samoan Islands, Fiji, and Tuvalu, who have come through the fellowship. So I would like to congratulate ICANN who have come through with the fellowship program for the fellows. Some of the challenges that has really been identified is that because we are a small market, there are distances and isolation, and it's really difficult to get to some of the physical meetings that they need to be in. And it comes down to really the lack of funding, as well, to attend. And some of the small markets that are there in the Pacific, they really don't have a lot of resource to come and let one of the staff to even go and participate at these forums. But since we are all in the Internet industry, most of them are following what's going on in the industry. But to be really participating or voicing their concerns, we seem to think that things are okay in their own markets. But one thing I would lake to also bring up is there's a lot of regional organizations that are present as well. And I'd like to congratulate APTLD, which is the Asia-Pacific top-level domain associations, and they are represented here. They have been doing a lot of work in the region and have been soliciting members or organizations and ccTLDs in the Pacific to join, and that's something we have been working together in identifying the ccTLDs that are there to be members. Also, there's the Pacific network operator groups, which most of the telcos and the ISPs are members of. And because they are incumbent and they are also ccTLDs, they are participating through that. And I would like to just voice here that through ISOC, within ICANN, we have been able to provide training for the ccTLDs at the technical level, and also some policy level. Of they have a very -- I mean they have a mailing list that they also participate in, so most of the information that we get from the controversial names through the Secretariat, we also are able to impart those information to them through that. So I'll just stop then, and just to say that they are participating, but not really physically, but through the mailing list and through the Web sites and Internet. >>LESLEY COWLEY: So I think you are saying that there is participation through other structures, and particularly regional structures, and also that there are clearly financial barriers to in-person attendance -- >>SAVE VOCEA: Yep. >>LESLEY COWLEY: From many of the smaller registries. Okay. Now, guys, this is your opportunity. If you are a ccNSO member, why? What made you -- what prompted you to join? If you are not a ccNSO member, what would prompt you to join? How with we persuade you to join what's rather a small club at the moment in and I think we very much need to change. Or is it just me that worries about this? >>PATRICIO POBLETE: Lesley -- I am Patricio Poblete from NIC Chile. I am afraid I haven't any answers, just more questions, but that's like the IDN session. I think when we look at the whole of the ccTLDs and why some are not here I think we can distinguish two cases. Even from the days when we were the WWTLD, we were very few compared to the whole of the ccTLDs. So there are many ccTLDs that are out there operating, and we've basically never seen them. Not then, not now. So there is outreach, perhaps, that should be considered to get to them, and find out why they have no interest or no need to contact us. But the rest, the ccTLDs that we do know that are not part of the ccNSO, perhaps it would be -- perhaps it is that we have succeeded too much in some of the things that we have attempted. Namely, that we try to form an organization that was as nonthreatening as possible. So basically, whatever we agree on is not necessarily binding, so we have our doors open. Anybody can come to our meetings. You don't need to be a member to be here and to come to the mike. For instance, one of the most interesting activities that we have, the technical day is organized by someone who is not a member of the ccNSO. So it would seem like since we succeeded at that, it is true that no one has a lot of reasons now not to join the organization. We don't hear those fears that we used to hear before. But on the other hand, there doesn't seem to be a lot of reasons, either, to join the organization. Like it doesn't make a difference if you are or are not a member. And perhaps we should look at that when we are looking at lack of participation. >>LESLEY COWLEY: Thank you. Chris. >>CHRIS DISSPAIN: I have a couple of points also, maybe more questions rather than answers. >>LESLEY COWLEY: That a paper on question? >>CHRIS DISSPAIN: Yes, yet another paper on question. I want to pick up on a couple of things Patricio said and respond to that. You are right, there are a number of ccTLDs who simply have never been involved, but I also think it's fair to say that increasingly, over the last three or four meetings, we have actually been seeing -- maybe not necessarily as members, but we have been seeing new ccTLDs emerging. And certainly at this meeting in the Caribbean -- and I've met people that I have never, never seen before, and it's marvelous that that's the case. I've got a couple of thoughts. I know that -- I know that one barrier or perceived barrier is that our membership application form still says, "And I agree to pay any ccNSO membership fees that may exist," and the bylaws still give us the opportunity to charge those fees. Now, I, having been intimately involved in setting these up in the first place, I never imagined that there would be any fees. But the principle was that if we had a Secretariat, et cetera, we would need to. I personally think we're now at a stage where at least for now, we can take that off the agenda, and I would actually suggest that we remove it -- replace it with a statement that says something like currently there are no fees charged, and any fees would be subject to approval by the members or something like that. I've got a couple other suggestions, but I'll wait for others to talk. >> Hilde. >> HILDE THUNEM: Hilde Thunem from the Norwegian registry. You were asking why we joined, what made us join. In our case, it was a gradual building of trust in the organization. Because from -- from Norway's point of view, we were part of the WW TLD, which was a nice discussion group doing things on best practice. Then this organization was created, and the concept of binding policy was introduced. And we've been fairly vocal on the point that the scope has been very important for us in sort of keeping it limited, making this a safe place for people to participate. We were part of the PDP to change things. And when things have been changed sufficiently that we felt comfortable in joining, we did. There are still minor points we would like to fix, but that's for another thing and another time, definitely. The other part for us was added value. What does this give us that we can't get from CENTR? Why should I travel many, many hours, use a lot of money, and, more importantly, use several of man hour days to be here when we're a small registry with ten people that will significantly -- can feel that I am missing. And if I'm starting to bring tech people to the tech workshop, which is a very good thing, but I'm taking central people from the registry out of commission for many, many days. So what does this bring me that I can't get on the local level? And I would imagine that's the case for -- even more for small and poorer registries than Norway is. Now, actually, yesterday, I got kind of a justification for why I'm here. I've gotten hints earlier, but yesterday when the ccNSO discussed IDN TLDs, which was an issue that couldn't, in my eyes, have been solved by the regions alone, where we had to go to a greater area. There's also the interesting sort of exchange of information on crossing Rogers, learning about new cultures, learning about their domain name policies, and stuff like that. So there's growing sort of added value for me in actually being here. But that's a significant point for us, where I have always had to make the judgment, is this really worth the time? Norway's decided that, well, we will invest the time in being here. We think it's a valuable enough organization, it has an especially thick function, and it also has a specific function in relation to the IANA database and making policy for the IANA database that we cannot get anywhere else. And that's why we're here. >>LESLEY COWLEY: Thank you, Hilde. >> MATHIEU WEILL: Mathieu Weill (inaudible). Three different points. The first point would be a question, actually, which is, what are we trying to achieve? Are we trying to achieve larger participation in the meetings? And having more people involved in our work and getting to know each other and getting to know what the dynamics are? Which I would subscribe to this objective. Or are we trying to increase the number of official numbers, which is maybe a valid objective for ICANN, but definitely not for me. And I would say that it's probably not ccNSO's mission to increase its number of members, per se. It's the number of persons in the meetings and the quality of what's being said which is valuable. But -- And the second question would be, do we have any idea in other constituencies, like the registrars, for instance, of the percentage of people that show up in meetings? That would be interesting to see if we don't already have a wire participation rate than in other constituencies. I'm not even speaking about the GAC, which is specific. Then I would -- I echo most of what Hilde said about why we are members of ccNSO. It's basically about the scope of ccNSO, the way it puts us in a position to influence IANA's level of service, issues related to our status as TLDs, and on the whole, try to have a voice in the ICANN world, which is definitely something that we as ccTLDs cannot avoid. And, well, if I was very confident that everything would be okay and was going in the right direction, maybe I wouldn't even be here. But as a risk assessment, it's probably better being here. And, finally, I would like to also underline that to increase participation, I believe the best ways in order to achieve this is to go through the regional organizations who will bring the first level of knowledge about what the market is and what is discussed in ccNSO, and probably the first step is going to a regional organization and then going to ccNSO when you're mature enough. Thank you. >>LESLEY COWLEY: Thanks, MATHIEU. Just to clarify from your first point on participation. I didn't see participation as being a number target. I saw it as having a ccNSO that gives you value, whether you participate in person or on the lists. How much you learn and take back to your registry. Where so many of us end up reinventing the wheel -- and I even have this in the U.K. I learn things at ICANN, I think, A-had a, I can take that back. And that is value to my organization. So I think participation was in the broadest sense for the benefit of the Internet and our ccTLDs. >> The ccNSO has to be found -- the value of the ccNSO has to be found in a way which doesn't interfere with your regional organizations. Because we learn a lot there as well. >>LESLEY COWLEY: Indeed. >> ALBERT DANIELS: My name is Albert Daniels. I am the country code manager for the dot LC domain, which represents the island of St. Lucia in the Caribbean. I would like to just comment and try to give a perspective, perhaps, on why there has not been a greater membership in the ccNSO from islands like St. Lucia in the Caribbean. This is my first ICANN meeting, and I'm here as a result of the work done by Jacob and the fellowship program. My last meeting of this nature was way back in 1995, which was INET '95. So I don't consider myself to be at the early stages of getting involved with this technology. But I must confess that many of these acronyms I completely ignored. And one of them was ccNSO, because I simply had no reason to find out, you know, what the organization was all about, what work it was doing, and why we should become members. Having been a participant at this meeting, I've grown to understand the importance of the work that the ccNSO is doing and the reason why St. Lucia and all of the islands in the Caribbean should actually become members. So the point is, perhaps part of the reason why more of us are not members is that we simply have not been exposed as you can be at a meeting like this to the work of the ccNSO. We simply do not understand as yet why it is important to be a member. And as a result, we simply are not interested. So what you will find is that if there are opportunities like the fellowship program that ICANN has put in place at this meeting for more of my colleagues to participate, that there will be a great expansion in our participation and membership in the ccNSO. >>LESLEY COWLEY: Thank you. And welcome. Good to see you. >>PETER VAN ROSTE: Good afternoon, everyone. My name is Peter van Roste. I represent CENTR. I have three short points to make. The first one is actually MATHIEU and HILDE already said a few things I wanted to mention, so I won't repeat that, except for one thing which I think is really important. Yesterday showed for me as well what the added value of ccNSO is. So that's what it's really about. My second point is, on the issues that we're discussing -- I mean, if you look at the ccNSO Web site, it isle and modest in its own definition. It basically talks -- I have to read this, because I was a bit surprised. It's about a narrow range of global ccTLD issues. So from that, we already do have a restriction. On ton of that, the ccNSO, as the name says, it's a supporting organization to the board. So we are somewhat restricted, I think, by the choice of topics on our own agenda in that logic. The third thing is that we are a policy development group. And probably policy is not the highest priority on people's mind, especially the ones that only have one or two human resources in their ccTLD to keep things running. And that might also answer the question on why some of them never show up here. Should we then try to get issues that are higher on their priority list on the ccNSO agenda? And -- I mean, I'm not honestly trying to protect the regional organizations' turf here. But as Jacob already mentions, I mean, the human factor is so important that it's probably hard to replace even part of the work that we're doing in the regional organizations by global events. To give you one example, in CENTR, we will have this year probably ten meetings. Three of them would be aimed at the -- at all the members. The rest would be aimed at a very specific group working on legal issues, really going into the granular detail of what people are focusing on. Trying to do that on a global level would not only complicate things just to get people together, but it would also mean that we would definitely discuss issues where the majority of the people in the room would simply not be interested in what we're discussing. And then a last statement. I'm personally very happy that the CENTR board decided only a couple of weeks ago to increase our participation in the ccNSO. Obviously, from our observer role will be a more active observer role than before. So thanks. >>CHRIS DISSPAIN: I just want -- sorry, but just before you start. Thank you, -- I agree with everything you said, Peter. But you mentioned, you talked about what the bylaws say and what our role is. I was going to make this point anyway, and it's just led me to it. It does also say in here, in addition, the ccNSO may also engage in other activities authorized by its members, including seeking to develop voluntary best practice, skills building in the global community, enhancing operational technical operations, and so on. So we do actually have a -- it's a -- we have a mandate to do that if we choose to do so. And not in any way interfering with what CENTR does. But I just wanted to make that point. >>LESLEY COWLEY: Thank you. Go ahead. >>BAHER ESMAT: My name is Baher Esmat. I am the ICANN representative for the Middle East. I'm sort of doing the same job that Jacob and Save do in other parts. I just wanted to share with you some of the, again, views of the Middle East ccTLDs in this respect and the participation part. And, basically, there are two dimensions here. One is mainly related to the ccTLDs themselves in the sense that most of the ccTLDs in the Middle East, they got, like, limited resources in terms of not only financial resources, but even human resources, and they cannot really afford to dedicate one of two participants to go to the several meetings. So that's one aspect. The other one is -- and I think Jacob has touched on this -- is regarding the regional events or the regional gathering. They -- sometimes I feel that most of them, again, prefer to have or to participate in regional sort of activities. And I think Chris has participated to the last meeting APTLD meeting, and maybe you witnessed that there was some good feedback coming from this region, even though they are not able to participate in many ICANN activities. So this is what I just wanted to share with you. Thank you. >>LESLEY COWLEY: Thank you. >>ROELOF MEIJER: My name is Roelof Meijer from dot NL. Lesley, I don't know how long you want this to go on. If I'm being too repetitive, just tell me and I will shut up. As we were one of the initiators of the ccNSO -- that was long before my time, so I'm not taking any credit for that -- I would just like to explain why -- what I think is the added value of a membership of the ccNSO. In short, those are three things. The first one is interaction. The second one is involvement. And the third one I could call influence. So just to make sure it has nothing to do with meeting in the most exotic places. And amongst very pleasant circumstances. That has nothing to do with it. Interaction, I think most people before me have said it already. We are in the unique situation that we have about 200 organizations doing the same thing. And there are different circumstances, without being competitors. Well, mostly without being competitors. I think we've seen so many initiatives here with, what was it, dot NL -- NL.PR, that tend to go into competition. But maybe that's also healthy. But the exchange of experiences, of knowledge, of opinions on issues that concern us all, I think that's very useful. We seek that in CENTR, but we also seek that in the global environment. The second one, involvement, I think that's about a felt responsibility to also exchange, if wanted, on the issues that do not directly involve dot NL or as IDN. And the third one, about influence, I always think that it's more efficient or effective to try to change something from within than from outside. It's very easy to criticize an organization like ICANN from the outside without trying to do anything from within. So I think as we saw yesterday with our discussion on dot IDN, we can really go away in that direction. Thank you. >>LESLEY COWLEY: Thank you. >>DAVE ARCHBOLD: Dave Archbold from KY domain. I'd just like to make a couple of points from the region's working group point of view. I find it interesting that we got quite a lot of feedback that regions had nothing to do with participation, and yet just about every speaker at this rostrum has talked about regions and regional support. And I think it varies very much from area to area in how appropriate it is or how comfortable the local TLD might be with the region in question. And when in our case, for example, we are across the Atlantic from our region, it makes participation quite difficult. The only other point I think I'd like to make is that some have said how the ccNSO has made itself, I think, less threatening was the comment that was made, but perhaps in doing so, it has also made itself too bland, because we have had the feedback, the comment that people don't come because you don't talk about anything that's of interest to them. And I think that's an issue. I understand the policy constrains and the bylaws, et cetera. But perhaps we can look at that and see if we can do more. Thank you. >>LESLEY COWLEY: Thank you, David. >>OSCAR ROBLES: Thank you. Oscar Robles from dot MX. And I want to say that I am -- I generally agree with what Roelof Meijer just said. And let me tell you that since the '90s, LACTLD has tried to address most of the ccTLDs of the region without enough success, mostly because we have been a political organization rather than an interaction and a place to share ideas of the development of the registries and these kind of things. So my perception is that most of the ccTLDs are not eager enough to be -- to have a participation for -- to influence things. But what they need is something that may help them develop their business, their companies, their ccTLDs into a better ccTLD. So I think that the sooner we move the ccNSO to a place where we can share ideas of day-to-day operations and these sort of things, the better for most of the ccTLDs that don't care about influence or political issues. That's my comment. >>CHRIS DISSPAIN: Thank you, Lesley. I just have a couple of other points I wanted to make, or suggestions. I think one thing that's pretty clear is that people come for different reasons. And also, it's clear to me that the regional organizations do a fantastic job. But regional organizations are great for some. They're not great for all. I mean some -- it depends on your region and all that sort of stuff. But I had a couple of concrete suggestions for -- just to put out there, and we'll obviously need to make a decision about how we take this forwards at the counsel meeting. I think most of you probably know I was asked at the -- I was asked -- I went to the orientation meeting, the ICANN orientation meeting, and I was asked whether there was anything on the ccNSO Web site where people could go and look up the different sorts of models there are of ccTLDs and the different sorts of policy models. And, of course, the answer to that is, there isn't. So I think that's something that we should be doing as quickly as we can. And I know that we're going to have a discussion about the Web site a bit later on. And I've been thinking about this one for a while. And it's kind of about the ccNSO in the sense that it -- if you use the membership of the ccNSO as the sort of starting point for doing this. And that is whether we could look at the sort of sister city model that exists around the world and actually take -- partner with a developing -- each of us, or some of us that feel that we can, partner with a developing ccTLD. And that could range from simply just exchanging information to helping them to attend meetings, to whatever you feel that you could -- that we could do. Now, there's a significant amount of work to be done to get that to work, because you'd have to figure out what the rules and regulations are. But, nonetheless, I think that's something that might be worth looking at. And, you know, you just pick a partner, and you help them. That's it. >>LESLEY COWLEY: Okay. Is there anyone else who would like to input a comment who hasn't been able to speak as yet? 'Cause I know there are some of you who said you were going to speak and haven't. [ Laughter ] >>CHRIS DISSPAIN: Are we going to name shame? >>LESLEY COWLEY: No, I won't name shame. Thank you. >> MARGARITA VALDES: Hello. My name is Margarita Valdes. I am from Chile, and LACTLD chair. My idea is quite simple. If we are a ccNSO open, everybody could come here and share experiences and so on, where is the carrot? That's my point. So we need to find to be attractive enough in order to try to gather more colleagues inside. In my case, in ccNSO, Latin American ccTLDs are a big number. But I have a pair of ones that are not inside and I am trying to find wait to invite them and make this attractive. >>LESLEY COWLEY: Thank you, Margarita. Okay. Let me just feed back, then, what I think I've heard you saying. And I have four sort of headings. The first is communication, where a number of you were saying we need to explain what the ccNSO is better and what we do here and also why you should be -- why you should be members for involvement, for influence, for learning. There was also an idea about revising the Web site, which, fortunately, is coming later. And also about participation remotely, through voice, through video, through conferencing, et cetera. And, quite clearly, some people do not see a need to attend, because maybe perhaps they don't know what's coming up at a particular meeting very well. So there are some communication things there. A number of the other comments, my next heading, were about added value. What is on offer at the ccNSO? Why should you participate? What can we develop as things that might attract people, and, indeed, may well help us to justify why we are here in terms of more sharing of ideas and best practice, sharing of policy models as well, and perhaps statistics and research that we -- a number of us carry out but perhaps don't share on a proactive basis. A couple of people have identified barriers, which is my next heading. And, yes, a number of people who have not spoken today have identified the issue about fees, particularly some of the smaller registries. If you know you're signing up and there's going to be some sort of future fee and you have no idea what that might be, then that is perceived by some to be a barrier currently. And also a much more difficult barrier to overcome, perhaps, is about increasing trust. I remember my first ccNSO meeting, and I think we have moved a long way since then, but still there are issues of trust. And, finally, we had some ideas, which is really good. And the idea of a mentoring program about some perhaps more experienced CCs being able to share with less-developed CCs, a twining program. I can just see the signs, "twinned with somebody." The idea about let's make a decision on fees, let's make a commitment on fees, or a lack of them, for a period of time, perhaps, I think would enable a number of people to resolve that issue. And also, there's a clear message about how do we coordinate, how does this work with regional organizations. Obviously, there is some very healthy and excellent work being done in the regional groups. How do we share that on a more international basis? But also, how do people who participate regionally but not internationally have their voice be heard through the regional organizations as well? I think that's something we need to develop a way through on going forward. Thank you for your input today. Hopefully, Chris is going to say whatever we're going to do next. But, clearly, there are some ideas. >>CHRIS DISSPAIN: Sorry. >>LESLEY COWLEY: I saw you disappearing out the door. >>CHRIS DISSPAIN: It's all right. Don't panic. >>LESLEY COWLEY: Clearly, there are some ideas that we can take forward. I think some may be more difficult to address than others. But there are equally things that we could do on this particular issue. >>CHRIS DISSPAIN: Yeah, I think what we'll do is, there's a couple of things that we can take, certainly, to the council this afternoon, you know, the membership fee removal thing, we can do that and stuff. And maybe what we should consider doing is forming a little -- sure, Peter -- forming a little participation working group, Lesley, chaired by somebody called Lesley, preferably. And then again, if we decide to do that in the council, we'll call for volunteers at that juncture. Yes, Peter. >>PETER VAN ROSTE: Thanks, Chris. I just got a message from a member who wanted to comment that one thing that hasn't been discussed, or at least not in -- hasn't been stated clearly -- again, this is not my opinion -- but is that the members who are not here have quite often a political reason not to be here. >>CHRIS DISSPAIN: Oh, sure. >>PETER VAN ROSTE: So they just wanted to add that to -- >>CHRIS DISSPAIN: Absolutely. >>PETER VAN ROSTE: -- the minutes. >>CHRIS DISSPAIN: That could be fine. It could be a visa issue, for example. It could be. It could be a political issue. It could be a statement about I'm not going to go to a country because I don't want to. I mean, that's possible. >>LESLEY COWLEY: Okay. But they're participating remotely? >> (inaudible). >>PETER VAN ROSTE: Just to clarify that statement, they -- for a political reason being they do not want to participate in a supporting organization for ICANN. >>CHRIS DISSPAIN: I see. >>PETER VAN ROSTE: It has nothing to do with travel or -- >>CHRIS DISSPAIN: You mean ccTLD managers would have a political reason not to participate. >>PETER VAN ROSTE: Yes. >>CHRIS DISSPAIN: Of course. Perfectly -- >>LESLEY COWLEY: I don't think that we're going to fix that one very easily. >> (inaudible). >>CHRIS DISSPAIN: Yes, but that's not -- we don't have to worry about that, because there's nothing we can do about it. Okay. Well, can -- Lesley, thank you very much. Save, thank you very much. And Jacob, thank you. [ Applause ] >>CHRIS DISSPAIN: Okay. We're going to move on now to a short session on the ALAC. Now, I can't remember who -- I don't know who was there on Monday and who wasn't there on Monday. But just, in summary -- Siavash, would you like to come and just summarize what the ALAC asked us to do on Monday? Are you okay to do that? >> SIAVASH SHAHSHAHAN: Yeah. >>CHRIS DISSPAIN: Come sit here. Yeah, yeah, yeah. Just before you start, I just remembered one more thing. We've been -- it would be good to say it now since we've just been dealing with participation. I currently have three applications for membership which arrived today. Certainly two of which I'm hoping to deal with at the council this afternoon, and maybe all three, but certainly two, one of which may have to be slightly delayed. So certainly it's obvious that having people at the meeting as nonmembers can lead to them applying to become members. I'm sorry, Siavash, please carry on. >> SIAVASH SHAHSHAHANI: I'm Siavash Shahshahani. I'm from -- I guess I'm the liaison of ALAC to ccNSO. I'm an Asia-Pacific member of ALAC, more specifically, I'm from Iran. Okay. Earlier this week -- by the way, I should say a lot of ALAC people are in the room across the hall, because there's a joint ALAC and NCUC session, a very exciting one, going on. If you don't see many of them here, that's the reason. Earlier this week, on Monday, I believe, we had a joint session with some members of ccNSO. And we found that there are some common grounds for cooperation. Let me just mention two. One is the fact that as -- when you talk about ccTLDs, one of the key words is "local Internet community." And local Internet community just does not mean the government only. We know that ccNSO has been cooperating with GAC to a large extent. Local Internet community also involves individual Internet users. And that's what the ALAC represents. So we hope that by giving an input from the ALAC side, the individual Internet users' side, maybe ccNSO can get a better idea of what the needs of the one -- one part of the local Internet community is. The other one is the structural question. Both ccNSO and ALAC are constructed within ICANN framework by geographic regions. And I guess these are the only two units of ICANN that are structured on the basis of ICANN regions. So there is some common ground there for discussion. Paragraphs I hope that maybe tomorrow, or if we can accommodate in our time, maybe Dave Archbold or somebody could give a presentation to ALAC if there is time on what you have been doing on geographic regions and the kind of proposal that you may present to the ICANN board. Okay. Now, let me say that ALAC has had a long -- well, can't say "long," but has had a history of interaction with the GNSO. But as a disclaimer, I should say that we do not expect a similar or a parallel thing going on with ccNSO, because the interests of ALAC in GNSO has been policy. And as you know, policy in ccNSO is not made. Policy in the ccTLDs is not paid by ICANN, but it made by the Internet communities, local Internet communities. So we understand that. And this is not an area that we think will be, you know, we'll be getting into. Finally -- Well, that's it, really. That's the summary of what went on Monday. Is there anything else I should add? >>CHRIS DISSPAIN: No, I think that's pretty much where we got to. The difficulty is that the only formal mechanisms that exist right now are the ability to have observers. So we have an observer in the ALAC and you are observing from the ALAC and that's fine. It's clear that certainly in respects to the regions that there is -- that the ALAC and the ccNSO are both the most affected constituencies. Regions are relevant to the other ones but in different ways. We are the only one -- two constituencies that have voting based regionally and so on. So I think we should consider some sort of formal -- in the same way that we probably are going to formally send our region's report to the board, we should -- we could consider actually formally sending it to the ALAC with a request for -- I mean, at the same time, not slowing the process down at all, but actually sending it to them but saying we have sent this to the board. We are interested what your thoughts are and what your feedback is. So that's certainly something we could think about doing. That would be discussed by the council at its next meeting when it's actually discussing the region's report because it's not discussing it today. If I can go back to a point that was being made about the ccNSO increasing participation, one of the points that was made and summarized by Lesley was the trust point. And we are slowly building trust within our own community, and slowly building trust in the processes that the ccNSO has. And I think it would also be fair to say that there would need to be a significant trust-building over time with the ALAC, because not all of us but most of us have a very firmly held belief that it's our job to liaise with our local Internet communities. Now, that's not to say that there isn't a role for the ALAC to play and that's not to say that we couldn't utilize the ALAC in certain circumstances. But we need to slowly start to develop. And also, I think it's important to remember that the ALAC is also changing significantly. It's not an interim ALAC anymore. It's now got RALOs and RALOs and all that stuff. So I guess an acknowledgment from us that you are there and we know you are there and we've got liaisons and we are going to continue to talk to each other is about the best you can hope for right now, except that in respect to the regional stuff, maybe we can use that, maybe we can use that as a sort of starting point for developing an interaction between the two groups. >>SIAVASH SHAHSHAHANI: Certainly. Could I just add that by the end of Thursday, ALAC will change from interim ALAC to ALAC, as you just mentioned, because the last of the RALO MOUs will be signed tomorrow. So I hope by next meeting, Los Angeles and beyond, we will have more interactive time with ccNSO. >>CHRIS DISSPAIN: Fantastic. Okay. This is something which, with respect to the regional documents, something that the council needs to discuss, but I'm willing to take anyone, if anyone has anything they, indeed, to say. Any questions at this point on this? Okay. Siavash, thank you very much indeed. Okay. We are moving along to the next item on the agenda which I think is actually the last item before we have a break and set up for the council meeting. And that is Mr. Boswinkel on the ccNSO Web site. Bart? Gabby? Whoever? I wish you could all have seen Gabby's face. >>BART BOSWINKEL: I just want to do it, yeah, it's going to be very brief. Just three topics for today. One is Gabby will give you a bit of the background of the update of the old Web site to the new one. I have something on what is called the ccNSO observers list and trying to create that, and the third item is moving the Web site further, especially in light of the discussions on the participation. Not so much in substance, but I will request you to appoint five people, one from each region, as I say, type of user group which can interact. Gabby. >>GABRIELLA SCHITTEK: Okay, Bart asked me to go through the new ccNSO Web site with you. That was the first task I had when I joined the ccNSO was to clean up the old Web site. This has finally been done. This is the result. I don't know how many of you actually have had time to look at it, but for those who haven't, I will just go through the most important links for you, which I think you might be interested in. So this is the front page. You can see there is something called "what's new" that you will remember from the old Web site as well. But under this, it's actually only the new things that are listed. It's only the last five new documents that are listed, not the last 35. Under that you see another heading called "Upcoming Related Events." These are not ccNSO events. These are events I thought might be of interest to you, such as regional organizations events, IGF, et cetera. I would lake to ask all of you to send me events which I can put up there which you think might be of interest. Also, I would like to say that I don't have LACTLD's events listed here because I don't understand Spanish. LACTLD, could you please send me your events, and I'll get them posted. There's another meetings page. These are -- This is where the ccNSO meetings are listed, the main ccNSO meetings which are held during the ICANN meetings. I can show you what a complete meeting set will look like. This is from the Portugal meeting. You see this and a link to the agenda, meeting reports, presentation, council meetings, ccNSO technical workshop. Everything is there so you can see what happened there during the event under that link. I hope this will not confuse you, but there is actually another link to another meetings page. This is called calendar, and this is copied directly from the GNSO Web site, because I thought that was a great idea when I saw that. This site has every ccNSO meeting listed. This includes all of the working group, working group Middle East meetings, et cetera. And so as you can see, on the 24th of June there was a GAC working group meeting here. There are the minutes. They are already up. On the 18th of June there was a ccNSO regions working group. This was recorded. We have started to record our telephone conferences. So there's a link there which you can listen to. I hope this Web site will be useful for you. Under "about" you will find all what I think will be -- like all documents you need, everything about the council, everything we have currently about the members. One thing that I was asked to do was to get a career members list, which is here. And actually, it also has a little cool feature. It can be sorted by region. Yes, see that? I inserted the links to all members that I could find. But, for instance, the Maldives don't have a Web site right now but this will be updated once they do, et cetera. Oh, I can also show you about the council so you know what's there. So here you can see, there's a list of all the councillors. There's also a list of all previous councillors. And if you click, you can see who of the councillors have submitted their biographies. Those that haven't, please submit your biography. All relevant council documents are in the side bar. Another I would say quite important link for you is the one that links to the working groups. All the current working groups, all the previous working groups are listed there. If you click -- I can click one so you can see. So you see the charter, a short description of what it's for, working group members, minutes, et cetera. And last but not least, I have a link made for surveys. This is especially interesting now that we heard presentations from Jacob, et cetera. The ccNSO is also meant to be a forum for exchange of information. So I actually put a clear link to surveys on the front page in the hope that if people can find surveys they might actually want to do surveys. Currently I only have two surveys and there's nothing ongoing but I would encourage you to use the ccNSO to conduct surveys. I think this is the most important links that I have shown you now. Please surf around, let me know what you like, what you don't like. And also, I would like to thank every one of you who actually helped me, because I had very much, very good input. So thank you very much [ Applause ] >>BART BOSWINKEL: Okay. The next topic, say in the last couple of months we've seen some very lovely exchanges on the ccTLD discuss list. And that made me think, and especially talking with Jacob, one of the regional liaisons, and with the others as well, is one of the things about the current ccTLD discuss list, and especially in view of, say, policy development processes and exchange of information, is that we don't know who is subscribed to the ccTLD discuss list. >>CHRIS DISSPAIN: It's the WW list. Just clarifying. >>BART BOSWINKEL: Especially in -- regarding the regions' discussions is I found that, say, people who are most affected by the current ICANN geographic regions or the definition of the ICANN geographic regions could not be reached either true the ccNSO members list or the WW TLD list. So that made me think to create something like what I would call a ccNSO observer list, and, based on the known e-mail addresses in the IANA database, in order to -- yeah, be able to reach the known admin and tech contacts. That will be a list, I will make an e-mail to them, I will send them an e-mail that they -- invite them to subscribe to that list. Yeah, before I do that, I'll work on a charter and send that through to the -- >>CHRIS DISSPAIN: Yeah, I think we'll need to -- just for formality, we probably -- the council will probably need to agree to set the list up. But I think if we just, as you say, if we just e-mail everyone and say, look, this is what it's here for, as you say, and if you want to join it, join it, at least you are giving everybody an opportunity. And -- Yeah. >>BART BOSWINKEL: Okay. So that was the second topic, so you know we are working on. The third one for today is an improvement of the Web site. As some of you, during the participation discussion, noted, currently it is very static. It is not very inviting. It has improved, but we want to improve it further. And so to do that, we haven't got our minds around it yet, which part we want to improve first and how we want to improve it. But in order to serve you better, we are looking for a, say a kind of user group, one person from every region who could sit on that group. And I think, again, that is something for the ccNSO Council. And we take it from here to come up with a plan and in, say, dialogue with this user group, start working on improving the Web sites, specifically for, I think, first for exchange of information, and secondly to make it a tool for potential policy development process. >>CHRIS DISSPAIN: Okay. >>BART BOSWINKEL: That's all. >>CHRIS DISSPAIN: Oh, sorry. I've got to say -- None of them are me, honestly. None. Has anyone got any questions or comments on this or will we just take it to the council to finalize? Good. Olivier, you seem to be looking like you want to say something -- Paulos, I'm sorry, I didn't see you there. >>PAULOS NYIRENDA: That's okay. I notice from the Web site that Mauritius has been pending on the Web site since 2004. >>CHRIS DISSPAIN: Correct. >>PAULOS NYIRENDA: As an applicant. Is this an issue for the Web site? >>CHRIS DISSPAIN: Yes, it's an issue for the Web site. It should have gone into the "new application required" basket. And now you are going to ask me why a new application is required, and I can't remember so I will have to go and check. Thank you, Paulos. Olivier. >>OLIVIER GUILLARD: Yeah, just a quick return of experience. If you go to the working group sections, you will see the IANA working group has a Web site. So historically, this Web site is just to provide an input with regard to the experience of mentioning this Web site. It was set up at the beginning because there were not anything to keep track of the progress of the work, so it was just a white board. And as an experience, it's very difficult to find -- TWiki is not a good technology, in my view, because you have all the information which is centralized around one person, and I think with the ccNSO we need more interaction. So something interesting would be to find something more collaborative to have the possibility to collect and gather the -- yeah, you see what I mean. Just a quick -- >>CHRIS DISSPAIN: Maybe you would -- Olivier, maybe you would consider -- >>OLIVIER GUILLARD: Yeah, yeah. TWiki and a Wiki. >>PATRICIO POBLETE: Why did you (inaudible). >>OLIVIER GUILLARD: Because you have to -- it's possible but it's not very friendly to go, and you have to have proposals, a very clear process on how to update the pages if you want to contribute. >>CHRIS DISSPAIN: Yeah. >>OLIVIER GUILLARD: And so it's not the most.... Just my view. >>CHRIS DISSPAIN: Sure. No problem. Okay. Olivier, maybe you could be one of the user group as well, because I think because of this. Dave. >>DAVE ARCHBOLD: Just a very quick thought. We were talking about communication as part of the participation group. Perhaps the steering group or user group could be a subsection of that because there's a very close relationship between the two. >>CHRIS DISSPAIN: Okay. Good idea. All right. Well, thanks, Bart. If that's that, then we've reached the point where we have come to the end of our formal agenda for the members' meeting. We have a council meeting scheduled for 5:00. I am going to stick with that schedule because some people are not here and are expecting it to start at 5:00. So we will start at 5:00 in this room. I doubt very much if it will take much longer than half an hour but you never know. We will get an agenda out to the council in the next ten or 15 minutes because we now know what we have been discussing today. And I would just like to call the members' meeting to a close and thank everybody for their participation and for attending. Thank you. [ Applause ]