ccNSO Meeting

 Monday, October 30, 2007

 ICANN Meeting - Los Angeles

 

 >>CHRIS DISSPAIN:  Good morning, everybody.  We'll be starting in 
about five minutes.

 Good morning, everybody.  Some of you seem to be a very, very long way 
away, and we have very low ceilings, so...

 Welcome.  I'm going to stand up for a little while, just so I can -- 
welcome to the ccNSO meeting.  There's some new faces in the room.  For 
those of you that don't know me, my name is Chris Disspain and I'm the 
chair of the ccNSO council.  Before we start, those of you that know 
Ming-Cheng Liang from Taiwan is here but he's in hospital at the 
moment.  He has a small heart issue.  He's going to be fine, but 
everyone wants to send a note to Ian over there to take to him.  He's 
going to be in for another -- for a couple of days, Ian, isn't he?  
Yeah.  So if you want to send wishes to Ming-Cheng, just let Ian know 
and he'll deliver the messages.  Thanks, Ian.

 Okay.  We're going to start with IANA, and because it's a very good 
place to start, so I'll pass you over to Kim.

 >>KIM DAVIES:  Thanks very much.  So can I be heard at the back of the 
room?  Everyone's just looking blankly into the distance.  I'll bring 
it a bit closer.  Is this better?  Good.  All right.

 So I'm going to spend about -- well, 20 or 30 minutes talking about 
IANA, what we've been doing, what we're looking to do, as usual, and I 
welcome very much your input onto our work program within the 
organization.

 I see, again, a lot of new faces here, so for those ccTLD managers 
that don't know of IANA and don't know me, I'm very interested in 
meeting with you through the course of the week.  We like to think that 
IANA works best when we have personal relations with all the ccTLD 
managers.  It certainly makes our lives easier and I think it makes 
your lives easier too, that you can speak to someone that can explain 
any particular issues that you might have and you don't feel that you 
need to go through a very bureaucratic system.

 So again, please come up and see me if we don't know each other.

 So the most interesting thing, I think, we've done in the last few 
months is we inserted the first internalized domain names into the DNS 
root zone.  These were added on the 9th of October, roughly three weeks 
ago.  For those that aren't aware, there's 11 new top-level domains 
representing 10 different languages represented in 10 different 
scripts.  The aim of these domains is to provide a platform for testing 
actions whether there's any outstanding issues that would prevent 
production deployment of top-level domains in the root.  I understand 
that the ccNSO will be dealing with the topic of what those production 
top-level domains should be this afternoon, but for us in IANA, the 
task involved ensuring that our systems could cope with inserting IDNs 
in the root, ensuring that we could develop systems to handle IDNs in 
the root, and so far, so good.

 We inserted them, as I said on the 9th of October.  Subsequently, a 
week later, actual applications were deployed on those domains.  You 
can find out more about those applications at IDN.ICANN.org.  There's 
also an informational booth downstairs outside the main meeting room 
where you can see these internationalized top-level domains in action 
if you so wish.

 So this is a graph of the load on the root servers during the day of 
deployment of IDNs in the root.  I've drawn a line down the middle as 
to when the event actually occurred and as you can see, there was no 
appreciable impact on the root zones.  We didn't expect that there 
would be, but when taking a new initiative like this, a number of 
people in the community felt it was very important that IANA had 
procedures in place to quickly resolve any issues that might occur.

 So at the last meeting, we had the board approve a new IANA procedure 
called the emergency backout procedure.  What this allowed IANA to do 
was, in the event of any of these new IDNs causing a technical problem 
with the root server network, they could be very quickly removed from 
the root.  Thankfully, it didn't prove necessary.  We keep 
communication channels open with the root server operators.  So far, 
the root server operators have not reported any problems, but we have a 
24-hour -- we have the 24-hour support line that is available to ccTLD 
operators.  We also made it available to root server operators, 
particularly for this, and they haven't felt the need to use it to 
date.

 I don't anticipate that there will be any further problems with -- on 
a technical basis with IDNs in the root, but we will keep our eyes open 
and wait for the policies to be developed within the ccNSO and GNSO as 
to what IDNs we should put in for production.

 So the 11 new top-level domains are formally registered to IANA.  This 
is consistent with the fact that IANA actually acts as the registrant 
or caretaker for a number of Internet resources that are managed in the 
public interest.  For example, domains like example.com, A.com are 
registered to IANA.  Similarly a number of IP addresses that are not -- 
do not belong to a single party are registered to IANA.

 So consistent with that, the formal registration of these domains 
belongs to IANA.

 It's anticipated that these test domains will last no longer 2010.  In 
practice, what that means is that when production top-level domains are 
introduced in the languages and scripts of the test domains, the 
related test domains will be removed.  For example, once we have 
Chinese top-level domains, then the Chinese top-level domains will be 
removed that are test domains.

 Within IANA itself, we're dealing with some teething problems, as I'm 
sure those of you who have deployed IDNs have needed to do.  We needed 
to make sure our system supported Unicode throughout.  We actually 
developed a new coding system for domains internally.  This gives us a 
special representation of the domain that we can use for processing 
that is neither sort of the ASCII version nor the Unicode version.  
It's actually a translation of the label into English plus a BCP47 
language tag which can be processed by computers.

 If you actually go to the beta IANA Web site, you can see a list of 
those codes, but suffice it to say those that register IANA top-level 
domains for IDNs will use this coding system, but for now it's probably 
just something of interest and nothing more.

 We're looking at how to upgrade our WHOIS server to best support IDNs 
and we're interested in finding out what the best practices within the 
ccTLD community -- obviously the WHOIS standard is silent on how to 
treat non-ASCII characters, and I know that there's a number of 
approaches used in different countries and we want to find out the best 
model for introducing IDN support in the root zone WHOIS.

 The third thing we would like to do and we started some initial 
discussion on the CENTR technical mailing list is, we have problems 
ensuring that everyone sees IDNs accurately in their Web browser.  In 
fact, I wrote a little log post on the ICANN company blog which 
explains some of the issues that we have, but what we would like to do 
is have a utility on our Web server that will accurately display the 
IDNs in an image format, so people don't need to rely on the support in 
their browser to see what an IDN should look like.

 We would like to develop a tool that is open source, and developed 
within the community, and if there's any interest by people in the room 
to contribute to an effort like that, I'd be very interested to hear 
from them.

 Within IANA, it's simply a matter of resources.  I think this would be 
something very useful.  We obviously have some limited resources that 
we can put at it, but I think as -- if we can do it as a community 
project, we can get the relevant expertise from different groups to 
build such a tool.  And then it would be free for any registry to use 
it within their own systems as well.

 Okay.  So I don't know how many of you were in the welcoming ceremony 
and the president's report yesterday.  I suspect most of you were up 
here in the technical workshop, but Paul Twomey referred to something 
he called "lumpiness" in our statistics in recent months.

 It's fairly easy to explain why the graphs looked so odd in the last 
few months.  It's really a combination of two or three factors.

 One is that we introduced those 11 top-level domains that were 
introduced into our system in August and that were closed in October.  
That represents 11 redelegation requests.  Admittedly processed 
together but it represented 11 requests in our statistics.

 We also had one of these large glue zone -- shared glue changes in the 
root zone.  This means that one single nameserver was changed, but it's 
used by many different ccTLDs.  Therefore, we needed to contact a great 
number of ccTLDs to obtain all the relevant approvals.  Again, this 
resulted in a number of tickets that was abnormal for the period.

 And finally, we also simply had a lot of redelegation requests 
normally.  We created two new top-level domains, dot kp for North Korea 
-- sorry.  We created three.  Dot kp for North Korea, dot me for 
Montenegro, dot rs for Serbia.  We also had a change request for dot 
YU.  We've had change why is for other domains, so it's really been 
quite a busy period.  And we can see, as a reflection of that, the 
yellow line represents the number of outstanding tickets.  It surged 
almost to around 80 a couple of months ago, and it's now below 30.

 So all these abnormal factors kind of conspired to a very unusual set 
of graphs, but moving on, I mean, I think that analyzes our data that 
we have available, the routine requests, the day-to-day requests, are 
still being fulfilled in a reasonable period of time, if not faster 
than before.  But the remaining tickets, the redelegations and so 
forth, are actually trending upward.

 This is because redelegations, on average, are requiring more due 
diligence.  They're often more contentious.  For example, those that 
were at the last meeting will realize that there was a very contentious 
delegation request for dot eh for Western Sahara.  That consumes a 
great amount of staff resources to deal with those kind of matters and 
to process them.

 We're also building the number of redelegation requests simply because 
our outreach efforts have improved.  We now have this network of 
regional liaisons.  They talk to the community in different parts of 
the world.  These communities realize the need to update their data 
within IANA, and consequently we get requests.  Just this week, I've 
met with probably four or five new ccTLDs that are interested in 
updating their data through redelegation, so we're continually building 
the quality of the data within the IANA database, but consequently the 
amount of work that IANA needs to do has been increasing.

 We will be further studying the underlying causes of our variations of 
the data, to see if there's important trends to report to you and 
report back to the next meeting.  Our feeling is that the actual amount 
of work is increasing to the point where currently we have one 
dedicated full-time staff member for root zone management, and we might 
be at a point where we actually need to move on to a second person.  
But that's something that we'll be looking at in the coming months.  
We'll see if this pattern of increased requests continues.

 Another thing that we've heard from you is that the way we report it 
is a bit difficult to analyze, recognizing the fact we have two fairly 
different types of requests.

 We have the regular and the irregular requests.  The irregular or 
exceptional requests are redelegations.  They're these third-party 
impacting requests which means that there's third parties other than 
the ccTLD manager that need to be involved in the approval process.  
Whether this is shared glue requires other ccTLDs, perhaps there's some 
special government relationship that requires involvement as well, 
these significantly skew our data, so if we separate our statistics 
from the routine to the nonroutine, that would help you better 
understand how we're handling regular requests.

 So we're going to be looking to defining what is a regular and an 
irregular request, and then improving our reporting to you by splitting 
up those two types of processes.

 And as always, if you have better ideas on how you'd like to see 
IANA's performance reported, we're very happy to have that feedback.

 So on service level targets, as I mentioned previously, I think IANA's 
doing relatively well in terms of handling routine requests.  We 
discussed briefly at the last meeting the idea of having formal service 
level targets.  There's been a dialogue within the community, not just 
within the ICANN meetings but at the regional ccTLD meetings, about 
having a more concrete set of service level targets.

 What we intend to do is in the coming months develop sort of a straw 
man proposal where we will create a set of targets ourselves, as IANA 
staff, and this is simply a starting point for the community to look at 
and to modify and then mutually we will agree on a set of targets.  I 
think IANA's the best place to give you a set of measures that we think 
would be appropriate to measure us against, but at the same time we 
recognize that ultimately it's up to you to decide how you want us to 
perform, so we want a collaboration moving forward on what those 
service level targets should be.

 With respect to our work on automating aspects of root zone 
management, when I reported to you at the last meeting we were 
intending to launch our testing period on a first phase of the 
development of the software, with a second phase to be deployed 
approximately 3 to 6 months after that.

 The first phase had a limited set of functionality.  It handled things 
like contact changes, but it didn't handle all types of nameserver 
changes.

 What we've now done, based upon our internal analysis and feedback 
from our development partners like NESC, the Polish registry, and 
VeriSign, we've actually merged those two development branches into 
one.

 So now the software actually includes the full complement of features 
that we need to deploy into production.  This includes using the EPP 
protocol for communicating root zone changes to VeriSign.  It's 
anticipated this will greatly expedite that step of the processing.

 It includes integration with the RT system that ICANN has.  RT is our 
internal tracking system, our internal auditing system, and it's where 
we currently process our manual requests.  So the automated and manual 
systems will now be fully integrated.

 And as I mentioned, we now have support for all the types of root zone 
requests that we anticipate receiving.

 So now we're ready to start focus group testing, sort of Stage 1 
testing.

 Our aim there is to have a small group of 10 to 15 TLD managers who 
will very closely work on the testing.  Once we are confident that all 
the problems we can foresee have been ironed out, we will then move on 
to a second stage of testing that will be open to everyone.  Our aim 
there is to run the system fully in parallel with our manual 
operations.  You, as ccTLD managers, will be welcome to submit uses 
either system.  You can submit a manual request, as you do today, or 
you can log onto the Web site and submit it through the Web site.

 If you don't submit it through the Web site, what's going to happen is 
when you submit it to ICANN staff, they're going to take your staff and 
launch it manually into the system, so it will end up being in the 
automated system anyway.  Then throughout the processing of a ticket, 
you will have a process being done within both systems.  We'll use the 
automated system and the manual system.  At the end of the processing, 
when a request is complete, ICANN staff will then review the whole 
process, make sure that it was processed the same throughout the whole 
system and that will form part of our testing.  And then once we have a 
few months of operations where the automated and manual systems have 
produced the same result, we will then be at a level of confidence that 
we can say the automated system can be put into full production and we 
can stop our manual processing track.

 The last piece of that is that the U.S. Department of Commerce has 
asked that we have a series of testing, security testings and approvals 
done by the U.S. government.  We think this is a positive thing that 
will be another set of eyes to make sure we haven't missed anything, 
but we'll need to go through a formal process of approval before we can 
put it into full production.

 I asked for volunteers for testing at the San Juan meeting.  If 
there's anyone further that wants to be involved in that active initial 
testing round, please do so up come to me and let me know your details.

 Otherwise, I anticipate that we'll be inviting everyone that operates 
a TLD into testing in the medium term.

 One thing that we need to deal with on a policy level with regards to 
automation is what to do with authentication credentials, and what I 
mean by that is today we actually authenticate requests by simply 
taking verification e-mails or subsequently telephone calls or other 
forms of communication to the requester.  When we move into an 
automated world, we need things like usernames and passwords.  We also 
envisage that we'll use PGP keys and also RSA keys, as alternate forms 
of authentication in Phase 2 development, but with that comes new 
challenges.

 If we have ccTLD operators using special keys, passwords, hardware 
dongles, we'll have issues such as who do we actually give these 
credentials to, what do -- what happens if you lose those credentials, 
what happens if they go to staff that are no longer with the company, 
what happens if you have an emergency change and you don't have your 
credentials handy?  Do we simply insist that you must find them or 
given that it's an emergency, do we bend the rules?

 And there's a number of security tradeoffs there.  We recognize, on 
one hand, that root zone management should be very secure.  On the 
other hand, we recognize that there's a pressing need to do some 
changes urgently, even if you aren't able to fulfill the exact letter 
of the law with regards to how you authenticate yourself.

 So there's a balance there that needs to be struck, and I think as a 
community, we need to have a dialogue about what you think is an 
appropriate level of security for root zone changes and what's the most 
practical way to implement it.

 We would -- we definitely think the current system needs improving, 
but the most secure way would not be the most appropriate way, because 
it would be too cumbersome to implement in reality.

 Other questions are, you have multiple staff within your organization.  
Should each of those be given a unique username and password or should 
there simply be a single user for each admin and tech contact within 
the root zone database?  These are the kinds of questions that we need 
to discuss, and I'd like to have a dialogue with you about that.  I 
don't have any papers, discussion papers available yet, but I think 
that we will produce something along those lines shortly to sort of 
kick off a discussion.

 If you have any thoughts in particular on how we should handle this, I 
think a number of you have similar issues with your customers, then 
please let me know.

 Another thing that I think I reported last time but I've heard in the 
intervening months a lot of comments such as, "IANA doesn't sign the 
root."

 Now, I guess that is true, but it's also equally true that we do sign 
the root zone.  We've had a project internally for -- I think it's 
actually been 9 months now -- to build institutionally the ability to 
sign the DNS root zone.  We've actually been signing the DNS root zone 
now for a number of months successfully.  This is not the root zone, 
obviously, that's published on the well-known root nameservers 
available on the Internet.  Rather, it's something that we're 
publishing on our own test nameservers.

 Our aim here is to make sure that IANA is not on the critical path for 
DNSsec deployment.  We want to internally have all the systems in 
place, such that if the policy conditions are right that the DNSsec 
signed root is to be made public, that IANA is ready with all the 
technical systems and operational systems in place, so we can deploy 
it.

 There's a Web page there for those that are technically inclined.  You 
can test our root.  You can have a look at it.  It's available for you 
to use.

 Obviously, that doesn't mean that the DNSsec deployment problem is 
solved.  There's a number of policy and technical issues to still be 
solved, but we have the signing mechanisms in place internally.  We 
think they're very robust.  We've been particularly working with the 
dot SE registry.  They've been very helpful in helping us develop our 
systems.

 Importantly, all that -- we've developed a lot of new software to sign 
the root.  We'll be releasing that as open source software so any 
registry can use that software if you think it's useful.

 And just to finish off, for a change, IANA has something cool to hand 
out.  IANA has something cool to hand out at this particular meeting.  
We did some graphs of IP address utilization.  We've converted it into 
a poster.  It's available downstairs.  I might try and see if we can 
get some brought up here as well.  It's -- if nothing else, it just 
kind of looks interesting on your wall, I suppose, but what it really 
shows is the white space on the left-hand side graph is all the amount 
of IP address space that's left, and it's actually disappearing quite 
quickly.  By 2010, current estimates say that it will all be gone, so 
we're coming to a pressing time where IPv6 is becoming more and more 
important.  Whilst it's not directly related to my work and our work as 
ccTLDs, certainly the IP addressing realm of IANA is very busy on this 
topic.  There will be a lot more activity in this area to come.

 But feel free to get this map and take it home with you.  And if it's 
not quite big enough for you, funnily enough, after we printed these 
posters, we had a visit from the information sciences institute, which 
is based upstairs in the same building as us in Marina del Rey, and 
they said, "You know what we've done?  We've actually mapped every IP 
address in the world and we've put it on a 9-foot by 9-foot poster.  
Come up and have a look."

 So I went upstairs and had a look and, indeed, that's what they'd 
done.  In fact, it was so tall that it kind of wrapped up onto the 
ceiling in their offices, and when I saw it, I immediately thought that 
would be something pretty cool to show off at the ICANN meeting.  So 
it's been a couple of months since then and they've reprinted it for 
us.  We've actually just hung it downstairs outside the main ballroom, 
so if you want to see roughly the same data and a lot more explanation 
as to what it is, there's a big 9-foot by 9-foot poster downstairs by 
the main ballroom.  I think it's quite interesting to see the spread of 
IP addresses around the world and how it's being used.  There's some 
very interesting patterns there.

 And that's it for me, so thanks very much for your time, and let me 
know any questions we have.

 >>CHRIS DISSPAIN:  Do we have any questions?  There is a microphone -- 
gabby, I think, has a microphone or someone has a microphone, oh, it's 
right there.  Sorry.  Microphone is right there.

 >>CHRIS DISSPAIN:  Do we have any questions?  There is a microphone, 
Gabby, I think has a microphone or someone has a microphone.  We have 
Hilde and we have Dotty.

 >> HILDE THUNEM:  Actually more a comment and question.  You were 
talking about solving authentication than credentials.  I would suggest 
while trying to do that, you also think about what the roles of the 
different contacts are so that you build a hierarchy of one being the 
super user, the registry being the super user, and the contacts having 
different roles in what operations they may perform because if you are 
going into more security and more credentialed-type of things, that's 
probably the time to actually look into that.

 >>CHRIS DISSPAIN:  Thanks, Hilde.  Just for those who are watching on 
the Webcast, could you, when you speak, could you say who you are and 
where you're from.

 >>DOTTY SPARKS de BLANC:  Hi, Dotty Sparks de Blanc from the VR 
registry, U.S. virgin islands.  Yesterday VeriSign's presentation 
showed a decline in registrations for dot com and dot org, that was 
marked decline for two quarters on the graph they showed and said they 
didn't have any answer to why that was.  Do you have any ideas about 
that?

 >>KIM DAVIES:  No.

 [ Laughter ]

 It is actually not something I'm terribly exposed to at the root 
level.  I hadn't heard that and I have no idea.

 >>CHRIS DISSPAIN:  It is very curious, yes.  Maybe everyone is 
registering in country codes.

 >> It was DNS queries, not registration.

 >>CHRIS DISSPAIN:  There you go.  It was DNS queries, not 
registrations.

 >>DOTTY SPARKS de BLANC:  Thank you.

 >>CHRIS DISSPAIN:  It was not quite as curious as we thought it was.  
Anyone else have a question or comment for Kim.

 Before I pass to Olivier, you sitting at the back, I am sorry about 
the fact there are not a huge number of chairs but there are still some 
spaces with desks up near -- one or two only but up near the front so 
if you want to take an opportunity at some point to run up and grab 
one.

 Now, one of the things we're going to talk about later on this morning 
is DNSsec -- excuse me -- DNSsec and we are going to look at the 
results of our survey and then go to the GAC room and listen to and 
contribute to Steve Crocker's presentation.

 But I thought that while Kim was here and Olivier is here, it might be 
useful to have some discussion on that.  You are going to do DNSsec, 
right?

 >>OLIVIER GUILLARD:  Yes, hello, Olivier Guillard.  I am with the 
French registry and also the IANA working group, and the IANA working 
group has been asked to provide some input about DNSsec.  We are not in 
a position to be able to do that now, but I met some personal 
investigation about it.  And thinking out loud, I have some questions 
that I will share with you and provide as an input to the IANA working 
group later on.

 So I will stick to my text.  So there is no real deployment of DNSsec 
in the ccTLD community at this stage, but some of the operators have 
already published their signed zones, like dot SE, BG, PR, Puerto Rico.  
As Kim has said, IANA publishes an experimental signed zone on the Web 
site and also on the experimental DNS server, which is ns.IANA.org.

 And here came the question, who should sign the root?  We had this 
question circulating on the community the first time.  What does it 
really mean to sign the root?  So it is going to be a bit technical.

 This is a query on the DNS, and I have here the list of NS server for 
dot FR providing to a root server and providing DNSsec information is 
it as.  And, obviously, if it responds, you get when you do that -- 
okay, I changed the resolution, sorry.

 If you do that, you get the list of server for dot FR, okay?  It is 
not readable at all.  Sorry.

 Okay.  This is what you get as answer is a list of servers for dot FR.  
If I ask the same question to the server -- the DNS server in an 
unsigned zone -- yeah -- then you have exactly the same answer but you 
have an additional information which is a signature of the record you 
just received.  So with this signature, you can check that the list -- 
the information you have received, you can check if it's good 
information.

 How can you do that?  As a DNS operator, okay, to be able to check 
this signature, you need to have the key that has been used to sign the 
information.  So you need to get the root key that has been used to 
sign the information.

 Here it is on the second comment.  I can ask the server to provide me 
these keys.

 Okay.  And you can see that you have many of them.  Here are the keys 
that are used to sign the root zone.  One, two, three, four, five, six 
-- nope, five.  Sorry, five keys are announced, and they are of two 
different types.  You have those type of 257 and those that are of type 
256.  And without entering into details, the one you want to cut and 
paste in your resolver so that your resolver can check the signature it 
will get back are those of type 257.  Okay?  This is the key signature 
keys.

 I don't want to be too technical.  So here are some questions.  Some 
questions now.  I see there are two signing keys that I would have to 
cut and paste to my resolver.  Why are there two keys?  Why not only 
one?

 So as a DNS operator, to be sure that my resolver can check the 
information through DNSsec, I have to copy this key and paste it into 
my resolver and say this is a trust anchor for the root.

 Yes?  I see a hand over there. No, okay.

 So would I need to do this operation regularly, or do I have to do it 
once and then it is finished forever?  Would I need to regularly update 
my resolver with this root KSK?  If yes, how would I be advised that I 
need to do so?  By who?  What would be the frequency of the change and 
the updates?  I'm here with the hat of a DNS operator, okay?  Not as a 
DNS registry.

 As a user, which guaranty would I really get once I have configured my 
resolver to use this key as a trust anchor for that?  Under which 
condition would I trust the dot keys that I have copied and pasted in 
my resolver?  And under which condition would the cc community trust 
the root KSK got published as a trust anchor for the top of the public 
DNS tree?

 Okay.  To query the DNS, and to ask for the DNSkey of the root zone, I 
have sent a DNS request which is not secured so there may be -- maybe 
not the best way to collect together a key and put it on my resolver.

 So here IANA publishes also a demo Web site where the key signing keys 
are also published here through a secured Web site.  And you can notice 
that I can cut and paste a key which has been certified by someone 
which has been signed here using PGP.  Doing that, I can collect and 
check if -- when I copy and paste, I can check that the information I 
have gathered are -- have been properly gathered.

 The question is, who has signed this?  And who should sign this for 
