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