the KSK dissemination, which is another problem.

 So you can -- rather than copy just the key, you can copy a certified 
key and the question is who certified the KSK for publication?  Under 
which condition would I trust this certification people?

 That was -- those questions were about direction between the one that 
signed the root zone and the final user.  Let's have a look on the root 
management and signing process.

 Yesterday morning, I think, there was a workshop on DNSsec where 
Richard Lamb from IANA presented the internal operation of IANA to 
process with the keys.

 So I won't go too much into details.  You have -- they have two keys, 
as we saw at the beginning, to operate, and some question to be sure 
that the process is secure.  Just thinking loud again, who does operate 
the KSK?  At the moment, in the experimentation it is IANA.  How is it 
operated?  Who operates the zone signing key which is the key which is 
actually used to sign the zone.

 What does the key infrastructure and management procedures look like?  
Are those procedures secured?  Who signs the root zone using which 
procedure?  What are the rollover frequencies?  Which plan in case of 
key corruptions?  Yesterday, there were many answers to those 
questions.  I'm not going to enter into those details now.  And I think 
IANA is doing a great job at the moment with those (inaudible) 
processes.

 So we saw the interaction with the user signing the root and 
publishing the root will involve interaction with the user and they 
will need to have interaction with ccTLDs, have new interoperational 
interactions.  Why?  Because DNSsec is building a line of trust over 
the resolution.  For example -- I'm not going to do all of this.  We 
know that doubt SE has its own zone, own DNSkeys.

 Okay.  This query asked the DNS authoritative server.

 Oh, no, that's not good.  Sorry.

 Asking a Swedish server, you can see that they publish also their own 
key signing keys.  And if I follow the same idea that I had with the 
root zone, I could cut those keys, paste them in my resolver and say to 
my resolver, those keys are authoritative.  Those keys are the trust 
anchor for dot SE.  If I had to introduce into my resolver all the key 
signing keys of all the TLDs and all the zone, it wouldn't be 
manageable.

 So the root zone publishes additional information about those TLDs 
that are secured by DNSsec and those information are called DS records 
that you can find here.  Okay?

 So to be able to announce properly those information, IANA has to 
collect the keys from the ccTLDs to introduce them in the root zone so 
that all the resolution -- Yes?

 >> NASHWA ABDEL-BAKI:  I am a little bit confused.

 >>OLIVIER GUILLARD:  Don't be.

 >> NASHWA ABDEL-BAKI:  I would like to understand what do you mean by 
"user"?  And what do you mean by --

 >>OLIVIER GUILLARD:  Good question.

 >> NASHWA ABDEL-BAKI:  Also, I understand KSK means signing key or 
what?

 >>OLIVIER GUILLARD:  Key signing key.  I didn't want to enter into 
those technical details, focusing more on interactions between the 
different --

 >> NASHWA ABDEL-BAKI:  I am trying to understand the whole story 
because I cannot get how --

 >>OLIVIER GUILLARD:  I understand that you don't understand 
everything.

 [ Laughter ]

 The process for providing a sign zone needs -- we talked yesterday 
about it.  Artificially, you have to deal with two keys, one which is 
used to sign regularly the zone but doing that, you weaken the 
strengths of these keys, so you have to rollover -- you have to renew 
regularly those keys.  These are the zone signing keys.

 To be able to ensure the interaction with -- less regularly with 
external people, then you deal with another key which is a key which is 
used to sign the key that is used to sign the zone key.

 [ Laughter ]

 >>CHRIS DISSPAIN:  It is one key to bind us all.

 >>OLIVIER GUILLARD:  One key is used to sign a key, okay?  Right.

 I would like to finish because -- yeah.  Sorry.

 I won't be the best person to explain technically those things.  I 
want to focus more on the questions and on the interaction that it 
requires with external people.

 But your first question, sorry, difference between user and ccTLDs, 
okay, users are those that operate DNS servers everywhere on the 
Internet.  And to configure their DNS server to work with DNSsec, they 
will need to collect the key from IANA.

 Without the registry -- it is not a registry matter.  It is not a 
registrar matter.  It is the final user.  So you have an interaction 
between the key operators, the root zone, and the final user.

 Okay?  So now interaction with the registries.  As we saw in the root 
server -- in the root zone, sorry, new records will be introduced to 
announce the DS of the ccTLDs.  So ccTLDs will need to provide their 
keys to IANA or to someone for the introduction in the root zone.

 Who should gather and introduce those DS and using which procedure?  
We need something secure here.

 And to respond now to your question in summary --

 [ Laughter ]

 >>CHRIS DISSPAIN:  That's a summary?

 >>OLIVIER GUILLARD:  That's a summary, sorry.

 Whereas, the complexity of processes and various operations that need 
to be performed to deploy and publish a usable signed zone, the 
question "who signed the root" is not really valid in my view and the 
question should be clarified.

 The first question is about the interaction with the final users.  Who 
would certify, who would sign the public root key, the KSK root for its 
dissemination?  Using which certification mechanism?  Which channels 
would be used for user information and interaction?

 About the internal IANA procedure for key operation, who would operate 
and use the DNS keys for root zone signature?  And for the interaction 
with the ccTLDs, who would collect ccTLD public keys for DS 
introduction in the root zone?  How would this channel be secured?

 Additional questions.

 [ Laughter ]

 >>CHRIS DISSPAIN:  There's always one.

 >>OLIVIER GUILLARD:  As the root zone is at the top of the DNS tree -- 
and that's just more question -- rather than introducing the root key 
as a trust anchor for the root, wouldn't it be possible to publish the 
root key -- the root DS information along with the list of root servers 
that are already collected by users at the end of the day?  If you go 
and look -- final user, need to provide to their resolver, the list of 
root server the list of root server which is in the repository, which 
is here, why not provide the DS information along with this list of 
server?  Just a question.  

 As this is information that the user has to collect also, who 
maintains the file today and who maintains this registry?  How?  Other 
general consideration what would be the incidence of a coexistence 
between signed and unsigned?  It is just open questions that came to my 
mind.  Coexistence between signed and unsigned space at the highest 
level of the public DNS tree, would that have any incidence to have a 
dot SE sign, a dot FR not signed and so on?

 What would be the incidence of heterogeneous practices for DNSsec 
management?  You could have some zone signed but not using the same 
procedure?  Isn't there a risk for lack of readability about the other 
DNS service?  Technically speaking, are there any side effects and new 
risks to be expected deploying this technology such as new DDOS 
amplification, accessibility problems.  When you query adding new 
DNSsec, you see that the response is much larger.  Don't we have any 
problem with that, not going into DNS cache, it is another one.

 What is the demand for DNSsec?  Who asks for it?  What for?  It is not 
any more a problem with signing the root, really.

 And last one, will DNSsec strengthen the DNS accountability?  That's 
it.

 >>CHRIS DISSPAIN:  There is not an additional supplemental question?

 >>OLIVIER GUILLARD:  No, no.  Come back to the process.  At this 
stage, I will send these first set of questions to the IANA working 
group and we will see what...

 >>CHRIS DISSPAIN:  Before we started this, I wasn't sure whether I 
understood DNSsec or not.  Now I'm sure I don't.

 >>OLIVIER GUILLARD:  Me too.

 [ Laughter ]

 >>CHRIS DISSPAIN:  There is a paper from Nominet. 

  Has that actually gone out, Lesley?

 >>LESLEY COWLEY:  Yes, it is not my personal opinion.

 >>CHRIS DISSPAIN:  Lesley would like to make sure that the DNSsec 
paper from Nominet is not her personal opinion.  It is a very useful 
paper for those of you who haven't read it.  It is on the list.  If you 
can't find it, let me know.  It is very useful because it gives -- it 
is very short paragraphs on each sort of individual question that needs 
to be answered.

 Olivier, you have raised some questions which I would like the answers 
to, as well.

 >>OLIVIER GUILLARD:  Over the process, if some people have considered 
DNSsec, have looked at it, would have any question with regard to 
signing the root.  And I have been investigating a bit over the past 
days when I knew I had to talk about it, I realized it was quite a 
difficult issue.  So if you have any questions, any ideas, please come 
to me and --

 >>CHRIS DISSPAIN:  We will have Steve Crocker during the presentation 
today in the GAC.  Maybe we can use -- ask some of those questions.

 You've got something else that you forgot?  Go for it.  We have a 
question on DNSsec.

 >> Roy Arends:  My name is Roy Arends.  I just wanted to point out 
most of these questions we have dealt with within the IETF within the 
last ten years.  Most of these things are resolved, at least the 
technical side is resolved.  

 Another thing I want to point out, we shouldn't care about zone 
signing keys.  The only thing important is key signing keys.  Key 
signing keys are, basically, the same as DS records or, basically, the 
same as trust anchors.  These are all the same thing.

 So -- but I saw a whole bunch of these questions, and we have within 
the IETF dealt with those within the last ten years.  So it might be 
good to use that as a source of information as well for answers to your 
question.

 >>CHRIS DISSPAIN:  Thank you.  We will send Olivier --

 >>OLIVIER GUILLARD:  Just one.  Most of those questions are not only 
technical-only questions -- not only question which would have regard 
with a test platform or something.  They are also operational issues 
and trying to consider the context of the CC community as well.

 >> Roy Arends:  I understand that.  I don't want to go into the 
discussion here.  I want to understand IETF is not only just a 
technical function but it also deals with operation management.

 >>CHRIS DISSPAIN:  What would be really helpful is if you guys talked 
to each other and then we can -- Yes.

 >> My name is Peter Koch.  My affiliation is DNIC but that doesn't 
matter for the moment. I happen to be one of the co-chairs for the 
DNSsec operations working group in the IETF.  I would like to emphasize 
on what Roy just said.  

 Many of these questions have been dealt with, have been checked in 
test beds.  There have calculations by pen and paper.  There have been 
measurements around packet sizes, around everything.  You have touched 
upon some of the open questions like the management of the final trust 
anchor.

 I strongly disagree that the final ultimate end user has to actually 
use with this key with his own hands.  Today you can just make a survey 
anywhere on earth how many people have dealt with root certificates in 
their Web browser.  None of them will respond with that.

 And these are the ways to deal with trust anchors, be that a root 
trust anchor or be that TLD trust anchors.

 The main thing, I guess, that you pointed out in kind of en passe 
style, if there is no central trust anchor and be that a signed root or 
be that a trustworthy trust anchor repository in some other manner, you 
just have the same problem times 300 which is times the number of TLDs 
and maybe a bit less times the number of signed TLDs, right?

 So the central trust anchor repository, again, that might be a signed 
root, a different means, is a convenience to those who publish their 
trust anchor.  A signed root or a signed trust anchor is a convenience 
to the ccTLD operators because it gives them a widely accepted single 
channel to publish their KSKs or DS records or whatsoever.  But I would 
be happy to further discuss with you some of the open technical 
questions.

 >>CHRIS DISSPAIN:  Thank you.

 >> PETER KOCH:  Just trying to avoid this impression that this is all 
not said and done.

 >>CHRIS DISSPAIN:  Just so you know, we have -- you might know this 
already.  We have an IANA working group we'll be -- this sort of sits 
kind of in the IANA working group because that's the -- where we put 
most of our technical bits and pieces.  If you could talk to Olivier 
and we could make some progress and hopefully talk about some more at 
the next meeting.

 Thank you very much, gentlemen.

 Any other questions?  Okay.  Kim, you've got something.

 >>KIM DAVIES:  I did.  I quickly created a slide.

 [Laughter]

 >>KIM DAVIES:  So for those that are interested, ICANN operates one of 
the 13 root zone networks, the so-called "L" root.  This will be 
renumbering to a new IP address on the 1st of November, 2007, which is 
this Thursday.  The reason for this is twofold.  One is that it's 
moving to anycast, which will allow it to have increased redundancy.  
There's currently two nodes in the network, one in Los Angeles, which 
should be Los Angeles, and the other, a new node that's just been 
installed in Miami.

 Miami was chosen because it gives good coverage of Latin America, good 
connectivity to Latin America.

 The aim is to expand the footprint of the "L" root beyond those two 
locations with more global nodes.  Also, I know that ICANN is planning 
on creating small root server kits that can be deployed as local nodes 
around the world.

 What this means is that for localized root -- if you want a localized 
root, ICANN will ship you a -- like a little box that you plug into 
your network.  It will be fully managed by ICANN remotely, and it will 
just act as a root server.

 This is not something being done by IANA, it's done by the office of 
the CTO, which is a separate department within ICANN, but as managers 
of the root zone, IANA's been involved in coordinating this renumbering 
effort.

 At the end of the day, what this means directly to you is very little, 
but what it does mean is over the course of the coming year's, that the 
old IP address needs to be phased out and this means that the hints 
file in most DNS software will need to be updated.  There's certainly 
no rush to do this, but it's something that will need be accomplished 
over time.  So I just wanted to mention that.  I thought it was useful 
to note.  Sorry, I forgot it earlier.  That's it.

 >>CHRIS DISSPAIN:  Okay.  Thank you, Kim, and thank you, Olivier.

 And we'll do more on DNSsec later.

 Okay.  The next session is our session with the board, and Paul Twomey 
-- I have Vint Cerf and Paul Twomey with me.  And there are some board 
members in the room.  Could the board members stand up just so that 
those people that don't know them could find -- could see them?  So 
that that's Bruce Tonkin, Roberto Gaetano, Harald Alvestrand and -- do 
we have anyone else?  Okay.  Thank you very much.

 This is our usual catch-up session when we get to find out what's 
going on at the board and ICANN management, and we get to tell them 
what we're doing.

 So who's going first?  Vint.

 >>VINT CERF:  Okay.  Good morning, everybody, and thank you again for 
inviting us to join you.  Why is this thing -- so there.  Okay.

 First of all, in case you wondered why there were not a whole lot of 
board members standing up, it's because the board is trying an 
experiment this week.  We're actually splitting the board members up 
and sending them to different of the constituency meetings, so that 
they can spend more time in each of the meetings, rather than racing 
around like, you know, a soccer team chasing one ball at a time.

 So don't misunderstand the small number of board members here.  It's 
because we're trying to split ourselves up.

 And then to report back to the board any important issues that have 
arisen.

 I'm going to take advantage of the fact that I've been given a 
microphone to show you something.  This is the one laptop per child, in 
case you've wondered what they look like.  They actually work.  They're 
going into Uruguay, according to the latest news report today, and so I 
thought some of you would be interested to see.  If you've heard about 
the hundred dollar laptop, it's not a hundred dollars.  It's probably 
more like 175 because the screens are still expensive, but the fact is 
that they exist, they're real, they're being produced, and I find it 
pretty exciting.  So I -- I brought one with me just so you'd have a 
chance to see it.

 I have very little, I think, in the way to specifically bring to your 
attention except to say that the question of accelerated IDNs for 
ccTLDs is of great interest.  It also raises a lot of concerns that we 
not take any steps that might set a precedent which was damaging in 
some way to the interests of everyone who would like to work with IDNs 
in the TLD space.

 But we're very interested in any conclusions or any thoughts that you 
have along the acceleration direction.

 I also wanted to express my appreciation to the ccNSO and its chair 
for the level of interaction that you're having with the GAC.  I 
suppose it's the role of the GAC to say thank you, but I'm very much 
appreciative of the fact that I'm seeing so much interworking going on 
among the various constituencies.  This was not a common practice in 
the earlier days of ICANN, and in its maturing, the dialogue has 
gotten, I think, much more extensive and, therefore, I think more 
effective.

 Apart from that, I think -- I'm very, very interested to learn whether 
there is a concrete proposal now for region definitions and changes in 
who's in what region, because I'm not certain what the side effects of 
that will be, if we have different region definitions for different 
constituencies, but I'm interested to know where that stands.  And 
apart from that, as you know, this is my last ICANN meeting as chair 
and I have to step down from the board because of term limits, so I 
don't have a lot of forward-looking stuff to say right this minute, but 
on Friday I do have -- you can anticipate that I will have a parting 
offering of advice to everyone at ICANN, so I won't bore you with any 
of that now, and will wait till Friday for that.  So thank you, Chris, 
for an opportunity to speak this morning and I think I'll turn this 
over to Paul Twomey, who probably has something more substantive to 
say.

 >>CHRIS DISSPAIN:  Should I respond to the regions thing?

 >>VINT CERF:  If you like, yeah.

 >>CHRIS DISSPAIN:  Yeah, I'll respond to do regions thing first.  

 Yeah.  Our regions report that we've sent to the board says two 
things.  One of them is a recommendation to the board, which is that we 
recommend that the slated regions review, which you're supposed to do 
every three years or something, the slated regions review this time 
around needs to be a full-blown proper review, and we've given 
illustrations of what the issues are that arise for us, and the things 
that we think would need to be addressed in that review.

 Rather than just saying everything looks okay, let's keep the regions 
that we've got.

 >>VINT CERF:  Okay.  All right.

 >>CHRIS DISSPAIN:  The other part of the report deals with an 
interpretation of the bylaw, the existing bylaw, for us that we -- we 
will probably choose to make.  We choose that -- there is a bylaw that 
says that where there is a question of the -- of a country's -- 
territory's region, they are entitled to --

 >>VINT CERF:  Self-select.

 >>CHRIS DISSPAIN:  -- self-select, and we are considering an 
interpretation of that to say that where the territory is in -- where 
the territory is in a region because of the mother country rule -- for 
want of a better description -- if the ccTLD manager and the government 
are happy for that ccTLD to move only for the purposes of the ccNSO to 
their geographic region rather than their mother country region, then 
we would allow them to do that.

 >>VINT CERF:  Okay.

 >>CHRIS DISSPAIN:  Okay.  But that doesn't have any effect on the 
actual regional structure of ICANN.  It's the review that will do that.

 >>VINT CERF:  Got it.  Okay.  Thank you.

 >>CHRIS DISSPAIN:  It was a pleasure.  Paul?

 >>PAUL TWOMEY:  Do you want to go through the things that you --

 >>CHRIS DISSPAIN:  No, no.  You go.

 >>PAUL TWOMEY:  Oh, okay.

 >>CHRIS DISSPAIN:  You go first.

 >>PAUL TWOMEY:  Well, hi.  Is this on?  First of all, I'm pleased to 
be here and I'm stunned by the size of the room.  We're going to 
obviously have to move to a football stadium for the next meeting to 
keep all the cc representatives in one place.

 I've got a couple -- I suppose a couple of things just to report.  
First of all, I'll come back to this, but we have our strategic 
planning process underway at the moment, which is looking for feedback 
on a draft strategic plan.  I would very much encourage you to find the 
opportunities to look at that and to participate and give your feedback 
on that strategic plan.  There's a specific part I want to come to 
shortly, which is about security and stability that I want to refer to 
specifically as it relates to cc's, but I would strongly emphasize that 
you look at that and give us your feedback.

 Related to that is there will be more work on -- at least in some 
parts of it in terms of setting milestones and timetables, although 
frankly in the strategic plan I think some major areas, that can be 
achieved; in some of the other areas, it may not be quite so feasible 
at the strategic plan level.  The reason why this is significant is the 
strategic plan feeds into our operational planning and budgeting 
process which will start as of January, which is where the rubber hits 
the road.  This is where we allocate our resources according to 
priorities, and if you've got views about what those priorities should 
be, then the strategy document is the first place to make that clear.

 Secondly, I just want to note that we continue to have a steady stream 
of accountability frameworks and letters exchange taking place.  I 
think we will be, by the end of this week, at 36, 37, 38 accountability 
frameworks signed so far, and that's continuing apace.

 So I do recommend that to people, if that suits your needs.  There's 
clearly another 200 to go, so we would -- but having said that, I think 
we now have something like over 60% of ccTLD registrants, the ccTLDs 
that represent over 60% of ccTLD registrants are presently in some form 
of accountability framework or agreement with ICANN.

 The -- one of the issues in the strategic plan that obviously you will 
have an interest in and also should be, I think, heavily involved in, 
in giving your feedback, is on the new gTLD process and on 
internationalized domain names, both as they will apply to new gTLDs 
and they will apply to ccTLDs.

 The -- I think that's an issue that obviously there's an interest in 
Internationalized Domain Names for country codes, but that's another 
area I draw your attention to, that that process is coming to its 
fruition, and that there will be, by Friday, I expect, a board 
resolution requesting the staff to take the new gTLD policy and look at 
implementation steps.

 I'm -- one of the things I'm tempted to do this week is actually run a 
competition -- trouble is I've got to get a lottery license if I'm 
going to do this, but I am tempted to run a competition asking people 
to write on the back of their business card how many new gTLDs they 
think we will receive in the first application round.  Why don't I try 
it here?  What's the -- quickly throwing out, who -- how many do you 
think we'll get in the first round?

 >> You mean get through or --

 >>PAUL TWOMEY:  No.  Applications.

 >>CHRIS DISSPAIN:  Applications.

 >>PAUL TWOMEY:  Requests.

 >>CHRIS DISSPAIN:  Okay.  Who says a hundred?

 >>VINT CERF:  I'm hearing a hundred, a hundred.  Do I have a hundred 
and twenty, a hundred a hundred and twenty?  A hundred and forty!  A 
hundred and forth. do I hear a hundred sixty?

 [Laughter]

 >>PAUL TWOMEY:  500?

 >>CHRIS DISSPAIN:  500.  Oh, yes that's apart from yours, Simon.  How 
many ours do you think --

 [Laughter]

 >>CHRIS DISSPAIN:  500?  Anyone else?  Any advance on five hundred?  
No one is going to go any further?

 >>VINT CERF:  I was going to say that we need to -- there's no 
incentive in that question until Paul explains that if you write your 
thing on the business card, your answer, and you turn it in, that we 
might offer a thousand dollar prize for whoever gets closest.

 [Laughter]

 >>PAUL TWOMEY:  Vint Cerf just said that on a personal basis and I 
want the general counsel and the Los Angeles Attorney General to 
realize that I did not say anything of the sort.

 >> How about a refund on the application fee?

 [Laughter]

 >>PAUL TWOMEY:  The GNSO Council meeting last night, we had a number 
of votes at 2,000.

 >>CHRIS DISSPAIN:  Really!  2,000.

 >> Wow.

 >>PAUL TWOMEY:  And that was irrelevant as to what the price was.  
Interestingly.  I didn't even say what would the price be for the fee, 
so -- and just --

 >>CHRIS DISSPAIN:  Have you run any metrics on --

 >>PAUL TWOMEY:  That was the upper bounds, by the way.  Other people 
were saying 300 or 500.

 >>CHRIS DISSPAIN:  Right.  Have you run any metrics on how long you 
think it might -- like if we get a hundred, it will take us two years, 
if we get a thousand, it will take us a decade.  I mean have you any 
clue.

 >>PAUL TWOMEY:  Haven't got there, but somewhat related to that is 
pressure to say, you know, the first round starts in the 1st of July 
and the second round will start on the 1st of January ---

 >>CHRIS DISSPAIN:  What will, that was a very interesting --

 >>PAUL TWOMEY:  No, we're not there yet, so I don't want to go too far 
down the track.

 >>CHRIS DISSPAIN:  Yeah.

 >>PAUL TWOMEY:  I just want to say in this room that you should be 
aware of -- it strikes me -- that that whole discussion is taking 
place.  And of course I expect many of you are involved in those sorts 
of discussions and one also realizes of course that there's a 
difference between registries and registry services in this evolving 
marketplace so that's clearly a very big issue coming forward.  
Similarly for Internationalized Domain Names gTLDs, and one of the 
observations, I've been asking people what do you think the ratio of 
costs are for implementing for the staff implementation challenges for 
gTLDs.  My ingoing hypothesis for IDN gTLDs is four-to-one in costs.  
One of the council members thinks it's 10-to-1 to an ASCII.

 In terms of the engagement at local levels and all sorts of schools, 
cultural schools, like linguistics schools, et cetera.

 >>CHRIS DISSPAIN:  Okay.

 >>PAUL TWOMEY:  So I just want to flag that this is the big thing next 
year, and you should be paying some attention to that in your 
considerations.

 >>CHRIS DISSPAIN:  Can I just flag that, I mean, the only -- there are 
obviously -- everyone has personal opinions about the policy that's 
being set forward, et cetera.

 The only thing that concerns me greatly is the issue of no reserved 
list for country names.  The challenge is that -- what effectively 
you're doing is handling that on a -- one would be seem to be 
suggesting you're handling that on an objection basis and I got the 
impression yesterday from talking -- when Kurt was talking about the 
implementation procedures that actually staff have looked at that 
recommendation and are doing some work on it, which kind of implied 
that there might be some movement there, but it is clearly of concern 
if -- if every time a gTLD application comes in, you've got to -- we've 
got to check it, to make sure -- you know what I mean.

 >>PAUL TWOMEY:  Well, these are the sort of things that you need to 
think about and you will need to input as we go into consideration of 
implementation.  So as we look at implementation issues -- and we will 
come back to the community about the implementation, but we do need to 
hear from you and others about these sorts of issues.

 One of the other issues, by the way, is I've been specifically looking 
at is -- talking about is what do you do with variants, variant tables.  
So if there's an application -- let's take the application, if there's 
an application in Chinese characters afternoon the variant table might 
show that there are 16 different combinations of characters that could 
mean the same thing, how does that apply in terms of the tests of 
confusingly similar and what do you do with variants and how do you 
handle that issue.  So...

 There's things that are of the experience of the cc's that are going 
to -- at the second level, that are going to be applicable.

 >>CHRIS DISSPAIN:  Is there still a grim determination to have the new 
gTLD round include IDNs or -- I mean, I accept that logistically it 
might not be --

 >>PAUL TWOMEY:  Yes, yes.

 >>VINT CERF:  Yes.

 >>CHRIS DISSPAIN:  So you have to get that stuff sorted out in order 
to --

 >>VINT CERF:  Yes, yes.

 >>CHRIS DISSPAIN:  Okay.

 >>VINT CERF:  Just one -- two observations.  If I've understood what 
you just said, Paul, I would have thought that in the case of the 
variant tables that are deliberately used, or recommended, registration 
of any one of those 16 sequesters the other 15 so that they are not 
available to anyone else.  You do know that, right?

 >>PAUL TWOMEY:  You should have a conversation with the GNSO Council 
on their interpretation of what they put forward.

 >>VINT CERF:  Well, I mean, I'm --

 >>PAUL TWOMEY:  That's -- no.  Frankly, that is not clear in the 
policy.

 >>VINT CERF:  Okay.  Well, I'm --

 >>PAUL TWOMEY:  And that's one of the things we have to look at in 
implementation.

 >>VINT CERF:  I'm referring to the CJK papers which are very explicit 
about the implementation that when there is a registration that 
involves those characters that have variants, that the block be 
reserved.

 >>PAUL TWOMEY:  Yeah, but that's -- CJK does that at the second level 
and that's one of the things we should learn from, but that's not 
existing presently in the GNSO recommendation.  So we need to move this 
through an implementation process.

 >>CHRIS DISSPAIN:  That's right.

 >>VINT CERF:  Okay.  Well, there were reasons for putting those blocks 
together, and I think the reasons are just as valid at the top level as 
they are at any other label level in the -- in the domain name system.

 >>PAUL TWOMEY:  That's right.

 >>VINT CERF:  So that's Point No. 1.  Point number 2, regard to the 
restricted names and the list, or the reserved list, it seems to me 
that as we enter into this gTLD -- or -- yeah, sorry, into this IDN TLD 
space -- and I make no distinction in that phrase between ccTLDs and 
gTLDs.  They're just IDN TLDs.

 >>CHRIS DISSPAIN:  Yes.

 >>VINT CERF:  In that space, I think there will be many, many grounds 
for expression of concern among -- from one party about some other 
party's registration.  And I think we are going to have to find a means 
by which those expressions can be made visible.

 And since they can come on many different grounds, trying to 
predetermine all the possible reasons and to reserve names in order to 
avoid that sounds really hard, and that we may simply have to accept 
the idea that a process is needed to deal with objections.  The more 
complicated thing, especially I think in your context, is that some of 
the objections may be on the basis -- well, let's see.

 Some of the objections may be made on the basis of sovereignty in a 
national context, and I can imagine an administration saying, "Why do I 
-- I'm a sovereign country.  Why do I even have to go through this 
process?"  And of course the answer is:  We're trying really hard to 
make sure that fairness is at play here, and also uniqueness continues 
to be maintained.

 So this is not going to be a simple thing to invent, the mechanism by 
which objections can be placed, on what grounds, and who has standing 
to make objections.  But we really have to find a way to do that.  
Because otherwise, I think this whole process would be too complicated.

 >>CHRIS DISSPAIN:  Okay.  Thank you.  Paul, were you still --

 >>PAUL TWOMEY:  Bruce wants to intervene.

 >>CHRIS DISSPAIN:  Bruce, yes.  Hold on a second.  Okay.

 >>BRUCE TONKIN:  Just wanted to comment.  I just noticed the dialogue 
there between Vint and Paul, so I thought I'd --

 >>PAUL TWOMEY:  You thought you'd correct it.

 [Laughter]

 >>CHRIS DISSPAIN:  Welcome, Bruce.

 >>BRUCE TONKIN:  Thank you.

 >>CHRIS DISSPAIN:  Feel free to walk up to the front of the room and 
address the room.

 >>BRUCE TONKIN:  I will.  I thought it would be easier than talking to 
everyone's back.  

 So my name is Bruce Tonkin and I'm an ICANN board member elected from 
the GNSO, and I was also chair of the new gTLD policy development 
process, so at least I guess I understand some of the reasoning behind 
what we've done there.

 To address the concern that Vint raised there about character 
equivalence tables that have certainly been done at the second level 
and how that might apply to the top level, the reality is the 
implementation of the introduction of new top-level names, whether you 
call them ccTLDs or gTLDs, is quite complex, and we're going to need to 
learn from people that have got experiences in the ccTLD community 
where they've already rolled out IDNs to some degree, and even from the 
gTLD community where IDNs have been rolled out as well.

 But the hooks or policy principles that we have at the top level, one 
of the policy recommendations is that strings at the top level should 
not be confusingly similar.  So that's been deliberately written in 
that way.  There's been a lot of debate about whether that should be 
visually similar or qualifying that, but we've actually left it a bit 
open, because we recognize that we're going to have to be dealing with 
different cases, and the basic measure is going to be:  Is it 
confusingly similar to the community of people that those strings are 
intended for?

 So it's not necessarily confusingly similar to everybody on the 
planet, but if you have a particular string that's aimed at a 
particular language or cultural community and you have another string 
that would also be used by that same community, the test is:  Would a 
typical person of that community be confused by those two different 
strings.

 So that's the general principle.

 We also have a concept of a reserved names list, and that's been 
populated with a fairly minimal set of reserved names to start with, 
but the concept is that as things are identified as being confusingly 
similar, they may well then be put on a list so that future applicants 
would then see that list and go, "Okay, I'm applying for a new top-
level name and I'll check this list and I'll see that there is actually 
a list of names that have previously been identified as being 
confusing."  So it starts to build up a bit of case history, if you 
like.

 And I certainly think that as we start considering particular scripts 
and look at particular character equivalents, you may well say that 
because a particular string has been approved and is now in the root, 
you may well want to create an equivalence table for that string and 
say, "Well, these actually should be on the reserved name list."

 So that's basically how it's handled in the new gTLD policy.  There's 
no way we could up-front suddenly kind of cover every case, but the 
mechanism and the principle is that no two strings at the top level 
should be confusingly similar to the community for which those strings 
are intended.  So I just wanted to kind of give that context.

 >>CHRIS DISSPAIN:  Thank you, Bruce.  Paul?

 >>PAUL TWOMEY:  Thanks.  Just I mentioned about the strategic plan.  
One of the items in which we have received a lot of feedback on the 
strategic plan, importantly both from the constituencies and the -- if 
you like, the regular ICANNers, but very interestingly from a much 
broader range of players who are watching and participating in ICANN in 
certain spaces and who introduce -- intervene in this particular area 
has been on looking for ICANN to play more of a role or dedicate more 
resources around security and stability.

 Now, very clearly ICANN is not an organization that is like -- that 
wants to be beyond its mission statement.  Its mission statement is 
very clear about the coordination of the Internet system of unique 
identifiers.  Nor is ICANN at all interested in getting any confusion 
about the policing roles people can identify with within concepts of 
stability and security.  That just ain't our business.

 So there are many players involved in issues around security and 
stability in terms of cybersecurity.

 Nevertheless there has been quite a lot of feedback we've received 
through the strategic planning process about looking for more 
participation, more -- and more action.

 One of the areas that's emerging as an item of discussion in that 
consultation process -- and it's coming from some of you as well but I 
wanted to share with all of you -- has been more activity in terms of 
information sharing about the nature of risks as they relate to the 
DNS.  In particular, things like discussions about how things like IP 
flux and high IP flux activities are taking place, the increasing reuse 
of domain names as a mechanism for booting stability for bot net 
formation, and in particular, responses to DDOS attacks on DNS 
infrastructure.  So that's one set of areas of concern -- of interest.

 And as you would appreciate, ICANN as a community has a lot of 
experience in this, and ICANN, if you like, as an institution, learns a 
lot about this space in terms of what happens in the root servers, in 
terms of what happens in the very large g registries, et cetera.

 So one is an issue of how do we -- how do we find an effective way of 
sharing more information.  The second issue that's been emerged and 
we've already been approached from some parts of the regional cc world 
is to potentially partner on potential issues of exercises, and of the 
-- the simple question of it's -- resilience is better prepared if 
you're actually -- if you've actually prepared and thought about the 
problem to start with.  So we're not potentially going to sort of shove 
this down everybody's throats at all, but I just wanted to let you know 
that we are considering this issue of how would you actually have 
potential exercises or think about what sort of things would be 
available and in testing, and we have been approached and we'll 
potentially do some stuff with some regional cc positions or 
participant players who want to have a sort of discussion at regional 
levels about how to -- potentially what would be involved in exercises.  
Because we ourselves are also increasingly involved in exercises and 
preparations.

 This is about building resiliency, about knowing how to respond, what 
to do, learning lessons.  So I just wanted to share those as a couple 
of examples of things that are presently coming up in the security and 
stability issues.  We are clearly doing more work on the g space on 
things such as amendments to the registrar accreditation agreement to 
build better protection for registrants.  Obviously with registry 
failover plans, implementing data escrow for the gTLD registries which 
will be completed very shortly.  So there are some very specific things 
in the g space we're doing on security and stability, but I suppose 
part of the message is, if I can sort of characterize the position, and 
if ICANN -- security is more than DNSsec.  We've talked a lot about 
DNSsec recently and there's a lot of discussion to go on about that as 
a topic in itself, but I wanted to make the point that when it comes to 
security and stability issues, it's more than DNSsec.

 >>CHRIS DISSPAIN:  Can we take a -- Hilde had a question.  Gabby on, 
could you give the microphone to Hilde for me?  Oh, Hilde is coming.  
Yeah, there it is.  Hang on.  It's coming.

 >>HILDE THUNEM:  Okay.  I'm going to try again.  I'm Hilde from the 
Norwegian registry.  I'm sorry about dragging us back to the IDNs after 
the security and stability issue, but I would like to raise a concern 
that I do sympathize a lot with the gTLDs' desire to move forward on 
this IDN issue.  That is shared by the people in this room.  But I am 
concerned that there seems to be very little effort made in dividing up 
what is g space and what is cc space in IDNs, and one of the reasons 
why today it works very well in the ASCII world in letting the gTLDs 
have their policy and the ccTLDs run their policy sort of fairly 
without stopping each other from doing stuff is that we have divided in 
saying that this is the gTLD, this is the ccTLD.

 Now, if the gTLDs will not -- or if the policy doesn't really divide 
into what is IDN cc's, then it would be very concerning for the cc's 
that the gTLDs are moving forward, because then we will really need to 
sort out everything or stop them from implementing their policy because 
they -- that might impinge on actually our part of the world.

 The challenging process is, on the paper, a good thing, but if you get 
2,000 new applications, we're talking about small communities for which 
language is very, very important and their country identity is very, 
very important, that have to follow each of these applications and try 
to realize is this something I need to challenge up against VeriSign or 
somebody else.  I shouldn't really pick on VeriSign, I guess, but I'm 
doing it anyway.

 >>CHRIS DISSPAIN:  But you have.

 [Laughter]

 >>HILDE THUNEM:  With lots of money and to follow that process, that 
concerns me.

 >>CHRIS DISSPAIN:  Okay.

 >>HILDE THUNEM:  I think that at the very least, some effort should be 
made in defining what is an IDN ccTLD, in principle, so that some of 
that space is actually left for the IDN cc's to find out what they want 
to do with it.

 >>CHRIS DISSPAIN:  Thank you, Hilde.

 >>VINT CERF:  So, first of all, I think that you've articulated well 
one aspect of the complexity of introducing internationalized domain 
names.  We had a lot of benefit from having this table from the 3166-1 
which had a bunch of little two-letter codes and that was it.  You 
didn't even have a choice really.  It was kind of a sign, although you 
could argue and sometimes they would change it to a different pair of 
characters.

 We don't have the benefit of anything like that in the IDN space.  So 
let me at least make one or two observations.  The first one is an 
internationalized ccTLD presumably should be the expression of 
something which is very much related to the locale, jurisdiction, 
whatever word you like, of that area, not intended to be an obviously 
commercial expression.

 >>CHRIS DISSPAIN:  Correct.

 >>VINT CERF:  So to the extent that we could make clear the intent 
which is to use these expressions in the IDN ccTLD space as a way of 
referring to the locale, that will help.

 The problem is it isn't quite as precise as "these two characters 
represent that locale" and that's it.

 So it's clear that judgment is going to show up in that space.

 On the other side, we found great creativity in the invention of names 
in the generic space.  People will find all kinds of ways -- I would 
suggest to you that things like dot Asia indicate the degree of 
interest there is in geographic references in the generic space.

 I don't know how to absolutely protect you from the need -- or the 
ccTLDs from having to examine the gTLD proposals because I don't see 
any way of in advance listing all the things that are forbidden.  If we 
did that, there might still be an invention of a name that was 
troublesome to you.

 So I think all we could do in this case is to help facilitate the 
awareness of the ccTLDs of the generic proposals that are showing up.

 >>CHRIS DISSPAIN:  There is -- I'm sorry.

 >>VINT CERF:  Yeah.  So -- I don't understand any other way to resolve 
the problem you raised because I don't see any way of listing a set of 
expressions which would inhibit a problem for you.  Even if we made the 
list of names that were specific to IDN ccTLDs, you might still be 
concerned about a gTLD proposal.  And so -- unless you wanted to argue 
that you wouldn't, and I'm having trouble --

 >>CHRIS DISSPAIN:  The objection to a gTLD proposal might be for 
several reasons.  It might be because it looks like, sounds like, 
smells like a ccTLD.  But it might also be it isn't -- it is clearly 
not a ccTLD but it impinges on us for a different reason.

 So I wouldn't argue, for example, that Azzie, Azzie, as a 
representation of Australia would obviously not be a ccTLD but 
Australia might object to somebody putting a gTLD application in for 
that either as an ASCII or an IDN.

 >>VINT CERF:  Just to pick a silly example.  What would happen if 
somebody wanted to register in Swahili a string that meant "Australia 
is a bad place to visit."  The first problem, of course, is Auda would 
have to figure out what that meant in Swahili, first, and then figure 
out whether they were unhappy with it.  But it is a big, complex 
environment.

 And I don't understand any way other than to make visible the 
proposals to account for possible objection.

 >>CHRIS DISSPAIN:  I'll take the question, Hilde, but we have a couple 
of other things we have to get on to.  Just quickly.

 >>HILDE THUNEM:  I will keep it very, very short.  Just as a starting 
point to say that the principle is there is a territory list.  We do 
actually have that.

 >>CHRIS DISSPAIN:  A territory list, yeah.

 >>HILDE THUNEM:  The territory list.  The ISO list is not just two-
letter codes.  It comes with the territory.  If you could sort of say 
that territory and the representation of that territory is the place 
where one should be aware where the principle is actually that this is 
a CC and then, yes, I do -- I'm running a forbidden reserved list 
within my own ccTLD as well so I know you can never, never get 
everything on the list and there is always something you do forget.

 But at least we do have a list of the territories and taking their 
sort of principles stand that this is actually ccTLDs, the names --

 >>CHRIS DISSPAIN:  The names of those territories, yeah, yeah, okay.

 Paul?

 It is also relevant in the ASCII space.

 >>VINT CERF:  Your microphone is live so if we should have a 
conversation --

 >>CHRIS DISSPAIN:  It is as relevant in the IDN space as it is in the 
ASCII space.

 >>PAUL TWOMEY:  I will stand up for this next item, if I may.

 >>VINT CERF:  No, you have to sit down.

 [ Laughter ]

 >>PAUL TWOMEY:  There are benefits about him leaving on Friday.

 [ Laughter ]

 I get about three or four days to be cheeky, and then I get a new 
chairman and then I have to shut up.

 >>VINT CERF:  So get it out of your system now, Paul.

 [ Laughter ]

 >>PAUL TWOMEY:  Some of you over a period of time have recorded in 
conversations with myself and others that you might like to see the 
particular role the United States government plays vis-a-vis ICANN 
shift potentially over time.  There seems to be a few nods going on in 
the room.

 Okay.  I just want to make certain everybody understood very clearly 
the signal sent yesterday by John Kneuer.  He said we are having a 
midterm review of the joint partnership agreement, and we are doing it 
in partnership.  John is very comfortable with the community -- the 
full community coming back and saying their perspectives about how 
ICANN is going.  But you may need to understand clearly, if you're the 
assistant secretary of commerce -- I won't make it person.

 If you are the United States government and your stated policy is that 
you wish to move to full transition -- quote, full transition to 
private sector management of the unique identifier system of the 
Internet, and you have made that point several times in Congress, in 
hearings, et cetera, that your policy is to make transition, then 
clearly one of the things that's important to you is to be able to say 
that the entity to which you are making that transition has the support 
and is, you know -- is working well and is stable.  In other words, 
politically, any sort of politician, "I am safe to make that 
transition."  You can't criticize me if the transition takes place.

 I am not saying in the next step that if you have got views about how 
ICANN is participating, about ICANN's roles, that you won't put forward 
things if you are discontented.  I'm not asking people not to.

 But I am pointing out to you that if you do have a view about how 
ICANN is participating and importantly the subtext is if you wish to 
see the process of oversight come to its conclusion, this joint 
partnership agreement is the mechanism whereby that will take place.  
And the midterm review -- how to put it?  That potentially -- I'm not 
saying it could.  It could take place at the end of that period, but it 
could take place earlier, depending upon the feedback that's received 
through this process.

 So I am exhorting you that you've got both views about how ICANN is 
going, we definitely want to hear that and that's part of the process.  
But if you've got perspectives about "we'd like to see progress on this 
oversight part of IT" -- many of you have raised that with me on a 
personal basis -- this is the time to say it and this is the mechanism 
which will be available to you to make presentations on it.

 So I'm just making that quite clear.  In case -- because I know it is 
not always easy in different political systems to understand the 
subtext of what's being said sometime.  There is a subtext behind this 
call which is if you want to see progress, you want to see movement, 
then clearly, not surprisingly, if you are the Department of Commerce, 
you want to have confidence that the community is supportive and that 
they have got confidence in the mechanism.

 I am obviously not asking you to say things you don't believe.  If you 
think ICANN is running very poorly and you have got perspectives on 
that, I suspect you will say that, too.

 But, nevertheless, I want people to understand clearly what 
potentially is the opportunity.  Now, my read is that we will receive -
- that there will be some sort of public hearings that will take place, 
my guess is, towards the end of January or in February next year, but 
that the opening for written communications will open sometime in late 
this month.  I suspect even before the IGF is my personal guess.

 We will be doing more things on transparency and accountability 
between now and December.  We've got a program of things to finish 
through to December, including, for instance, putting up -- we will be 
posting by December a dashboard for the community to see transactional 
-- day-to-day transactional reporting of various things like, for 
instance, all the IANA processes and functions will be on a day-to-day 
basis on a dashboard for the community to see.

 You will have seen we put up a lot of material on management operating 
principles and on our accountability processes.  That's been posted 
recently and I ask you to look at that.

 If you have got any more questions on that, let's please hear about 
that and let's ensure that you're aware of it.

 If you want -- if you want to have discussions about this, if you want 
to say that I didn't fully understand this, can you explain what you're 
doing and if we want to respond, can you please help us think through 
the issues or something, can you tell us what you've done on the 
following things, please do not hesitate to approach us and ask us, 
okay?

 Last time there was one of these exercises, 18 months ago, the 
Department of Commerce received 700 responses.  They were 
overwhelmingly from North America.  And after that exercise, there was 
a certain amount of angst I received from people internationally saying 
but we want to see change and progress.  The way the system works here 
is you've got -- if you want to see that, you got to say it and you got 
to participate in it.

 And this is the mechanism to do that.  So I would -- I'm certainly 
hopeful that in this next round of calling for comments and getting 
feedback that that balance between international feedback and U.S. 
domestic feedback will be different from what it was 18 months ago.

 I just want to remind people of that and say take this into your 
considerations that it is coming up.  If you have got any questions or 
want assistance or want any -- any questions in that, please don't 
hesitate to contact myself or any of the regional liaisons or Theresa.

 >>CHRIS DISSPAIN:  Thank you, Paul.

 We need to wrap this up because it is time for coffee and then we have 
another session.  Any last comments?  Okay.  I just want to say one 
thing.  This whole week is going to be full of thank yous and stuff.  
All I want to say is thank you and we'll miss you.

 >>VINT CERF:  Well, will you see me?  You will not see me at any of 
the ICANN meetings in 2008.  I'm absolutely committed to taking my time 
back.  I really need it.  So I'm not planning to appear or take any 
official role with ICANN during that time frame.

 I'm available for consultations, but I'm not going to hover around 
like Bankwo's ghost over the proceedings.  I think it is important 
actually.  It is a very symbolic thing that I not be visible at all 
because we have to show that ICANN is fully capable of absorbing 
changes in leadership in the normal course of events.

 Paul is the third CEO.  Alex Pisanty stepped down in June.  I am 
leaving in November.  Four guys that have been part of the leadership 
for almost seven years, it is very important symbolic demonstration and 
substantive demonstration that the organization can adapt and find 
leadership.

 So by surviving for 2008 without either of us around is a really 
important thing.  I know you can do it.  There is no doubt in my mind.  
It is not because I hate ICANN or I don't ever want to see you ever 
again.  This is partly to get some time back but also to make sure that 
we show the world that this is an enduring institution.

 >>CHRIS DISSPAIN:  Thank you, sir.

 [ applause ]

 Okay.  We're going to have a coffee break.  There is coffee outside or 
there was earlier opposite.  Apparently you are supposed to go down 
stairs to the main room.  Can we be back please at five past 1:00 
because then we are do the DNSsec survey and then we are going to the 
GAC.  It is important everyone comes back on time.  Thank you.  (Break)

 >>CHRIS DISSPAIN:  Please take your seats, ladies and gentlemen.  
We'll start again.  Please take your seats, ladies and gentlemen.

 Please take your seats.  Ladies and gentlemen, please be seated.  We 
need to get started.  Please take your seats.

 Just before we do -- just before we do start, a couple of logistical 
matters.  We're going from here at 11:45 to a joint session with the 
GAC, and that is in their room, which is across the way, La Jolla, and 
straight after the GAC session which finishes at 1:00 or thereabouts, 
we are going to lunch, and our lunch is being sponsored today by 
NeuStar, who will have a little chat with us after lunch.  The lunch is 
downstairs in the lower lobby, so that means you have to get the lift 
to the ground floor, and then either get the escalator down to the 
lower lobby or go to the other lift and get that down to the lower 
lobby.

 And apparently once you get to the lower lobby, it will be obvious to 
you where the lunch is.  Apparently.  And there are tickets for the 
lunch, so when are you going to hand those out?

 >>GABRIELLA SCHITTEK:  Just before lunch.

 >>CHRIS DISSPAIN:  What about when we leave this room to go to the 
GAC?

 >>GABRIELLA SCHITTEK:  I don't have the tickets.

 >>CHRIS DISSPAIN:  You don't have the tickets.  Go get the tickets.  
No, no, no.  That's all right.  We'll do it afterwards.  We'll do it 
afterwards.  That's fine.

 Okay.  So everybody clear on that, I hope?  Excellent.  All right.  So 
this session is basically the sort of pre-DNSsec meeting session for 
gabby to tell us the results of the DNSsec survey, and for us to have a 
chat about that.  So gabby, over to you.

 >>GABRIELLA SCHITTEK:  Okay.  Hello?  Okay.

 Hi.  I'm Gabriella, if you don't know me.  I'm the one who has been 
sending out the survey and the reminders on the list.  And I'm going to 
now go through the results of the survey.

 First of all, I would just like to give you some background 
information.  The survey was initiated after a council meeting in San 
Juan, and I'm citing the minutes here.  The ccNSO secretariat is to 
find out what the cc community has done so far individually regarding 
DNSsec and to take part of their experiences on the matter.

 So we thought the easiest way to fulfill that task was to launch a 
survey.  And the reason for why the council asked us this was that one 
registry had asked ripe to become the signer of the root, and the 
council wondered is that something the ccNSO should have an opinion 
about.

 So that's the background for why the survey was launched.

 The survey was conducted from mid-September to mid-October, and we 
sent it out to all available e-mail lists, which is the ccNSO members 
list and the ww TLD list.  I know that some of the regional 
organizations also sent it out to their lists, so many thanks to you.

 In total, we had 61 replies.  You can see the breakdown there.  It's 
18 from Africa, 19 from Asia-Pacific region, 12 from Europe, 8 from 
Latin America, and 4 from North America.  And I have to add I was here 
strictly following the ICANN regions.

 So let's start with some good news.  90% declared they know what 
DNSsec is.  Another 5% said they know what it is but they don't know 
how it works.  Only 5% said they'd never heard about it.

 Although so many knew what DNSsec was, only 7% of our respondents had 
implemented it.  86 hadn't.  But there were a few registries who were 
actually running a kind of test version, so that meant they had already 
implemented DNSsec internally and they were more or less ready to go, 
but it was still just in a test version.

 One registry had deployed DNSsec, but only on ENUM, because of -- they 
were scared of zone walking issues, so they said when the zone walking 
issue has been resolved, they are ready to go in the ccTLD.

 So then we asked, "If you have not implemented DNSsec, do you plan 
to?"  And as you can see, the vast majority said yes.  6% were unsure.  
10% said no.  Although I have to say that most of these people who said 
no, it was not a definite no.  They had like a little disclaimer 
saying, "We don't plan to right now, but we know it's important and we 
know it will happen in the future."

 I think almost everyone who said no stated that as well.

 Then we asked, to those who did not want to implement DNSsec in the 
closest time why they don't want to do so.  This was an open-ended 
question so I just tried to compile the -- what I thought was stated 
most often.  The most frequently mentioned reasons.  And clearly there 
was lack of resources, especially from the developing countries, that 
said, "We need to get access to software or know-how or hardware, 
even," but as many of these also stated that we're waiting for DNSsec 
to mature.  They felt that the current version of DNSsec is not the 
ultimate, final, best version.  They were waiting for something better 
to emerge that would cover the current problems that DNSsec still has.

 Some others stated that they have projects that actually have a higher 
priority right now.  This is linked to lack of resources because they 
just simply didn't have the means to employ more staff to deal with it.

 And finally, several stated they will implement it as soon as the root 
zone has been signed, because they didn't see a point in having DNSsec 
without having the root signed.

 Oh, I will skip this slide because this is technical, and I just can't 
explain this to you, but --

 [Laughter]

 >>GABRIELLA SCHITTEK:  -- I will get some more expertise to deal with 
this, and on the on-line version which we will put up on our Web site, 
there will be some more explanations to this.

 This is another slide which I can't explain.

 So then we asked, so if you're planning to implement DNSsec, what is 
the planned time line?  And you can see most of the respondents want to 
do it within a year.  In fact, most of them actually had already 
started work -- to work on it.

 However, there were also many who said they don't know yet, and the 
main reason for why they didn't know was because they were waiting for 
-- there were three main reasons.  They were waiting for issues such as 
zone walking to be fixed.  Others said that they want to have some 
standardized software.  They're waiting for that.  And the third reason 
was, they want to have the root zone signed.

 Oh, this is the -- again, a slide that I can't explain.

 Then we asked how strategically important DNSsec was considered to be.  
This was, again, an open-ended question.  It was quite hard to compile 
the results because of the variety of answers, but these are what I 
think were the main -- mostly stated reasons.  Well, the main drivers 
and goals -- well, first of all, that it would improve the DNS security 
by ensuring the integrity of data transmission.

 Then many had expectations that the technology can improve business 
confidence on the Internet, and, in fact, many said that businesses had 
actively approached them to get this implemented.

 And many also stated that they hoped this would help against phishing, 
spoofing, and so on.

 Some of the obstacles the respondents saw was that, first of all, the 
root hasn't been signed.  Many registries thought that DNSsec was 
actually very hard and complex to understand for themselves, but also 
for the end user, of course.  But I was very surprised to see how many 
ccTLDs actually thought this was a very, very hard issue for themselves 
to understand.

 And finally, they also thought that the technology can overly 
complicate the registry/registrar relationships.

 So then we asked, "Is it important to you that the DNS root zone is 
signed?"  While the majority said yes, as you can see -- well, this is 
pretty self-explanatory.

 So then we asked who should be the signer of the DNS root zone and 
this is again very obvious what the answer was.  Almost 70% said they 
thought IANA or ICANN -- ICANN IANA should be the signer of the root 
zone.

 You see this table called "Other"?  No.  Yes.  Sorry.  Yes, "Other."  
Very often people under "Other" presented suggested models on how they 
would like to see it, and they were very often including ICANN IANA in 
those models as well.  They were models like ICANN IANA plus RIRs, 
ccNSO, GNSO, or ICANN IANA plus NGOs or ICANN IANA plus governments.  
So under "Other" this -- there's very often some kind of models which 
includes very often ICANN.

 Then we asked, "Should the ccNSO actively promote the deployment of 
DNSsec?"  Well, most did, but it was actually big -- surprisingly many 
who thought no, we should not.

 What I found out -- what I think was the reason for that was the 
formulation "actively promote."  Many said, "Well, the ccNSO should 
provide a platform but they should not actively promote it."  Or some 
people said, "Well, you should not actively promote it now when there 
is no standard software yet."  So I think that was the main issue.

 And then we asked, "How should the ccNSO promote DNSsec?"  Again, this 
was an open-ended question, so I just compiled what I thought was 
mostly mentioned.

 Most -- almost everyone said we should arrange regional workshops.  
Often mentioned was they should be in the language in the region, the 
main language of the region.  Another suggestion was that the ccNSO 
should push to get the root zone signed.  Some people thought we should 
compile information and produce a kind of brochure that explains how 
DNSsec works in an easy way, and how it -- what it would cost, for 
instance -- everything pro and con and so on.

 And finally, many people actually liked the survey and think -- 
thought that the ccNSO should more regularly do surveys like this and 
share the information.

 Well, that was the end of the survey but before I end, I have to say a 
few thank yous.  First of all, I have to thank the Swedish registry 
because they helped me formulating the questions.  I could have not 
done it without the Swedish registry.  So thank you.  [speaking in a 
non-English language] as you say in Sweden, and also have to thank many 
other people, people that helped me translating the survey, because we 
translated it into Spanish and French and we had many replies in 
Spanish and French as well, so many thanks to you.

 And these results will be up on our Web site, hopefully by next week.  
They will be commented -- the tables will be commented, the charts will 
be commented, and, yes, if you have any questions, that's -- you can e-
mail me.

 >>CHRIS DISSPAIN:  We're going to take some questions now.  Before we 
do, Steve, did -- Steve, was there anything you particularly wanted to 
say?  You don't have to at all.  I'm just -- I thought I'd give you the 
opportunity.

 >>STEVE CROCKER:  I'm speechless.

 >>CHRIS DISSPAIN:  Okay.  Good.  Excellent.

 [Laughter]

 >>CHRIS DISSPAIN:  Fantastic.  Are is there any questions?  Olivier 
had a question.shall I be the microphone fairy?  Thank you, Olivier.

 >>OLIVIER GUILLARD:  You're welcome.  Just one question.  How many 
cc's have responded that they planned to implement DNSsec within one 
year?

 >>GABRIELLA SCHITTEK:  This is percent, so it's not the actual number.  
If you want the actual number, I can count it for you, but as you can 
see, it's the majority.

 >>CHRIS DISSPAIN:  32% of 61.

 >>GABRIELLA SCHITTEK:  Or 33, 34.

 >>OLIVIER GUILLARD:  Okay.

 >>CHRIS DISSPAIN:  Roughly speaking.

 >>OLIVIER GUILLARD:  20.

 >>CHRIS DISSPAIN:  Yes.  Sabine.

 >>SABINE DOLDERER:  I have also a question, maybe also to the ccTLDs 
who want to implement it within one year and who are in the room, how 
many of you have already discussed this with your registrars?  How many 
of you have done tests with your registrars?

 >>CHRIS DISSPAIN:  Is there anyone in the room who is prepared to -- 
yep.  Okay.  So we have Keith.  Keith, do you want to take that one?  
Sabina would you mind passing the microphone to Keith?  Thank you.

 >>KEITH DRAZEK:  So I think the question was which registries have 
done --

 >>CHRIS DISSPAIN:  Could you say your name and where you're from?

 >>KEITH DRAZEK:  Yes.  I'm sorry.  Keith Drazek, with dot us and I 
think the question was who has done tests with registrars.

 [Speaker is off microphone]

 >>KEITH DRAZEK:  Yeah.  So approximately two years ago, the dot us 
registry conducted a DNSsec trial.  It was a production trial, so it 
was actually live, but it was a trial environment with one particular 
registrar that was interested in participating in DNSsec.  
Unfortunately that was the only registrar that we were able to identify 
that was interested in participating.  We actually initiated a second 
trial about a year ago, and again, the same registrar was the only one 
that was interested in participating.

 And the intent for our second trial was to try to broaden it to a 
wider range.  It was actually the same -- the same general process, the 
same testing, the same, you know, exchange of information, but we were 
hoping to broaden it to be a wider group.  And unfortunately we only 
had one registrar, the same registrar respond, so the challenge that 
we've identified is that there's not a whole lot of interest at the 
registrar level -- at least in our marketplace -- to participate in 
these trials, because they don't see the economic benefit of it.

 There's not enough demand, as we've heard, from their customers, from 
the registrants, from the user community, to draw the attention of the 
registrars into participating in these trials, so I think it's a 
question of the chicken and the egg.

 >>CHRIS DISSPAIN:  So can I ask you a question just for my 
nontechnical brain?

 Instead of sort of going up the tree for the moment, let's go down.  
If we were to introduce -- if we were to introduce DNSsec in dot au, 
how far down the hierarchy does it have to go for it to be meaningful?  
Does it have to go all the way down to registrants or does it top at 
the registrar level?  What --

 [Speaker is off microphone]

 >>KEITH DRAZEK:  I don't have anything to add.

 >>CHRIS DISSPAIN:  Okay.  So you just said it has to go down to the 
very end to make sense.

 >>SABINE DOLDERER:  I think in the long run, it has to go down to the 
very end to make sense and especially it has to be implemented at the 
user level that they really acknowledge the results or at least at the 
ISP level that they acknowledge the results.

 >>CHRIS DISSPAIN:  Right.

 >>SABINE DOLDERER:  And another question is what we have seen within 
dot de, a lot of registrars are using DNS software which doesn't 
support DNSsec at all.  Has somebody dealt with that too?  We have done 
actually also made a query to our registrars if they are interested in 
that -- in letting us do such a trial, and we didn't make a same 
assessment that there was not a very huge amount of interest in that 
part of the community.  I'm very astonished about the result, about the 
implementation within one year, which means that you have to be very 
far in the planning process.

 >>CHRIS DISSPAIN:  Yes, I was very surprised.  Steve wanted to say 
something and then the gentleman there and then Jay.

 >>STEVE CROCKER:  Thanks.  The point that you were making about it has 
to go to the end users, there are sort of end users in a way on this.  
On the client making the query and getting an answer back, that has to 
be integrated, of course.  On the registration side, I think this is -- 
you've pushed on a very, very important point about the registrars have 
to get involved and that will take a while to sort itself out.

 In my thinking about the registrars, two important things emerge.  One 
is that unlike a registry, you have multiple registrars.  It doesn't 
require all of the registrars to be client or to be capable of that 
because then the users can sort themselves out or the registrants can 
sort themselves out according to whether a registrar offers that.

 The other thing which is a bit more subtle, is that it makes a big 
difference where the name service for the registrant is and if a 
registrar offers the name service, hosting of the site, for example, or 
at least hosting of the name service, then the registrar or some other 
aggregator can sign the zones and do that on a mass basis for all of 
its customers so that there is essentially zero impact and no deep 
requirement for the registrant to have to modify his own systems or to 
know very much about it except possibly to check a box saying, "Yes, I 
would like this" and if there is a charge, being willing to pay it.  
But in terms of learning curve, in terms of impact on his business, in 
terms of all the things that are big drags, that can all be outsourced 
to a conflict provider.  I think that will be one of the interesting 
models that will likely emerge somewhere along the way.

 >>SABINE DOLDERER:  I agree with you on that, that it can be 
outsourced.  But on the other hand side, there is usually -- the 
parties will also talk to the registrants -- that that's our assessment 
-- are not very interested in offering it.  That's what we get as a 
result from our Technical Advisory Committee, from people we are asking 
from technical meetings when we are asking.  We receive a lot of "It's 
very interesting, yes.  We should be studying on it."  We should work 
on it and getting knowledge, informed people.

 Any time when it came to do -- we needed to, we should implement it.  
And who actually wants to sell it, the result is also very 
disappointing, I have to say.

 >> DANNY AERTS:  Hi.  My name is Danny Aerts.  I am responsible for 
dot SE.  Regarding interest from registrars may be interesting.  But if 
you look at our situation, we don't have many registrars interested. 
Right now we have six out of 200.  

 Then, again, if you -- let's say you take one step and you go directly 
to the end user, then we did surveys and then you see that both 
actually private users and companies are interested up to 60% in our 
surveys.

 So what we decided is we start with six registrants and we start with 
the companies that are interested and what you see right now is 
actually big companies and communities are pushing.  They go to the DNS 
operator and say, "I want to have it" so you get another type of 
situation, is that even though the registrar says, "no, thank you, this 
is a lot of hassle, I'm not going to do this," they are being forced in 
Sweden to implement now.

 If you have a nice customer like my regulator, they want to have it.  
So they go to their registrar and they say, "I want to have it."  "Oh, 
this is a lot of hassle."  "I want to have it."  And then it comes and 
they're on board.  And by doing that, all their customers are enabled.

 So I think you have to take that step from not only talking to your 
registrants, to be honest, a registrar is not my customer.  It is still 
the end user is my customer.  So you have to go all the way to the 
customers, the end persons.

 >>CHRIS DISSPAIN:  Thank you.  While I am passing the microphone to 
Jay, it occurs to me one of the things we need to make sure we do with 
DNSsec, if you are saying you want it to be customer driven from the 
end of the tree and people actually need to know what it does for them, 
because I suspect there is a complete lack of understanding.  I think a 
lot of people think it makes the Internet safe, well, it doesn't.

 So if you want your registrar to market it to registrants, they need 
to be marketing to the registrants by telling them what it does rather 
than the perception of what it might do.

 >> JAY DALEY:  I am going to slightly disagree with you.  

 >>CHRIS DISSPAIN:  Of course you are.  

 >>JAY DALEY:  To me expecting a high-level demand from registrars for 
a specific technology is wishful thinking.  If you ask the registrars 
do you want a secure Internet, then they're all going to say yes.

 If you ask the registrants, do you want a secure Internet, they're all 
going to say yes.  It is us as the experts in registries who have to 
tell them that DNSsec is a key component of making a secure Internet.

 >>CHRIS DISSPAIN:  Yes.

 >> Jay Daley:  You also have to promote them to them and you also have 
to implement it and correct the demand by doing that.

 >>CHRIS DISSPAIN:  I accept that.  Anyone else?  Thanks, Jay.

 Okay.  So we're going to publish the results, right?

 >> GABRIELLA SHITTEK:  Yes, that will be on our Web site hopefully 
next week and the technical comments will also be there done by someone 
more skilled than I.

 >>CHRIS DISSPAIN:  We're all going to be fairly busy over the next two 
or three meetings, I suspect, dealing with IDNs.  But we're not going 
to -- if we just do that on its own, that's going to get very boring 
and very silly.

 Would I be right in thinking that more discussion on DNSsec is 
something that we want to do over different points of view or is it 
something we've had enough of now?  Do you think we need to spend more 
time talking about DNSsec in all sorts of areas, technically, policy, 
everything?  Who thinks we need to talk some more about it?

 Wow, so who thinks that we don't need to talk some more about it?  So 
you're all asleep then.

 [ Laughter ]

 Who doesn't care?  Thank you very much, Eberhard.

 I guess the IANA working group is going to do some work on it.  We 
have an agreement that we would -- we had an agreement we would 
consider the RIPE and CC resolution that IANA, or whatever it was, 
should sign the root -- Sorry.  Yeah.  Do you want to grab that?

 >>PETER KOCH:  Peter Koch again, this time speaking -- channeling the 
message that the RIPE community gave.  Just to set the record straight, 
it was the RIPE community, not the RIPE NTC.  The RIPE NTC sent the 
letter in its function as the secretariat of the RIPE community.

 The second point is that the message was -- or the question was to 
ICANN to get the root signed.

 >>CHRIS DISSPAIN:  Correct.

 >>PETER KOCH:  Did not specifically say sign the root but just take 
care of it being signed.

 >>CHRIS DISSPAIN:  All right.  So one of the things that our working 
group is going to be doing is considering that.  So when we get -- when 
we talk about -- when we talk about it again in Delhi, hopefully we 
will be able to be a bit more specific about all of that.

 While I remember another logistical matter, tomorrow there is a 
strategic planning and accountability, transparency session -- full 
ICANN session at 3:30  that Patrick Sharry is running.  A number of you 
have said you would like to go to that.  I would like to go to that.

 If it is all right with you, we are going to shift the council meeting 
from 3:30 until 5:00.  So what we will do is we will finish in here at 
3:15 tomorrow.  And then go down to coffee and to the strategic 
planning meeting and then reconvene the council here at 5:00.  Okay?

 All right.  So now we're ready to go to the SSAC briefing for the GAC, 
except that we're about five minutes early.  So if we just kind of mill 
around until such time.  There is no time to do anything else in the 
five minutes.  If we just mill around and we will make a call as soon 
as the GAC opens up the room.  Judging by the normal course of events, 
it will probably be lunchtime before they're ready.

 Sorry, also, Gabby has lunch tickets.  Maybe we can usefully use these 
five minutes.  For those of you who would like to go to lunch, she has 
the tickets.

 Also, if you have not filled in the registration list with your name 
and stuff, please ask Gabby and please fill it in.  Thanks.

 (Lunch Break)

 >>CHRIS DISSPAIN:  So ladies and gentlemen, we'll get started again in 
about five minutes time.  I told the people at lunch we'd be starting 
at five past 2:00.

 Okay.  Please take your seats.  We're going to start.  Oh, that's for 
you, Julie.  Please start taking your seats.  In fact, please take your 
seats would probably be a better way of putting it.  Please take your 
seats out the door, yes.

 So ladies and gentlemen, we're going to spend the afternoon -- as you 
all know, we're going to spend the afternoon discussing IDNs but before 
we do that, I'm once again proving conclusively that there really is no 
such thing as a free lunch.  Keith Drazek.

 >>KEITH DRAZEK:  Hello?  Hello?

 >>CHRIS DISSPAIN:  You're on.

 >>KEITH DRAZEK:  Okay.  Just wanted to say that NeuStar's dot us 
registry was pleased to sponsor lunch today and I just want to 
introduce one of my colleagues, Rick Wilhelm, who will give a brief 
presentation on NeuStar and our various services.  Thanks, Rick.

 >>RICHARD WILHELM:  Thanks, Keith.  Hopefully they had plenty of 
coffee.  It's always one of the worst slots to ever draw in the 
speaking lottery is the right-after-lunch slot.  It's even worse than 
the right-before-coffee slot because at least everyone is anxious about 
getting to coffee, so hopefully there's plenty of caffeine and sugar to 
keep everyone awake.

 We're going to talk about a few things here, so NeuStar is the ccTLD 
registry for dot us but we also operate as you know dot biz and as a 
result, we sort of have some services that sort of go beyond where the 
traditional ccTLD operates, but since we are a ccTLD, we know the world 
in which ccTLDs live, and so we can offer some different kinds of 
services to help out in different ways.

 So these are all things that we'll give a brief overview here and you 
can approach any of the folks on the NeuStar team to talk about any of 
these.

 So we're going to talk about these things that are up on the slide:  
Launch services, IDNs, primary and secondary DNS things, as well as 
something that we have that's kind of innovative called a registry 
gateway.  So...

 So ccTLDs, of course, are far different, as everybody knows, than 
gTLDs.  Everyone here knows that.  They're really sort of a digital 
national asset that different countries operate and use in different 
ways.

 For some folks, it's purely a revenue source.  For other folks, it's 
about building local technical expertise.  For other countries, it's 
really about building up commercial capabilities or nonprofit 
capabilities inside their country, as it relates to the Internet.  So 
there's a lot of different ways that people handle their ccTLDs, and 
just as importantly, there's a lot of different variations in policies.

 Some ccTLDs are open to let anyone anywhere in the world register.  
Others are open if you have a presence in the country of some sort.  
And still others require a lot of very extensive and detailed 
documentation.  And there are some -- as a result, all these different 
ccTLDs have widely varying levels of registration activity.

 They also -- different ccTLDs have different ways they approach the 
registrar community.  Some of them function as registry and registrar; 
others are more in the sort of ICANN model; and others have only 
domestic registrars that are allowed.  So a lot of variability there.

 And obviously different countries have different levels of technical 
expertise and infrastructure capability.

 So as -- being a long-term player in the DNS space, NeuStar 
understands all these things, and so we're very aware of your context.

 So one of the ways in which we can help is with what we call launch 
services.  So launch services you might say, "Well, launch doesn't 
really apply to me because my ccTLD is already up and operational."

 And one of the things, though, that some ccTLDs go through an 
expansion or opening period where they're operating currently as 
possibly a multilevel space or they're opening up some other set of 
spaces in various ways, and so they actually go through a launch 
process.

 We went -- we did this in dot us where dot us, back in 2001 was just a 
hierarchical locality space and we opened up the second level of ASCII 
names for registration.  So we went through a sunrise and launch 
process.

 So as part of this, one of the things that we can help out with is 
working with you on policy development and talking about the various 
tradeoffs of that.  We can help with intellectual property claim 
services for -- help out with your sunrise process, as well as a 
regular sunrise process to have people apply for names and get them in 
various manners.

 Additionally, one of the things that's different about sunrise is -- 
launch services is that a sunrise is often followed by a land rush and 
this can require a registry to be able to handle -- a first come, first 
served land rush can require the registry to build infrastructure 
that's far in excess of what their normal operating capability -- our 
normal operating needs happen to be.

 So we can help out with these things, help you manage the land rush 
needs and such, too.

 And additionally, since we're also a gTLD registry, we have a very 
large community, a global community of registrars, so we can help you 
reach large numbers very quickly.

 So another thing that we're -- we have a lot of experience about is 
IDNs, as you're looking at expanding your name spaces into IDNs.

 In biz, we currently operate IDNs in nine different languages, all in 
a fully standards compliant manner.

 We most recently launched CJK, Chinese-Japanese-Korean and we've got 
the first gTLD implementation of CJK IDNs that use bundling and are 
compliant with the various policies that are in place by those three 
countries.

 We also operate -- and I have to conduct -- consult the list because I 
can never remember these.  We started doing IDNs back in 2004, and 
since then we've launched nine.  So we have German, Danish, Icelandic, 
Norwegian, Sweden, Spanish, Chinese, Japanese and Korean and so we're 
going to be adding more of those.  And so that's another area where we 
can add some capability to you.

 We know about bundling.  We know about reserved names and all sorts of 
things like that.  So we can help consult on those.

 We can also -- we're also looking at some advanced IDN applications as 
it relates to different registry model customizations that might be 
required to accommodate new IDN mechanisms, especially as the new round 
of TLDs is coming forward, and then we're also looking at some other 
things in the future as it relates to IDNA2000 and such, and then we're 
sponsors of an open source project called EchIDNA.  The primary author 
of that is in the back, Will Tan.  Most of you probably know Will from 
all of his good work in the IDN space.

 One of the other things that we offer are DNS solutions.  We currently 
provide primary and secondary DNS for a number of various TLDs, and 
presently we handle about -- we supply DNS for about 25 million domains 
out in the marketplace, and that round -- that turns out to be over 175 
billion queries a month.

 So we can, for your ccTLD, either do primary or secondary operations 
of that, and we have different ways that we can get those names into 
our DNS cloud.  We can either go in through a ixfr/axfr mechanism, sort 
of old school BIND compliant DNS, as well as we have a custom -- 
special XML API to link the two, your registry to our DNS 
infrastructure.  Our DNS network allows these changes to get pushed all 
the way around the world in about two minutes, quite literally, so if a 
name gets registered, gets handed over to the nameserver cloud, it will 
be all over the globe replicated in two minutes, so it gives you very 
fast capability, to be very responsive to your customer base.  We -- 
our TLD network sits apart from our enterprise network and this means 
that you don't have to worry about any issues relating to traffic 
overlap and such.

 And we can also do a lot of very interesting infrastructure things to 
give you, as a ccTLD operator, the ability to do the primary DNS and 
then have our infrastructure there that when you need to have capacity 
and bandwidth on tap, that we can do things with routing tables to 
enable our infrastructure to come on line and start soaking queries.

 And then we also do some other things in the area of DNSsec advanced 
features, IPv6 and ENUM and things like that.

 This is a map that shows our data centers all over the globe.  
Currently 14 of them.  You can see the list, look at the map.  We 
recently brought China on line, and then we're planning on going into 
South America, and then we've got some other things that are on the 
whiteboard but haven't been promoted to being on the slide deck.

 So...

 One of the things that we offer that's very different than other DNS 
implementations that you might be able to build out yourselves -- 
because ccTLDs approach us all the time and they say, "Well, why don't 
I just deploy my nodes around the world?"  Well, one of the things 
we've built and we really kind of pioneered is something called a DNS 
shield, and what this is is we put authoritative nodes -- DNS nodes -- 
directly in the -- on the network, inside the network, inside the 
firewall of leading ISPs.  You can see them listed up here.  These are 
some of those that we have.  We're working on adding more to this list 
all the time.

 And what this means is that these particular authoritative nodes don't 
get any queries from outside the Internet.  And so if your TLD is on 
our infrastructure, your zone data is inside the ISP's network.  What 
that means is that no matter how ugly it gets out on the open Internet 
with regard to DDOS attack and all sorts of other things, your DNS is 
inside the ISPs' network and that means that the ISPs can then manage 
the network such that it's always made available queries.  Because ISPs 
do a good job of managing DDOS attacks -- DDOS things originating 
inside their network.  It's the wide-open Internet that's more of a 
problem.

 So what this means is that these partners, your DNS on the -- no 
matter how bad DDOS storms get out on the Internet, your DNS with your 
ccTLD will always be available inside of these partner networks.

 So this is very important as it relates to ccTLDs' ability to stay on 
line during sort of general Internet problems.

 Here's a little picture, sort of a stick diagram of how this works.

 So we've got the end users down in the lower left-hand corner hitting 
the existing ISPs' recursive servers.  We stick a node inside of the 
ISPs' network, actually in their data center, cross-connected with 
Ethernet into their recursive servers, and then we inject updates via 
VPN from outside, from our infrastructure.

 Then the routing is -- the PGP routing is set up such that -- any 
cache routing is set up such that the existing recursive servers will 
favor these more local NeuStar private nodes that are inside the ISP 
network.  If that -- if that node has a failure, PGP takes over, flips 
out, and the queries will flip out onto the public Internet and hit the 
public node.

 So this gives you a great deal of robustness as it relates to your DNS 
infrastructure and it's really something that's unique that we provide 
on the market.

 One of the other things we offer is a registry gateway.  We're going 
to flip off of the resolution side and over into the registration side, 
and that's what the registry gateway is about.

 What this is is a mechanism whereby we can bring our community of 
registrars -- and we've got well over 100 registrars that we service 
out in the marketplace that are connected to us -- and then we can 
provide a mechanism where they come to this registry gateway.  This can 
do protocol translation and other services, and then send those 
registration operations on to your ccTLD.

 So NeuStar's not acting as the registrar; we're between the registrar 
and the registry, and give you, as a ccTLD operator, great market reach 
very quickly.

 So what this does is, it allows you to have specialized -- if you have 
specialized legacy protocols that your ccTLD needs to operate for 
various reasons, or wants to operate, you can open up your marketplace 
to this international community of registrars that speaks EPP.

 Additionally, we provide all the registrar support.  We handle all the 
-- all of their e-mail, their phone calls.  We do the billing, the 
invoicing and such, and we -- so we handle all that with the 
registrars, and you just get the money.  So...

 So here's a stick diagram of how this looks.

 So we see the domestic registrants and registrars on the top.  The 
international or foreign registrars and registrants in the bottom.  And 
then you can have the registrars connect to your registry as it makes 
sense, and then we will build a mechanism where the international 
registrars speak EPP to this registry gateway, that then does protocol 
translation and other operations, and goes ahead and sends those 
registrations on to the ccTLD registry.

 Your registry is authoritative always.  Any discrepancies are always 
resolved in favor of the ccTLD registry.

 Here's some success stories.  We have -- we currently operate two of 
these with CN and TW.  We -- CN, we launched first, back in late 2002.  
To date, we have -- we currently manage about 140,000 names as part of 
that, and there's 75 registrars, which is pretty good, that are 
connected via that.  And it's really helped to give CN NIC some good 
market reach.

 Additionally, we operate one for dot TW, and we did that one in early 
2004, not quite as big, 41 registrars connected and about 30,000 names.  
So...

 Then lastly, some additional things.  NeuStar's a company that's more 
than just registry and DNS operations.  So this -- what you see up here 
on this slide is some of our other services.  We can do private ENUM 
implementations, a lot of ccTLDs are involved in VoIP and next-
generation network operations for telephony.  We can help out with 
that.

 We offer mobile instant messaging through one of our operating units 
that used to be a company called FollowApp, very big in Europe.

 We also do resource administration for numbering and for telephone 
numbering and for SMS short codes, as well as we do -- we are very 
active in the number portability marketplace, currently providing 
number portability services around the globe.

 So that's kind of a brief overview of some of the services that we 
offer to ccTLDs, and like I said, there's a number of us from NeuStar 
that are here all week, so feel free to accost any of us in the 
hallway.

 Any questions about anything?  This is a quick 15 minutes or so, 
plowing through lunchtime fatigue.  Any questions that I can answer for 
anyone?

 >>CHRIS DISSPAIN:  Well, they can talk to you, as you said, all around 
the place.  So ladies and gentlemen, would you join me in thanking 
Richard, please.

 [Applause]

 >>CHRIS DISSPAIN:  And thank you very much for the lunch.  That was 
great.

 Okay.  So now starts the fun.

 I'm going to start with an overview and then -- okay.

 I thought I'd start with an overview of where we've got to on IDN 
ccTLDs and then we're going to go into some slides that we have on the 
various things that have been happening.

 So just to recap for everybody, we spent a long time at our meeting in 
San Juan discussing the issues paper, the questions paper that we 
prepared for the board in -- jointly with the GAC.  And we endorsed 
that paper, and that went to the board.

 We also discussed some of the answers to that paper in San Juan, and 
we then -- the board then passed a number of resolutions -- the ICANN 
board passed a number of resolutions asking the community to come back 
to it with answers to the questions, and with further work on the 
possibility of having a fast track or interim approach to IDN ccTLDs.

 Subsequently, the ccNSO council met and passed a resolution, taking 
the first step to running a policy development process.  Now, the 
reason they did that is because the council felt that the best way to 
answer the questions raised in the questions paper that went to the 
ICANN board, and, indeed, a whole -- a whole heap of other questions 
that may arise, was to do that in a formalized process of a policy 
development process under the -- under the ccNSO.

 However, the first step in the policy development process is the 
presentation -- is the preparation of an issues report, and part of the 
job of the issues report is to confirm that the work being proposed is 
actually within the scope of the ccNSO.  And so we have called for the 
preparation of an issues report.  We've appointed Bart Boswinkel the 
issues manager, because we don't think he has enough to do, and we have 
asked him to report back to us on several things.  Firstly, are these 
things that we currently call ccTLD IDNs or IDN ccTLDs actually ccTLDs 
based on the current descriptions in the bylaws or any other documents 
that he can find.

 Secondly, if they -- well, if they are, fine.

 If they are not, if they don't fit the description, then what needs to 
happen to make them fit the description, assuming that's what we want 
to have happen.

 And so therefore, that might involve the need for the policy 
development process to not just be looking at the overarching policy 
for IDNs, but also to be looking at some changes to the bylaws to 
accommodate the IDNs within the definition of ccTLDs.  And thirdly, is 
the development of policy in respect to these ccTLDs within the scope 
of the ccNSO, which I think that one's fairly clear.

 So Bart is working on that, and in a little while, I'll put up a slide 
-- I'll put up some slides on the indicative timing that these things 
are likely to take.

 At the same time, we -- the council talked about the fast track 
approach or the interim approach.  It's been called so many things that 
I -- I can't even remember now which one we finally decided on.  I 
think we decided on "interim approach."

 You'll remember that we discussed at length that there was -- we 
thought there might be a pressing need amongst a number of ccTLDs for 
the issue or delegation of an IDN ccTLD quickly and that given that our 
estimate is that the policy development process will take a minimum of 
two years and may take significantly longer if we decide that we think 
that a mandated list or some sort of authoritative list is necessary, 
that waiting that long was simply not going to be acceptable.

 And so we would investigate whether it was possible, in a limited 
number of cases, to issue, delegate, allow for application an IDN 
ccTLD.

 So the council resolved to bring to this meeting a discussion draft 
which we're going to talk about in a little while.  It resolved to 
bring to this meeting a draft charter for such -- for the setting up of 
a committee.  And it also resolved that I would send a letter to every 
ccTLD manager and ask them a series of questions to gather some 
information about IDN ccTLDs and the need for them.

 So the purpose today -- and in parallel to this, the Government 
Advisory Committee is also working on endorsing the document, the draft 
discussion document, effectively saying to the ICANN board, "Yes, 
please set up an IDN committee."

 So the first step, then, is to look at what the results were of my 
letter to ccTLD managers, and to consider those because that's the 
first step.

 Clearly if there is no demonstrated need for a fast-track approach, if 
there's no demonstrated need that a number of ccTLDs require an IDN 
ccTLD quickly, then we might as well just concentrate on the policy 
development process and not worry about the -- not worry about the fast 
track.

 So gabby?

 So here we go.  What's the first -- no, you go ahead.

 So the background.  We sent out -- I sent out the letter on the 5th of 
October to every ccTLD manager.  Now, interestingly -- and this is 
something that we'll talk about perhaps tomorrow or in the council 
meeting when we discuss IANA.  Interestingly, some 30 of those -- I 
think it was about 30 -- bounced.  So we need to put some kind of -- we 
need to talk about whether we should be putting some sort of processes 
in place to help IANA update the data for ccTLD managers.

 But leaving that aside, the questions were:  Do you believe that the 
local community in your territory has a pressing need for an IDN ccTLD?  
There was a whole background in this document.  Those of you who got it 
will remember there was an vast amount of background.  References to 
various links and so on.

 If so, is there yet agreement in your territory on the scripts and the 
string within the scripts for which delegation would be sought?  Could 
you tell us what they are?  And do you believe that the delegation of 
an IDN ccTLD under a fast track/interim approach would be of interest 
to your community?

 So there were 54 replies.  Now, this is looking at everyone's reply.  
The answer is:  Do you believe your local community in your territory 
has a pressing need for an IDN ccTLD?"  33% of the replies said yes and 
67% of the replies said no.

 But of course countries like Australia would reply no, we don't have a 
pressing need for an IDN, but that doesn't mean that we don't -- that 
we don't think that a fast track approach is important.  We don't have 
a pressing need for an IDN but we -- we think that the fast track 
approach actually is important.

 So just so that you know, the -- if you take the countries that 
responded who we could easily say -- thank you -- we could easily -- 
you spelled America wrong, gabby.  America is spelled with a c, not a 
k.

 >>GABRIELLA SCHITTEK:  Sorry.

 [Laughter]

 >>CHRIS DISSPAIN:  If you take out the -- yeah.  So this slide shows 
that 15 IDN -- 15 non-ASCII script-using territories in the Asia-
Pacific region, two in Africa, five in Europe, replied and said yes, 
they had a need for an IDN ccTLD.  None in Latin America, and none in 
North America.

 [Laughter]

 >>CHRIS DISSPAIN:  And the Arab working group on IDNs which represents 
22 states, Arab states, also replied "Yes, we have a pressing need."

 So if you take out the responses from territories like Australia that 
have no need for IDNs, and only look at the responses from territories 
who have scripts that would go into IDN, 82% of the people who 
responded said, "Yes, we have a pressing need for an IDN ccTLD."

 And 18% said no.

 The most -- if so, is there yet agreement in your territory on the 
scripts and the string within the script for which delegation of an IDN 
ccTLD would be sought?  And could you tell us which ones?

 The most frequently mentioned scripts were Arabic, Cyrillic and 
Chinese, but as you can see from there, there were other languages -- 
obviously other languages mentioned.  Demangari, Greek, Hindi, 
Japanese, and so on.

 So 33% Arabic, 17% Cyrillic, 11% Chinese, 39% other.

 Do you believe that the delegation of an IDN ccTLD would be of 
interest to your community?  Yes.  86%.

 Okay.  So questions on that?  Or comments on that?  We have a heap of 
other information.  We know, for example, we had letters from -- from 
China setting out what it was that they wanted in terms of IDNs.  We 
had the same from Russia, as I recall, and various other countries.

 It's pretty clear -- well, it's pretty clear to me, anyway, that 
amongst the territories that responded who have scripts that are non-
ASCII scripts, that they're saying, "Yes, we need a fast track approach 
to this."

 Does anybody want to ask anything or make any comment at this stage?  
No?

 Okay.  We will publish the survey.  We don't -- we're not going to 
publish the -- obviously the individual responses we had because we 
didn't say we would, so we won't.

 Can I -- can I take it, then, by the lack of questions or comments, do 
-- does the -- do the ccTLD managers in this room think that that is 
sufficient indication of a pressing need that would mean that we should 
certainly seriously look at ways of implementing a fast track approach?  
Does anybody think that that proposition is just a wrong proposition?

 [Speaker is off microphone]

 >>CHRIS DISSPAIN:  No, either, either, oats.  Sorry Roelof.  You don't 
want to miss a chance to speak, so --

 [Speaker is off microphone]

 >>CHRIS DISSPAIN:  As soon as I saw your hand go up, I changed the 
question.

 [Speaker is off microphone]

 >>CHRIS DISSPAIN:  Can we turn the mic on, please?  The roving mic?  
Thank you.

 >>ROELOF MEIJER:  It was a yes to your first question so it was a no 
to the second.

 >>CHRIS DISSPAIN:  So you think it demonstrates a need.

 >>ROELOF MEIJER:  Yes.

 >>CHRIS DISSPAIN:  So you think it demonstrates a need.  Does anybody 
think it doesn't demonstrate a need?  Eberhard, I should have known.  
Thank you.  There you are.  I'll even bring you the microphone.  How's 
that?

 >>DR. EBERHARD LISSE:  No, no.  I'm just against it.

 >>CHRIS DISSPAIN:  Oh, you're against it.  You didn't want to say 
anything.  Eberhard is against me.  I need the exercise so it's fine 
for me.  Did somebody else call?  No.  Okay.

 [Speaker is off microphone]

 >>CHRIS DISSPAIN:  Please come this way, Patricio.

 [Laughter]

 >>PATRICIO POBLETE:  Just something I was discussing with Oscar there, 
so he can share the blame.  It's a bit of a self-supporting conclusion.  
I mean in the sense that there is interest among those that are 
interested, so I think we need to --

 >>CHRIS DISSPAIN:  Well, no, that's not strictly true but --

 >>PATRICIO POBLETE:  No, but it's kind of a bit like that.  I mean, we 
should try to find a way to go beyond that, to -- how to assess if 
there is a pressing need.

 >>CHRIS DISSPAIN:  Well, if the -- clearly the people who -- clearly 
the people --

 >>PATRICIO POBLETE:  Yeah, I think how do you measure how pressing the 
need is.

 >>CHRIS DISSPAIN:  Well, it can only -- yeah.  Well, you can only do 
that -- I understand.  You can only do that on the basis that you ask 
people a question and you see what response you get.  But I guess we 
were -- this was never supposed to be an empirical study.  It was just 
meant to be trying to gather a little more evidence that our -- is that 
our intuition or our gut feeling was right, and that the -- and that 
the statements that were made with such passion by those countries or 
those territories who speak a language that uses a script other than 
ASCII were not just an individual person saying that.

 I think you would also -- so I -- I would argue also that even if you 
look at all of the responses, all of the 56 responses, 33% of the 
people who -- was it 33%?  Gabby?  Who said yes?  At the very 
beginning?

 Yeah, 33% of those said yes.  Now, it's not a forgone conclusion.  I 
mean at least one -- one Arabic speaking territory responded that no, 
they didn't think there was a pressing need for them and they've never 
been asked for one and they couldn't imagine why anybody would want 
one.

 But having said that, the responses from various other territories -- 
and I'm sure that, you know, Russia and China won't mind me mentioning 
them -- were fairly adamant that, "This is an important and immediate 
issue that needs to be dealt with."

 Having said all of that, of course, we don't know if it is even going 
to be feasible to do it.  But the question I'm asking right now is 
should we have a look if it is and see if it is.  The general feeling, 
I think, is yes.  So let's look at the timelines -- no, let's not do 
that.  Let's leave that until last.

 Let's look -- first of all, I just want to go over the PDP so that 
everybody's clear.  Has everyone -- has anyone got any questions on the 
full-blown policy development process?  We're putting together -- Bart 
sent a note to everybody today asking for volunteers for the steering 
group and I think we have those now.

 They will be coming from the council.  Yes, Bart?

 >> BART BOSWINKEL:  In order to avoid confusion, it is from the 
council.  The councillor will be on the steering committee.  The reason 
is there is more or less --

 >>CHRIS DISSPAIN:  Don't worry, it is fine.  We are going to have a 
steering committee of five councillors to guide this issues report 
through and get the issues report to us as soon as possible.  

 Could you put up Bart's track 2 slides, please.

 So this is the indicative timeline for the policy development process.  
The purpose is to recommend an overall policy for the introduction and 
use of IDN ccTLDs.  So the process is the issues report which Bart 
expects will be -- will take until May 2008 to complete.

 Now, the rest of these dates assume that the result of the issues 
report is that we proceed with a policy development process, okay?  So 
it is possible that the result of the issues report would be that we 
don't.  But assuming that we do, there would be an interim report from 
-- on the policy development process in October 2008, which I imagine 
is designed to coincide with an ICANN meeting.

 There would be a final report in January 2009.  Then there will be the 
ccNSO approval process, which would take from February to May because 
we have to have various public consultations, open debates and so on.

 And then we would go -- the goal would be to have the policy developed 
by the board -- ICANN board at its June 2009 meeting which hopefully 
will be somewhere where IDNs matter.

 >>ROELOF MEIJER:  Still matter.

 >>CHRIS DISSPAIN:  Still matter, that's right.

 And then implementation.

 I don't propose to spend too much time this afternoon working through 
anything to do with the policy development process.  The most important 
thing for us to do is to look at the fast track.  But I just wanted to 
open -- if anyone has any comments to make, they're welcome to do so.  
Okay.  We will come back to this for the other one.

 So can you go to the discussion draft now?

 What I'm going to do now is take us through the discussion draft on 
the fast track.

 Yes, did you want to ask a question?

 >> A quick one.

 >>CHRIS DISSPAIN:  Sure, no problem.

 >> STEPHEN DEERHAKE:  How does that timeline correspond with what we 
may see coming out of the gTLD community?

 >>CHRIS DISSPAIN:  It doesn't.

 >> STEPHEN DEERHAKE:  Are we going to have, like, the thousand names 
we are going to have to review?

 >>CHRIS DISSPAIN:  It does not.

 >> STEPHEN DEERHAKE:  There is no attempt to coordinate or anything 
like that?

 >>CHRIS DISSPAIN:  It cannot be done unless you prevent -- which is 
why I asked the question this morning, is it still intended that the 
new gTLD process will include IDNs in the first cut and the answer is 
yes.

 The goal, however, is to try to dovetail the fast-track approach to 
the gTLD release.  But that does not solve the problem of checking gTLD 
applications for issues.  But I don't think that the PDP is going to 
solve that problem either.

 The PDP is actually about the basis upon which they're issued.

 Okay.  So I think it's important that we go through this document so 
most of you, if not all of you, will have it on your computers.

 So we start with an introduction and that's, basically, in part what 
I've already said, but let's look at -- the paragraph that starts "in 
designing a process," in designing a process to develop and propose an 
interim approach, the following assumptions/requirements have to be 
taken into consideration.  The proposals for mechanisms have to be 
developed through a process which all relevant stakeholders have agreed 
upon.

 I want to say at this point, we will be discussing this in the body of 
the document.  But it is pretty clear to me -- and I should imagine to 
most of you -- that this is not a ccNSO policy development process.  
This is a created, suggested approach to deal with something outside of 
the policy development process because of a demonstrated need.  And, 
therefore, a different set of rules apply and it's also pretty obvious 
to me that this has to involve the other constituencies, the other bits 
of ICANN.

 You cannot, for example -- you could not, for example, expect the 
board to agree to issue an IDN on the fast-track approach without the 
policy being in place in a circumstance where there wasn't -- the 
current delegation procedures of IANA, for example, had not been met.

 In other words, you know, you got the ccTLD manager involved.  You got 
the government involved and so on and so forth.

 So we need -- the way we've designed this approach is specifically to 
endeavor to involve the people in ICANN who need to be involved in the 
discussion to ensure that actually what we end up with is acceptable, 
otherwise it just won't be acceptable.  But we can discuss that in a 
bit more detail in a minute.

 So we're saying the proposals have got to be dealt with through this 
process.  The outcome will need to feed into the policy development 
process obviously.  Transparency and predictability should be 
guaranteed, participation optimized and the proposals supported.

 So B, phase 1, is there a need for an interim approach?  Let's assume 
for the moment that we've said yes to that question, because we just 
talked about that.  So in the assumption that there is an interim 
approach, what are we suggesting?  What we're suggesting is that a 
committee be formed that is charged with the job of working out whether 
there are any feasible methods -- method or methods under which an IDN 
ccTLD could be issued to a territory.

 And in doing that, this committee is going to have to take into 
account a whole heap of things.  It is going to have to take into 
account that the issue of an IDN ccTLD in a fast-track or interim 
approach can only be done if its issue does not interfere with the 
policy process.  The easiest way to explain what I mean by that is to 
give you an example.

 One of the things we talked about when we were in San Juan -- in fact, 
it was talked about in the GAC session yesterday -- was -- or whenever, 
Sunday -- was how many IDN ccTLDs would a territory be entitled to?  As 
many as it wants?  Two?  We don't know.  We actually don't know the 
answer to that question.

 So it is one of the functions of the policy development process to 
answer that question.

 In order for an IDN to be issued under a fast-track or an interim 
approach, issuing more than one IDN to a territory has the effect of 
interfering with the policy development process because it assumes that 
more than one can be issued.  So when we've discussed this, we've 
always discussed it on the basis of a single TLD.

 Having said that, that's not written in stone.  The committee itself 
might come up with some really clever way of dealing with that.  So the 
reason for saying one is only because more than one, we think, is going 
to interfere with the policy development process.  But if the committee 
can find a way of avoiding that, then that's fine.  And to give you an 
example of that, one of the countries that we talked to about a fast-
track approach said we could not choose one because we have two scripts 
and we would be unable to make a choice between them.  Politically, it 
would not be possible for us to make a choice between the two scripts.

 So what we will say is we will not take part in the fast-track 
approach but we support it because we recognize that it's not fair for 
us to insist on something that won't work and stop it from happening 
for the benefit of other communities.

 So what I'm trying to do is build a picture of the boundaries that 
this committee -- if we set it up, is going to have to deal with.

 We've also said -- if I can find it.  We've also said that clearly 
there are existing poises and existing structures that need to be 
abided by.  So there is currently a delegation procedure that is used.  
There are some IANA guidelines on delegation that are used.  There are 
a set of GAC principles that sit out there and are -- have been 
referred to in the past by the board.

 All of these things -- the committee will need to take them into 
account in trying to find a methodology that will work for this fast-
track approach.  So it's not a foregone conclusion that they will 
actually be able -- they will actually be successful in coming up with 
this methodology or method.  At least we can try.  

 Any questions so far?  Okay.

 So part C.

 >>KIEREN McCARTHY:  There is an issue with gala tickets where there 
have been fewer tickets than people wanted.  So we have rejigged the 
setup at Sony Studios to get another 75 tickets.  We are presenting a 
wonderful opportunity to distribute these tickets.  We have devised a 
system which I'm sure everyone will loathe with equal measure, which is 
quarter past 3:00 at the registration desk, the first --

 [ Laughter ]

 >>CHRIS DISSPAIN:  They are going to be issued like gTLDs on a first 
come, first-served basis.  It won't be scrum, basically.

 >>KIEREN McCARTHY:  We are hoping this will be the first of the new 
gTLD process.  The first 75 people that can come to the registration 
desk with their badge and business card, we can provide with a ticket.

 >>CHRIS DISSPAIN:  Do they have to prove they haven't already got a 
ticket?

 >>KIEREN McCARTHY:  If you have a badge, it has been marked off.  
There was a system in place.  It just didn't work.

 >>CHRIS DISSPAIN:  Hands up all the people in the room who want to go 
and scrum at 3:15 for a ticket.  One, two, three, four, five.  

 No, Eberhard, you can't come.

 [ Laughter ]

 Five.  Okay, what are you saying, 3:15?

 >>KIEREN McCARTHY:  Although, I suspect because I have told everyone 
3:15, get in there at 3:10 would probably be a good idea.

 >>CHRIS DISSPAIN:  Can I make a suggestion that judging by -- can I 
suggest that at quarter to 8:00 this morning when the booth was due to 
open at 8:00, there was already a line.  Those of you who -- it is now 
five to 3:00.  Those of you who want to go and get a ticket --

 >>KIEREN McCARTHY:  This is competition at its finest.

 >>CHRIS DISSPAIN:  -- should go and get in the queue right now.

 >>KIEREN McCARTHY:  Sorry.

 >>CHRIS DISSPAIN:  Thank you, Kieren.

 All right.  So let's take it back -- let's take it back to the 
document for paragraph C.  In the event that a need for an interim 
approach is demonstrated in taking into account the assumptions and 
requirements it is suggested that the ccNSO, the GAC and other relevant 
ICANN constituencies recommend the board establish a committee to 
propose mechanisms to introduce a limited number of IDN ccTLDs in a 
limited time frame.

 The proposed methodology will need to be developed according to a 
predefined process which is accepted.  In order to assist with an 
informed discussion at the meeting here in Los Angeles, the council has 
requested some preparatory work for discussion.  So that included the 
stuff that I have already talked about on the chart that we will get 
to.

 The adoption of recommendation by the ICANN board and establishment of 
the IDNC, the formalities of that are simply that, if we agree to do 
this and the GAC agrees to do this, then a joint recommendation or two 
recommendations, one from each organization, goes up to the board and 
the proposal is that they will then set up this committee.

 So let's look at how we're expecting this committee to work.  
Development of feasible methodologies for interim approach.  The IDNC 
will be tasked with developing a methodology or a number of alternative 
methodologies for an interim approach.  That will be discussed by the 
relevant stakeholders, in particular by the ccNSO and the GAC and it is 
hoped it can be done at the ICANN meeting in Delhi.

 So the preparatory work is the IDNC develops feasible methodologies.  
It provides an initial report for public consultation, hopefully by the 
first of February, 2008.  We discuss that in Delhi.  We prepare an 
interim report from the Delhi meeting containing a review of all of the 
comments received.

 Now, if all of that happens -- and I have to say that we've already 
had an indication from the GAC that that time frame might be too tight, 
but, on the other hand, it might not be.  If all of that happens, what 
we will end up with is a report from this committee containing a series 
of recommendations.  I want everybody to be absolutely clear about 
this.

 The report from the committee is a report to the ccNSO and report to 
the GAC only if the recommendations the committee makes are acceptable, 
with those recommendations be made to the board?

 So if the IDN committee comes up with a recommendation for a fast-
track approach that we do not think will work or we do not think is 
acceptable on a consensus basis to the ccNSO, then that's it, it stops.  
They're not making a recommendation to the board.  They're making a 
recommendation to us.  You're looking puzzled.

 (Speaker off microphone).

 >>CHRIS DISSPAIN:  I have no idea.  The council might decide the 
members should vote.  I don't know.  That doesn't need to slow down the 
report itself.

 So I just want to make sure you're clear.  We're not handing control 
of this fast-track decision to a small group of people.  What we're 
doing is asking a small group of people to come back to us with a 
series of recommendations that we can talk about.  So we can debate 
those recommendations and we can play with them, et cetera.

 Now, I know that there is some disquiet among some ccTLD managers 
about the closeness of the GAC in this process.  I'm happy to talk 
about that.  My personal opinion is that this is the only way there is 
any chance of getting a fast-track approach agreed simply because the 
ICANN board is not going to -- the GAC has to be involved in the 
process.  Now, it's a struggle for the GAC to be involved in this 
process because they don't actually have the same way of dealing with 
things that we do.

 Those of you who are at the joint meeting with the GAC on Sunday will 
have seen that they are having to -- they're having to sort of stretch 
and change the way they do things to try and accommodate this.

 So when we look at the charter of the working group, we are going to 
need to make some changes to that in order to accommodate the GAC.  
Let's see if we can deal with the point about the GAC, if anybody wants 
to make any comments on that.

 Who has the microphone?  Steven.  I had see Paulos first.  Please say 
your name as you speak into the microphone.

 >> PAULOS NYIRENDA:  Thanks, Chris.  Paulos Nyirenda from (saying 
name.)  I just wanted to find out the work of the board committee 
reporting to the ccNSO.

 >>CHRIS DISSPAIN:  That's a really good question.  So because it is -- 
yes, what we want is effectively we want the board to approve this 
process.  It is not actually a board committee.  We want the board -- 
because the board passed the resolution saying would the communities 
please come back to us and give us a proposal for the fast-track 
approach, this is our proposal for -- sorry, this is our first step in 
the proposal for a fast-track approach.  So we're asking the board to 
effectively endorse this committee, but it's not actually a board 
committee, as I understand.  Am I right, Bart?

 In other words, Paulos, this has never been done before so we're on 
new territory here.

 >>BART BOSWINKEL:  You could argue the other way around as well 
because if you look at the design, you see more constituencies 
involved.  Now, somebody needs to appoint it and endorse the mandate of 
that group.

 >>CHRIS DISSPAIN:  That's right.

 >>BART BOSWINKEL:  And the only entity within the ICANN environment 
that could do it is the ICANN board.

 >>CHRIS DISSPAIN:  Yes.

 >>BART BOSWINKEL:  That is another reason to have the board appointed 
and endorsing the process.

 >>CHRIS DISSPAIN:  Correct, it doesn't make it a board committee 
because the board committee has a different structure.  That's fine.

 So Hilde was next.

 >>HILDE THUNEM:  Hilde Thunem from the Norwegian registry.  I was at 
the GAC meeting yesterday or Sunday.  I mean, jet lag, it starts to 
blur.

 I think the thing they had most problems with was for them there is no 
way they can pick five people to represent.

 >>CHRIS DISSPAIN:  That's correct.

 >>HILDE THUNEM:  But actually that's the same in the ccNSO.  I 
wouldn't be happy with having somebody that were representing Europe 
and voting on behalf of all of Europe or all of Africa or whatever.

 So my suggestion would be to -- unless we're very married to the word 
"committee," I would suggest calling this a working group and removing 
the sort of voting members, non-voting members because they're not 
going to vote anyway, they're going to produce a report.

 >>CHRIS DISSPAIN:  Absolutely.

 >>HILDE THUNEM:  And make it really clear that they are working on 
producing something we will then either support or not.  They're not 
there representing any party.

 >>CHRIS DISSPAIN:  Thank you.  We are taking the voting thing out.  In 
fact -- Did you have another version of the chart or not, Bart?

 >>BART BOSWINKEL:  Yeah.

 >>CHRIS DISSPAIN:  We are taking the voting thing out.  We are quite 
flexible on numbers except that I don't -- it is important that we try 
to keep it manageable.  If there is no voting, it doesn't matter 
because you simply say these documents will go out.  People will 
comment on them, et cetera.  So I agree.

 And I think we've actually dealt with that.  This draft that I am 
going to put up in a minute hasn't been changed but it will be changed.  
Does anyone else have anything they want to add at this juncture?

 >>BART BOSWINKEL:  Maybe I should explain.

 >>CHRIS DISSPAIN:  Come on and explain into the microphone.

 >>BART BOSWINKEL:  Explain why they're called voting members.

 >>CHRIS DISSPAIN:  They weren't all voting members.

 >>BART BOSWINKEL:  If you look at the membership of that committee, 
you'll see two people from ICANN as well.  In order to make very clear, 
the role of the ICANN staff on that committee is completely different.  
We came up to voting.  You could do it the other way around as well and 
that will be probably in the next --

 >>CHRIS DISSPAIN:  We need to sort that out now this afternoon and get 
a fresh draft.

 >>BART BOSWINKEL:  You could call them nothing --

 >>CHRIS DISSPAIN:  Just say they are the members of the committee and 
the committee will reach a recommendation by consensus.

 >>BART BOSWINKEL:  And the ICANN staff is the advisory.

 >>CHRIS DISSPAIN:  That's fine.

 Yes, Bill.

 >> BILL SEMICH:  I agree with Hilde's recommendation that this become 
a working group and not a committee.

 >>CHRIS DISSPAIN:  Not a problem, thank you.  

 I think that actually -- I'm less concerned about the actual words but 
I understand the reason why.  That's not a problem.

 It will suit everybody, I suspect, including the GAC to -- was there a 
particular -- Bart, could you remember, did the staff have a particular 
name in mind?  I can't believe this actually matters but apparently -- 
not the part about working group or committee.  Apparently there is 
some problem with IDN or something.

 >>BART BOSWINKEL:  Within ICANN staff itself, there was the same type 
of debate.  The IDN committee was so often used, the ICANN staff came 
up with the term I call "the nation group" because this is what they 
actually do.

 >>CHRIS DISSPAIN:  Since we all use the term "working group" and we 
know what that means, I think we stick with that, shall we?

 >>BART BOSWINKEL:  That's fine.

 >>CHRIS DISSPAIN:  Okay, good.  Gabby -- I'm sorry.  Siavash.

 >> SIAVASH SHAHSHAHANI:  You had a rigid composition for that 
committee or working group.  Are you still sticking to that like you 
had chairs of various ICANN committees coming in?

 >>CHRIS DISSPAIN:  Yes, to a degree.

 >> SIAVASH SHAHSHAHANI:  My comment is that I have been on ALAC and I 
know that ALAC is a very complex group, different people there 
represent different interests -- at-large interests and not the chair 
is necessarily interested in being involved in IDNs.  Sometimes they 
appoint people from outside to these committees.

 >>CHRIS DISSPAIN:  Well, the point is --

 >> SIAVASH SHAHSHAHANI:  So I don't know how you plan to do this.  Do 
you want to stay in that rigid composition, or do you want them to send 
delegates to this group?

 >>CHRIS DISSPAIN:  I want them to appoint their chair because the 
chair has been elected and the chair should have the necessary skills 
to be able to represent their community and not push their own -- 
necessarily their own view and be able to report back with a degree of 
authority.

 I don't want a circumstance where time is taken up by a particular 
community deciding it is going to take them -- they got to figure out 
who is on point and the person who gets appointed is the person with 
the loudest voice who may be the person who has the most vested 
interest.

 I'm not saying any of that is true.  I am just saying the reason we 
took the decision to suggest to you all was that we thought it was 
important that people had -- that we had the chairs.

 Now, it does say, too, "the chair and," so there is scope for another 
person from the ALAC and another person from the GNSO.

 And, frankly, if either of those organizations came to us and said, 
look, we actually think -- you know, this person really should be on, 
they can really help, this is supposed to be a process that we all work 
together on to try to figure out a solution.  So we're not going to be 
completely closed about it and the documents -- documentation will all 
go out for consideration, consultation anyway.

 But there has to be some sort of management structure, otherwise it 
simply won't work.

 So that's why we've done it, but there is -- yes, there is some 
flexibility.

 I mean, you know, we've already said the GAC has already said we can't 
make five, because it doesn't work for us and, you know, et cetera.  My 
guess is that -- is that this will probably end up working much the 
same way that the joint GAC/ccNSO questions thing worked which was 
effectively that three or four of us did some work and then sent it out 
to everybody, and then everybody commented and we got it back and 
that's probably what will happen.  Do I have any other questions right 
now?

 No.  Okay.  So can we put up the charter?

 I wonder how the queue is going down at reception.  10 past now.  I 
saw Eberhard has left, so --

 [Speaker is off microphone]

 [Laughter]

 >>CHRIS DISSPAIN:  Yeah.  No, that's all right.  I'm going to suggest 
to Kieren that we just need to keep doing this and eventually the room 
will just be full.

 [Laughter]

 >>CHRIS DISSPAIN:  Okay.  So the charter is somewhere here.  Here we 
are.

 Let's look at the -- okay.

 So the purpose is to meet near-term demand, gain experience in dealing 
with IDNs as ccTLDs and to inform the Country Code Policy Development 
Process launched on the 2nd of October.  Aimed at creating an overall 
policy and interim approach to introduce a limited number of IDN 
ccTLDs.

 The purpose of the working group is to develop and report on feasible 
methods, if any.

 Now the scope.

 The IDN ccPDP is intended, if initiated, to develop overall policy for 
IDN ccTLDs.

 The scope of the IDNC -- which for the sake of this discussion I'm 
going to continue to call the IDNC but we all know we're going to 
change the name -- is limited to developing feasible methods for the 
interim introduction of a limited number of IDN ccTLDs that do not 
preempt the outcomes of the PDP.

 In considering feasible methods, the IDNCs should take into account 
and be guided by the overarching retirement to preserve the security 
and stability of the DNS.  Compliance with the IDNA protocols, input 
and advice from the technical community in respect to the 
implementation of IDNs, and current practices for the delegation of 
ccTLDs.

 If issues become apparent to the IDNC that are outside of its scope, 
then the share should inform the issues manager -- PDP issues manager 
of the issue so that it can be taken into account in the PDP.  Because 
we are anticipating that the -- some of the work that this working 
group does will actually throw out -- throw up questions that we 
haven't thought of yet that need to go into the PDP.

 Now, membership.

 We'll obviously need to play with this membership, but we need to add 
the quite sensible suggestion from the GAC that Security and Stability 
Advisory Committee should appoint somebody, and we need to -- to figure 
out some sort of wording that works for the -- for the GAC and for us.

 The processes for the development of feasible methods.  So the initial 
report is published for public consultation on a method or alternative 
methods.  The consultation should include a public discussion with 
relevant stakeholders at a designated ICANN meeting, which we'll get to 
in a minute.  Then there's -- at the end of the public consultation 
period, there will be an interim report which contains a review and 
analysis of comments made on the initial report, so we have a first 
report, initial report, then we have a comment period, we have a second 
report, the interim report.

 So -- and that will look at the comments that were made on the first 
report.

 And then there's another period, and considering its recommendations 
for a final report, the IDNC will seek to act by consensus.  The 
consensus view of the members shall be conveyed to the GAC and to us.  
If a minority opposes a consensus position, then that position will be 
incorporated in the report.

 We then look at the report.  We decide if we like it or not.  And if 
we do, it goes to the ICANN board.

 The time line -- this time line is the same as the one in the slide -- 
what the hell was that?

 [Laughter]

 [Speaker is off microphone]

 >>CHRIS DISSPAIN:  Okay.  It sounded like an airplane, low-flying 
over, though.

 Okay.  So this is the suggested time line for this process.  Publish 
the initial -- so the IDNC working group will publish the initial 
report on the 25th of January.  Public comment period 25th of January 
to 15th of February.  Then 15th of February -- so that includes the 
ICANN meeting in Delhi.  Okay?

 Then the interim report 9th of April.  Public comment on the interim 
report 9th of April to the 7th of May.  Final report 4th of June.  The 
GAC and ccNSO considerations of that final report 4th of June to 25th 
of June, which includes Paris.  ICANN Paris.

 And the board -- and if we decide to make the recommendation, it goes 
to the board at the Paris meeting.

 Now, I don't know if the GAC is going to be able to work with that 
time line.  We don't even know if the GAC is actually going to be ready 
to sign off on this process at this meeting, although I'm hopeful that 
they will be.

 What we do need to do, Bart, while I remember is we should get a 
redraft of it as soon as possible so that they can consider it, okay?  
The charter, that is.

 Questions.

 Okay.  What we're going to do now is we're going to take a break for 
coffee.  We've got 15 minutes.  It's, I guess, downstairs again in the 
big room.  Yes?  Roelof.  We're going to come back to this after the 
break.  I haven't closed the discussion down.

 >>ROELOF MEIJER:  I just wanted to make a suggestion on the document 
that you just showed.

 >>CHRIS DISSPAIN:  Yes.

 >>ROELOF MEIJER:  You mentioned -- you call it an interim -- what is 
it?

 >>CHRIS DISSPAIN:  Interim approach.

 >>ROELOF MEIJER:  Interim introduction, which suggested that it is a 
temporary introduction.

 >>CHRIS DISSPAIN:  Okay.

 >>ROELOF MEIJER:  I would suggest that we stick to calling it a fast 
track --

 >>CHRIS DISSPAIN:  Okay.

 >>ROELOF MEIJER:  -- introduction because that would also remind us of 
-- that one of the main purposes of this whole thing is to do it 
quickly.

 >>CHRIS DISSPAIN:  That's a very good point.  Yes, we can do that.

 Okay.  So let's take a break.  We're going to come back and carry on 
talking about this.  Let's be back at 25 to 4:00.  25 to 4:00 back in 
the room, please.

 [Break]

 >>CHRIS DISSPAIN:  Ladies and gentlemen, please start taking your 
seats.  We are going to carry on.  Gabby's just pointed out to me that 
America is correctly spelled in Norwegian.

 [Laughter]

 >>CHRIS DISSPAIN:  And Dutch.  And so -- and Swedish.

 [Speaker is off microphone]

 >>CHRIS DISSPAIN:  And probably in German as well.  Not in German.

 [Speaker is off microphone]

 >>CHRIS DISSPAIN:  In deep Tennessee, yeah.  So in acknowledgment of 
the fact that we're talking about IDNs, I withdraw the slur on gabby's 
spelling ability.  Unreservedly withdraw the slur on gabby's spelling 
ability.

 I think we might wait another couple of minutes just for some others.  
Do you want to go somewhere Margarita?  We'll give it another couple of 
minutes.

 [Speaker is off microphone]

 >>CHRIS DISSPAIN:  That is an excellent idea, Patricio.  Face the 
camera when you speak.

 Okay.  We'll get going.

 All right.  I guess what I'd like to do now is we've kind of gone 
through the document and Bart is going to do a redraft and I just want 
to run through the changes that we're going to make.

 We're going to change the name to a working group.

 We're going to take out voting.

 We're going to take out fixed numbers of people representing.

 We're going to change the definition -- the description from "interim 
approach" to "fast track approach" and if we've used "interim" in any 
other capacity, we'll change it to "fast track."

 Did I forget anything else?  Anything?  Sorry?

 We're going to add the Security and Stability Advisory Committee as a 
supplier of a member of the working group.

 I think that just about covers it, and I don't think any of that is 
problematic or contentious for us.

 So what I would like to do is actually to see if we can move on from 
this topic to talk about gTLD -- new gTLDs because we have a particular 
issue with new gTLDs, so can I ask for any objections in the room -- if 
at the council meeting tomorrow I say, "There was a consensus amongst 
the members in the room" --

 >>BILL SEMICH:  Yes, Bill.  I'll speak loudly.

 >>CHRIS DISSPAIN:  No, no.  You need the mic, Bill.  The Webcast can't 
hear you if you don't use the mic.

 >>BILL SEMICH:  It's a petty point but it's an important one.  This is 
a document, I believe, that refers to the GAC is a constituency.

 >>CHRIS DISSPAIN:  Yeah, we can change that.

 >>BILL SEMICH:  And I think it would help things if we could change 
that so something for a more general Gary --

 >>CHRIS DISSPAIN:  An advisory group.  If we call them what they are.

 >>BILL SEMICH:  In the language itself, there's a reference to the GAC 
and other constituencies, quote-unquote.

 >>CHRIS DISSPAIN:  I agree, yeah.

 >>BILL SEMICH:  If we could just change that to interested parties and 
not mention the GAC or other constituencies.

 >>CHRIS DISSPAIN:  I'm happy with that.  Just so we're clear, the only 
document that is actually a public document in the sense that it will 
go to the -- we're going to send -- what are the sending board, Bart?  
A resolution and just the charter?  They don't get the discussion 
document, right?  I mean they've seen the discussion document but --

 [Speaker is off microphone]

 >>CHRIS DISSPAIN:  They're voting on the charter, okay.

 >>BART BOSWINKEL:  If they need to vote, they need to vote on the 
charter.

 >>CHRIS DISSPAIN:  That's fine.  Okay.  So if I say tomorrow at the 
council meeting that the consensus of the people in the room today was 
that we should recommend to the ICANN board that this IDN working group 
is formed and that the charter as amended by Bart -- I've discussed 
everything we're going to -- change is adopted, is anyone going to have 
a problem with me describing that as a consensus view?  I know there 
may be people who disagree with it, but does anyone think we do not 
have consensus?

 [Speaker is off microphone]

 >>CHRIS DISSPAIN:  Well, the council will do that, Dotty.  The council 
will do that tomorrow.

 [Speaker is off microphone]

 >>CHRIS DISSPAIN:  Do you actually want me to do a members vote 
because if I do that, then I've got to sign up who is -- who's a 
member, isolate who the members are, what do you want me to just ask 
the managers in the room?  What would you like me to do?

 >>DOTTY SPARKS de BLANC:  Well, I'm only addressing the fact that 
we're being Webcast, and I think we should do it properly according to 
rules of order.

 >>CHRIS DISSPAIN:  Okay.  Why don't we do this.  Why don't we -- why 
don't we do this:  Why don't we get Bart to redraft the document that 
he's going to do, get the document posted to the list tonight, get -- 
come to this tomorrow morning at a particularly convenient time during 
our sessions tomorrow morning and everybody will have had a chance to 
look at the document again.  That's the charter again.

 And I'll ask the question formally at that point and then we'll take 
it to the council meeting in the afternoon.  Is that okay?  Is that 
okay with you, Dotty?  Okay.  Bart, you're okay with that?

 [Speaker is off microphone]

 >>CHRIS DISSPAIN:  Excellent.  Good.  So I want to move on now to talk 
about gTLDs and very specifically new gTLDs and very specifically one 
thing, which is that the current recommendation -- and let's be clear.  
This is their recommendation.  They have completed their policy 
development process.  It has gone to the board and the board is 
intending to vote on this on Friday.

 Now, one of their recommendations is that there are no -- is that the 
reserved list is very, very small.  It's www whatever.  I can't 
remember the few things that everybody would put on their reserved 
list.  But very specifically, there is a recommendation that no 
geographic names be placed on the reserved list.

 Now, that does not mean that geographic names are available for gTLDs.  
It just means that they're not on the reserved list.  And as we know 
this morning from talking to Vint, the current -- the current intention 
is that a list of applications for gTLDs would be published and every 
person, every country, every territory, every management organization, 
every ccTLD will look at the list and will say, "We object to this 
because it's the name of our country" or "We object to this because 
it's a significant geographical location in our country."  So just to 
take Australia as example, I suspect that if somebody applied for a 
gTLD dot great barrier reef -- why anybody would I don't know but if 
they did, I suspect that the Australian government would be somewhat 
concerned to ensure that that did not end up as being a commercial 
gTLD.

 Perhaps more likely and more importantly is if a -- is if a gTLD was 
applied for for Uluru which is the aboriginal name for Ayers Rock.  I 
mean that would be extraordinarily difficult for the stage government 
to deal with.  They would have to object.  Now, of course that assumes 
that they know and it also assumes that they also understand the word 
because I've just used two English words for ASCII gTLDs but we're also 
going to be talking about IDN gTLDs and so therefore, I as the ccTLD 
manager of Australia might be faced with a list of 300 gTLD domain 
names in languages that I don't even recognize, and I have to go and 
find someone to tell me what that actually means and not just what it 
means but what it could mean, and not just what it could mean but what 
it sounds like, and not just what it sounds like, but what it -- and so 
on and so on and so on.

 Now, the reality is Australia could probably do that.  The U.K. could 
probably do that.  Norway could, Germany could.  But I suspect that 
there are a number of countries who would struggle to have the 
resources and the money and the access to people who speak the 
languages to enable them to do that.

 Now, Hilde made an extremely good point this morning -- Hilde always 
makes extremely good points but this was an extra special extremely 
good point, that we could just -- we already have a list.  Now, it's 
not the most satisfactory solution in the world, but it exists.  And it 
exists, as I understand it -- exists in the sense that there are name -
- there are translations into all sorts of different -- doesn't every -
- doesn't every territory have an official -- or certainly every 
country has an official translation of its -- do you know?  You'd know 
this, Anna Beth, wouldn't you?

 >>ANNEBETH LANGE:  Hello, everyone.  I am Annebeth Lange.  I've been 
working with the GAC for seven years but now I've changed field and 
come over to your camp and working for the Norwegian registry.

 >>CHRIS DISSPAIN:  And it's much more fun over here.

 [Applause]

 >>ANNEBETH LANGE:  I completely agree with what Hilde said today, but 
it's very important to be careful about what we say about the lists, 
because we have the ISO3166 list with the two-letter codes.  That's one 
list.  And they have another list, 3166 stroke 1, and in that list, 
it's a few so-called official names -- country names, and, for example, 
in Norwegian it is Norway and [speaking in a non-English language] and 
that's it.

 >>CHRIS DISSPAIN:  Yeah.

 >>ANNEBETH LANGE:  And so I think we should be clear that it's the 
territories, and it's the list with the two-letter codes that forms the 
thing we go out from.

 >>CHRIS DISSPAIN:  Yes.

 >>ANNEBETH LANGE:  And then all the national descriptions of that 
territory, in whatever script, should be the decision of the government 
or the local Internet community, if they want it or not.

 And if the gTLDs have a stroke there and just take the clear cases 
that it's not a dispute about, they have more than enough to start 
with, and then after the PDP, perhaps we need -- we reach a common 
agreement of what's what.

 So my fear is that they really are so eager to grab it all that in the 
time we have finished our PDP --

 >>CHRIS DISSPAIN:  Yeah.

 >>ANNEBETH LANGE:  -- the grass has been eaten already.

 >>CHRIS DISSPAIN:  Yeah.  Can I just ask a quick --

 [Speaker is off microphone]

 >>CHRIS DISSPAIN:  The gTLDs.

 >>ANNEBETH LANGE:  No, the gTLDs.  They -- of course I understand 
their point of view.  They want as many gTLDs as possible.  It's money.  
And ICANN wants to register gTLDs.  But we have to fight for our rights 
as well.  Thank you.

 >>CHRIS DISSPAIN:  Can I ask a question, then?  The easy thing is to 
say, in ASCII, every listed country in the -- or territory rather in 
the ISO3166 list plus the exceptions are reserved.  That's easy.  I 
mean, you can do that -- you could do that like that.  The problem is 
how do you -- what methodology do you use to decide what should be 
reserved in Arabic for Australia or for Norway?

 >>ANNEBETH LANGE:  Of course that's -- that's a problem.  I know that.  
But the example that was raised when the board was here today that "I 
hate Australia" or --

 >>CHRIS DISSPAIN:  Yeah.

 >>ANNEBETH LANGE:  -- that kind of things, of course that has nothing 
to do with this.  I really mean that.  That, you have to object.  On 
the --

 >>CHRIS DISSPAIN:  Of course, yes.

 >>ANNEBETH LANGE:  -- usual courses, but it will always be some kind 
of doubt about the scripts and how to -- the different names of all the 
country codes and territories, but if we have a general principle that 
they should leave the territories, let them be.  They can take other 
places and other things.  It's more than enough to take from.  And if 
they take a town that we don't like them to take, okay, then you can 
object.

 >>CHRIS DISSPAIN:  Sure.

 >>ANNEBETH LANGE:  But at least if we can take care of the territories 
we have one place to start.

 >>CHRIS DISSPAIN:  I understand.  But I'm -- I believe I -- okay.  I 
believe I could walk into a meeting tomorrow and convince them that 
they use the ISO list and block the ASCII names.  I would -- I have no 
idea how I would sell some methodology for blocking the country names 
in different scripts because I've got nothing to -- I -- there's 
nothing to hang that on.  I don't know what to use as a reference 
point.

 And that's why we're struggling so much with this anyway as a policy 
development.  Hilde?

 >>HILDE THUNEM:  There isn't, I think, the very easy -- well, I'll 
look towards the Webcast this time.

 There isn't a very easy answer.  If there had been, we wouldn't have 
been struggling with the ccPDP, we would just be starting the process.  
But I think what you might say is that the general principle is that 
the ccTLD is the territory, any description in different languages of 
that territory is an IDN ccTLD.  That's the principle.  And then if 
you're talking about process, we might then ask that the ICANN staff, 
which would have to process all these 2,000 applications anyway, and 
presumably have a look at the IDs behind and get some idea of whether 
this is actually a territory name or the Indian word for frying pan or 
whatever, that they could alert the ccTLD if the -- if this seems to be 
a description of the territory.

 So not a perfect solution, definitely not a solution that I can -- 
would be very happy with or the gTLDs would be very happy with, but 
even just stating the principle that we actually believe that the 
territory, the description of the territory should not be taken by the 
gTLDs would possibly help.

 >>CHRIS DISSPAIN:  Okay.  Could we consider -- could we consider the -
- I think I'm saying the same thing as you, only slightly differently.

 Could we consider asking that -- it's one thing to say if you get an 
application in Arabic for whatever it might be and you realize that 
that is actually, you know, Norway or whatever, then you're going to 
tell Norway.  But that -- apart from anything else, that involves a 
subjective judgment to a degree.  I wonder whether we could suggest a 
differentiation be made between gTLD and IDN gTLD applications, in that 
IDN gTLD applications are perhaps communicated out in a slightly more 
push way, rather than just publishing -- presumably what will happen 
with the gTLDs, they'll just publish a list on the Web site that says 
"These are the applications that we've had and please object if you 
have a problem with them."

 I'm just wondering whether we could perhaps talk about some sort of 
different methodology for IDNs that meant that they were pushed to us, 
and, you know, we were given a specific instruction from ICANN to, you 
know, please respond by this date, formal deadlines, et cetera.  Hilde?

 >>HILDE THUNEM:  It would possibly -- or it would help, but it would 
still not solve the problem for a lot of ccTLDs that today, for 
example, didn't get your e-mail on the survey because their e-mail 
address bounced.

 >>CHRIS DISSPAIN:  Yeah.

 >>HILDE THUNEM:  And then two years later, come along and find that 
the language has been -- the language code for their country has been 
taken by a gTLD --

 >>CHRIS DISSPAIN:  Yes.

 >>HILDE THUNEM:  -- and they weren't able to discover it and nobody 
thought to actually look after them during the process.

 So possibly a practical work-around to ask people to do that, but I 
think also making the principle statement like the GAC sometimes makes 
a principle statement saying subsidiarity is the main principle here.  
I would say that we he should make a principle saying that description 
of a territory is an IDN ccTLD and should be treated like that.

 >>CHRIS DISSPAIN:  Okay.  Anyone else want to add something.  Desiree, 
did you -- you were...

 >>DESIREE MILOJHEVIC:  Okay.  So good questions.  Maybe just two 
things.  One is --

 >>CHRIS DISSPAIN:  Desiree, could you just introduce yourself?

 >>DESIREE MILOJHEVIC:  Desiree Milojhevic, wearing multiple hats.  Dot 
gi.  

 So one thing that you asked, and I think Hilde tried to make a 
starting point, to use a theory -- to use the -- would a territory be a 
good starting example?  I think it's a good question because if gTLDs 
are going to apply for strings, IDN strings, some of the country codes 
would not be able to abbreviate it to a two-letter character, like 
Arabic.

 >>CHRIS DISSPAIN:  That's right.

 >> So that's going to cause a lot of confusion.  And secondly, maybe 
just a clarification, if I haven't heard it earlier, whether ccNSO 
working group actually has a liaison with ISO 3166.  Is that something 
you plan to do or --

 >>CHRIS DISSPAIN:  That would be the -- that would be on the policy 
development process side and yes, we would endeavor to -- we don't, but 
we will endeavor to organize that.

 >> Good news, thanks.

 >>CHRIS DISSPAIN:  What we have, of course, is we have the ISO 
challenge, which is which bit of ISO do they talk to, because they 
don't always seem to agree with each other.

 Okay.

 What I'm trying to do is see whether we can get to some kind of letter 
that we can send to the board on behalf of the ccNSO.  Roelof, you had 
a comment to make?

 >>ROELOF MEIJER:  Just to make sure, first, if I still follow it.  Are 
we only talking about dot idn representation of country codes or are we 
also talking about a gTLD that is a translation in another language 
representing a certain country, like dot Holland, for instance?

 >>CHRIS DISSPAIN:  Correct, yes.  We'd be talking about all of the 
above.

 >>ROELOF MEIJER:  I really feel that this is something that we're 
never going to solve by a system or a list or whatever, because if you 
take the example of the Netherlands, there are several translations of 
our country's name in almost every language.

 >>CHRIS DISSPAIN:  Sure.

 >>ROELOF MEIJER:  And then somebody could still sneak out by calling 
it the country of the thousand windmills or something.  There's 
probably only one country in the world that has a thousand windmills.

 [Laughter]

 >>ROELOF MEIJER:  But the bottom line is probably that if you come up 
with such a funny top level --

 >>CHRIS DISSPAIN:  Sure.

 >>ROELOF MEIJER:  -- which is not visibly aimed at a certain country 
or group, it's not going to be a success.

 >>CHRIS DISSPAIN:  But you could always object to that on the basis 
that you'd be -- objection is open to everybody, to object, because for 
whatever reason.  So no one is suggesting that simply by having a list 
of things that are reserved, it stops you from objecting to something 
else.

 What we're saying is it would make life a lot simpler -- okay.  This 
is a starting point.  Does everyone think -- hang on.  Oh, in fact 
let's not worry about what I was going to say.  Let's take Hilde and 
then --

 [Speaker is off microphone]

 >>CHRIS DISSPAIN:  No.  Sorry Annebeth.

 [Speaker is off microphone]

 >>CHRIS DISSPAIN:  I apologize.  You sort it out amongst yourselves 
then.  Lesley.

 >>LESLEY COWLEY:  Hi, Lesley Cowley from Nominet U.K.  Those of us at 
a previous meeting will remember a disagreement between ISO 
representatives where at the time we were talking about some sort of 
table here being developed by the ISO process with people who have far 
more experience than we do. in this area, I suspect.

 We were disappointed to note that that initiative was disapproved at 
the last meeting.  Not by us, sorry.  By ISO.  Because there were not 
sufficient volunteers.  And I think if we are to end up with any 
statement as a result of our discussions on this, it would be helpful 
to include some sort of encouragement for that process to go forward.

 >>CHRIS DISSPAIN:  Yes.

 >>LESLEY COWLEY:  Because I agree with the earlier points on lists, 
but I think we really are looking for some guidance from somebody like 
the ISO on this issue.

 >>CHRIS DISSPAIN:  Yes.  I agree.  Now, who was next?  Annebeth and 
then Jonathan, I think and then Richard.  Sorry.  Steve.

 >>ANNEBETH LANGE:  Thank you.  Really, I don't think the list, if you 
understood me that I wanted a list, I don't mean that, actually.

 >>CHRIS DISSPAIN:  Okay.

 >>ANNEBETH LANGE:  It's never possible to have a list that you will 
forget a lot of things.  But I think that it's important at this stage 
to -- we can discuss a lot of things in the PDP.

 >>CHRIS DISSPAIN:  Yes.

 >>ANNEBETH LANGE:  But at this stage, to meet that GNSO report --

 >>CHRIS DISSPAIN:  Yes.

 >>ANNEBETH LANGE:  -- we have to establish a principle.  What's --

 >>CHRIS DISSPAIN:  I understand.

 >>ANNEBETH LANGE:  -- the right of the national ccTLDs.

 >>CHRIS DISSPAIN:  I understand.

 >>ANNEBETH LANGE:  And it will always be a lot of things that they can 
-- they can register anyway, but then it will be fewer things that we 
have to object to, and not that process to take everything from.

 He talked about 2,000 applications?  That's quite a lot.  And for 
small countries to do this process, I think it will be impossible.

 >>CHRIS DISSPAIN:  So you're suggesting that -- you're suggesting that 
we should -- you're saying we should be suggesting to the board that 
there is a principle that the name of a territory -- so referring back 
to the 3166 list, the name of a territory in any script or an 
understandable abbreviation of that territory in every script should, 
as a principle, not be allowed in the gTLD space.

 [Speaker is off microphone]

 >>ANNEBETH LANGE:  Yeah.  Just a little comment on that.  That the GAC 
has a best practice document --

 >>CHRIS DISSPAIN:  Yes.

 >>ANNEBETH LANGE:  -- on new gTLDs.

 >>CHRIS DISSPAIN:  Yes.

 >>ANNEBETH LANGE:  And it is a paragraph in that that says about the 
same.

 >>CHRIS DISSPAIN:  Okay.

 >>ANNEBETH LANGE:  That they should keep it out.

 >>CHRIS DISSPAIN:  Okay.  So can we -- hang on.  There's some more -- 
no, wait a second.  There was Stephen and then Jonathan and then Nashua 
and then Olivier.

 >>STEPHEN DEERHAKE:  A point of clarification here.  Do we have -- are 
we talking, do we have the right of objection to these strings or do we 
have a veto over these strings.

 >>CHRIS DISSPAIN:  No, no.  We're saying everyone -- look, under the 
current -- the proposed policy is that you can object to anything.  If 
somebody wants to register dot Stephen, you can object to it.  It's got 
nothing to do with being a ccTLD or whatever.  You can object for all 
sorts of reasons.  What we're talking about right now is sending a -- 
the way you would do this is the council would actually pass a 
resolution to the -- saying as a principle, we believe.  Now, that's -- 
all that does is that puts pressure on the board to make some sort of 
distinction in the gTLD process about the way that names -- geographic 
names are handled.  Or sorry, actually, it's territory names.  
Territory names are handled.

 >>STEPHEN DEERHAKE:  But if we have -- if we actually have like veto 
power, then we can turn this whole thing around and say, "Okay, you 
have to demonstrate to us that this name is not a problem."  In other 
words, this list-making behavior really can become much more 
manageable.

 >>CHRIS DISSPAIN:  No, no.  It's clearly every name that is applied 
for is going to be examined by ICANN in its process for deciding 
whether it is acceptable or not.  So they're going to look at it -- so 
if you look at the current gTLD policy recommendations that the GNSO 
has made, that I spent six hours talking about yesterday, there are 
requirements of looking at morality and public order issues so to say 
that the name does not offend international standards -- I forget the 
exact words but international standards of public morality or something 
like that.

 What we're effectively talking about is adding a -- something else for 
them to look at and say "And it is not the name of a territory."

 >>STEPHEN DEERHAKE:  How about "and it is not one we object to," 
period, full stop?

 >>CHRIS DISSPAIN:  Because that's not workable, though.  See Roelof 
would not -- Roelof's example of the land of a thousand windmills -- 
you are going to be very upset when they lose one of them because it 
will be the 999 windmills.  

 The land of a thousand windmills would fit, would be fine unless 
someone objected.  But I would suggest that -- well, Germany is, 
perhaps -- or dot Holland or dot Germany would not be acceptable 
because that is a name of the territory.  That's what we're talking 
about.

 >> KEITH DRAZEK:  Just a quick question for clarification.  This is 
Keith Drazek.  Are we talking more about just IDN at the top level?

 >>CHRIS DISSPAIN:  This is about gTLD policy between the two.  The 
GNSO chose to make no distinction between the two.  Jonathan?  Jonathan 
was before you, Olivier.  He was, I promise you.

 >>JONATHAN SHEA:  Jonathan Shea, dot Hong Kong, dot HK registry.  I 
totally echo Hilde's point about the importance of stating a principle 
that a territory should not be a name -- the name of a territory, as a 
principle.

 Of course, we all understand it is impossible to have an exhaustive 
list containing all the variations or even the name of the territory in 
different script.  It is entirely impossible.  But that is not a reason 
not to have a list, I guess.  That is not a reason that we do not do 
anything about it.  At least we should put the obvious ones on the 
list.

 >>CHRIS DISSPAIN:  The problem with doing that, Jonathan, is the 
moment you start a list, it is treated as being all there is and that's 
-- thank you -- inclusive and that's a problem.  I'm persuaded -- 
Annebeth's point is exactly that.  The moment you start a list, it is 
inclusive.

 So you can't say, Well, here's a list but it's not complete.  You are 
much better off to rely on two things, one, an objection process -- 
Vint was right, an objection process will work it is just that it is 
very complicated.  But, secondly, and above that a principle that days 
-- it doesn't mean that things won't slip through.  It doesn't mean 
that ICANN won't look at something and realize it is actually something 
but then that's what the objection process is for.  At least if it is 
stated as a policy, one hopes there won't be that many applications.  
This is not to stop dotBERLIN, dot Paris or dot NYC.  This is 
specifically relates to the territories on the ISO-3166 list.  Does 
that make --

 >> We are 2,000 applications potentially coming in.  We're a first 
screen mechanism.  If we just rely on an objection mechanism, I'm still 
afraid that is quite likely that some of the --

 >>CHRIS DISSPAIN:  What we're doing is we're saying -- we might end up 
doing, we're saying, let's see if we get them to agree that every name 
in the same way they are going to look every application and say, Is 
this offensive to public morality, they also look at every application 
and say, Is this the name of a territory or a meaningful abbreviation 
of a territory that is listed on the ISO-3166-1 list.  

 If it is, they will just say that is not within policy.  In the same 
way if they receive an application for an offensive -- whatever the 
rule is about offensive stuff, an offensive word, they will simply say 
that's not acceptable.

 So there is -- so what we're trying to do is create a first cut and 
second cut.  The first cut is whoever is running this process -- 
presumably the staff -- look at it against the set of principles, one 
of which is that territory name should be not gTLDs and then the 
objection process backs it up.

 Does that make sense?

 >>JONATHAN SHEA:  Well, I believe -- Yeah.

 >>CHRIS DISSPAIN:  You think that would work?

 >>JONATHAN SHEA:  Yeah, but better if -- at least we have a list of 
all the standard names there, understanding that this will not be 
comprehensive.  Everyone knows that the list will never be exhaustive 
but it would be a useful first --

 >>CHRIS DISSPAIN:  Can I suggest to you that actually -- a result of 
this principle, if we were to get it accepted, would be the creation 
over time of that list.  Because once a name had been found to be an 
abbreviation of a name of the territory in a script -- right?  We don't 
have any problem with ASCII here because we're all pretty clear that 
what the ASCII names are, although there are different translations 
from different languages in ASCII, right?

 What would happen if dot Holland was found to be as a principle not 
available for a gTLD, then it's on the list.  So what we would be doing 
is creating a list as we go by the finding that something is, in fact, 
the name of a territory.  So you'll get your list, you just won't get 
your list immediately.  It will be an ever-growing list.

 >>JONATHAN SHEA:  I totally agree that we can start with just the 
ASCII at least first, to get every principle --

 >>CHRIS DISSPAIN:  That's your reference list.  The ISO 3166-1 list is 
your reference list.

 >>JONATHAN SHEA:  That should be sufficient as a start.

 >>CHRIS DISSPAIN:  Nashwa, did you want to say something?  Olivier was 
next.

 >>OLIVIER GUILLARD:  Olivier Guillard from the country of the a 
thousand cheeses.

 [ Laughter ]

 I think you answered my question.  I think the idea of stating a 
principle is a really good idea in the gTLD process.  I wanted to just 
have an idea -- a clarification of what you call a territory.

 >>CHRIS DISSPAIN:  It is on the ISO 3166-1 list.  That's it.

 >>OLIVIER GUILLARD:  It would be a principle link to this list?

 >>CHRIS DISSPAIN:  Yes, with the exceptions included which I believe 
include the U.K.

 >>OLIVIER GUILLARD:  Okay.  But this list -- this list may also 
change?

 >>CHRIS DISSPAIN:  I don't know.

 >>OLIVIER GUILLARD:  So, for example --

 >>CHRIS DISSPAIN:  Well, names will be --

 >>OLIVIER GUILLARD:  (inaudible) this list could be --

 >>CHRIS DISSPAIN:  Names will be added to the list as well.  We can't 
legislate for what might happen in ten years' time.  It's not possible.

 >>OLIVIER GUILLARD:  Okay.

 >>CHRIS DISSPAIN:  Nashwa, you had something?  And then I had Bill and 
then I have Hilde.

 >>NASHWA ABDEL-BAKI:  Actually --

 >>CHRIS DISSPAIN:  Stand up and introduce yourself.

 >>NASHWA ABDEL-BAKI:  The discussion, I was pretty confused.  I think 
now a little bit better but I would like to be sure -- now I understand 
what you are discussing.  I would summarize what I understand and 
please correct me if I am wrong.  Now we have today the ccTLDs and the 
generic top-level domains.

 >>CHRIS DISSPAIN:  Yes.

 >>NASHWA ABDEL-BAKI:  Now we're talking about the IDNs -- when the 
IDNs come.  This can be also for me both top-level domains and country 
codes and also generic.

 >>CHRIS DISSPAIN:  Correct.

 >>NASHWA ABDEL-BAKI:  Good.  What kind of list are we talking about?  
The list of all of these things?

 >>CHRIS DISSPAIN:  No, we're talking about whether we can -- the 
current -- a ccTLD is currently limited only to a territory that is 
listed on the ISO 3166-1 list.

 >>NASHWA ABDEL-BAKI:  Good.

 >>CHRIS DISSPAIN:  And the two-letter abbreviation for that.  So 
Australia is dot AU because it is on that list as dot AU, okay?  When 
we introduce IDNs, then we lose having a mandated list from ISO because 
there is no list of country -- there is no authoritative list of 
country names in Arabic.  There is no authoritative list of 
abbreviations of country names in Arabic.  There is no same in Chinese, 
same in Cyrillic.

 >>NASHWA ABDEL-BAKI:  We are not only Arabic countries.  We are 
talking all countries in Arabic.

 >>CHRIS DISSPAIN:  Yes, because it is possible that Australia might 
want in the future to have Australia represented on the Internet in 
Arabic.

 >>NASHWA ABDEL-BAKI:  Exactly.

 >>CHRIS DISSPAIN:  It's possible.  Okay?

 >>NASHWA ABDEL-BAKI:  Yep.  That was the last question actually, who 
reviews the rights to do that?

 >>CHRIS DISSPAIN:  This is what the policy development process is all 
about.

 >>NASHWA ABDEL-BAKI:  Thank you.

 >>CHRIS DISSPAIN:  For those of you -- Stay standing up.  Stand up.  
Nashwa is the new NomCom appointee to the ccNSO Council.  And so she 
will be joining the council after the meeting tomorrow.  So thank you.

 >>NASHWA ABDEL-BAKI:  Thank you.

 >>CHRIS DISSPAIN:  No problem.

 I had Bill, I believe, just because Gabby isn't getting enough 
exercise.

 >>BILL SEMICH:  My name is Bill Semich, and I am with the dot new 
domain.  I just want to take a giant leap backwards here.  I'm 
uncertain how we can justify putting forward a principle which -- for 
which we haven't explained the basis.  Why is it that we would want the 
right to restrict someone from registering the name of a territory or 
country?

 >>CHRIS DISSPAIN:  You take that one, Hilde.

 >>HILDE THUNEM:  I can try.  For the same reason as when we do the IDN 
ccTLD fast-track that we don't want to prejudice the result of the cc 
PDP.  And the same here is that the GNSO will launch IDN gTLDs long 
before we will be able to sort out the IDN ccTLDs.  

 Now, that is fine.  I don't want to delay them but for us then to say 
in principle the name of the territory is a ccTLD but some time to find 
out what we will actually do with it without those things being 
registered in the gTLD world as well.

 But the other point I will make when I have the microphone before it 
goes back to you is that adding this principle or stating this 
principle will also, I think, ease the objection process because I 
fairly much doubt that it is just enough to go up and say "I object" to 
everybody the gTLDs want to register.  You probably have to supply a 
reason if you want to object to the land of the thousand cheeses or 
whatever.

 And if there's a stated principle saying that the name of a territory 
connected to the ISO list is not an IDN gTLD and IDN ccTLD, then you 
can refer to that if something slips through and you have to object.

 >>CHRIS DISSPAIN:  Also, I think what we're trying to do here is look 
-- the distinction between gTLDs and ccTLDs, the easy distinction 
between ccTLDs and gTLDs is being lost because of the two-letter, 
three-letter distinction.

 And we're trying to corral what it is that we have and what it is that 
we might want to have and so, Bill, I would say to you in the same -- I 
echo what Hilde says, but I also would say it's simply the turnaround 
of why should ccTLDs not be able to register words that do not mean 
their territory or an abbreviation of their territory.

 My view as a ccTLD is for a very specific purpose, it is to represent 
the territory on the Internet in a particular script.  The "in a 
particular script" bit is the bit that has been added because we have 
only just recently got those particular scripts.

 But I don't -- I certainly think that -- there is nothing to stop 
America -- sorry.  There is nothing to stop a private company even with 
this principle in place, there is nothing to stop a private company 
applying for dot America and getting it provided that they have the 
consent of the American community.  We're not saying it couldn't be run 
as a gTLD.  We're simply saying that -- now, why you would want to 
actually put it under a gTLD contract when you have actually got more 
control over it under a ccTLD contract is another issue, but...

 Roelof, Dotty, and then I'm going to make a suggestion for -- of how 
we can wrap this up.

 >>ROELOF MEIJER:  Yes.  Somehow I think we have to separate the two 
things because if it is a dot IDN representation of a territory --

 >>CHRIS DISSPAIN:  Yes.

 >>ROELOF MEIJER:  -- then we could come up with a phrasing we do not 
want because we are still making policy on dot IDN ccTLDs.

 >>CHRIS DISSPAIN:  Yes.

 >>ROELOF MEIJER:  But dot Holland has nothing to do with dot IDN.  It 
is ASCII script.  So if we want to object to dot Holland or dot 
America, then it has to be on another ground.

 >>CHRIS DISSPAIN:  No.  I'm sorry.  I thought what we were talking 
about was the overall -- overall gTLDs, the name of the territory or a 
meaningful abbreviation of that territory should as a principle not be 
a gTLD.

 I thought -- maybe I've misunderstood, but I thought that's what we 
were actually saying, not just related to IDNs.

 >>ROELOF MEIJER:  I agree that's what we're saying but the previous 
question was, what is the ground for that objection.  Why can't it be?  
And for the dot IDN representation, I understand the reasoning.

 >>CHRIS DISSPAIN:  It is because -- yes.

 >>ROELOF MEIJER:  But for the other representation -- so for the dot 
Holland and the dot America, I don't really get it yet.  And the 
problem might be that a lot of people will feel that it will bring 
necessary competition to have dot Holland next to a dot NL.

 >>CHRIS DISSPAIN:  I understand.  Fair enough.

 >>ROELOF MEIJER:  I think we should also consider the question if it 
can't be a gTLD, does it automatically become a ccTLD?  Or is it an 
exclusion?

 >>CHRIS DISSPAIN:  No.  I don't think it would automatically become a 
ccTLD, but that's an extremely good question.  

 So I had Dotty and now Hilde has changed her mind.  No, she is back 
again.

 Dotty?

 >>DOTTY SPARKS de BLANC:  I know that I am very thick-headed on this 
subject.

 >>CHRIS DISSPAIN:  Right.  Is that all you need to say?

 [ Laughter ]

 >>DOTTY SPARKS de BLANC:  Prefacing my remarks with that, however, it 
seems to me would be just so simple if we made it a simple translation 
into the local language just as if we took the ICANN charter and 
translated it into all of those language so people could understand.

 I understand that this involves tables and things like that.  It is 
much more complex.  But, if there is a single representation for a 
country on the Internet, and it could be translated into various 
things, then who owns it?  And whether it is a gTLD fighting for it and 
all that, all of that stuff goes away.  Those issues go away.

 >>CHRIS DISSPAIN:  Okay.  Can you pass the microphone to Ron. Can you 
say who you are?

 >> Ron Sherwood with dot VI.  Are we really talking about languages 
here, or are we talking about character sets?

 >>CHRIS DISSPAIN:  We are talking about scripts.

 >> RON SHERWOOD:  The reason I say this is because gTLDs could be 
registered with a noun that is descriptive of a country, for example.  
You talked about America or Holland.  But what about dot Virgins, for 
example?

 >>CHRIS DISSPAIN:  Well, that's descriptive of a number of things 
including the country in which you live.

 >>RON SHERWOOD:  There is going to be an enormous list if each 
territory is permitted to judge such extensions in whatever language.

 >>CHRIS DISSPAIN:  I agree.  I mean, you can take it -- you can 
extrapolate this out to the nth degree.  If it contains any letters 
that are contained in the name of a country, it will be an issue.

 Hilde, can I get the last comment from you, and then I am going to 
make a suggestion.

 >>HILDE THUNEM:  I kind of lost things in this.  I think Roelof made a 
point in regards to dot Holland.  That point was raised in the GAC 
meeting.  It was actually made by Canada saying that as a government, 
they felt that if somebody wanted to register dot Canada, that would be 
a ccTLD because they would feel that it would be in direct competition 
with dot CA and dot CA is set up under specific rules to serve the 
community and they would not want a gTLD to come and take dot Canada.

 Now, that was their point of view.

 >>CHRIS DISSPAIN:  Yes.

 >>HILDE THUNEM:  I would also add the comment, for those of you who 
actually have languages and scripts that are Latin-based, there is a 
question when you come to the grounds of why dot Holland should be 
excluded, should those scripts be discriminated because they are Latin-
based.  They should not be allowed to be protected just because the 
others are protected.

 >>CHRIS DISSPAIN:  I agree.  Roelof, I take your point but I think 
that I would argue that the ASCII TLD is the same as the IDN TLD 
because we have never been in this position with the ASCII IDNs.  If 
you look at the process of new gTLDs, there was one round of new gTLDs 
which was a trial and there were no country names put forward.  Then 
there was the sponsored TLD which was also a trial.  And this is now 
the first time we've had this sort of full-blown new policy and we know 
there is a huge, you know, pipe out there of applications.

 Now, I'm not saying it's workable.  I don't know if it is or it isn't.

 What I'm going to suggest is that Bart and I try and copy the GAC's 
principle into our own principle that works for us and then bring that 
to you tomorrow morning and see if we can actually talk it through.  
Because we may get nowhere.  The worst-case scenario, I would argue, is 
individual ccTLDs can send a note to the board saying we have a problem 
and this is what our problem is.  But if we could actually get a 
consensus and pass a resolution, that would be fantastic.

 Olivier, you are looking puzzled.  Hang on.

 >>OLIVIER GUILLARD:  Sorry, I shouldn't ask this question but I do it.

 [ Laughter ]

 We just talked about Canada and I'm just wondering, would it be a 
problem for the Canada registry if someone asked for Quebec, for 
example, or for dot U.S. if someone asked for California.  Just 
wondering.

 >>CHRIS DISSPAIN:  It might be but for one is suggesting that city 
names and province names or state names should actually be reserved.  
They are things that you can object to.  So in the dot Asia -- the 
recent release of dot Asia, Australia government and us sent a note 
saying the following names need to be reserved for Australia.  So 
Australia, obviously, this is obviously the second level Australia, dot 
Asia, we listed all the names that needed to be reserved.  In fact, we 
ended up -- I still don't know how it has been resolved.  We ended up 
being resolved because dot Asia said, "We will not reserve state names" 
so we will not reserve Newsouthwales.Asia or Victoria.Asia.  The 
Australian government's response to that was, Well, the problem is, you 
see, they are actually sovereign governments.  They may be state 
governments, but they are actually governments and they kind of own 
that name and they really would be very upset if you let 
Newsouthwales.Asia or NSW.Asia be registered.  That's an objection 
process rather than a block.

 So if it's okay, we'll see if we can work something up.  If there is 
any way you can find the reference to it and e-mail Bart, that would be 
fantastic.

 >>BART BOSWINKEL:  I know where it is.

 >>CHRIS DISSPAIN:  You know where it is?  Okay.

 >> Hello.  Mary Udama, dot NG.  I am wonder whether it is tied to the 
countries to submit their objections by saying, Look, we don't want 
anybody to register these Nigeria.Nigeria or dot (non-English word) or 
dot (non-English word).  There are lists so each of the countries would 
be asked to submit their objections to the -- to the committee.  

 Let it come from them and not from this side so it makes it easier 
that a country has already made objections so that when people want to 
register a gTLD, then they know that there are certain countries that 
don't want certain names.

 >>CHRIS DISSPAIN:  My understanding is that the GNSO looked at that as 
a possibility but they didn't think it was workable.  There's a -- 
there are two distinct.  There is an objection process and they've 
decided that the objection process works only on the basis that an 
application has been made and, therefore, you can object, rather than I 
object and therefore there won't be an application.  That's one thing.  
And on the other side is the -- is whether or not there is a principle 
that certain names should not be, generally speaking, granted as gTLDs.

 I'm going to wrap this up now, because we have one more thing to do 
before we go.

 So we'll come back tomorrow morning with some sort of -- with a 
suggestion, and then if we can reach some sort of a consensus, we'll 
see if the council can pass a resolution.  Already the agenda is 
changing.

 Okay.  We're going to do one more thing before we close for today, and 
we're going to have a presentation from dot CN or CN NIC on IDNs in 
China, and you're going to need to come up and introduce -- excuse me.  
Why don't you come up and introduce your colleague would be the most 
sensible way of handling this, all right?  Thank you.

 So while that's being prepared, we start again tomorrow at 9:00 with 
what I have been referring to as phishing but I've been told I have to 
say anti-phishing because apparently otherwise it seems like I'm in 
favor of phishing.

 [Laughter]

 >>CHRIS DISSPAIN:  So Rod Rasmussen, who those of you who were in San 
Juan came and did a fantastic presentation is coming back again to 
present some more, and then we're going to continue on with that after 
the break, and Oscar is going to -- Oscar Robles is going to chair that 
session.  Is Oscar in the room.

 [Speaker is off microphone]

 >>CHRIS DISSPAIN:  He's not here.  Typical.

 [Laughter]

 >>CHRIS DISSPAIN:  So Oscar is going to chair that session and there 
will be some presentations also from other -- from ccTLDs about what 
they're doing in respect to anti-phishing, and then Hilde is going to 
discuss domain name policies and Norway is buying us lunch, which is 
great.  And then we'll continue on in the afternoon with other stuff.  
Okay.  You have the floor.  Hang on, hang on.  Can we have this 
microphone?  Thank you.

 >>YU YANG:  Okay.  Thank you.  This is Yu Yang, from CNNIC, and I'd 
like to introduce my colleague, Mr. Yao Jiankang, who is a chief 
engineer in CNNIC and who is in charge of the IDN structure.  He is the 
cochair of the Joint Engineering Team, which is known as JET.  It is 
composed of Japan, Korea, China.  It is a Joint Engineering Team that 
focuses on resolving the technical problems of the IDNs.  And he is 
also the co- -- one of the drafters who drafted IETF RFC 3743, and he 
will give us a short presentation regarding the IDN resolutions and TLD 
tests.  Let's welcome him.  Thank you.

 >>YAO JIANKANG:  Good afternoon everyone.  Thank you, Chairman.  Thank 
you, everyone.

 So thank you, everyone, for giving me the opportunity to introduce 
RFC3743 and the IDN TLD tests, to share our ideas.  My name is Yao 
Jiankang from CNNIC.

 So what is RFC 3743?  Maybe someone know it, someone don't know it 
here.  

 RFC 3743 is JET guidelines, Joint Engineering Team guidelines for IDN 
registration and administration for Chinese, Japanese, and Korean.

 Because Chinese, Japanese and Korean characters have variants for the 
same conceptual characters, it means that one conceptual character can 
be assigned with different codepoints or characters.  For computer use, 
it may be different.  This is maybe difficult to be understood by 
westerners, but later I will give some examples that will be easier to 
be understood.

 So the principle of this RFC is to assign a bundle of names with 
character variants to the same registrant.

 So CJK character variants issues.  For example, in English, there is 
the term "international."  It means -- in Chinese, for example, there 
is a symbol in Chinese is [non-English word].  There is codepoints in 
computer.  There is another traditional Chinese.  Also other variants 
combinations [non-English word].  

 So these are for the same term "international."  In Chinese, it has 
three -- at least three possible combinations.

 So in Japanese, there also -- in modern Japanese, maybe use this 
character to represent "international," but also sometimes you use this 
character.

 So there are also other possible combinations.  This one.  

 This is especially used for CJK, the Chinese-Japanese-Korean.  Some 
Europeans maybe also have similar problems.

 So this is an example.  In English, this is uppercase A and lowercase 
a.  For you, it is the same, equal, and the same meaning.  

 B is -- uppercase B and lowercase b is equal, and the same meaning.  

 Similar in Chinese.  These are Chinese characters.  [Non-English word] 
means country.  But this is -- looks very similar, but in meaning it 
also same.

 So for Chinese this character and this character is the same.  And 
this character is -- and this character is the same.

 So similar to uppercase A equal uppercase -- lowercase a.

 So Chinese character variants has -- some Chinese characters has many 
variants but they are the same in the meaning.  

 This character may be four character variants.  For example, this one.

 Why RFC 3743?

 This is -- ICANN IDN guidelines said we should follow some IDN-related 
RFC in IETF, so this is -- here's the work page for this RFC at ICANN.

 So this is an example.  Uppercase BANK.cn equals bank -- equals 
lowercase bank.cn.  It should be equal.  If not equal, there are -- 
because according to character current standards, they are equal.  

 But for -- similar for Chinese.  This is -- also means bank.  In 
Chinese, the pronunciation is yinhang.  This is also -- equals this 
yinghan.cn.

 Similar to this is uppercase BANK, this is lowercase bank.

 So in Chinese, we should also -- same meaning.

 So this also should be equal.  So to protect the interests of the 
registrant, CNNIC current policy for registration for Chinese domain 
name has following policy, one original domain name and three 
traditional domain names and another three is similar domain name for 
three.

 For example, this character [non-English word] is three -- have three 
character variants.  [non-English word] has three character variants.  
[non-English word] also has three character variants.  

 So the registrant input changhuauniversity.cn, this is Changhua 
University in China.  A very famous university.  If a registrant input 
this one, CNNIC will give this one, and also [inaudible] gives this one 
as present.  Also this one.

 So other --

 >>CHRIS DISSPAIN:  Slow down.

 [Laughter]

 >>CHRIS DISSPAIN:  Speak more slowly.  You're causing a major problem 
with our -- with our transcribers.

 >>YAO JIANKANG:  Okay, okay.

 >>CHRIS DISSPAIN:  Now just speak a little bit more slowly.  

 And we don't expect you to transcribe the Chinese words, okay?  That's 
not a problem.

 [Laughter]

 >>CHRIS DISSPAIN:  Okay.

 >>YAO JIANKANG:  Okay.

 >>CHRIS DISSPAIN:  So just slow down.

 >>YAO JIANKANG:  Okay, okay, okay.  I'm afraid of time limit.

 >>CHRIS DISSPAIN:  That's okay.  Don't worry.  We'll let you finish.  
It's all right.

 [Laughter]

 >>YAO JIANKANG:  Thank you very much.  For example, a registrant 
registers changhuauniversity.cn in CNNIC, first we -- CDN will -- 
according to the RFC 3743, there is a CDN package with a bundle of 
names here, here, here.  Many, many, many, many.  Sometimes more than 
10.

 So CDN used in DNS resolution, we have three.  Changhua, Changhua 
[non-English word], means changhuauniversity.cn.  Then these three will 
put in DNS for resolution.

 >>CHRIS DISSPAIN:  Can I just ask a question?

 >>YAO JIANKANG:  Okay.

 >>CHRIS DISSPAIN:  So this is a city name?  Is this the name of a 
city?

 >>YAO JIANKANG:  University.

 >>CHRIS DISSPAIN:  University.

 >>YAO JIANKANG:  Yeah, yeah, yeah.  Very famous university.

 >>CHRIS DISSPAIN:  Very famous.  Okay.

 >>YAO JIANKANG:  Yeah, yeah, yeah.

 >>CHRIS DISSPAIN:  All right.  And there are three versions of that 
name.

 >>YAO JIANKANG:  Yeah, yeah, yeah.  Three versions.  

 Then other versions of this name will -- were reserved only for this 
registrant.  If Yu Yang want to register this other version of this 
domain name, CNNIC will not allow him to do so.

 >>CHRIS DISSPAIN:  Okay.

 >>YAO JIANKANG:  So this -- so it protects the interests of the 
registrant of CDN and it limits possible phishing problems.  

 Why phishing?  I will give example.

 So, for example, here's yinghan means bank.  Bank may be for 
commercial uses.  But this is another version of yinhang.cn.  This is -
- but this looks similar xn, dash, but these are different.  For 
example, these two names belong to different registrant.  If this is -- 
belong to some -- for example, USA bank, but this version is -- belongs 
to me, this IP address -- this IP address, if I have Internet banking, 
I will input this version, I will go to this here, go to here to maybe 
transfer money.  

 But I have -- for example, me registers this bank.cn, I will put my -- 
sorry.

 I will put this IP address to my server.  Then as someone will -- then 
logs a bank account in my server that transfer money to my bank so I'm 
very rich.

 [Laughter]

 [Speaker is off microphone]

 >>CHRIS DISSPAIN:  Very rich.  Extremely rich.

 >>YAO JIANKANG:  Yeah, yeah.  All USA bank belong to me.

 >>CHRIS DISSPAIN:  Beyond your wildest dreams.  

 But RFC 3743 stops that because these two are the same.  Yeah?

 >>YAO JIANKANG:  Yeah, yeah, yeah, yeah.  You are right.

 >>CHRIS DISSPAIN:  All right.  Good.

 [Laughter]

 >>YAO JIANKANG:  So for same.  Same reason.  

 For example, now IDN TLD test in ICANN.  For example, dot test, he 
also have two -- for Chinese have two versions.  This is [non-English 
word] equals [non-English word].  These are the different versions, 
Chinese version.  Now ICANN Wiki, we can see two.  

 >>CHRIS DISSPAIN:  Yes.  Someone has phished your mouse.

 >>YAO JIANKANG:  Yeah, yeah, yeah.  These two have two version and 
also have two version.  So this version test -- Chinese test equal to 
this version of Chinese test.

 >>CHRIS DISSPAIN:  Okay.

 >>YAO JIANKANG:  So if you input bank dot [inaudible] means one 
Chinese version and bank.test, another Chinese version, this is not 
equal.  Belong to different registrants, so these have phishing 
problem.

 >>CHRIS DISSPAIN:  I understand.

 >>YAO JIANKANG:  Yeah, yeah.  Okay.

 So the principle of RFC 3743 is to protect the interests of the 
registrant.  

 So in future, when ICANN allow maybe the new TLD -- new TLD -- IDN TLD 
application, we should all consider this issue.  If bank dot test not 
equal this version and bank dot [non-English word] and this version 
different, a new phishing opportunity, so if ICANN does not consider 
RFC 3743 they will introduce a new phishing problem.  

 So this is ICANN's fault, so we must consider this issue.

 >>CHRIS DISSPAIN:  Right.

 >>YAO JIANKANG:  Thank you very much.

 >>CHRIS DISSPAIN:  You finished.

 [Applause]

 >>CHRIS DISSPAIN:  Not quite.

 >>YAO JIANKANG:  So this is --

 >>CHRIS DISSPAIN:  You know Olivier?  Do you know my friend Olivier?

 [Laughter]

 >>CHRIS DISSPAIN:  He always has an additional supplementary slide 
that comes in afterwards.

 [Laughter]

 >>YAO JIANKANG:  So may I?

 >>CHRIS DISSPAIN:  Yes.  Carry on.  Do you want to finish that?

 >>YAO JIANKANG:  So I went to another sharing idea.

 So a suggestion to IDN TLD test.  So Chinese -- so this version and 
this version should all have equals --

 >>CHRIS DISSPAIN:  Yes.  Be the same.

 >>YAO JIANKANG:  Yeah, yeah, yeah, yeah.  I see.  

 So I also share some international e-mail address, because currently 
I'm also main drafter for international e-mail address, so a draft 
[inaudible] may also maybe for SMTP attention for international e-mail 
address [inaudible] because I'm mainly involved in IETF working group.  

 So now here we have a Chinese [non-English word].cn.  Now, in future, 
this is my name, this e-mail address.  

 Now ICANN introduce this one in future, we will have this one, totally 
internationalized e-mail address IDN.

 So this is our dream.  

 So we are -- our dream, we're becoming two --

 >>CHRIS DISSPAIN:  You said your dream was just to become immensely 
wealthy.  Now you changed your mind.

 [Laughter]

 >>YAO JIANKANG:  Yeah.

 >>CHRIS DISSPAIN:  So okay.

 [Speaker is off microphone]

 >>CHRIS DISSPAIN:  So that presumably -- eventually that dot cn would 
be replaced by a Chinese --

 [Speaker is off microphone]

 >>YAO JIANKANG:  Yeah, yeah, yeah, yeah.

 >>CHRIS DISSPAIN:  Okay.  Good.  

 >>YAO JIANKANG:  So IETF or EAI working group progress [inaudible] e-
mail address internationalization, so [inaudible] overview and for 
international e-mail address.  This is edited by John Klensin.  RFC 
4952 is already published in July 2007.  So these are a blue map for 
whole international e-mail address.  SMTP attention for international 
e-mail address is already finish.  ICANN working group last call.  So 
[inaudible] also for this draft.

 Another two draft will also -- have already finish working group or 
working group last call.  So in future, end of this year or early next 
year with these three RFC will be published by IETF.

 >>CHRIS DISSPAIN:  Okay.

 >>YAO JIANKANG:  So any questions?

 >>CHRIS DISSPAIN:  Whew!

 [Laughter]

 >>YAO JIANKANG:  So actually, for international e-mail addresses 
[inaudible] test bed, so test bed proves that international e-mail 
address protocol in IETF is workable.

 >>CHRIS DISSPAIN:  Thank you very much.

 [Applause]

 >>YAO JIANKANG:  Thank you, Chairman.

 >>CHRIS DISSPAIN:  And thank you Yu Yang, and thank you very much.  
How do I say my name?

 >>YAO JIANKANG:  Yao Jiankang.  

 >>CHRIS DISSPAIN:  Yao Jiankang.

 >>YAO JIANKANG:  Jiankang is "healthy."  Yao is -- Yao means "Yao."

 >>CHRIS DISSPAIN:  So "Yao" means Yao.

 >>YAO JIANKANG:  Yeah, yeah, yeah.

 >>CHRIS DISSPAIN:  Yeah.  Healthy Yao.

 >>YAO JIANKANG:  Yeah, yeah, yeah.  

 >>CHRIS DISSPAIN:  Good excellent. 

 >>YAO JIANKANG:  Thank you.

 >>CHRIS DISSPAIN:  Thank you very, very much.  Yes, Olivier has a 
question.

 [Laughter]

 >>CHRIS DISSPAIN:  Stand up, Olivier.

 >>OLIVIER GUILLARD:  Yes.  No, no.  Does it work?  Yeah.  Olivier.  
Not a question.  Just a comment.

 I think I will look at this work because we haven't introduced the 
IDNs on dot FR because some people have put forward the problem of 
potential confusion with the characters that only have a little sign, a 
little diacritic sign, and maybe if I understood properly your 
approach, maybe it would be a possibility to put those signs that are 
very close within the same bundle to protect a set of characters.

 So thank you very much.

 >>YAO JIANKANG:  Thank you very much.

 >>CHRIS DISSPAIN:  Okay.  So that's the end of today.  Well, not 
literally.  I mean, we still have the rest of today to go, but that's 
the end of today's meeting.  Thank you all very, very much indeed for 
coming and for paying attention.  Bart and I have a bit of work to do 
now.  We'll start again at 9:00 tomorrow morning.  Please don't forget 
that the council meeting is now changed till 5:00 because we want to go 
to the strategy meeting, the ICANN strategy meeting.

 And we'll see you all tomorrow morning or at Sony Studios.  One or the 
other.  Thanks, everybody.

 [Applause]