GAC Meeting
ICANN Meeting
Sydney, Australia
Tuesday, 23 June 2009

>>CHAIR KARKLINS:   So good morning, ladies and gentlemen.

Welcome to the GAC plenary meeting.

Today, we will have -- first part of the day, we will have sessions
related to technical standards and security issues.  And the first
session we will have on IDN TLD technical requirements.  And we will
have with us Patrik Fältström, who is physically in Sweden and will
be briefing the GAC on document development and use of IDN tables and
charter variants for second and top-level strings, it's revision 1.

Patrik, thank you very much for joining us, taking into account time
difference.  I believe it is late night or very early morning in
Sweden.  We really appreciate your gesture and your generosity.

What I would like to propose, that you maybe can walk us through the
document, explain what document is about, why it is so important to
adhere to standards and follow those, what are consequences if
somebody makes a sidestep, what are the consequences for others.

And your slides you will be using, they were sent to the GAC mailing
list.  And I see that all laptops are open and we will be able to
follow your slides if you would say "slide 1," "slide 2," that would
be help.

And after your presentation, then we will engage in Q and A session,
clarifying things which potentially will not be clear from your
presentation paragraphs once again, thank you, Patrik.  And the floor
is yours.

>>PATRIK FÄLSTRÖM:   Thank you very much, Janis.  Yes, it's 1:00
a.m. in the morning here.  But on the other hand, we have nice
weather in the middle of the summer here in Sweden.  So I actually
enjoyed staying here.

Anyways, what I'm trying to do is to try to explain a little bit on
the reasoning behind the current documents that you have seen that
are passed around and that are discussed.

And I tried to come up with this presentation, as you mentioned,
that tried to explain the various issues.  So we can go directly to
slide number 2, please.

So one thing to remember to start with is that in (inaudible) domain
names is not really feature in the protocol itself.  Because in the
DNS protocol, we are still passing around domain names using the
Latin script.  That means that we are still only using A to Z, 0 to
9, and the dashes, the normal characters that we have always seen.

We are not passing around anything in the DNS protocols or any other
protocol which are using domain names using, for example, the special
characters in Swedish or Chinese characters and whatnot.

So I will come back to this a little bit later, the reasoning why we
have chosen to go down this path.

When we talk about Internationalized Domain Names, you talk about a
much, much larger sort of piece in the puzzle than just the domain
name itself.  We're talking about a full functionality and the
ability for users to express domain names using a non-Latin script.

Slide number 3, we do see Internationalized Domain Names in three
different places.  First of all, we see Internationalized Domain
Names mentioned, of course, in the various standards that are set by
the IETF.  And we will come back to why those are important.  Those
standards talk about what codepoints are allowed, because the Unicode
character set is, of course, very, very large and can include -- and
includes lots of different characters.

We also see Internationalized Domain Names mentioned in the various
applications that implement Internationalized Domain Names, the
applications which both encode and decode the xn-- form of the domain
name and present it to the user or interprets the input from their
user.

And the third place where we need to talk about Internationalized
Domain Names is in the various policies that registries set up. 
First of all, of course, we need to, for the registries that want to
have domain names themselves which they're registered for which uses
Internationalized Domain Names, we are talking about the policy for
what domain name they can use and be registered for.  And secondly,
for the domain names which are registered in that registry, which
means the registrants that want to register domain names in that
registry, what are the rules that they can use, the registrants.

Specifically what is discussed at the moment in an ICANN context are
two different things.  The first discussion has to do with what TLDs
can be created.  And this, of course, can be separated, as all of us
know, into the internationalized gTLDs and the internationalized
ccTLDs.

The second issue that is important to discuss is what policies these
TLDs must implement in -- for registrations in the second-level
domain.  And as you will see later on, it's still the case that the
most important issue is that the TLD registry is actually
implementing some policy.  Because, as we will see later, hopefully,
the intention with my presentation is to demonstrate why it's
important to actually have a policy in the TLD.

So why are we not using just Unicode?  Slide 5, please.

There are two different reasons for this.  First of all, Unicode as
a character set includes many, many characters.  And many of them do
look the same.  And I will show a couple of examples.

So the first problem is that we cannot really use all of Unicode,
because that might lead to various different kind of conflicts,
various different kind of look-alike problems, that I have registered
something that I think looks like my name, but other people that want
to look it up, they are typing in what they think is my name
differently, and then we don't get a match, because as we will see a
little bit later, the important thing is that what the registrant
register and what other people try to look up actually is the same
thing.

So the first thing is that Unicode include many, many characters
that we simply cannot really use.

The second thing is that Unicode itself is a standard that is
updated now and then.  And we need to agree on what version to use or
we need to express the rules for what characters that we are going to
use in the way so it is independent of versioning.

For example, if it is the case that a version of Unicode is released
which includes many new characters that was not used and was not
defined before, the question is, when can a registrant start to
register domain names with those new characters?

Excuse me.

And then the last thing here is that Unicode is only character set. 
But, of course, if you have any kind of data that you would like to
send in a protocol or store in a database or something, you need to
decide how to store that.  And Unicode itself does not define one
specific way of storing Unicode characters.  Instead, Unicode --
together with Unicode, you have many different ways of storing
Unicode characters.  One of the more common ways that we like in the
IETF is -- and on the Internet is called UTF-8.  That's ICANN an
encoding which has variable length for the codepoints.  But,
unfortunately, many protocols and applications that use domain names
cannot handle UTF-8.  So it's better for us to -- from a technical
standpoint -- use a different encoding.  And because of that, we have
used the -- by using the xn-- form, we can support domain names using
Unicode in many applications where the applications don't have to be
updated themselves or the protocols that they support don't also have
to be updated.  Slide 6, please.

A simple example, and I say it's simple just because it uses Latin
characters, and Latin characters are something that we are used to. 
If I register a domain name which is Fältström.se, which is my last
name, and then later on, someone would like to look up things in that
domain name, in that second-level domain, they might use the
uppercase version.  Now, people that are used to domain names today,
they know that in the DNS standard, it actually is stated that U.S.
ASCII is supposed to match in a case-sensitive fashion.  So if you
look at the first character, the "F," we'll see that, yes, the DNS
server itself would match the uppercase "F" with the lowercase "F." 
But we look at the second character.  We have an uppercase version of
the lowercase "A" with umlaut.  And unfortunately, there is nothing
in the DNS server that can do that matching.  So there are two
different ways of dealing with this to make sure that you actually do
a match in this case for case insensitivity.

One is to change all the DNS servers in the world to use a different
matching algorithm.  And the second way of dealing with this is to
canonicalize the string uppercase F, A with umlaut, LTSTR -- et
cetera, to canonicalize that string and lowercase the string before
the search is done in the DNS.  And what we have decided to do in the
IDNA solution is to canonicalize the string in the domain names
before they are looked up.  So the actual string that is used when
looking up things in the DNS is the one you see at the bottom, xn--
FLTSTRM-5WALO.SE.  And that xn-- is, -- because of this is an
encoding of the Unicode string where the Unicode string is first
canonicalized.  So there is a canonicalization step and then an
encoding step.

Next slide, please, slide 7.

So if we look at this scheme, you look at the top left, you have the
registrant that do two things.  The first thing the registrant is
doing is going to very often something that I in this picture call a
registrar, but very often there is some other kind of middleman in
between the registrant and the registry.  And the important thing
here is that the registrant passes to this registrar something that
it passes to the registry which they, in turn, put into a zone.

At the same time, the registrant also gives sort of the same thing
to DNS operator that manages DNS for that zone and you set up the
actual zone content.  So you have two different zones which include
information about this domain name.

In the lower left, you see a friend of this registrant or someone
that would like to become a friend that tries to enter some kind of
domain name in an application that, in turn, is using a resolving on
the Internet that is doing some queries to various DNS servers.  And
what is happening is that you have a matching of the domain names in
the DNS servers which are shown here as zones.

The important thing here is that what is coming from the DNS
operator to the left from the registry in the top right and from the
resolver in the bottom right needs to be exactly the same thing.  And
it needs to be exactly the same thing using the rules for the DNS
that was defined when DNS was defined in 1983/'84.

And this is one of the reasons why it's so important that all of us
are using the same rules when we are taking Unicode domain name,
canonicalize it, and encode it.

And all of us must use exactly the same both encoding and
canonicalization.  Otherwise, what the registrant enter into their
zone at the DNS operator or what is entered in the zone by the
registry will not match what people that are looking up things is
trying to find.  And this is also one of the reasons why it's so
important to come up with policies and rules for what can be
registered that is not going to be changed.

Because I don't want to be the person or I don't think anyone in the
room would like to be the person that think about the dispute
resolution process when a registrant discover that they can no longer
use a domain name that they have already registered just because the
IDN standard has changed.  Because I don't know --  Because today in
the various policies that exist, the power of the registrant, of
course, is preserved as much as possible.  And if someone has
registered a domain name and there's no dispute on the domain name
from a third party or some other potential registrant, the domain
name is theirs, should be theirs, and it's up to them whether they
should be able to keep it or not.

And that's one of the reasons why we are, from the technical
community, sometimes it might look like we are -- if we are very,
very conservative and careful, that this is -- we feel this is
really, really important, and if someone has registered a domain
name, that should stay registered.

Slide 8, please.

So, for the implementation of IDN to work, what we have discovered
so far in this presentation, it's really important that what the
registrant register and what other people use must match when
comparing the two domain names in the various DNS servers in the
world.  Okay.  And it's much easier to define what strings to send to
the DNS servers than to change the matching rule in every DNS server.
And this is the reason why IDNA is defined the way it is.

If you will go to slide 9.

So the actual standard IDNA is implemented between the presentation
layer and the communication layer in every application on the
Internet.  So --  And it's also defined so that it is backward-
compatible.  So if you have an e-mail client or a Web browser that do
not support IDNA, you can still enter the xn-- version, and things
will still work, because what you enter in the presentation layer
will be also what is used in the communication layer, both in DNS and
other protocols, and it works.

So slide 10, please.

So let me come back to the various issues with equivalents and the
reasoning behind variants and why we cannot use any Unicode character.

Here's an example from the Arabic Script Working Group that they
use.  So I shamelessly  borrowed or stole this slide from the Arabic
Script Working Group.  And thank you for the example.  I presume that
some of the people are in the room here.

So if we look at these two, these two strings, we can see that there
is some graphical difference between these two.  But for someone that
don't know Arabic script, for example, I don't, for me, I cannot
really tell whether the round circle or the squarish thing in the
middle is part of a font difference or whether it's actually having
some significance in the meaning of the characters.  It is really the
case that those two are written in different -- with the help of
different Unicode characters, as you can see in the bottom.  The
string to the left is written using five different Unicode
characters, and the string to the right is written using three
different Unicode characters.

Next slide, slide 11, please, which I see, unfortunately, doesn't
have a number.  But the title is "they look the same to us, but not
to a computer."

So here's another example.  If we look at the string to the left in
red, it is the Unicode character with the number 623.  That is a
separate character that is just one Unicode character.  But it can
also be interpreted using two Unicode characters, which is character
654, followed by character 627.

And if it is the case that you have a computer looking at both of
those, the computer, of course, thinks that these two are different,
because 623, which is one Unicode character, is not the same as 654
followed by 627.

But the rules in Unicode and the rules for rendering the actual
glyph say that the two of them should actually look exactly the same.

So this is one of the reasons why the IDNA standard in the IETF say
in this case that 623 is okay to use, but 654 followed by 627 is not
okay to use.

And here is one of the basic rules for IDNA standard that registries
must follow in the documents that you have seen, is that because of
this, it's also important that any second-level domain that is to be
registered cannot use 654 followed by 627.  They are to use 623
instead.

Slide 12, please.  It is also the case that in the standard itself,
slide 12 has the title "when 1 is not 1."  There's also some
complicated pieces in the IDNA standard, and that is that some of the
characters, we think, are so dangerous to mix that we have what is
called context-dependent rules.  And this is one of the places where
this is -- this occurs has to do with Arabic-Indic compared to
eastern Arabic-Indic digits.  You can see the various digits here,
they look almost the same, but in different contexts, you can write
the digits in different ways.  You use different Arabic digits
depending on whether you are dealing with Arabic-Indic or eastern
Arabic-Indic digits.  So one of the rules that we have in IDNA
standard is to say that in the same label, you cannot mix.  If it is
the case that you are using Arabic-Indic digits, the whole label has
to be using those, or you can use eastern Arabic-Indic digits.  But
you can mix.

Because if it is the case that we allow mixing, that might lead to
various different kind of problems regarding confusion, which in turn
might, of course, lead to pretty tragic phishing incidents and
accidents.

We have, though, in the -- which we'll come back to later on, we
have, though, in the actual IDNA standard tried to limit the amount
of contextual rules.  But this is one example where the consensus is
that contextual rules should be applied.

Slide 13, please.

So if it is the case that we look in the Unicode standard and if we
look to the left, all the characters, A, B, C, and D in this example,
we say that when humans look at these, we can say that -- we can
agree that they are more or less similar.

But we have different levels in the standardization and in the
policies to block which one or tell which one of those can be
registered.

If we move to the right, we can see that in this case, the IDNA
standards say that B, the B version of the character "A" cannot be
used at all.

So B is already blocked by the IDNA standard.  But the IDNA standard
might allow both "A," "C," and "D."

If we then move to the right, to registry policy, we can see that in
this case, in this example, very, very simple example, we have a
registry policy that further limit the possible registrations.

The first example is with the "C."  There might be a policy that say
that when someone registers "A," that party also implicitly gets "C,"
just because "A" and "C" are so equal.  So when someone is trying to
look up some --  So when someone registers "A" and register one
domain name, your reality -- or the registrant get two, get both "A"
and "C."

Another kind of policy might be that when someone is registering
"A," "D" is automatically blocked, so "D" cannot be registered at
all.  So if "A" is registered, "D" cannot be registered.  And the
policy can either be that you cannot register "D" at all, you can
only register "A," or it could be, if you register either "A" or "D,"
you can have what you want to register but not the other one.  And
"A" and "D" will never be registered at the same time as a second-
level domain in this policy -- according to this policy.

So we have sort of a filtering that takes all of the Unicode
characters to the left, first of all filters out in the first step
the ones that can be used according to the IDNA standard, and then
you have a registry policy.

Excuse me.

And the registry policy either can implicitly say what domain names
you get when you register something or also what kind of characters
are to be blocked.

But the registry policy, of course, can only -- is only applied to
the actual second-level domain delegation, because when someone
actually have the second-level domain, of course, you can have
contractual agreements that say that you promise to only use these
and those characters in your labels, but we don't have any technical
ways of blocking violations of such rules.  It could be policing and
such things.  But the only thing that we can sort of force in these
standards and technically has to do with IDNA standard.

Slide 14, please, which has a list of code page 600 in the Unicode
script, titled "The Arabic Language is Only a Part of the Arabic
Script Table."

And this is an important issue when starting to look into the
various policies for registries.

And this is that there is a difference between language and script.

First of all, you have the Unicode standard itself, which includes
many, many characters, and then you ever various scripts.  And here
you have an Arabic script, and then a subset of this script are those
characters which are used in a certain language.

And various policies and bundling and variants might be policies
that are built upon language, and some of them can be used based on
script.

So we look at table -- sorry, slide 14, you see the characters in
green, they are the one, Unicode characters, that are used in the
Arabic language.  A subset of the Arabic script; in turn, a subset of
the Unicode.

If you go to slide 15, the next slide, you see in green the
characters that are used both in the Arabic language, the Persian
language, the Urdu language, and the Pashto language.

And as you see, if you look at all of those languages, we use many
more characters from the Arabic script than what is used in the
Arabic language.

Now, of course, if it is the case that you have a registry that deal
with the Arabic language, it is, of course, preferable that they use
the same kind of policy for bundling and variants as other registries
that deal with the Arabic language, first of all.  But it's also, of
course, appreciated and good if it is the case that all registries
that deal with any language in the Arabic script have policies that
actually -- that are similar.  And policies that do not violate each
other.  Otherwise, it might be confusing for the registrants, if some
characters from the Arabic script can be registered in one registry
and not another one.

So the more registries can work on common policies for the same
script, the better.

But I do understand personally that in some cases, of course the
most important thing is to have the same policy for the same language.

But when languages share the same script, like in the case of the
Arabic script, those many languages using it, it is much, much better
if all of those language groups can agree on some kind of policy.

So slide 16, the last slide.  I hope I have been able to show you
some examples of why we have to agree on what codepoint can be used
in domain names, and specifically when we have multiple variations
for expressing the same character.

This policy and these agreements, of course, to large degree, is in
the IDNA standard itself, but it's -- but large part of these
agreements had to be implemented as variants and other kind of
registry policy, and it's better the more global, across language
groups and across script groups, that those agreements can be shared.
And that's why I think it's good to have the Arabic Script Working
Group be a good example of where such agreements have been tried to
be found.

And the last thing is we do need rules both for the TLDs themselves,
which is like what kind of TLDs can we accept to be registered in the
-- when we want to have internationalized TLDs, and also we need
rules in the second-level domain registrations at the registries.

So that's it for the introduction.  And I think we should move to
discussion, I think, or if there are follow-up questions on the
presentation.

But I'll leave it to you, Janis.  I'll leave over the talking to you.

>>CHAIR KARKLINS:   Thank you, Patrik, for this presentation and
explanations.

So we have many people in the room, and I believe that you can see us.

>>PATRIK FÄLTSTRÖM:   Yes.

>>CHAIR KARKLINS:   I hope you can see us.  So there are
representatives of the GAC, but equally, there are also
representatives from different constituencies.

And, of course, priority I will be giving to the GAC representatives.

But in case there are questions from others, certainly if we will
have time, I will allow also others to ask questions.

So now I'm turning to my colleagues and invite them, whether to ask
follow-up questions on presentation or comment on Patrik's
presentation.  Or we also have here in the room Tina Dam from staff,
so she is also available for answering questions related to the paper
itself.

So, who will start?

Netherlands, Thomas.

>>NETHERLANDS:   Thank you, Patrik, for this presentation.  I think
it's very useful.  It gives some insight, but I think it gives
insight in just one percent of the complexity, I think, because it
seems to me much more complex even than this.

I have just a question to try to simplify things.  Basically, what
strikes me is that, what you said, the technical community is very
keen on imposing the standards, as opposed to all other kinds of DNS
protocols which we used to use.

So basically, is what you are saying is that the basic
interoperability of the DNS is at stake if one registry does not use
IDNA?  And let's say in line with this question, what goes really
wrong if, for example, the -- somebody does not use IDNA in the
basic, let's say -- just in the right codes in the basic level on the
top level?  And, yeah, what basically goes wrong?  Because this kind
of horror scenario, which many people on the ccNSO have told us, I
don't get really a grip on this.

Thank you.

>>PATRIK FÄLTSTRÖM:   Okay.  There are two parts -- there are two
different things that can go wrong.  The first one that can go wrong
is nothing that really breaks the DNS protocol.  And that is, for
example, if you are using a different encoding, if you don't use an
xn--, if you are taking the Unicode string that someone could
register and you put something that -- in the DNS that doesn't comply
with that encoding.

If it is the case that you do that as a registry, then other people -
- then people that would like to look at that domain name will not
find it.

So it doesn't really break the DNS.  But it will make the domain
name that is registered by the registrant completely useless.

So the reason why we need to have the same encoding is something I
tried to show.  If we go to -- let's see, if we go to slide seven,
you will see the important thing here is that what the registrant
actually put in the DNS must be the same as what someone is trying to
look up.

So if I register the second-level domain -- or if you register the
second-level domain Thomas in the dot ML top-level domain, and I
would like to look up thomas.ml, it is really important that the bits
on the wire that my client sends to your DNS server or to the
registry of dot ML is after the same bits that has been stored in the
dot ML server to be able to produce a match.

And this is why you see on slide seven the two boxes which have the
word "zone" in it.  You have two arrows going to the box, and it's
really important that what you send in both of the arrows to the box
marked zone must be the same.  That's the first thing.  And I hope
that is clear.

The second reason why it's important to follow IDNA is on the higher
level on confusability.  And this has more to do with the case that
if it is the -- that in the Unicode, you can express the same
character in two different ways.  And in some cases, you can even
express the characters in more than two ways.

And if it is the case that someone registers something that the
registrant believes sort of looks in a certain way, it is real
important to minimize the amount of ambiguity to also reach the same
kind of -- the same goal, and that is that when you have registered
something, that I actually can read through some of that Web page. 
When you have a registered domain name, that I can send an e-mail to
that.

And to maximize that functionality, we need to have an agreement on
what the subset of the Unicode standard to use.

>>CHAIR KARKLINS:   Thank you, Patrik.

Maybe, if I may follow-up question to this one, there has been a lot
of talk that if, in given territory, local registries are using a
variant which is different -- slightly different from, let's say, a
neighboring country, and all those who live in that territory can
access the Web site, but is there any -- let's say if there is
something which does not follow clearly standards but is accepted in
one territory, how that influences the stability of work on the
neighboring -- in the neighboring territories which may use the same
script.

I don't know whether you understood the question, but I think that I
was sufficiently clear.

>>PATRIK FÄLTSTRÖM:   Yes, yes.  And I think there are two parts of
this answer as well.

The first thing is that if it is the case that -- The first thing
that might happen is that if -- if the IDNA -- if the IDNA standard
is not used -- so let's say that different conanicalization forms are
used by different registries, you might think that in a territory, it
might be the case that, for example, the registry together with all
the service providers agree to use a specific canonicalization.  The
problem then is when the end user who would like to look up things
travels to another territory or to Sydney or to Sweden and tries to
do a lookup using the DNS servers and the services that service
providers have in that country then it will not be possible to find
the same domain name as you could when you were in your local
territory with your local service provider.

You see that kind of -- sort of what I call games being played
regarding various key-word systems.  But this is also where we can
draw a line between various key-word systems where the end user is
explicitly using a key-word system that is local to, for example, a
certain service provider as compared to the global DNS, which must be
global.

The second part of the question has to do with if you had, for
example, two registries that uses the same script, let's say the same
Arabic script, but they use different variant tables, what can go
wrong?

Well, for the variant tables, nothing really can go wrong more than,
for example, than if it is the case that you have a second-level
domain, let's say Thomas, that you can register in one of the TLDs
but you cannot register the same domain in the other TLD.

And this means that what is a valid second-level domain in one TLD
is not valid in the other one.  And now I'm not talking about the
ability to register but I'm really talking about with the equivalents
and similar -- similar blockings, but I had an example in my
presentation.

What can be complicated here has to do with the various bundlings
when you, in one TLD, might do a bundle of two second-level domains
in one script, but then in another TLD, another registry might choose
to not do the bundling of the same domain names at the second-level
domain.

That can be problematic in the DNS in the case that you use a
technical thing called the search path when your ISP, when you happen
to connect, is imposing to you a search path that is dependent on
either the first or the second territory where the actual bundling
and the matching that you get depends on whether the search path was
in use or not.

But most of these problems have to do with confusability, phishing,
and other various kind of policing issues.

And I would, for example, be surprised if it is the case that, for
example, my last name is managed differently in the different
Scandinavian registries, Sweden, Finland, Norway, because we are
using a very similar language and we sort of do understand it, we use
the same script.  And as a registrant, I will be surprised if it is
the case that they are different.

Maybe Tina remembers some other examples that she can bring up.

>>CHAIR KARKLINS:   Thank you.  Thank you, Patrik.

European Commission, Bill.

>>EUROPEAN COMMISSION:   I think maybe Australia was before me,
actually.  So I defer to Brenton.  No?  Okay.  You are very kind.

Thank you.

Hello, Patrik.  It's nice to see you again, even if at a distance. 
And thank you for a very interesting presentation.  Your presentation
is always interesting.

I have a question which may be a dumb question, so forgive me in
advance.

I am just wondering what happens with IDN domain names at lower
levels in the DNS hierarchy.

In other words, if the IDNA is respected at the registry and at the
second level but it isn't respected further down at third, fourth and
fifth level, will the same kind of problems you describe happen?

>>PATRIK FÄLTSTRÖM:   The short answer is yes, you will see the same
kind of problems.  And that is one of the reasons -- that is actually
the gating factor, whether we, in the IETF, have -- sorry.  Let me
take a step back.

When I -- I explained that we have two different levels where the
policies -- where this policing can be implemented.  One is in the
IDNA protocol.  The second one is in the registry, which is the
policy that the registries have.

And we have to remember that a registry is someone that is
responsible for the policy and the ability to create domain names
below a certain domain name in the DNS tree.

So the first thing, you are absolutely correct, we have registries
in more levels than the top level.  We have one registry at Cisco for
the cisco.com that set the policy what can be registered there.

I have my own domain name, and I set my own policy what can be
registered in that one, and the same thing for the European Commission.

So we have registries in all levels.  But we have certain things
which are really, really serious, like the example I had with the
Indic-Arabic digits, where we have said we have something that is so
important and it creates such a great confusion that we must have the
policing in the protocol itself, which is part of IDNA.

Because that is something that we implement -- will be implemented
in all softwares that everyone uses on the globe, regardless of the
territory and regardless of the local policy.

And the cost of that, that can only be violated if you use a soft --
if some software is in use that is not according to the standard. 
Which of course protocol violations happen all the time, but it's
actually pretty serious.

The second kind of violation has to do with when a registry on a
lower level in the tree is not -- is having a broader policy than
what a higher-level registry is forcing.

For example, the Swedish top-level domain today allow registration
of a few non-Latin characters and Hebrew, and the Hebrew script, but
it doesn't allow registrations in the Arabic script, regardless of
language.  What I can do as a holder of a domain name in the dot SE
is of course to come up with a policy that allow me to register
domain names in the Arabic script.  And when I do that, of course I
can choose to not follow any of the bundling or policies that any of
the registries for the Arabic script is using.

So absolutely, you can see the same kind of problems lower down the
tree, but it is the case that when you -- but it's still the case
that when you are dealing with things at the top-level domains, the
higher up you are in the tree, then it is more and more dangerous and
there is a higher risk that the problems that I just pointed out
earlier will create a larger problem.

So the higher up the tree, the worse the problem gets.

But if there are really, really bad problems, then we have chosen to
implement them in the IDNA protocol itself.

Of course, some people might say why don't you implement all
policies in the IDNA protocol, but, for example, there are value
scripts which are using characters where you will have and you have
the interest of interesting different rules in different territories.

So there are various bundling that you would like do in one context
in one territory for one language, one script, but what you don't
want to have for the same codepoints, Unicode in other contexts.

So there is a certain freedom that we think must exist for the
registries.  But every time you allow some freedom, you, of course,
also create that kind of risk.

And that is a balance that is discussed in the IETF, but that is
also where the line is drawn.

>>CHAIR KARKLINS:   Thank you, Patrik.

Australia, Brenton.

>>AUSTRALIA:   Thank you, Patrik, for your presentation and I think
what is quite a compelling case for the need for standards.

I have quite a basic question which I think you were leading into a
little bit in the last question about policing of standards.

But really, my question is what are the mechanisms for enforcement
of standards in a range of different places?  And do you think
stronger enforcement is required to make sure that we don't come
across a number of the problems that you highlighted in your
presentation?

Thanks.

>>PATRIK FÄLTSTRÖM:   This is something that is -- Let me just say
that this is a really, really good question, and this is something
that I think should be discussed in more context than just
Internationalized Domain Names.

And the reason for this is that a lot of discussion is going on, for
example, in the regional registries regarding compliance to the DNS. 
How do you set up the DNS?  Do you accept lane delegations and
various other things.  And I also know it has been discussed in the
ICANN context here and there.

I myself have also been looking at the quality, as I call it, on
delegations in the SE top-level domain and together with the dot SE,
that there are people around there in Sydney and you can talk with
them, we have found that there are approximately between 17 and 20%
of the registrations or delegations that have errors.  And I know
that findings in Netherlands and in France give similar numbers. 
Between 15 and 20% actually have errors of various kinds.

This number -- there is also risk, of course, that this number goes
up when we introduce things like DNSSEC or when you introduce
Internationalized Domain Names.

It has also been discussed in an eNOM context because when dealing
with telephone numbers, we are moving into different legislative
domain with explicit requirements on functional ability and their
ability to resolve e164 numbers.

Now, where has all of this discussion gone?

First of all, there are many parties in the world, including
registries, that try to keep track of the quality of the domain names
that is in their domain.  And that is something that I think is a
good thing.

But the question is, of course, how do you do policing?  How do you
ensure that someone -- How do you decide, first of all, what is right
and what is wrong?

What the findings have been in the RIPE community where I have been
active and also what we are looking at in the dot SE top-level domain
is that it must be first of all a broad consensus and discussion on
what is right and what is wrong.

The second thing is that the actual policing is something that
doesn't have to be done by the registry.  It might be the case that
anyone running DNS might like to have some monitoring of their domain
name, and there are many monitoring services that are out there in
the world.  So it's sort of -- sort of a commercial market exists for
those kind of policing services or watchdogs or verify that my Web
server is up and running, verify my DNS server is up and running and
correctly set up and, otherwise, warn me.

Then, of course, the registry itself can also do policing and inform
the registrants that their DNS -- that their zone is not behaving
correctly or that something is wrong in the register there.

I think the conclusion so far has been that registries probably
should be a little bit careful with that, and the best way of dealing
with it is that, if it is the case that the registry has an opt-in
mechanism.

And the reason for this is very often the errors are made by the DNS
operator or the -- or the registrar, not so often the registrant.  So
what the registry would like to do is to contact the DNS operator
when there is something wrong.  But of course, the DNS operator might
not be the same entity alleges the registrant.  And if the
registrants start to get all of these warning messages or error
messages, there might be more confusion that creates more harm to the
DNS system as a whole than if it is the case that no -- that no
warnings or no policing is done.

Now, for the specific thing regarding what is registered in the
third-level domain in the case of delegations of the second-level
domain, sometimes it's hard to actually do policing there, because
even though you have a contractual agreement, it might be the case
that the registry is not allowed to do some transfers to watch what
is actually registered.  And it might be the case that the tree is
very deep.

So you can simply not, as a registry, look at every domain name that
is registered there.  But of course having a policy that say that you
are only allowed to register this and that below in the tree, that's
something that, of course, can be done.

But technically, to police things is very, very difficult.

>>CHAIR KARKLINS:   Thank you, Patrik.

Let me ask you a follow-up question to this one.

We, of course, are discussing here a staff proposal, version 3, of
the fast track.  And a question of enforcement of standards is one of
those, until now, unresolved.

I think that here we have found the way forward in terms of
adherence to standards, but we are still struggling with how to
resolve issue of policing or monitoring.

And I would like to run with you one idea, one question which
potentially may be a solution.  It is to say if ICANN develops kind
of procedure of monitoring adherence to standards, which would become
a roadmap for IANA people who are dealing with DNS on a daily basis,
would that, in your view, be a technically sound proposal?  I mean
from technical perspective, would that be enough?  Or would that make
any difference if, for instance, as some suggest, that we need kind
of very strict agreements or contracts to monitor and to police
adherence to standards.

So the question is, would a procedure for IANA people to follow be,
from technical community's perspective, sufficient to monitor
adherence to standards?  Or do you think we should have something
stronger than that?

>>PATRIK FÄLTSTRÖM:   And now you are talking about the policing
what is registered as a second-level domain; right?

>>CHAIR KARKLINS:   No.  Also on the top level.

I'm talking about fast track -- fast track all the papers and
requirements, introduction of IDN ccTLD under fast-track procedure.

>>PATRIK FÄLTSTRÖM:   Okay.  That consists of sort of two things.
first of all, the actual TLD string must adhere to certain
restrictions, and the second thing is that if I remember correctly,
and now I want Tina to jump in here, is that it's also the case that
from the technical community, we would like to have the registry that
applied for the top-level domain to have a policy for registrations
in the second-level domain.

Is that your -- sort of your question?

Your question is, then, how to police that or how to enforce it,
that those requirements are fulfilled; right?

>>CHAIR KARKLINS:   Yes.

>>PATRIK FÄLTSTRÖM:   Yeah.

For the first one, regarding what string is to be selected, from the
technical community perspective, we see that as part of the
application process where the string is accepted.  And as I mentioned
and showed, did show just by showing you the characters that are
allowed in Arabic, it is pretty difficult to actually say beforehand
exactly what codepoints and combination of codepoints in a general
sense, without any context, can be good or can be bad.

But, on the other hand, when you see a proposed string of Unicode
characters, it is very, very simple to say whether that is something
that is dangerous or not, if you see the difference between these two.

Basically, it's very hard to come up with very, very, very explicit
rules as a mathematic formula to say whether something is okay or
not.  But when you look at something, it's very easy to say whether
it is dangerous or not based on the characteristics of the codepoints
and in the order the codepoints are, et cetera.

So I think for the top-level domain, I see that as part of the
application process, and when the application has passed, then you're
done.  You don't need to police that anymore, of course.

For the second-level domain, I think that the important thing from
the technical perspective is that the registry is sort of promising
to follow IDNA, and it's good if it's coming up with -- and I think
that is also what is required in the fast track, that they actually
have a policy for what codepoints and what variant tables the
registry is going to use.

And exactly how that has to be implemented in the actual agreements
and whatnot, I don't know because Tina knows the actual process much
better than me on where that can be verified and whether the contract
is really needed.

>>CHAIR KARKLINS:   Thank you.

Yeah, Tina, if you want, please.

>>TINA DAM:   I was going to be really brief.  Hi, Patrik, just
because you mentioned me a couple of times.

I didn't want to just sit silently in the back.

But, yeah, you got it right on point.  But enforcement of some of
these policy requirements are really difficult to find a good way of
dealing with, because so far, we've said, well, the tables, the
variant tables, and the registration policies, and so forth, are
going to be set by the local registry.  But now that we're moving to
the top level, we actually have had some comments and concerns around
some entities, at least, in the community wanting ICANN to enforce
that and, you know, go deeper into, for example, how is the content
developed for an IDN table and what is that content, compared to
other tables, for example, if it's in the same script or the same
language, and should there be some part of ICANN who should, you
know, validate that.

And we haven't done that so far.  And the papers that are out right
now are also not proposing it.  They're going slightly a little bit
in that direction by saying, well, if we get two tables that are
different, but they're for the same language or the same script,
we're going to compare them and we're going to ask the second
submitter or the latter submitter, "Why is your table different than
the first one we got?"

That's not necessarily the same as saying, "You have to change your
table," but we are going to -- we are -- well, the proposal is that
we're going to do a quick little check on that.

So it's going slightly in that direction.  But, you know, direct
enforcement of it, I think, is really difficult.

So it is a good question.  And I think it's something that's really
relevant to talk about.  You know, how far can ICANN go or should
there be some other kind of enforcement mechanism in that area.

>>PATRIK FÄLSTRÖM:   And let me continue.  Thank you, Tina.  Let me
continue with what Tina just said, is that we have two different
scenarios here.  And the first one is when you have registries that
behave in a good way, and they really would like to have a different
variant table for Swedish for some reason than what has -- what we
have defined in Sweden, because the language might be used in
different countries and whatnot.  And, for various reasons, the
various -- the world has come up with two different variant tables.

And personally, speaking from a strictly personal point of view, I
think that we need to -- to a certain degree, we need to trust
parties that say that, no, this is the policy we would like to use.

And so far, the problems I have seen regarding registration in the
second-level domain for IDNA has not been where registries actually
have come up with a policy.  Because that has always sort of worked,
because they have been using in all cases an open dialogue and
multistakeholder discussion in that local community on what variant
tables to use, and they have very often been talking to other parties
in the same language group.

On the other hand, where the discussion has not happened and when
there has not been a policy, that's where we see more problems. 
Where there are no variant tables, where they have swapped the
variant tables after a while, basically, where they have not done
their homework, then things have not worked.

So I sort of think that it should be enough for IANA to verify that
in a very light procedure where IANA, as part of the application,
they verify that a point to two variant tables and language tables
exist.  And if it is the case that they -- as Tina said, maybe if it
is the case that they are pointing at the language or script table
from the Arabic script but it's different from some other language
table for the Arabic script, in that case, a question is asked why. 
And if it is the case that the -- but then, of course, the answer is,
"No, we need this because," who is evaluating whether that is a good
enough reason?  I don't know.

>>CHAIR KARKLINS:   Thank you, Patrik.

Norway.  Ørnulf.

>>NORWAY:   Thank you, Janis.

Yes, hello, Patrik, thank you very much for your presentation and
your interesting inputs to this discussion.  And apologies for
repeating probably something that has been said previously.  And I
don't want to derail exactly this discussion, but just for my
clarification, just to repeat the thing that you mentioned in the
beginning regarding the two things that can go wrong.  So, basically,
the first thing that can go wrong is that some domain names may not
be resolved.  That's the first thing.

And the second is that some domain names may not be globally unique.
That is the second thing that can go wrong, as you were mentioning,
if you then move your computer to another part of the world and then,
of course, the name servers do not operate according to whatever
somewhere and, of course, may not be globally unique, and then that
can have several consequences, of course.  But that is the -- those
two things that can go wrong.

Thank you.

>>PATRIK FÄLSTRÖM:   That is absolutely correct.  And you -- you are
right on the spot.

Let me just try to expand on your second point on some domain names
might not be unique.  It's even the case that that can be divided
into two different kind of problems.

The first is, if it is the case that you move to a different
resolver or a different application that do a different
canonicalization, which means that when you type in exactly the same
Unicode string, it might be the case that you're sending two
different DNS queries over the network, which might have the -- which
might have the implication that you either cannot resolve the domain
name that you wanted to resolve or it might be the case that you get
a return -- a response back that you did not -- that you did not
expect.  That's one problem.  And that's why we need to use the same
standard and the same applications all over the place.

The second thing of uniqueness has to do with human interpretation. 
And this is where we move into the variant tables.

If it is the case that, for example -- I read -- if it was the case
that we had a variant table for Swedish characters, for example, and -
- the Swedish or Norwegian characters, and I use my domain name,
Fältström, in dot SE and then type in something that I think looks
like Fältström in dot NO.  If it was the case that we had variant
tables and had different variant tables, then I, as the end user,
would be surprised, and I would think that the domain names were not
unique or could not be resolved.

But that is something that is not on the bits, on the wire level. 
It's on the human consumption of the domain name level, in the
abstraction layer, so to speak.  And that's why we should, as much as
possible, try to have the same variant tables in the same script or
in the same language groups, although it is not needed -- it's -- as
I said earlier, it is impossible to enforce that across language
groups and scripts, because there might be other contextual reasons
why the variant table should be different.

>>CHAIR KARKLINS:   Thank you.

I have three requests, from Egypt, U.K., and European Commission.

And taking into account that we have five to ten minutes remaining,
five to ten minutes for this session, maybe these, then, would be the
last questions.

Egypt, Manal, please.

>>EGYPT:   Thank you, Janis.  And thank you, Patrik, for the very
interesting presentation.

Now, talking about where to implement the rules and where to draw
the lines, the Arabic Script Working Group, for example, was
discussing that we shouldn't implement diacritics, for example, in
registration names.  And being part of the language, we could not
decide prohibiting it on the protocol level.  So it had to be
protocol-valid.  But, still, what if we agree that we don't want to
see it in the registrations, at least at the time being, especially
that they would open the door for security threats, confusability,
and burden and cost on -- in bundling and things like that?

I mean, where should such characters fit that are protocol-valid but
should not be registration-valid?

This is one question.

Another quick comment.

Although I fully respect ICANN and IANA's being reluctant to
validate submitted tables or look into the content of submitted
tables, but I personally think that there should be some housekeeping
at the IANA side.  Otherwise, the repository is going to be -- I
mean, could be a mess and could be very difficult to compare tables
to each other and could not be helpful in asking registries to look
at past tables before submitting their own.

Thank you.

>>PATRIK FÄLSTRÖM:   Yeah, I -- thank you very much for the question.

I think, first of all, it's a very good question of you on what to
do with characters in Unicode which are valid but a registry feel
some reluctance of allowing those for various reasons.

And what I encourage any registry to do is to not immediately jump
to a situation where they allow registration of any character in the
world.

I think that a registry should, even though you have a variant table
that include, for example, all characters in the Arabic script, I
think a registry -- it is good if a registry is opening up carefully.
Because you can always add more characters that you're allowing, but
you cannot -- you cannot remove characters that you don't want to
allow to have registered.

So, for example, if you see a character that you are nervous about
in Arabic script, I don't see any reason for you to allow it in Egypt
immediately, on the first day.

Of course, each sunrise that you are doing when you are accepting
more characters is a procedural burden by itself.  And you need to be
able to -- need to decide how to handle that.

But on the other hand, I think that limiting in the registry policy
on what can be registered is something that I think is good.

That said, if it is the case that multiple registries, for example,
the ones that participate in the Arabic Script Working Group, first
agree on what characters to allow from the Arabic script for the
various languages, and then some of those registries are moving away
and implement their own subset of the characters, but, of course,
might create some stress on the cooperation between the registries. 
So I think in some kind of cooperation where registries try to agree
on having it the same or a similar policy, I think it should be part
of that discussion on how to do the sunrise and how to enable all of
those codepoints.  Because if it is the case that there might be some
risks with some codepoints, maybe they should be added in the second
step.

But to answer your question very precisely, where you have to block
characters which you don't want to or which you are nervous about
which are Pvalid, that is in the registry policy.

>>CHAIR KARKLINS:   Thank you.

United Kingdom, Mark.

>>UNITED KINGDOM:   Thank you, Janis.

And, hi, Patrik.  And my thanks also for your joining us at such an
ungodly hour for you, and for giving us such a useful and very
interesting presentation in which you emphasized the importance of
script groups being established to ensure that the variant tables are
as complete as possible.  And that is a very important message for
ensuring global inclusivity in implementation of the IDN process. 
And the Arabic Script Working Group is an exemplar of best practice
there, and their achievement is particularly impressive.  And your
slide 15 is a very vivid demonstration of that.

I was wondering what the position is with other major scripts and
whether there is effective joint working there or whether more needs
to be done with particular scripts to ensure that the variant tables
are as complete as possible and that the DNS rules which you also
emphasized are applied as effectively as possible.

Are there any specific difficulties that you might draw our
attention to with regard to other major scripts?

Thank you.

>>PATRIK FÄLSTRÖM:   Thank you.

What I have seen, there might be other people in the room here that
can talk about their own individual experience.  But what I see from
my limited viewpoint here in Sweden is that the cooperation across
language groups was something that started, actually, in Asia with
the cooperation in -- between the various languages and registries
using the Chinese and Japanese script, specifically, the Chinese
script.  And a lot of work has been done there.  And I see a lot of
progress there.

I see a lot of progress regarding the Hindi script, mostly in India.
I have seen progress in the Arabic script, as you said.  I have seen
work in the Hebrew script.  And Cary, which I believe is in the room,
can talk more about that later on in the coffee break.  

To be honest, I'm a little bit nervous that we will see more of the
problems when later moving to the Latin script.  Because, for
example, Swedish, as an example, is used both in Sweden and in
Finland.  And I do know that there is cooperation between the various
registries.  But I'm a little bit nervous that we need more
cooperation between, for example, all the registries using Spanish,
all the registries using other different languages.  And,
specifically, I'm a little bit nervous of, for example, all the
various registries that use the -- from the Latin script, the "A"
with umlaut, that we have not talked enough.  And even though I use
those characters myself, I don't even know whether -- what kind of
implication might be if we are using -- if we are going to use
variant tables and what kind of problems we might have.

So, yes, there might be various cases where we need to have more
work.  But for the large sort of difficult script groups where we
also have billions of Internet users, actually, I'm not nervous.  And
that is the Hindi, Arabic, and sort of Chinese, Japanese, Korean
script.  I see good work in those large script groups.  So I'm not
nervous.

>>CHAIR KARKLINS:   Thank you, Patrik.

I think in Cyrillic script group also, there is cooperation between
countries who will be using Cyrillic.

>>PATRIK FÄLSTRÖM:   Yes, thank you for pointing that out.  I forgot
that.  Sorry.  Yeah.

>>CHAIR KARKLINS:   European Commission, Bill.

>>EUROPEAN COMMISSION:   Thank you.

And we'll let you go to bed very soon, Patrik.

Quick question.  Feel free to give me a very quick answer.

I understand that some ASCII TLDs have allowed deployment of IDNs at
the second level already.  And I just wondered --

>>PATRIK FÄLSTRÖM:   Yes.

>>EUROPEAN COMMISSION:   That's my first question, is it true.  So
it is.

>>PATRIK FÄLSTRÖM:   Yes.

>>EUROPEAN COMMISSION:   Are there any lessons we can learn from
that?  Are there any experiences that have been particularly bad or
has it been relatively painless?  Or is there anything to learn? 
Thank you.

>>PATRIK FÄLSTRÖM:   I think it has been more painless than what I
expected.  I thought it would be more painful.  And I thought we
would see more problems with applications, which you have not seen. 
I also thought we would see more confusion with the end user, for
example, when the end user go to registrar and want to register a
domain name, what do you want to register, is it the Unicode or is it
the xn-- version?  But most registries and registrars have found
that, yes, the end user should enter whatever they think they enter
in Unicode, but the actual contractual agreement is the xn-- version.

Okay.  So that has resolved itself actually pretty easily.

The only places where I have seen some confusion are the registries -
- and this goes back to the question from Egypt -- are the registries
that may be open for too many codepoints the first day.  So they had
registries that could not handle all the characters.  And what
happens then when you do a transfer, et cetera, et cetera.

So a careful sunrise and opening up with the languages that the
registries and registrars know about is very, very helpful.  And I
think that is the lesson we have seen.

So it's good to start with the local languages in the local
territory, simply because of help desk issues.  When someone try to
register something in the registrar and the wrong thing happens, or
at least the user things the wrong thing happens and calls help desk,
it's pretty good to be able to talk about the characters that there
might be some confusion about.

>>CHAIR KARKLINS:   Thank you, Patrik.

And, indeed, I -- on behalf of the GAC and all of the people in the
room, I thank you very much for this presentation and for the light
you have shed on this issue, which is far from simple and far from
understandable.

So I believe that we are now much better prepared for formulating
our views on proposed policy paper by ICANN staff.  And I would like
once again to thank you.  And I think that Patrik deserves a round of
applause.

[ Applause ]

>>CHAIR KARKLINS:   Thank you, Patrik.  And good night.  Sleep well.

>>PATRIK FÄLSTRÖM:   Bye.

>>CHAIR KARKLINS:   Bye.

So now we are breaking for ten minutes.  And at 10:30, we will have
two sessions.  The first one, Greg Rattray will be briefing on
ICANN's plan to enhance Internet security, stability, and resiliency.
And afterwards, we will have a joint session with the SSAC and RSSAC,
and we will be addressing questions like signing the root, deployment
of the signed root, scaling the zone, and the SSAC review questions.

Ten minutes' break.  Please be back in the room at 10:30.

(Break.)  



>>CHAIR KARKLINS:   May I ask to take seats.  We're starting in a
second.

So, ladies and gentlemen, our next session is devoted to issues of
Internet security and stability.

We will start with the presentation of ICANN's chief Internet
security advisory, Greg Rattray, and he will introduce the ICANN plan
to enhance ICANN security, stability, and resiliency.  He will
explain to us what ICANN is doing in this field and what ICANN is not
doing in this field.

And after that, we will have a joint session with the SSAC and RSSAC.

Without further delay, I am turning microphone to Greg.

>>GREG RATTRAY:   Thank you, Janis.

And I appreciate the opportunity to come in and talk to everyone
here about the plan that we've developed on this subject.

The briefing is ten, 12 slides long.  It's really an effort to try
to introduce you to the boundaries around the plan and some of the
substance within the plan.

So with that, I think we'll go to the next slide.

I wanted to start, because the term, you know, "security" and then
"Internet security, stability, and resiliency" can mean a lot of
different things.

And what -- ICANN's role there has not been defined in a planning
document like this before.

So I thought it was very important to make clear as I have worked
with the staff and the board to develop this plan, you know, what we
were trying to accomplish through putting this all down on paper,
really, for the first time.

Most importantly, and I think especially in the context of this
room, it's trying to provide the community some role definition about
what ICANN does and doesn't do, as Janis mentioned just a moment ago.
And then, more broadly, because these activities cut across the wide
range of staff and supporting organization, advisory committee
activities within ICANN, to try to put that all down in a single
location so that we can tick off or account for each of those
programs, activities, and the resources.  The ICANN strategic plan
calls for the creation of this document in explicitly providing the
community insight into our activities and the resourcing of those
activities.

So what the plan -- which is here, in terms of a document, which you
can see is a reasonably lengthy, 50-page document in toto -- does is
really depict for the community what we're doing, what we plan to do
as part of our FY '10 operationally plan.  It is not a document
that's a think piece that points out broad conceptual new paths for
ICANN in this area.  It really is an effort to try to give the
community a document that provides for buy-in on what the starting
point is regarding ICANN's role on security, stability, and resiliency.

So the thing is structured around each of the sections of the plan,
so it's pretty linear in that fashion.  So the first section of the
plan, really, in a very short manner talks to what the plan does. 
I've already started to do that.  Role, programs and activities.  And
you will see, if you get a chance to look at the plan, which had been
posted for public comment.  The public comment period closed on the
19th of June.  The last portion of the plan is an annex that shows
our specific investments for FY '10 in these areas.  And, as I've
mentioned, really, we see this plan as an integrated part of what
ICANN does in its process of defining strategic goals and doing
operational planning and budgeting.

The next section is, again, a relatively short section.  Really, it -
- the document does not try to lay out all of the potential threats
and problems related to security, stability, and resiliency in the
Internet, but does, you know, address the fact that we have a growing
amount of misuse of the Internet and that oftentimes that misuse
involves using the unique identifier systems.  I'll probably mention
the Conficker worm for those who understand that particular problem
that has been upon us in the Internet, and the domain name system for
about the past about six months now and continues to be an
operationally significant part of our activities.

But that type of Internet concern is very much intersected with the
operation of the unique identifier systems, in this case, the domain
name system.

And ICANN right in its bylaws, and there's a quote on the slide, the
first article of its bylaws says that ICANN's mission is to ensure
the stable and security operation of the Internet's unique identifier
systems.

So we -- with that challenge, we say the plan provides the community
a road map for what we plan to do in this area.

So this slide is, I think, a very important slide, again, for this
audience, which is trying to be clear about what ICANN's role is and
isn't when it comes to security, stability, and resiliency activities.

The first bullet, I would argue, is a little vague.  But we're going
to go a couple slides down and look at specific programs.  But ICANN
focuses its security programs on its core missions related to the
Internet's unique identifier systems.

And then there's three bullets, important bullets, about what ICANN
does not do, which is to be an operational policeman combating
criminal behavior.  ICANN is not involved in the broader national
security issues of cyber-espionage and cyber war and does not have a
role in what constitutes illicit content in the Internet.

It will, however, and has in a continuing way going forward
participated in activities with the broader both Internet communities
and cybersecurity communities to combat abuse of the unique
identifier systems.  And, again, the combat of the Conficker worm of
late has been really a focus area for us.

The plan in section 4 really just lays out all the areas across the
ICANN staff that work on this, as well as the roles of the supporting
organizations and advisory committees.

With regard to staff, I lead a small team on the ICANN staff that's
called the security team.  But the DNSSEC implementation efforts with
-- that ICANN's partnered with the Department of Commerce and
VeriSign on are conducted through the IANA portion of the ICANN
staff.  And similarly, the compliance on issues such as the
implementation of WHOIS is conducted by the compliance department and
the services staff in ICANN.  So the plan tries to clearly identify
all of the elements of ICANN that are working on security and
stability-related problems.  As well as pointing specifically to the
SSAC and the RSSAC as advisory committees, I will talk a little bit
later about what the plan says related to the role of the Government
Advisory Committee.  But it basically identifies those.

And with regard to the SSAC, in particular, they have had a
historically very vigorous role.  It continues to be so.  They --
Steve Crocker, the chair of the SSAC, will be briefing after me.  So
there's a close integration between the staff and the SSAC in terms
of activities.

Next.

So I had mentioned a couple slides back that there's a section that
really does lay out where we do think our core focus areas are in
this plan.  It's section 5.  So this -- and I'll try to touch on
without, you know, reading in depth the bullets on this slide.  But
it's really an effort to show the community where we are focused and
where we think we have a participatory role but not necessarily
directly responsible.

So where we are clearly responsible is for the operation of the IANA
functions as the highest priority.

ICANN does work with a wide range of organizations, players, some
contractually obligated in the generic top-level domain space,
collaboratively in the country code top-level domain space, to
strengthen the security and stability.  One aspect of that is, we
have, particularly with the SSAC, been engaged in working on the
DNSSEC protocol implementation as one of those things that can be an
enabler for stronger DNS and addressing systems.

ICANN does work with registries and registrars directly in
collaborative response, as well as we have a program that works with
the ccTLD community to provide basic training regarding how to do
attack and contingency planning for the smaller, less resourced ccTLDs.

We certainly feel directly responsible for the security and
stability of our own assets and services.  We have an internal
security and business continuity planning effort.  And we do
participate in broader forums such as the IGF and activities related
to security, stability, and resiliency of the Internet as a whole.

Next slide.

I don't think it's probably useful to try to just read every major
heading here on the slide.  But what the slides do provide is a look
at the structure of the document, which is intended to parallel, you
know, what I had just gone through regarding the priority of our
programs.

So the first portion of this section 5 of the document lists all the
things that we're doing regarding IANA operations in terms of root
server operations, both our operation of the L root specifically, but
also with the root server operator communities.

The second portion of this section of the plan is -- goes through
the fairly extensive set of activities with both the G and ccTLD
registries, as well as how we work with the registrars in this area. 
It does mention the fact that we've -- see ourselves as
collaboratively engaged with the entire DNS community in response to
malicious abuse activities and have facilitated some broader
discussions about security, stability, and resiliency risks to the
domain name system.

Continuing on, really, with this -- what is a pretty meaty or long
section of the document, section 5, it also talks to the
relationships with the Number Resource Organization and Regional
Internet Registries.  It does point to specifically our internal
corporate security and continuity operations, talks to the roles of
the different supporting organizations and advisory committees, and
then points to the fact that ICANN does participate globally through
the -- its global partnerships' staff, but in a wide range of
activities in many regions as well as global forums, and the fact
that in terms of security and stability-related dialogues, we are --
we have been engaged and will continue to engage in those dialogues.

Right at the bottom of the slide, but cut off, I highlighted the
"working with governments" portion of the plan, which is section 5.6.3.

What that section says is, really, that we would like to work with
the GAC and really use this forum as the place where we come in and
describe on a regular basis the sets of things that we're doing and
seek feedback on documents like this plan or our activities.

And we will working with the chair of the GAC and the committee as a
whole to do that in the most effective fashion going forward.

The next couple slides and another large section of the plan, talks
to what we will do in what is our fiscal year '10.  Many of you may
know, but many may not, that ICANN's cycle for planning and the
conduct of its activities works from a July-to-June.  So we are about
to end what we call our fiscal year '09 set of operations and
activities and about to initiate fiscal year '10 after this meeting
when the board approves the fiscal year '10 operating plan and budget.

So what you see in this section of the plan and on the slides for
the next couple slides is just a list of the types of things that are
really focus areas.  I didn't put everything in that 15-page section
up on these slides, but tried to focus on some of the major sorts of
activities that are ongoing.

So with IANA operations, DNSSEC implementation is clearly a major
portion of that.  But working with our partners in that area.  Other
things, like, you know, the automation and improved authentication
mechanisms that can be used in IANA will be major activities.

We are continuing to work on -- as part of the root server
operations community and really want to try to get a voluntary
program of contingency planning and exercises initiated with the root
server operations.

With the gTLD registries, really, the focus is very much on the new
gTLD process, understanding concerns.  We have four overarching
issues which you've probably been made aware of, two of which have to
do with security, stability, and resiliency: the understanding of
whether the number of new gTLD and IDNs as well as technical
implementations, such as DNSSEC and IPv6 glue records, will present
any challenges at the root zone level.  There's a specific effort
that's been discussed at this Sydney meeting regarding making sure
that we've analyzed that and provide the community findings.  And
then there's another specific effort on the potential for increased
malicious conduct as we create new gTLDs.  And we'll be putting a lot
of effort, particularly in the next couple of months, to making sure
that we've clearly understood those concerns and build remediation
measures into the new gTLD program.  And I have a specific managerial
responsibility for that aspect of the new gTLD.

With ccTLD registries, I mention we've instituted what we call an
attack and contingency response planning program, really, with the
sponsorship of the regional ccTLD associations.  And we've done five
of these under the sponsorship of, I think, all of the regional ccTLD
activities, associations.  I believe that's been very well received,
and they've asked for a deeper technical layer of training there
which we are going to collaborate with ISOC on creating.

Some other initiatives for next year.  Contractual compliance. 
There's a, you know, strong attention to the fact that the
obligations with the revised RAA and as we move forward into the new
gTLD, that ICANN's role in ensuring with the gTLDs that those
obligations are taken into account by our contracted parties and that
we are doing audits and taking measures if we do not see the
performance we need to as a strengthened contractual compliance
department within ICANN.  

The response to malicious abuse of the Domain Name System, there has
been a very active discussion in the CC tech day yesterday, and it's
on the agenda for this afternoon in the ccNSO about how the CC
community that was the subject of the major recent variant of the
Conficker worm, how well they reacted and what they need do to
collaborate going forward in these situations.  We have been very
much a part of that dialogue and want to continue to enable, as well
as we can, those sorts of activities.  So that will be a strong focus.

And in terms of our internal security and continuity operations, we
have built both risk management, business continuity, in addition to
security programs, and we are continuing to document those in a
fashion that will allow us to move forward.

And then in partnership with the global -- in partnership with the
global partnership team, led by Theresa Swinehart, the security staff
supports Theresa's team in their global engagement efforts in terms
of trying to work with stakeholders about ICANN's role and what we
can contribute.

Next.

And this is just an example slide.  The last portion of the plan
provides these matrix slides about what we specifically plan to do in
fiscal year '10 to provide deep visibility, in my estimation, as to
our objectives, deliverables, and the resources committed so that the
community understands exactly what we plan to do.  We can be
accountable for delivering on those things and what resources are
invested from ICANN in these activities.

Janis, that's it for the briefing.

>>CHAIR KARKLINS:   Thank you, Greg.  And I also would like to thank
you for the time that you devoted to make presentation to the GAC
during the conference call in the run-up to this meeting.

So now I'm turning to colleagues and see whether there are questions
or comments in relation to Greg's presentation.

Italy, Stefano.

>>ITALY:   Thanks.

So I very welcome this interesting presentation from the ICANN
staff.  And the theme of security is, of course, a theme that is a
key in the -- also in the policy aspects, especially if we see the
relation of ICANN with the NTIA and the U.S. government.  But not
only that, also in any future plan of the organization, the security
and stability is one of the most important aspects.  So I very
welcome this presentation.  

And what I would say is that security has an enormous amount of
aspects that goes from robustness, resiliency, stability, and then
even trust.  That is more soft, but in any case, is something very
important for the users and for the Internet community.

And it is important to understand that this is made for the security
of DNS, but in another way, we can say that, especially for policy
aspects of the GAC, we sometimes ask questions and want to know also
the relation of DNS security toward, in front of the global security
of the Internet.

So it is also important that we have this general perspective.  And
I see in the presentation that this is the case.

And of course the continuous interaction with the Security and
Stability Committee and the Root Server System Committee.  So it is
something that is growing as an important within ICANN, and we
welcome that.

Thank you.

>>CHAIR KARKLINS:   Thank you, Stefano.

Any other comments, questions?

>>GREG RATTRAY:   Looks like there's one down there.

>>CHAIR KARKLINS:   Australia, Brenton.

>>AUSTRALIA:   Thank you, Greg, for the presentation.  That was
extremely valuable, and I think it yet again reinforces the
importance of security issues to all aspects of ICANN works and also
to the work of this committee itself.  I think we need to understand
on an ongoing basis the various threats that are coming in, because
they affect all the policies that we actually implement.  So I think
it's extremely valuable.

There's two questions that I have on a couple of issues that you
mentioned.  One was that there was -- you mentioned a response to
malicious conduct that may arise from the new gTLDs.  I wonder if you
could elaborate slightly on that.

And then the second aspect, which I'm not really across, is the
potential for increased contractual -- I think compliance or
obligation, I'm not really sure, and how that actually might be
implemented in terms of a practical contract with users or
participants going forward.

Thank you.

>>GREG RATTRAY:   I can address both those.

With regard to malicious conduct in the new gTLD area, in the two
versions of the Applicant Guidebook that sets the rules for the new
gTLDs, in the public feedback, you know, there was a concern
expressed by a relatively large number of stakeholders about whether
increasing the number of gTLDs and how registries were created and
the systems that they put in place with their registrars might
increase the opportunity for activities like phishing and financial
fraud.  And that as we implement those procedures and allow new
registries to stand up, that we needed to make sure that we built in
specific measures that would limit the possibilities for that.

So we're at the stage of making sure we understand those concerns
and start to develop specific remediation measures.

There's a set of public consultations through July in New York,
London, and Hong Kong that will actually include this along with the
issues related to trademark protection to make sure that we are
addressing the community's concerns.

So that's the first one.

In terms of contractual compliance, it was more a note that we are
going to try to more vigorously implement what is now with the RA- --
the -- I'm trying to get the right technical terminology, but the
recent RAA amendments have actually given more contractual
obligations to the registries in some of these areas in terms of
needing to comply with the ability to identify registrants.  And we
are stepping up in the compliance team, both more people, in a very
kind of -- not blunt way, but to do compliance, you need to have
staff.  So it was a note that the compliance staff is stronger and
will begin to do audits in addition to just responding to complaints.
We're actually going to go out and proactively look at potential
problem areas and take action in those areas.

>>CHAIR KARKLINS:   Thank you.  Norway, Ørnulf.

>>NORWAY:   Thank you, Chair.

Thank you very much, also, for this presentation and for this very
important issue.

Just two questions.  We don't have too much time, of course, so it's
a lot of things we would really discuss further in detail.  But could
you just elaborate a little bit on the plans regarding the
cooperation with VeriSign and NTIA regarding signing the root?  And
also one other thing, I would just a few comments on.  Your plans
regarding the signing of the resource allocations, the PKI, the
cooperation with the RIRs.  What's the status and sort of expected
deliveries and so on on that?

But just -- of course I understand it's not time to get sort of a
very deep response to those but just a quick comment.

>>GREG RATTRAY:   Right.  So in a quick comment, with regard to the
DNS signing of the root zone, you know, there's an active commitment
now to step forward and, by the end of the year, work with NTIA and
VeriSign to ensure that that's going to occur.  And there's two
levels of that, and we are working through the procedures with those
partners about how that will occur.

On the working with the numbering community on -- can you --
basically, making sure numbering resources are also subject to a
technical verification or authentication, that's not as far along in
a practical manner.  But the ICANN staff is engaged with the RIRs on -
- and there may -- Suzanne or Steve, you may know more on the
technical level, but on the development of approaches, technical
approaches, to be able to basically sign or authenticate the
allocation of those blocks.

So it's a collaborative effort.  We are not driving the
implementation of something that's called RPKI.

Does that get it on a quick note?

>>CHAIR KARKLINS:   Thank you.  Singapore.

>>SINGAPORE:   Thank you, Greg, for the presentations.  I have just
one question.  I refer to key initiatives in section 6 wherein you
mentioned that you will focus on collaborations with regional TLD
associations.  Would you care to elaborate on what broad activities
you foresee in your FY '10 plans?  Thank you.

>>GREG RATTRAY:   I think there is going to be two major dimensions.
One will really be a strong follow-through on what I consider a real
success story.  Each of the regional TLD associations has sponsored
this attack and contingency response planning program.

We have had, I believe, over 50 ccTLD operators, different
operators.  Over 90 people in these courses received the training to
try to build capacity for those organizations to resist potential
malicious conduct, and also just do broad business continuity planning.

We have been asked to deepen that technical training that would
include illuminating how to deal with denial of service attacks and
implement remediation members like Anycasting and we plan to do that
in cooperation with the Internet society in the next year, as well as
the regional associations that have been sponsoring this training.

The other dimension that's really kind of emerged of late is working
with the regional associations as well as the ccTLD operators in how
to collaborate and pass information effectively about emerging
situations like the Conficker worm.

We engaged very vigorously when it became clear that the next
version of that worm was going to try to resolve through what turned
out to be 110 TLDs, mostly in the country code domains, and we had to
figure out how to get the word out to everybody and provide practical
information about what they would do.  You know, being a bridge
between the security community and the ccTLD community.

The regional associations were an essential part of that outreach,
and we believe that will continue going forward.

>>CHAIR KARKLINS:   Thank you.

So I don't see any further requests -- there is one.  United
Kingdom, Mark.

>>UNITED KINGDOM:   Thank you, Chair.  I wanted to, first of all,
thank Greg for the presentation today and summarizing the plan and
the program of work.

We, as the U.K. government, didn't respond in the consultation, but
the plan has been circulated to my colleagues in the U.K.
administration who deal with this whole area of security, and they
very much support the work that ICANN is doing and feel that the
direction you are taking this work is very much the right one.

They point to work that's being undertaken in the European sphere,
in at least the European Network for Information Security agency, and
it sounds like you are sort of taking account of work going on there
and obviating the risk of duplication and so on.  And we also very
much welcome your elevating this dialogue to the level of the IGF,
the Internet Governance Forum.  So we are very supportive of that.

And my colleagues also point out to the useful push on business
continuity management, which is brought out in -- which is mentioned
in your presentation and is clearly described in the plan.

So that's -- They feel that's very useful, indeed, and a very good
element in the program.

So that's our view, and we will continue to follow this work with
very close interest, and very much welcome your undertaking to keep
the GAC informed and to elicit feedback from us.  And we will
certainly continue to try to do that.

Thank you.

>>CHAIR KARKLINS:   Thank you, Mark.

So in absence of further requests for the floor, I would like on
behalf of the GAC to thank Greg for the presentation and engagement. 
It was highly useful to understand what ICANN is doing to perform its
core objective, maintain security and stability of Internet, and
understand what ICANN is not doing.  Because there is a lot of
different ideas around and perceptions on what ICANN is doing and
what ICANN is not doing.

So thank you very much, indeed.  And now we can move to the next
segment of our session is our joint session with SSAC and RSSAC.

I thought that with RSSAC, this is the first time and GAC is meeting
but this is not true.  Suzanne reminds me that some years ago,
unidentified number of years ago, there has been one session.

So we are very, very happy to greet Steve Crocker and Suzanne Woolf
and the GAC.  And I will, without further delay, pass the microphone
to Steve Crocker.  And as we agreed, we will discuss a number of
important issues, but I will let Steve introduce them.

>>STEVE CROCKER:   Thank you, Janis.

It's a pleasure to be back here again.  I feel it's been a little
while, but we have enjoyed a number of interactions in the past, and
particularly, it's excellent to work with both you and Stefano in
organizing these kinds of interactions.

Quite a lot is going on.  We have a kind of fast-paced collection of
presentations to present to you today.

We're going to start off with two presentations related to DNS
security with specific attention to signing the root.

Let me mention that -- I don't know, you are meeting all day
tomorrow, I imagine, but there is a half-day session on DNSSEC
tomorrow morning from 9:00 to 12:30, and the -- we have had a number
of these sort of on a continuing basis.

The agenda is getting more and more packed, and I'm particularly
pleased that a good fraction of the agenda tomorrow is featuring
progress with TLD operators in this region.  And we are now getting
enough activity where it's hard to keep track of it.

And I consider that to be a good thing.

So here is the set of topics we are going to present.  Without
further ado, let me just turn things over to Ashley Heineman from
NTIA.  Ashley, you are all set up there?  I will put your slides up,
and introduce yourself and it will take me just a second.

>>ASHLEY HEINEMAN:  Thank you.  Basically I am here to answer
Norway's earlier question, which is where are we now in terms of
implementing DNSSEC at the root.  As I believe most of you are aware
there were two press releases issued earlier this month, one from the
Department of Commerce and one from ICANN, basically expressing our
intent to work together -- that being ICANN, Department of Commerce
and VeriSign -- in the implementation of DNSSEC at the root.

So the purpose of my presentation today is to give you an overview
of how we came to that decision, how we intend at least for the
interim to implement DNS at the root, and what the next steps are for
moving forward.

Just for purpose of background, I think most of are you aware of the
fact that NTIA issued a Notice of Inquiry in October of last year. 
We received 55 comments as part of that process from a wide range of
constituencies, including industry, nonprofit organizations,
academia, and quite a few individuals.

All of these comments, including the NOI itself, are still posted on
our Web site at the following URL if you are interested in reading
all of these in further detail.

So coming out of this NOI process, it was very clear that there was
consensus that DNSSEC should in fact be implemented at the root zone
level.

Other issues that came out of this process included that issue
should be implemented as soon as practically possible.  It should be
implemented in a manner that maintenance the security and stability
of the overall Domain Name System.

At least with respect to the TLD operators, in order to avoid any
further complexity or duplication of efforts, the implementation, at
least the operation of DNSSEC they root zone level, should be aligned
to a certain extent with whatever the root zone management process is.

And also, many commenters took the opportunity to reinforce with the
department that DNSSEC is not about control.  It is about data
integrity and authenticity, which we took this point to heart.

Next slide.

So based on the results of the NOI, as well as a number of
discussions that we held either with industry or with experts,
including some of those who have already implemented DNSSEC in their
zones, we determined that it was important to go ahead and move
forward with implementation of DNSSEC at the root.

And in the sense of trying to do it as practically possible, we set
a goal for ourselves to have an operationally signed root by the end
of this year.  Just to restate, this is our goal to shoot for.

In order to meet this aggressive goal, we determined that an interim
approach to implementation would be required to ensure the rapid
implementation as well as to do things in a manner that does, in
fact, maintain the security and stability of the DNS.

This interim approach would be essentially closely aligning a DNSSEC
process onto the existing root zone management process.

Once this is implemented and operational at a term not yet to be
determined, we do envision a review process.

The point of this being is that we want to take into consideration
any advancement and technology process or procedure related to DNSSEC
to assist us in determining whether or not this interim approach
needs to be modified, streamlined, making sure that things work.

And just to make it very clear, we see this as an iterative process.
We don't see implementation or the processes involved to be set in
stone.

We intend to continue to have discussions and consultations with the
DNS technical community and the appropriate stakeholders as we move
forward with any kind of process.  As we implement, as we test, and
also as we move forward with the operational aspects.

Next slide.

So as I stated in the previous slide, NTIA made the determination
that implementation, at least for the interim, should be closely
aligned to the current root zone management process.  Just to be
clear, in case it's not fully understood, the current root zone
management partners are ICANN as the IANA functions manager, NTIA as
the administrator, and VeriSign as the root zone maintainer.

Under the basic architecture that we established, ICANN as the IANA
functions operator would have the responsibility of overseeing the
root key signing key, or the KSK, that that management process.

In addition to that, the very important role of publicizing and
distributing the public root key.  This is pretty much the linchpin
of how all this works.  This is what the community is going to rely
on, and ICANN is going to have the very lovely job of trying to work
with the community in determining what is, at least for the interim,
what is the best way to get this information out there, what works
for the community.

Also, very closely in line to what they already do in terms of
taking change requests from the TLD operators, they will also use a
very similar vehicle in receiving requests to update TLD public key
information.

Next slide.

As for VeriSign, who is currently our root zone maintainer, their
responsibilities will include very much in line with what they do
today, which is the generation of the root zone file and distribution
of the file.  In between those two processes, they will now also have
the responsibility to sign the root zone.

Considering that the root zone today is currently generated and
distributed approximately twice day, it became very clear, at least
from an operational perspective, that this would require easy access
to the root zone signing key.

So at least for the interim, VeriSign will have the responsibility
of managing the root zone key signing process.

Now, all of this will be in consultation with ICANN and vice versa.

The department is going to rely very helpful on our root zone
management partners, ICANN and VeriSign, in the development of
detailed testing and implementation plans, which the sums assumption
is that's underway right now.

The other thing we worked very closely with our sister agency, the
National Institute of Standards and Technology, in developing a broad
overarching set of technical requirements that outlines things like
certain amounts of security are necessary in certain areas, requiring
that procedures be developed and put in place and published with
respect to key rollover.  There are audit requirements, those sorts
of things.

But other than that, we are going to rely quite heavily on ICANN and
VeriSign in developing the details, and especially in cases with
ICANN, working with the appropriate stakeholders and the community in
determining things like how should the public key be made available
to the community.

Next slide, please.

This is just a diagram of the current root zone management process
to provide a visual of how things currently exist today.  Just to
briefly go over this process.

It starts with the TLD operator, putting forward a request for a
change to the root zone file.  This goes to the IANA functions
operator, which is ICANN.  They do the necessary processing.

Once the processing has occurred, this is pushed to NTIA as the
administrator, who then verifies that the proper procedure and
process has, in fact, been followed.

Then VeriSign is authorized to make those changes to the root zone
file, and then generate the file and distribute it to the root zone
operators.

Next slide.

And this diagram is to show how DNSSEC, at least for the interim,
will be overlaid onto this process.

So the TLD operator, just as with any other change request, would
use some sort of vehicle, to be determined by ICANN, to also include
any changes, updates or just inserting their public key information
into the root zone file.

Again, just as with any other change request, this would go through
some kind of a processing, verification process, by ICANN.  Along
with the other change request, NTIA would make sure that a process
was followed and authorize VeriSign to include those changes and
information into the root zone file.

The extra step here in the process is then, at this point, after
VeriSign generates the file, the zone would then be signed.  And then
go to the next state, which is distribution.

Now, to go into more of the key management portion of this, you will
notice that there is a freestanding box which essentially covers the
basics of KSK management.  It has been identified that ICANN will be
responsible, as the IANA functions operator, for this process.  The
details have not yet been determined, which is why it's a free-
floating box.  But essentially, this is where the KSK will be
generated.  The root key set will be signed.

VeriSign, having generated the zone signing key, would push the
public portion of that key to be signed.  Signature would then go
back to VeriSign and then be utilized for the signing process.

On the other side of things, once the KSK is generated, the public
portion of that will then be the responsibility of ICANN to
distribute, publish to the community.

And I think this pretty much covers how at least the basic
architecture will be established.

Again, the detailed testing and implementation plans will be
developed jointly by ICANN and VeriSign.  We fully intend, once this
draft is available to NTIA, that then the draft will be shared with
the technical community and other relevant stakeholders to review and
provide input.  And this will take place throughout the process.

Next slide, please.

So in terms of next steps.  The technical requirements document is
by and large complete.  I think we have a few T's to cross before we
can actually look to begin consultation.  But we're very close to
that.  I would say probably within the next week.

We hope to also have VeriSign and ICANN in a position to share their
draft testing and implementation plans in advance of the IETF meeting
in Stockholm.

And assuming that we get a good solid, at least, start with the
testing/implementation plans, we would like to initiate testing as
early as this summer.  And at that point, I think that will really
determine where we are in terms of being able to move forward with
operations and whether or not we are going to be at a point at the
end of this year to move things forward.

So that is the basic undertaking we have, and I'm happy to answer
any questions, if there are any.

>>CHAIR KARKLINS:   Thank you, Ashley, for this presentation.

Any questions?  European Commission.

>>EUROPEAN COMMISSION:   Just to say it was very good, actually, and
very useful.  And will the slides be available for GAC members to
have a look at?

>>ASHLEY HEINEMAN:  I sent them to Steve.

>>CHAIR KARKLINS:   He is not a GAC member.  At least not yet.

[ Laughter ]

>>ASHLEY HEINEMAN:  My assumption is they will be posted on the
ICANN Web site.  If not, I am more than happy to have Suzanne or
someone else distribute it to the group, or Janis.

>>STEVE CROCKER:   I have the complete set of slides.  I will make
them available to Janis or Stefano or somebody, sure.

>>CHAIR KARKLINS:   And since this is the GAC open session, the
session is audio streamed.  Transcripts will be placed on ICANN Web
site, and all presentations as well.

So any further questions to Ashley?

Singapore.

>>SINGAPORE:   Thank you very much for the great presentation.

I have two questions.  Earlier you mentioned this interim approach. 
Is the interim approach the same as your testing?

And a second question is, how long you provide for testing and how
do you go about to start to provide training to users?  Because I
think you have six months left, and you intend to launch it by end of
2009.

Is that a sufficient period for you to start a launch the DNSSEC?

Thank you very much.

>>ASHLEY HEINEMAN:  In terms of testing, that is actually outside
the mandate of what NTIA and the Department of Commerce is
responsible for.

I would assume that ICANN would be taking on those responsibilities
vigorously, as well as other organizations, such as the IETF.

I think you touch on a good point.  I think there's going to have to
be a fairly extensive campaign for education as this moves forward,
in addition to making sure that all of the procedures and the plans
and the policies are made very widely available to the community so
they understand how this is going to work, particularly in the case
of key rollover.

Is it going to be a scheduled key rollover on a regular basis?  Is
it not going to be?  How will the information get pushed to the
community that the key, in fact, will be rolling over?

There's a lot of questions that have to be answered.

In terms of the interim approach, the point here is to say that this
is not set in stone.

One other point that was clearly -- that came out of the NOI process
was that this should be something that has the ability to change, it
has the ability to -- the different functions to move from one player
to the next, if necessary.

So we see this as a starting point.  I don't think it's possible to
have the most -- a perfect implementation right off the bat.  I think
things, in terms of DNSSEC, are still evolving.

So whatever goes into place initially is very likely to change as
things move forward.

>>CHAIR KARKLINS:   Thank you.

So we have another four presentations in front of us, and we have
divided time about equally, 15 minutes to all questions.  Since this
is a very important issue, I will certainly take more questions.

And I have Australia, Senegal, Netherlands, U.K., and France in that
order.

Australia.

>>AUSTRALIA:   Thank you, Ashley, that was very helpful.  And my
question is simply a point of quick clarification.

The NTIA's role, is that process authorization and checking or
decision-making as to what goes forward?

>>ASHLEY HEINEMAN:  We're basically making sure that ICANN followed
the process.  No real decision-making other than, okay, the process
has, in fact, been followed.  It can now proceed.

>>CHAIR KARKLINS:   Senegal.

>>SENEGAL:   Thank you, Chair.  I just have one question.

For those who are not using DNSSEC, what will be the impact on if
the root will be signed?

>>STEVE CROCKER:   That question leads directly into the very next
talk, so let me just suggest -- unless, Ashley, you really want to
jump into it -- that this will flow naturally into the next talk.

>>CHAIR KARKLINS:   Netherlands.

>>NETHERLANDS:   Thank you.

Just a question about the process which is going after the interim
solution.

I can understand that you look to a close cooperation with the
parties directly involved.  But in the end, what do you expect to be
the final solution?  Because, I mean, with managing keys, probably
the -- let's say the end goal will be to have a kind of trusted third
partner, independent, holding the keys.

Maybe through a kind of bid procedure.

Can you say anything about this long-term end goal?

>>ASHLEY HEINEMAN:  I'll try not to be obtuse.

There are contracts involved.  One contract in particular is annual.
We do have to keep that in consideration in terms of how we move
forward, in the case that we will probably be in a position at some
point very soon to probably bid the IANA functions contract.

One would think that perhaps there would be no change in how things
move forward in that respect.  But in terms of a final solution, I
don't think there will ever be a final solution.  As with the regular
root zone management process, there will be modifications, there will
be advancements and how things are handled just as we're going now
from a more or less manual process to an automated process for root
zone management.

I think that is, perhaps, the most obvious next step for DNSSEC
implementation is automating that process as well.

So I can't really say when there will be a final solution because
I'm not convinced that there ever will be.

>>CHAIR KARKLINS:   U.K.  Mark.

>>UNITED KINGDOM:   Yes, thank you, Chair.  I just need a further
clarification about this interim period.

What exactly would signify that the interim period has finished and
how long do you anticipate this interim period to be, given the
timeline you've indicated on implementation and deployment?  Can you
help us out on that point?  Thank you.

>>ASHLEY HEINEMAN:   I hate this word, "interim."

[ Laughter ]

>>ASHLEY HEINEMAN:  I like the word "iterative."

I think the point we're trying to make here is that, don't fret.  If
you don't like this approach, there is going to be time to streamline
it, to modify it, depending on what best works.

If this doesn't end up being the best approach, which I -- I doubt
is possible in any sense of the word, there will be opportunities to
streamline things.

I don't see an interim period.  I don't see a time where we're going
to say, "You know what, the interim period is now over."  I think as
part of a review process and looking at where things have evolved
with DNSSEC implementation, lessons learned from TLDs like dot SE in
terms of what they've done, I think "interim" just meaning that what
we do by the end of the year will evolve.

>>CHAIR KARKLINS:   France, Bertrand.

>>FRANCE:   Thank you.  Two quick questions.  The first one will
probably be also in connection with the presentations later.

But, currently, the updates of the root zone file are done with the
whole file.  As the number of TLDs is likely to expand, you might get
into a dynamic update system for the updating of the file.

Is that --  Does that have an impact on the DNSSEC?

>>STEVE CROCKER:   And, Bertrand, actually, if I might, now you've
stepped into another presentation, which is scheduled right behind
that.  So let me ask you to hold on.

>>FRANCE:   Okay.

Then the second thing is related to this notion of an iterative
process and the term "interim" and the temporary initial phases.

I just want to put a flag, I think it was also in the spirit of
other comments, about the notion of path-dependency, like things that
are interim or initial have a tendency to perpetuate.  The reason why
ICANN is based in Marina Del Rey was completely indoctrinal in the
origin.  It now is a place where you don't move 100 people easily
from place to place.

How can you and what measures do you intend to take to guarantee the
flexibility of the process that you are describing so that in the
course of time, the decisions that are made now are maintaining the
options open and not restricting future possibilities?

>>ASHLEY HEINEMAN:   I think that needs to be addressed as we flesh
out what the review process is and what that review mechanism is
going to entail.

And, quite honestly, I'm not at that point yet of being able to tell
you specifically.  But I'm well aware of these concerns.

We got that message pretty loud and clear.

I mean, we'll keep you posted.  And I think this is probably one of
those areas that it would probably be good to continue having
dialogue with the GAC and other forums to make sure we do the right
thing.

>>FRANCE:   The encouragement, then, is to have the process to
design the review process as early as possible in line with the
technical process itself.  So pay attention as early as possible to
the review process for that reason.

>>ASHLEY HEINEMAN:   Mm-hmm.

>>CHAIR KARKLINS:   Thank you.  Thank you, Ashley, for your
presentation.

And now we can move to the next one.

>>STEVE CROCKER:   Suzanne Woolf on a symposium that we held a
couple of weeks ago that looks at the next layer of issues around
deploying a signed root.

Suzanne.

>>SUZANNE WOOLF:   Good day, and thanks very much, Steve, Mr.
Chairman, ladies and gentlemen.

We will be quick with this.  But we wanted to sort of introduce the
topic and summarize what we went through here as a snapshot of some
of the things going on among experts in DNS and DNSSEC around the
specifics of deploying a signed root.

I won't be going into technical detail in this presentation.  Those
of that you know me know I'm always happy to talk technical detail
with anyone who's interested.  But we're going to keep this
discussion very high level.

Next, please.

The symposium we did was sponsored by the DNSSEC coalition, which is
an industry group comprising software vendors, operators of TLDs and
other infrastructure, ISPs, and others active in the deployment area
around DNSSEC, and Google was gracious enough to host.

We did it on the 11th and 12th of June of this year, which was
immediately after the ICANN/VeriSign NTIA announcements about
pursuing DNSSEC in the root.  So it was very timely.  We had a great
deal of interest.  We had, you know, very tight timelines and limited
attendance and a very strict -- and Steve remembers, we had to work
pretty hard at this to make sure we were focused on a very narrow
technical set of questions.  There are a great deal of issues around
DNSSEC deployment in general that we sort of put outside the fence
for this symposium so that we could focus on just assume a signed
root and what are the immediate set of questions and issues that
arise thereafter.

Next, please.

The attendees we had, we actually, given the constraints we were
under, we got a very good variety of the key technical players in the
room.  We had root server operators, DNSSEC implementers, operators
of signed TLDs, other folks with field experience with DNSSEC, ISPs,
protocol experts, some -- you know, some of the authors of the
technology, ICANN and VeriSign and NTIA were all represented. So we
got the scope of the major players.

And what we did was introduce the initial first-order questions and
started talking about possible answers on three major topic areas.

The first we looked at was sort of what happens on day one when
DNSSEC signed data appears and possible issues around avoiding
unintended consequences of adding signed data to the root.  And I'm
realizing I don't like the term avoiding so much as managing, because
when you change a system this complex, there's always unintended
consequences.

But the second area we looked at was key distribution.  And the
third was key rollover.  And I'll go into a little bit more detail on
all of those.

We did decide, going in, that the root signing mechanics, the
material that Ashley just presented, was not going to be part of that
discussion, because that's being discussed within ICANN, VeriSign,
and NTIA, and they're managing those discussions and feedback on what
they're doing in that area.

Next, please.

So the first area we looked at was just around avoiding unintended
consequences, because, as I said, this is a complex system.  When you
change something at this fundamental a level, things will happen that
you didn't fully expect.  The key issue is to expect that, that those
things will arise, and to understand them and manage them.

So we organized this around a couple of framing questions:  What
happens to traffic, to the root servers, and any behavioral
consequences there?  What happens to resolvers, you know, that ISPs
and enterprises run to do their DNS service?  And what happens to
other network devices?

From the very beginning, you know, the primary result of the
questions and the space we spent this time in was, when the root is
signed, many network elements, not just DNS resolvers, not just the
root servers, but also firewalls and other pieces of infrastructure,
will see new DNS data, not all of them are going to know exactly how
to handle it, what to make of it.  And sort of the bottom line here
is the reconfiguration or upgrade of software will be needed in some
cases.  And people do need to be able to look at what's going on in
their networks and manage this change in the ecosystem.

Next.

The next set of questions we looked at was around key distribution. 
The root zone DNSSEC public keys have to be easily available in
absolutely trustworthy ways.  And it's not completely clear yet how
that's going to be managed.  There were a couple of existing
infrastructures we could look at and evaluate for possible -- for
direction.  There are existing systems and mechanisms for
distributing the list of root name servers, for instance, which the
DNS has had from the beginning.  There's also experience from other
vendors and players.  Some folks were gracious enough to share the
experience around certificate authorities for software updates that
major vendors have used.  There are a number of key distribution
infrastructures in use, and we're looking for lessons to draw from
there.

The obstacles to timely and reliable distribution of keys include
that people don't always maintain software, and people don't always
maintain their networks in a secure way so that you can get secure
data out of them.  Key distribution as we look at the fact that keys
need to be maintained, there's a new set of constraints and that you
can't just set things up and forget about them and assume they will
always work just because they work today, which is, frankly, an
organizing assumption many people run DNS around.

The sort of bottom line there was that existing mechanisms aren't
really adequate long term, but we have enough basis to go forward and
gather experience and manage to a higher level for the longer term, a
little bit like that interim or iterative concept that Ashley was
talking about.

Next.  And the last topic we took up was key rollover, which refers
to how and when and how often to change keys.  There's kind of two
classes of key rollover concerns and questions.  There's ordinary
operation.  Do you assume that the root key needs to be changed ever,
under normal circumstances?  And if so, when and how and how often?

There's also a question of, like any system, no matter how sure you
are that nothing bad is ever going to happen to it, you still want to
have emergency procedures.  You still want to know what you're going
to do when the unthinkable happens.  It turns out that key rollover
and the related aspects of key management are a very active area for
experience and development of VCPs by folks that are deploying DNSSEC
today within the IETF, others who are signing zones.  That's actually
a very active area.  It was reasonably easy to get to consensus that
we have to assume that even a key as infrequently used and highly
secure as the root key, the key signing key, will need a rollover
process, even if we end up deciding that we hardly ever need to use
it, having one is a fundamental.

And there will have to be further review and discussion on exactly
how to do the key management aspects of the key distribution and
rollover aspects of having a signed root in the field.

Next.

So sort of the takeaway, the high-level points out of all of this,
there will be side effects to deploying DNSSEC in the root, just
because we're changing a large, complex system.  There will be new
processes and capabilities needed by various players throughout the
DNS ecosystem around deploying DNSSEC in the root, both to make sure
that they know what's going to happen and to make sure that they can
effectively use DNSSEC signed data.

The issues will take some time to fully characterize and resolve. 
And one of the areas for discussion coming out of the symposium is
how to follow up.  You know, where to -- where and when and how to
get further work done on these topics.

But I believe we also came away with the sense that these issues
can, in fact, be resolved.  And we will see successful DNSSEC
deployment in the Internet and in the root zone.

And that's what I have got.

>>STEVE CROCKER:   Thank you.  Let me add a word or two.

Suzanne and Olaf Kolkman and I formed the program committee for
this.  The DNSSEC Coalition, as Suzanne mentioned, is an industry
forum not tied to government or existing players.  I saw Alexa Raad
somewhere here -- yep.  Hi -- head of PIR.  PIR and Nominet were the
spearheads for this.  And there's quite a broad participation.  And
IFC is a founding member.  And it's a very vigorous and effective
forum for thrashing out a lot of DNSSEC deployment issues and has
been a big addition to the scene, very complementary and supportive
of the government-initiated activities.

I wanted to flag that, because it's provided a way of looking at
some of the aspects that fall outside of the more specific concerns
that NTIA, for example, has been focusing on.

Other questions?

Singapore, did you get the answer to the -- I think it was your
question about unintended consequences or what happens to the people
who are not participating in DNS, DNSSEC?

>>SINGAPORE:   Singapore I think it's the question from Senegal.

>>STEVE CROCKER:   I'm sorry.

>>SUZANNE WOOLF:   Yeah, I also see a few people in the room who
were in the symposium.  So if anybody wants to raise a hand and say,
you know, 'cause any of us could discuss any of these issues further
if people want more information.

>>CHAIR KARKLINS:   China.

>>CHINA:   Yes, thank you.

Thanks a lot for your great presentation about all of these root
server resolutions.

Suzanne, would you please give us more detailed information about
what is the side effect of the DNSSEC added to the root zone.

Thank you.

>>SUZANNE WOOLF:   Well, there's a cluster of effects.  And I'm -- I
have a couple of people who can chime in if they like.  But there's a
cluster of effects around the fact that DNSSEC-signed answers to DNS
queries are not exactly the same as sort of standard DNS answers now.
The answers are larger.  There are new resource records involved. 
There's new data.

And the thing that we've found is that a lot of older software,
particularly in firewalls and routers and intermediate network
elements, are programmed to have certain expectations about what DNS
data looks like.  And if the data they're getting does not in fact
match the expectations, errors can be generated, confusion can
follow.  There's a variety of specific effects.

But, generally, they fall into that class of network elements that
think they know what DNS looks like and are not prepared until
someone fixes them for DNS to behave in a slightly different way.

>>CHAIR KARKLINS:   Thank you.

Any other questions?

Senegal and Egypt.  Maimouna.

>>SENEGAL:   Thank you, chair.

I wonder if after this presentation I think that what they say is
the first result is one the root will be signed, many network
elements will see new DNS data.

My question is about those who are not signed yet DNS, those who are
not implementing DNSSEC on the -- for example, TLD.  What happens to
them?

>>STEVE CROCKER:   Is your question if a TLD is not yet signing
their zone -- notice that I slipped in the "not yet" there, that will
there be any impact for them, and will their users be affected?

I think the simple answer is no.

And you can expand on that, if you want.

>>SUZANNE WOOLF:   It's hard to expand on "no" because I agree with
it.  I think that's a reasonable assessment.

>>CHAIR KARKLINS:   Egypt.  Manal.

>>EGYPT:   Thank you, Janis.

Just excuse my technical ignorance.  But you've just mentioned that
the DNSSEC knows how the DNS data looks like and would be confused
otherwise.  And I was just wondering how IDNs would be taken into
consideration.

>>SUZANNE WOOLF:   Thanks for the question.  Partly because that
will lead right into the next presentation.  You guys are setting us
up very well.  This is very good.  Thank you.

But I think IDNs for the DNS, underlying all of the processes of
turning them from characters and scripts into DNS names, by the time
you're looking at DNS queries and answers, they're the same as any
other DNS labels.  They're -- it's -- so it's not any different, for
example, querying at the root or TLD server.  All you're seeing is
standard DNS queries.  So what we've already said applies absolutely,
applies strictly.  It's not any different.

>>CHAIR KARKLINS:   Thank you.

Netherlands and U.K.

Thomas.

>>NETHERLANDS:   Well, thank you, all, for a good background on the
new implemented DNSSEC.

I have a question which depends a little bit if it falls within this
forum.

But having DNSSEC, having the technology, having it implemented
means step one.  But step two, of course, is, people should use it
now.  And, of course, nobody is obliged to use it.  I mean, everybody
can go on doing the old-fashioned DNS queries.

So my question really is, where are the triggers which part of the
market players versus governments should step in and really stimulate
users to use DNSSEC?

Thank you.

>>SUZANNE WOOLF:   Wow, that's a large question.

First of all, this is Steve's cue to jump in and talk about our
DNSSEC workshop tomorrow.  But I'll give him a moment.

Without commenting on the question of who should be creating which
incentives, 'cause I'm not prepared to comment on that, but the thing
-- one of the things that has been very interesting to watch recently
is, a kind of critical mass has been going on.  The vendors already
in the space are deploying DNSSEC solutions usable at all levels of
the hierarchy.  More TLDs are signing.  There's more attention being
paid to the value add, which, you know, is always hard with security
technologies, because what you're doing is paying to prevent bad
things.  But there's more and more being -- attention being paid to
that, not only because of, you know, specific incidents last summer
where there was a particular ability -- particular ability discovered
to sort of turbo charge an attack that we had known about for a long
time that DNSSEC can mitigate, but also, people are starting to talk
about, in addition to protecting you against bad things, what does
DNSSEC actually add.  And to me, that's very, very hopeful that
there's an active area here and that deployment has positive drivers
now, which, from being in this space for a long time, I can tell you
it was a very long time where it didn't appear that that was
happening or was going to happen anytime soon.

>>STEVE CROCKER:   Let me take your bait, Suzanne, and jump in and
add a little bit.

There is a sort of chicken and egg problem as to why bother to check
signatures if there's nothing that's signed.  Why bother to sign
zones if there's nobody who's checking it and sort of a deadly
embrace there.

That has resolved itself in the signing process happening earlier or
being a bit ahead, and then the checking process coming in behind.

So we are now seeing considerably more activity on the signing side,
as you're seeing.

And we're beginning, indeed, to see some activity in the checking
process.  And so certain ISPs, Telia in Sweden, Comcast in the U.S.,
and certain other operators, University of California, Berkeley, for
example, taking a proactive, leading role at setting up validation
servers that are actively checking.  And we'll see more of that over
time.

Then, in addition, as Suzanne mentioned, besides the use of DNSSEC
as simply checking to see that nothing bad is happening, also, it
does open up some new applications.  And I think that will hasten
things forward.

Also, as long as I have the mike on, let me add just a quick answer
in addition to the previous.

In the root zone now are some test zones for IDNs, as I'm sure you
know.  What's probably less visible is that those are in fact being
signed simply because they're there and they're useful as an
experiment.  So there is actual experience with DNSSEC with IDNs
happening just quietly, just because it all fits together and is
happening smoothly.

>>CHAIR KARKLINS:   United Kingdom, Mark.  And that will be the last
question on this presentation.

>>UNITED KINGDOM:   Yes, thank you, Chair.

Thanks also to all involved in making the presentations, very
detailed, and I think we'll all have to sort of look back on the --
on the presentations and try and absorb it a bit more.

And my notes, I try to sort of write down things, and a couple of
words really jumped out as I look at my notes.  And those are
unintended consequences.  And I think we really appreciate your frank
discussion of those.  And I was very struck by the fact that, of
course, there will be consequences that will be impossible to
anticipate.  And that's something -- I have noted that as something
that is inevitable.

And related to that, I noted down the need for emergency procedures.
And I just --  Which I think is related to, you know, trying to
anticipate what's actually going to happen with deployment.  And I
was wondering if you could say a bit more about how advanced your
thinking about that is and what actually it means, I suppose.  Does
it ultimately mean at some point, you might pull the plug on the
whole thing as a final emergency procedure to -- if something
horrendous was happening?

Thank you.

>>SUZANNE WOOLF:   Sure.

First, thanks for the opportunity to clarify a little bit.  I was
kind of talking in terms of with -- the context of what I said about
emergency rollover was in the context of key rollover, where it's
sort of a fundamental among cryptographers and people that study this
sort of thing professionally, that no matter how careful you with how
you build your keys, there is always the possibility, however slight,
that a key will be compromised and you will then lose the
authentication provided with being able to use that key.

And that's usually the context where people talk about emergency
rollover of keys.

To the more general issue of unintended consequences, one of the
reasons why this is a very active area, one of the things that came
out of the symposium being that we -- there's more work to do here is
along those lines.  The fact that we can't anticipate every possible
consequence does not mean we can't anticipate what we'll do with
unanticipated consequences.  It's just a basic of systems
engineering.  This is not new territory when you're talking about
deploying and changing complex systems.

I personally can't imagine a situation where we'd say, "Call it
off."  But that doesn't mean that that's not a possibility we should
be looking at and that people are looking at.

>>STEVE CROCKER:   Thank you.  Let me also add as we close this off
that I meant to add before with the question of the pickup on
checking that there is also a certain amount of pressure coming from
the U.S. government and I would imagine other governments to insist
on implementation within government systems and then subsequently
with systems in future years that interact with government systems so
that there is a very active initiative within the U.S. government to
have adoption first on the signing side and then also on the checking
side.  And then there are vendor forums and public processes that
engage the vendors in these processes.  So this is moving along.  It
takes a number of years, of course.  But it's moving with a certain
amount of vigor.  It's going through -- we had a day-long government
security session in March in Washington and filled up a whole day of
presentations and implementation.  And that goes hand in hand with a
directive from the top level of the government that all of dot gov
would be signed.  And similar things are going on.

Thanks.

So let me move over to the root scaling study that Lyman Chapin is
conducting under the joint supervision of a team from the Root Server
System Advisory Committee, the Security and Stability Advisory
Committee, and ICANN staff across IANA and DNS operations and so forth.

Lyman.

>>LYMAN CHAPIN:   Thank you, Steve.

You can move to the next slide.

When we think about the way in which we've managed the root, the top
level of the DNS, over the past ten years, longer than that, but
certainly the past ten years of ICANN's lifetime, one of the things
that is most important about that is that we haven't changed much. 
And when we have made changes, we've made them relatively slowly.  So
we have about 300 entries in the root at the moment.  And if you
amortize over the past ten years, we've made about one addition, one
new TLD addition, per year over that period of time.  And we haven't
changed much in the root.

As you know from the discussion that you've already been engaged in
today, we're about to change a number of things about both the root
zone and the way in which the root server system that supports it
operates.  We're going to be adding new resource records and new
procedures for DNSSEC.  That's -- you just heard about that.  We're
going to be adding IDN top-level domains.  We're going to be adding
support for IPv6.  And we're going to be adding new generic top-level
domains.

All of those things are going to create stresses on the root system.
And the study that was commissioned by ICANN, which I've been
managing for about two months now, is designed to determine what the
effects on the root server system are likely to be of doing all of
these things and doing them all at the same time.

So root zone expansion and the DNS scaling study refer both to the
effects of making the root larger by adding new records and new TLDs,
and also making the operation of the root server system more complex,
both because the root zone is potentially larger and also because
you're doing things like DNSSEC.

Next slide.

The study was requested by a resolution of the ICANN board back in
February.  And we started our work assembling a study team early in
May of this year.  So we haven't been working for that long.  But we
don't have very much time left, either, because we would like to have
a draft report completed by the 31st of August.  And there are two
reasons for that.  One is that, of course, the next -- and we hope
final -- draft of the draft applicant guidebook for the new gTLD
program is expected to be released in September.  And we would
certainly like to have the results of this study available to inform
that next draft.

We also need to have the work done by the end of August in order to
have sufficient time for public comment and review by all of the
interested parties prior to ICANN's annual meeting in Korea at the
end of October.

Next slide.

The root scaling study team conducted a session at this meeting here
in Sydney.  Today is now yesterday.  This was yesterday at 4:00.

The transcript and slides from that session, which went into much
greater detail on what the study is trying to accomplish, are already
posted at the appropriate place on ICANN's Web site for the schedule
for meeting.  And public comments are encouraged and are being
collected through the usual ICANN mechanism at the email address
scaling@icann.org.

Thank you, Steve.

>>STEVE CROCKER:   That's, indeed, brief and appreciated,
considering that we're running behind.

The session yesterday was -- had a full room and went on for an hour
half plus-plus, if I remember correctly.

There is enormous amount of energy going into this, and the process -
- the question of how big can the root be has come up over and over
and over again, and has gotten,  in the past, a little bit of
attention with considered answers from technically competent and
knowledgeable people have said, basically, well, it's not really that
big of a problem.  But if you scratch the surface, it's going from,
say, 300 to, say, 3,000, or sort of a few more.

And since the question keeps coming up over and over again, finally
the decision was made, well, let's go really nail this question once
and for all and look at it not just in the immediate sense of could
you add a few more, will anything break, but let's look at it in a
really deep and enduring sense.  So really huge numbers.  Plus the
complexity issues of IDNs and DNSSEC and IPv6 all happening at once.

I am very excited about this study, and I appreciate Lyman and his
team on this.

Any questions?

Yeah.

>>ITALY:   Okay.  Have you already an idea of how much, in
percentage, new gTLDs must IDN versus DNSSEC will be the impact on
the dimension on the complexity of the root server system.  And of
course, it is very interesting the discussion that we are having on
how many new gTLDs will appear next year, or in the following on.

And the question that raising -- that asked mainly connected to, of
course, to the number, the number of thousand or number of 10,000 or
something like that.

So if you have already some ideas about, okay, the ratio between the
elements you mentioned, as I say, the IPv6, IDN, DNSSEC and new
gTLDs.  An idea, I remember, maybe one year ago or so, the impression
of the SSAC was that perhaps hundred, several hundred of new gTLDs
will not change the thing.  I remember discussing something like that.

Thank you.

>>STEVE CROCKER:   Well, gosh, that's a pretty interesting question,
and my first reaction is I wouldn't want to try to answer that
question in this setting.  Much better to be in the bar and with
plenty of liquor around.

[ Laughter ]

>>STEVE CROCKER:   As I indicated before, adding a few hundred is
not going to break anything.  At least, there's no appearance that
that's going to happen.

It's what happens when you go well beyond that, and there are maybe
reasons why you can't get very far beyond it, which we don't know. 
But the focus here is to look at a very broad spectrum.

The ratio question you are asking is, in my experience, not a
question that has come up in that form before.  And I'm quite curious
why you have asked that, but I'm not sure that this is the right
place to take that up.

But let me invite you to -- let's have a follow-up discussion of that.

Anybody else want to chime in?

>>SUZANNE WOOLF:   Only just briefly.

Just to take up Steve's point.  One of the reasons why I am so happy
to see that this study is being done is that it's attempting to
quantify exactly those kinds of questions because there's a lot of
operational experience, for instance, with zones much bigger than the
root that change much faster than the root changes that make most
people's experience in the area pretty comfortable saying that
changing things by a little bit is not going to cause a problem.  But
not knowing exactly where the boundaries are, it's time to stop that.

So this is exactly why the study is being undertaken.

>>ITALY:   Just another comment.  Okay.  My questions were just to
point out that if a criticism is made, why so late, a study like
that?  Because especially looking at the new gTLDs, the community
asks, okay, how many?  How much will they complicate the root server
system, and so on.

But in any case, of course, we very welcome the result that we will
see by the end of August.

Thank you.

>>CHAIR KARKLINS:   So in Latvia, we say better later than never, so
maybe that's the answer to this question.

Yeah, please, Lyman.

>>LYMAN CHAPIN:   Probably the most significant point that I can
think of for the timing of the study, why is it happening now, is
that we have accumulated, as Steve mentioned, over the years a large
number of comments from technically knowledgeable people, essentially
saying variations on a couple thousand, whatever, is not going to be
an issue, shouldn't be a problem.  Look at dot com, which has far
more entries than the root is likely to ever have and a much greater
rate of change.

So everything should be fine.

These have all, at some point, been anecdotal accounts.  They
haven't been rigorously databased.

And one of the big reasons for conducting the study at this point is
that so that as we move into the last phase of making decisions about
things like new gTLDs and the new gTLD program that we can have
whatever discussions we have to have about effects on the root server
system using a data-based and an analysis-based study of the effect,
rather than having to rely on a bunch of anecdotes.

So this is an attempt to gather all of the information that we know
about the way the root operates today and the way the root server
system operates today and to codify it in such a way that when we
have these policy discussions over the next couple of months in
particular, that we have something we can refer to that is fact based
and analysis based and not anecdote based.

>>SUZANNE WOOLF:   If I may.  Also, one other observation on that
point is it only became -- as a technologist looking at this set of
issues, one of the things that changed in the relatively recent past
is it became clear that a number of different things were going to be
happening at roughly the same time.

You know, we were talking about doing all of these things in a short
period of time compared to the operational lifetime of the DNS so far.

And as a technologist, that -- I tend to think of that as adding a
different set of possibilities to the mix, and that also sort of adds
to the imperative to look closely and rigorously, not only at
specific changes but how they interact.

>>CHAIR KARKLINS:   So thank you.  And maybe the last question, last
three questions.  France, Netherlands, and U.K., and then we will
move to the next presentation.

>>FRANCE: Thank you, Janis.

First of all, although I share the comments that Stefano was saying
regarding the very late nature of this study, I endorse your position
that better late than not.  And it's a very interesting one.

I want to sing the praise, really, of the team that made the
presentation yesterday, because the session was absolutely
fascinating.  And even the term of reference is a great help for
people like me who have a relatively minor understanding of how the
whole system works.

So I'm hoping that the study will produce something very
interesting, in particular by mapping, if I understand well, the
dynamic behavior of the root server system as a whole.

Because this is an element that will be taken into account for the
final element of the policy.

In order to display my newly acquired science (laughing), I wanted
to ask you two things. one, I understood that there is a major
difference between the way you update files when they are big or
small.  And today the root server system is updating the whole root
file, which is basically 300 of length.

If we go to several thousand TLDs, I suspect there is a moment where
you switch to dynamic updates.

Is there any moment that you expect such a qualitative change from a
quantitative growth?  And second, what is, in that case, the
connection with DNSSEC, and is DNSSEC harder to implement on a
dynamic update model for the root than on the current root zone file
batch update?

>>STEVE CROCKER:   I'll be happy to take that.

>>SUZANNE WOOLF:   I can answer it, but....

>>STEVE CROCKER:   It's a very good question, Bertrand.

First of all, the question you are asking, each of the elements of
that, in fact, are, in fact, very specifically within the scope of
the study.  And I hope -- I see Lyman's head shaking very vigorously
yes.

It's not yet clear whether there are specific points that one can
say at this point, at 9,276 we switch.  But it's clear that there is
some place up there and there's some room in that.  

The other element that you asked about is does DNSSEC make that
worse and so forth.

The basic answer is it shifts the numbers but it doesn't change the
nature of the answer.

Yes, there's a qualitative change.  Yes, it comes at some point. 
And exactly where that point is remains to be understood.

It is well understood how to do that.  It's a question of when and
whether and so forth.

And I think that's the right level for this discussion.  I expect to
see a more extended discussion of exactly those points in the report
that comes out.

>>SUZANNE WOOLF:   Thanks.  And also just to that point, with
respect to a more dynamic zone, even with respect to DNSSEC, although
it is a lot less operational experience, we are talking here about
widely used technology.  We are talking about things that enterprises
and top-level domains and ISPs do every day.

You know, in my day job I work for a software vendor in this space,
and I know the technology exists and I know it's used very regularly.

But the root is special, so extra care needs to be taken to
characterize what will happen in the root.

>>CHAIR KARKLINS:   Mark, U.K.

>>UNITED KINGDOM:   Thank you, Chair.  I wanted to come back on the
better late than never scenario.

I think the reason why we are quizzing you on this is the stability
of the Internet is of paramount importance to governments.  And it's
a reflection, I think, of the fact that if something does go wrong,
government ministers will be down on us like the proverbial ton of
bricks.  And their first question I think will be why wasn't this
anecdotal evidence checked out right at the beginning, and why was
the conference of all these important, valuable initiatives on IDNs
and gTLDs and IPv6 and DNSSEC, the conference of all those was not
checked out in terms of stability impacts.

So I think I just wanted to make that point, that when -- we're
here, accountable to governments and to the public interest, and of
course economies and society as a whole rely on the stability of the
Internet, and avoiding any risk of that stability and resilience and
robustness being compromised in any way.

So I think that's the point of better late than never.

>>CHAIR KARKLINS:   Netherlands, Thomas.

>>NETHERLANDS:   First of all, I concur very much with my English
colleague.  I think also for us, for the Netherlands, stability,
continuity, resilience is the number one priority of, let's say, also
within ICANN, our efforts.

I have two questions.  Maybe the first one is more an expectation,
because what I see is that let's say there are two processes within
ICANN.  One is to get -- maybe I am exaggerating, but as much
possible to gTLDs as any community can ask for, and the other one is
let's say more technical community, looking at how this can be
implemented, which basically you are doing.

And my expectation is, I think, in the event that you cannot give a
figure on, okay, we can have 2,350 new TLDs in the root, because
probably you can say it, but my expectation would be can you give a
kind of roadmap, a pace or a -- let's say in which -- with which
velocity you can introduce in the next years without a good risk?

So that's the first question.

The second question is, how do you integrate also other aspects
which are more -- maybe not purely technical, but more organizational
and even, I think, having developing countries aspects.

For example, we have a lot of Anycast root servers.  Now they
function on a certain level of complexity.  What happens if you have
root -- Anycast servers in all parts of the world which are, for
example, a thousand times more complex?

And, well, these are the two things I wanted to ask you.

Thank you.

>>LYMAN CHAPIN:   Thank you.  I'll take the two questions in reverse
order, because I remember the second one better than -- I may have to
ask you to repeat first one.

The way in which the Anycast system works today, there are, in fact,
many locations where Anycast servers are located where the equipment
that's available at that site and the bandwidth to that site are
considerably less than they would be at some of the larger centers.

One of the things that we're going to be studying as part of the
work that we're doing now is the effect on those Anycast locations of
increasing the size of the root and adding some complexity to the way
in which the root zone file gets distributed to those places.

The first-order observation appears to be that it is relatively
simple to make relatively minor upgrades to either equipment or
bandwidth in some of those locations that would accommodate the
increases that we're looking at.

It's important to realize that increasing the size of the root by,
say, an order of magnitude or two orders of magnitude does not, in a
linear way, mean that you need a server, for instance, that is an
order of magnitude bigger or more expensive.

You don't need an order of magnitude more bandwidth.

So the way in which the equipment, the server requirements, and the
bandwidth requirements increase looks like, and we're going to model
this very carefully and quantitatively, but it looks like it's a very
slow ramp as you increase the size of the root zone.

So without -- you know, with the caveat that these are preliminary
results, and obviously the final result won't be known until the end
of the study, it certainly appears at this point that that's a very
manageable part of the problem.

But more importantly, it will definitely be a part of the model.

And I believe a good answer to your first question is to imagine
that what we're producing in this study is a model which is not so
much a list of breaking points where things start to go bad if you
exceed certain limits.  It's a way of observing what the root server
system will look like at various hypothetical points in the future.

So if you imagine at some future time that the root zone has grown
to be, say, 10,000 entries or 100,000 entries, and the rate of change
in the root zone has increased so that instead of having, on average,
one update per TLD per year, we have now several updates per day per
TLD multiplied by the larger number of TLDs in the root.  The model
we are developing will enable you to take that scenario with those
settings for those variables, and observe what the effect on the root
server system will be.

If we imagine a time when that's the case, here's the way in which
the root server system will have to evolve to accommodate those
changes.

So it's a way of knowing what the consequences of various changes in
circumstances are likely to be.

And my sense is, and certainly from talking to the people that we
have been interviewing and consulting in the course of doing the
study, is that that kind of tool will be very valuable as we make the
important decisions over the next couple of months and years about
how we want to manage that process.  Because we'll have that
information available.  We'll know what a future root server system
with 10,000 entries or 100,000 entries will look like.

Here is how it will operate.

Did that answer your first question, I hope?  Not quite.

I would be happy also to talk to --

>>NETHERLANDS:   Maybe because we have a time constraint, but one
thing I am still missing is the scalability.  But maybe that's not
part of your group, but --

>>STEVE CROCKER:   You are asking about the rate at which changes --

>>NETHERLANDS:   Yes.

>>STEVE CROCKER:   Both the magnitude of how many entries can be in
the root zone and the rate at which changes can be added are very
much central to what we're studying.

And those have impacts in different ways.

It's natural most people focus first on the query side.  Can a root
server have a million entries in it and still answer questions?  It
turns out that the more interesting aspects are on the other side of
the equation:  How do you get stuff into the root zone in the first
place?  How do you manage the change processes?

There is, for example, as a rough figure, not precise, but roughly,
if you look at the entire set of top-level domains, they make, in
aggregate, about one change per top-level domain per year.

So in the Netherlands, in the U.K., in Italy, on the average one
change coming out of each of them each year.

If you scale up by a large factor and you assume nothing else
changes, then you are going to have -- that one change per TLD per
year translates on the order, give or take, very imprecisely, of one
change per day in the entire system as it stands today.  Scale that
up by a factor of ten, you will get ten changes per day coming
through into the system.  Scale that up by a factor of 100, you will
get 100 changes per day coming into the system.

That has a very serious stress on the current processes that are in
place, and so you want to look at how are they able to accommodate
that.

And then there's second-order effects of can you introduce new ones?
What is the vetting process for could you process the paperwork for
the applications, and so forth.

So there's a whole set of issues there.

It's unclear within the time constraints how much of that will get
fleshed out in detail, but certainly the overall picture is going to
get looked at.

And then to take it one step further, what are the errors that are
inherent in such processes?  Because we are dealing with people and
we are dealing with complex systems.  We don't have good handles on
what the errors have been, but it's for sure that nothing is perfect
in all of this.  And as you scale it up, what happens to the rate at
which errors get made?

>>SUZANNE WOOLF:   Yeah, just very briefly.  It's also helpful to
remember the part of the frame of all of this, around the work that
Lyman has been talking about, is that they are very rigorously
staying away from policy.

This is inputs to policy processes.  This is data for policy
development processes and for input into existing policy processes
throughout the other pieces of ICANN and the pieces of the ecosystem.

>>CHAIR KARKLINS:   So, thank you.

And we have to move on to the next presentation.  And it seems to
me, due to the time constraints, we will not be able to listen to the
last presentation, which we planned to have, on SSAC review.

And without further delay, let's take up, then, the next
presentation, prohibiting redirections.

>>RAM MOHAN:   Thank you, Lyman.

So SSAC has, over a period of time, focused on redirection and the
synthesized DNS responses.

The first SSAC interaction on this topic dates back to 2003-2004
time frame when there was a particular -- SSAC was engaged in some
discovery and details about the wildcarding and the redirections and
synthesized DNS responses in the dot com TLD.

If you could go to the next slide.

The issue that we're focused on is that when DNS records get
wildcarded, the effect of it is that valid addresses and routing
seems to exist.  So even though an actual domain name or an actual
destination does not exist, because of the redirection of the DNS
responses and the synthesis of the DNS responses to the -- either the
computer or the user who is trying to go to that Web site or send e-
mail or an application that is trying to use the DNS, it gets back a
response as if that domain name actually exists.

Now, there are some serious consequences to this redirection and
synthesizing of DNS responses.  It fundamentally breaks the core DNS
systems and legacy applications, applications that have been around
and working for tens of years on the Internet.

It also erodes trust relationships, and it creates new opportunities
for malicious attacks.  And what is particularly concerning is that
these malicious attacks, when they come, the affected party has no
ability to mitigate the attack.  So it's a particularly pernicious
problem.

If you go to the next slide.

Some examples of what -- some of the things that actually break. 
Most basic tools and applications break when DNS responses are
synthesized and redirection is done.

For example, if you send an e-mail to a domain name that doesn't
exist and if you work on the assumption that it was sent to the wrong
place and you expect a bounce-back, you won't get a bounce-back
anymore.

And further than that, there are questions about, you know, if the
TLD implements redirection in such a way that it actually reads the
mails, then you could be sending, you know, a mail to a wrong address
and have those mails be read.

There are other things, link-checking software would break, because
all of a sudden on the Web, there will no longer be any broken links.
Every link will work.

And there are appliances and software applications.  They depend
upon the DNS, the core protocol and the functionality of the DNS to
work in the way it has worked.  And all of those will break.

Therefore, SSAC's advice to the community is pretty straightforward.

The synthesis and redirection of the DNS poses a clear and
significant danger to the security and stability of the DNS.  And as
a result of that, on the next slide, SSAC is making at this meeting a
recommendation to the ICANN board, asking ICANN to take all available
steps with appropriate entities to prohibit the use of redirection
and synthesized DNS records.

And the action might take the form of the various bullets below.  It
might mean that ICANN -- and we're actually recommending ICANN take
steps, including, for instance, revising the new gTLD guidebook,
certainly consulting with the ccTLD community, with the GAC, for new
ccTLDs, and add appropriate guidelines to existing ccTLD agreements
and widely work with the community in such a way that this bad
practice can get eliminated from the DNS as we know it.

Thank you.

>>CHAIR KARKLINS:   Thank you, Ram, for presentation.

Questions.  Any questions?

Pretty straightforward.

>> Very simple.

>>CHAIR KARKLINS:   Any doubts?  My question is what we could do,
what GAC can do in this respect, because if -- from all known
wildcards on CC side, countries are not represented in the GAC, and
how we can influence that, how we can address the issue.  We need to
think it through, most probably.

Suzanne.

>>UNITED STATES OF AMERICA:   I'm -- just have a question, and
really going to show my technical ignorance here.

But if you could clarify, it's my understanding, possibly deeply
flawed understanding, that the protocols permit wildcards.

>>RAM MOHAN:   Yes.

>>UNITED STATES OF AMERICA:   So I'm just curious to know, are there
efforts to amend the protocols?  Or -- you know, because, normally,
if you have a technical problem, you would seek a technical solution
as opposed to a political or policy solution.

So I'm just curious to know the status of any work in that arena. 
So I guess I am -- am I correct?

That's remarkable.

>>STEVE CROCKER:   Unlike your  preface, you're well informed here.

The subtlety of this tension between how the protocol spec was
originally laid out versus what the experience has been was dealt
with in -- with some care back in the 2003/2004 period when this
issue first emerged.  And to give the short answer, there was a --
two things happened.  One is, there was a consideration back in the
IETF and the IAB as to whether or not they wanted to try to change
the spec and say, "Don't do this anymore."  And the answer was no. 
But there was equally a clarification based upon experience about
what to do in this environment.

And I don't want to try to get all the different cases of this
captured here, but I'll try to do an approximation.

There are environments which I will characterize as inherently
small, so, in an enterprise where you have knowledge about who all
the users are and what the applications are as well as sort of what
all the hosts are involved, there may be useful ways to use this
facility which was designed in a long time ago.  The experience,
however, has been that in the large, where you have an unbounded
number of players and you don't know what the relationships are, that
this has turned out to be poor practice.

And so it's one in which the boundary between those is not so clear
as to lead to a protocol change, but, rather, to a clear piece of
guidance about what to do in operation.  And to say that, once again,
where you have a parent that has an arm's length relationship with
the children zones -- so a top-level domain registry with many, many
customers is the typical example -- you do not want to have this kind
of redirection and synthesis.  But in a very contained environment
where you have a close relationship between the parent and child
zones, so subordinate zones within, say, you know, Acme
Manufacturing, and it's got a number of different small operations
inside, they may choose to configure it that way and take advantage
of that for some reason.  But they also can anticipate what the
consequences are going to be.  And that is not -- does not scale very
well.  And so that's where --  And there is a fair amount of dialogue
about that.  And I would recommend going back and reading both the
original report, SSAC 006, I believe, and the transcripts and the
presentations, some of which went into some depth on that very point.

It is acknowledged one of the areas where it makes it a little bit
harder because one has to engage in this kind of long explanation as
opposed to we just took it out of the protocol and it stopped
existing.  That, of course, would be much easier.  Would that life be
so simple.  But you live in the world that life is never simple.  So
we understand about that.

>>CHAIR KARKLINS:   Okay.  Any further questions?  Or if none, then
it remains for me to thank SSAC and RSSAC for spending time with us,
for tutoring us and answering our questions.

Thank you very much, indeed.  And we're looking forward to our next
sessions, whether next meeting or meeting after.  So that remains to
be defined.

>>STEVE CROCKER:   Thank you for the invitation.  The door, of
course, remains open.  And we're accessible in a variety of ways and
happy to be helpful.

>>CHAIR KARKLINS:   Thanks.  Thanks.

And for the GAC members, we're resuming our session at 2:00.  We'll
have a joint session with ALAC.  And I would like to invite those GAC
members who did not put their names on the list of participants
today, do it on the way out from the room.  So there were lists
circulated.  But if by any chance you did not receive them, please
make sure that your name is on the list.

Thank you.  And see you at 2:00.

(Lunch)

>>BERTRAND DE LA CHAPELLE:   Welcome, everybody.

Our -- Janis, our GAC chair, has asked me to co-chair with Cheryl
this joint meeting.

As you know, it's something that I appreciate very much.  I think
the interaction between ALAC and the GAC can be very, very fruitful. 
We will -- I don't think we will go around the table to make a
presentation one after the other.  But I encourage you strongly to
identify yourself when you make interventions.

We basically have identified three main themes for the agenda and
the discussion.  It's really open discussions.

The one is on the IDN ccTLD fast track issue.  The second one is the
new gTLD and the whole process of the applicant guidebook and all the
different questions.  And the third one is related in a certain way
to the SOAC interaction format and the section we had yesterday.

And I would like to make sure that in that third part, we deal both
with the format itself and the topic, which actually are interrelated
this time.

So maybe the important element is to focus on the points that are --
I wouldn't say the contentious -- most contentious elements, but the
key elements in discussion in the current process.

And very briefly, in the first one on IDN ccTLD fast track, you
probably know that for the GAC, one of the main problems is the
nature of the relationship between the ccTLD IDN operators and ICANN,
whether there should be a compulsory agreement or not.  We think not.
And compulsory fees or not.  We think not.

That's the main subject.

And regarding gTLDs as you know and as we discussed this morning,
it's mostly the question of protection of geographic terms.  But this
is far from being the only subject that needs to be discussed, of
course.  And I hope we will broaden this in the second point.

Cheryl.

>>CHERYL LANGDON-ORR:   Thank you very much.  And thank you on
behalf of all the ALAC and regional leads and ALS leads, who have
given up their valuable time, and the government representatives, to
talk to each other today.

With the IDN ccTLD fast track, we have pretty well agreed with you,
with the nodding around the table, your "nots" are probably our
"nots" as well.  We're more in -- at sort of 30,000-foot view.  We
just want them.

>>BERTRAND DE LA CHAPELLE:   I think we do.

>>CHERYL LANGDON-ORR:   We really, really have to tackle this issue
of holding up the CC, the access to the next billion and the billion
after that while we get some of these recipes right.  It's untenable.
It's always been untenable in our view.  And I'm sure I've got -- I
know I've got Korea in the room, our new to be at-large structure. 
Look my way, professor.  I'm looking down there to you.  No, she's
not going to do that for me.

It is something that Asia-Pacific in particular is very passionate
about.

Are you concerned that we hold up to get it right?  Because we
depart on mutual interest if there was any holdup involved.

>>BERTRAND DE LA CHAPELLE:   So do you want to maybe launch a few
comments?

Are there any other dimensions?  I think on the two issues, we
shouldn't spend too much time if basically there's a general
agreement on the two first points.

On the second point, I think you raise a very important issue that
is shared by GAC members of the real priority of having IDNs.

One thing I'd like to throw into the mix, though, is a question that
is not broadly discussed and I'm not sure there's even complete
agreement among GAC members on this is the relationship between IDN
CCs and IDN Gs introduction.

Are you discussing within ALAC about the IDN gTLDs?  Because we're
all talking about the new gTLD process as they were all more or less
Roman TLDs.

>>CHERYL LANGDON-ORR:   No.  Quite the opposite.  Any of our agendas
-- and this has been the case long, long before Mexico -- we refer to
new gTLDs including IDNs.  Those words are strung together in our
agendas.

>>BERTRAND DE LA CHAPELLE:   Okay.  But this doesn't lead to having
ICANN actually addressing IDN gTLDs that much, as far as I'm concerned.

So is it necessary -- that's the point I would like to discuss -- to
identify this as an issue itself?

Maybe if we have either GAC or ALAC members have any idea on that.

>>CHERYL LANGDON-ORR:   I see Izumi.  If you care to come forward to
the microphone.

>>IZUMI AIZU:   Thank you, chair.  Izumi Aizu from Japan and the ALS
at-large.

We are working there in Japan on both the IDN ccTLD and geographic
names in the prospective framework of some kind of council, private
sector-driven but government, it's sort of a multistakeholder thing. 
There's a huge need for the geographic names.  If the new gTLDs
application fee will be lower than the proposed one, there will be
more.  And there may be overlapping names between the Japanese and
Chinese or even Brazilian.  And how do you deal with this?

So our government is asking the private sector, including the
industry associations and consumer groups, to deal with this in
consultation with local governments.

So, clearly, it's a sort of blurring areas between G and CC.

Besides, if I may, we are also working on the new selection of the
IDN ccTLD.  It's not necessarily going to exist in TLD, although they
can apply for to have some open, fair process.  So there is need for
coordination between the IDN ccTLD and the ASCII TLD in terms of
policy and other areas.  That's another new area.

What we find, it's very difficult as evaluating Internet users to
talk about the new gTLD things, because there has been no mechanism
in domestic context.  What we have to do is make an ALS and go to
RALO, but no in the Japanese areas of coordination that we can talk
to the government or the CCs or others at this moment.

And I think the similar situation almost everywhere.  The users are
very difficult --  Unless you come to these places, it's very
difficult to have a local sort of dialogue.

Thank you.

>>BERTRAND DE LA CHAPELLE:   Anybody else would have a comment? 
Particularly among the GAC members, if I may, I encourage them, who
are planning -- oh, sorry.  Go ahead.

Ravi, go ahead.

>>INDIA:   Thank you, Chair.

On issue of IDN gTLDs, I would tend to think that there is a need to
have an awareness activity on this for the simple reason, in the lack
of an awareness activity, there may not be a demand for it.  So that
is primary to the issue.

While the movement I heard on the IDN ccTLD fast track, if we may
call it, order, hasten the understanding, I still think that the
profile of IDN gTLD would be predominantly commercial-driven.

Second aspect.  While the gTLDs is a very well-embedded system, the
operators or the registrars of the gTLDs, would they pitch in for the
IDN gTLDs is an issue that would open up, depending upon the pricing
mechanism of the IDN gTLDs in itself.

>>BERTRAND DE LA CHAPELLE:   Thank you.

Could I ask other GAC members if -- who are planning to have IDNs
whether they are aware, to follow on Ravi's question, whether they
are aware of actors in their country, or maybe themselves, that would
have initiatives or are planning initiatives of IDN gTLDs?  Because
in the ICANN environment, honestly, I'm hearing a lot about
initiatives for new gTLDs, but almost all of them are presented in
Latin characters.

Are you aware -- and we can make a poll of initiatives.  I know that
China has plans to do dot Chongwu and maybe another thing that is for
commercial activities.

Is Egypt aware of things in Arabic in the space?

>>EGYPT:   Yes.  Thank you, Bertrand.

Yes, I think the League of Arab States have already contacted ICANN
regarding dot Arab in Arabic script.  I think both in Arabic and ASCII.

>>BERTRAND DE LA CHAPELLE:   Dot Arab or dot Arabic.

>>EGYPT:   Not Arabic.

>>BERTRAND DE LA CHAPELLE:   So it's not the language --

>>EGYPT:   No.

>>BERTRAND DE LA CHAPELLE:   It's the region, community?

>>EGYPT:   Yes, more.

>>BERTRAND DE LA CHAPELLE:   And it would be run or applied by the
Arab League?

>>EGYPT:  The Arab League as the owner or the administrative
contact, but definitely not the operator.

>>BERTRAND DE LA CHAPELLE:   Okay.

>>EGYPT:   So....

>>BERTRAND DE LA CHAPELLE:   Interesting.

Do you want to say something?

Thank you.  China.

>>CHINA:   I'd like to introduce some information from China.  And
now in China, we -- I know there are some Chinese gTLD, some like dot
-- I don't know how to say that -- just similar like company, and dot
network, just like that, but in Chinese.  And they have been running -
- operating this system for a little time.  And it's in the testing
period.

And so I think the Chinese gTLD maybe we will apply for the IDN gTLD.

>>BERTRAND DE LA CHAPELLE:   Thank you for the information.  It's --
Vanda.

>>VANDA SCARTEZINI:   Now, I just raise some point that may be not
well accepted around, but it's a kind of price.  And we should think
about the ccTLDs around the world in IDNs should not be treated like
a commercial issue.  Because they are not.  They are not.  They are --

>>BERTRAND DE LA CHAPELLE:   You will get a lot of support on that.

>>VANDA SCARTEZINI:   They are not.

Their role is to allow their population to be connected.

So we need to have some kind of statement about that.  Because it's
being treated like it's commercial, it's profit and so on.  It's
completely wrong.

And maybe we'll avoid many countries to go into the IDN.  It's a
very high barrier on this.

We in Brazil, we don't have this kind of problem of IDN.  But I can
see in other countries, how could this be a barrier, you know, to pay
a lot of money when you cannot get profit from that.  And, you know,
it's something that you need to offer to your population.  That's
something that certainly I don't know why the approach of ICANN with
CC IDN was different.

>>CHERYL LANGDON-ORR:   We don't know?  You don't know?

>>VANDA SCARTEZINI:   I know, but I don't want to share.

>>CHERYL LANGDON-ORR:   We won't say.

>>VANDA SCARTEZINI:   But that's the point that I would like to
raise here in GAC.  Because in my point of view, it's something that
it's not acceptable.

>>BERTRAND DE LA CHAPELLE:   Manal.

>>EGYPT:   Yes.  Just following on what Vanda just mentioned and as
a matter of clarification, the League of Arab States did not yet
submit an official proposal because of the pricing issue.  They just
communicated with the ICANN maybe sort of a letter of interest or
something like that.  But they are still studying how can they afford
for submitting a proposal.

>>BERTRAND DE LA CHAPELLE:   Thank you.  Actually, this points to,
one, the question of the recent formulation of the average suggested
price for the ccTLD.  And there is a discussion that has to take
place not only on the obligation or not, but also on the amount.

The second thing, what is interesting here is that we might have, in
certain countries, initiatives by the government or by public actors
to launch gTLDs or gTLD-like level domain.

The problem being then, will those IDN gTLDs be exactly treated like
the current gTLD framework for purely commercial or so.  In the case
of China, this has been running for a while, I suppose you will be
confronted with the question of will this thing be treated like any
purely commercial gTLD introduced by the --

>>VANDA SCARTEZINI:   Yeah, can I sell for any countries -- it's not
the idea behind those things.  It's the lack of understanding from
the ICANN side on that.

>>CHERYL LANGDON ORR:   There seems to me like there's an
opportunity to explore some mutualisms here, and we might make a note
to come back to that later, Bertrand but when something on IDNs --
oh, sorry.

Alan.

>>ALAN GREENBERG:   It's quite clear that ICANN's current position
is, it's a single price for all.  At the second -- in the second
round, if and when there is a second round, maybe we'll look at it.

And that's been the position since I have been involved in the
process about two and a half years ago.

I don't think we have ever succeeded in convincing ICANN that, at
the first round, there really are different situations for different
people and they should be allowing it.

That message from the GAC, which I don't think has ever been
conveyed strongly, might well help change that situation.

>>BERTAND DE LA CHAPELLE:   Jayantha from Sri Lanka.

>>SRI LANKA:   I think following up from what Manal and Alan and all
the others said I concur with.  And as quite stated during our
earlier meetings in the week at the GAC, one of the dissuading
factors preventing government from responding to the letter from
ICANN was the -- of course the contractual issue, which is a
political issue, as well as the fee -- the suggestion that it would
be bordering on compulsory.

[ Laughter ]

>>SRI LANKA:   So we, I think -- So with those issues, we can
(inaudible) at this time, as quite rightly suggested by Alan.  There
would be a clear message from the GAC indicating what our position
would be in connection with that situation.

But in relation to the gTLDs, we cannot even persuade potential
tourism or spices or tea exporting communities to even consider
playing, because the amount is exorbitant.  So I think --

>>ALAN GREENBERG:   That's the important message.

>>SRI LANKA:   The pricing factor is something the ALAC and GAC
should all together request ICANN to reconsider.

Thank you.

>>CHERYL LANGDON ORR:   Bertrand, I'm wondering whether or not --
we're sort of morphing between our first and second agenda point. 
And I think that's a very healthy thing, thinking about to where we
were discussing this in our ACSO meeting in Mexico.  And the question
was raised, of course, are we going to see a difference between some
Cs and some Gs in a new world.

>>BERTAND DE LA CHAPELLE: Frank.

>>NEW ZEALAND:   Yes, I'm sorry.  It's just the issue of generic top-
level domains in the IDN space.

We have -- Although the GAC hasn't made a statement about that in
terms of costs, we have put on our agenda, not yet of submission to
the board but one to be discussed after this meeting, to be sent
after this meeting, the idea of social and cultural top-level
domains, which have very, very many similar characteristics.  In
fact, the driving forces are much the same.

There was a discussion yesterday, a workshop, talking about
linguistic and cultural top-level domains.  There's not a big
difference between these two constituents.

But the commonalities are that they are noncommercial.  They are
often restricted to relatively small groups.  They have very little
overlap, in fact, with the interests which drive so much of the rest
of the generic top-level domain space in terms of property rights,
trademarks, and all of those sorts of issues.

And so I don't think it's a big shift from the point of view of the
GAC to note that these same characteristics, of course, do apply to
ccTLD IDNs.  And perhaps some of the other generic IDNs as well.

Thank you.

>>BERTAND DE LA CHAPELLE:   Maybe one point before, as Cheryl said,
morphing into the second topic.  If I understood well, you were
suggesting to see whether this would be appropriate for a sort of
joint statement, of sort.

Spontaneously, but I would be --

>>CHERYL LANGDON ORR:   An exploration of the option.

>>BERTAND DE LA CHAPELLE:   I would be asking the GAC members, it
may be early to jump into this format, but at the same time, I think
there has been a certain number of bullet points that clearly are
common concerns.  I mean, things that we both know are apparently
shared.

So I suggest that maybe after this meeting, as a feedback for us,
just having a document for our own internal consumption, not as a
statement externally, saying some points were addressed, and in
particular, these elements were identified.

>>CHERYL LANGDON ORR:   Yeah.

>>BERTAND DE LA CHAPELLE:   That we can use them later on.

Adam.

>>ADAM PEAKE:   Adam Peake.  I am an ALAC member.

And following on from Frank's comment, in our submission to or our
response to, I think it was version 2 of the gTLD guidebook,
handbook, we did make points about pricing, that there should be for
new -- well, for new TLDs, whether they be IDN or not, those that
don't have any interest in monetizing that particular TLD should be
looking at different pricing structures.

There should be concern for -- another point was a concern for
domain names that would never be aiming to have a particularly large
number of registrants.  They may be specific to cultural or
linguistic applications.

So I think we are already on the way to having a quite similar set
of comments, and the responses we put into the guidebook cover some
of this.

Looking at Stefano over there, there was a specific one for Italy,
which Vittorio Bertola is trying to lead.  So those would be issues I
would imagine that the GAC and governments would be interested in
because they come into your sort of sovereign space as well.

So that's one issue.

Just going on and raising a separate issue, and probably one that is
rather risky, is WHOIS.  And I was wondering if they has made any
consideration of what happens with WHOIS in the IDN world and IDN
ccTLD world, saying the ALAC has not considered this, but it is going
to be an issue I imagine we are going to have to consider because it
seems to live with us all the time.

>>BERTAND DE LA CHAPELLE:   Any comment from GAC on that?

GAC members?

I think the fair answer and the short answer is we are relatively in
the same situation.  We care about this.  We haven't devoted a
specific subject to -- a specific discussion to that issue.

At the same time, you know that the WHOIS issue is of great concern
for the GAC, and the ongoing nontreatment of this issue is of great
concern.

So I think one benefit of this meeting is to flag for us also that
this is maybe something we should put on the agenda further.

Alan.

>>CHERYL LANGDON ORR:   Just before I move to Alan, I think it's
just worth all of us noting that, of course, the SSAC, in some of
their current work -- so we're bringing in another AC I realize --
are focusing not on WHOIS, per se, but the effect of the
internationalization of scripts in registry data.  And that's
something we could perhaps marry in here as well.

Sorry.  Go ahead, Alan.

>>ALAN GREENBERG:   Almost no need after you said that.

I was just going to point out that with the registration of second-
level domains in IDN scripts, we already have the issue that the
WHOIS data is being submitted in other scripts that are unreadable
and unprocessable by the current WHOIS.

And there is an effort going on in a number of places, including the
-- I think starting in the GNSO, but originating with SSAC, on new
tools for WHOIS which will allow processing of IDN.

And that's separate from the discussion of what data is in WHOIS,
but just saying how do we handle these scripts and make them readable
and legible in the various other contexts that they may be used.

>>BERTAND DE LA CHAPELLE:   If I may make one comment on this.  It's
a very interesting distinction, because the way I understood the
question was slightly different.

But actually, there are two different problems.  Is the WHOIS system
for IDN TLDs, one, which is in certain way the similar question that
we have for the rest, which is WHOIS rules for ccTLDs are different
from country to country, and for gTLDs we have a problem regarding
privacy and so on.

And the second question that you are alluding to is the existence of
data in WHOIS databases in languages that may not be accessible by
all.  I think this distinction is a very important one that we must
keep in mind, yeah.

Cheryl, shall we move to -- Any other comment?

>>CHERYL LANGDON ORR:   Well, let's morph officially through to the
new Gs.  And there I'm not going to be surprised if we head into an
interesting discussion on geographics.  And I'm expecting to hear
much from the GAC on that, hopefully.

And just before we get into what could be a more extensive
conversation -- because I've heard your views on this before,
Bertrand -- I wondered whether or not, while we're looking at
transition from the IDNs to the new, if we look at the one-, two-,
and three-character rulings in the G spaces, which obviously, for
scripts which use Pictographic, single or two-image meanings, is
something that both our end user interests, the few billion that need
that, and out on the Internet yet, and your sovereignty issues I
would have thought have perfect nexus.

>>BERTAND DE LA CHAPELLE:   Do you want to start with this issue? 
Or deal with the geographic?

>>CHERYL LANGDON ORR:   I think if we start -- because we are moving
from IDNs on.  I am a very linear person at times.

I thought we'll move through the IDNs and then into the geos.

>>BERTAND DE LA CHAPELLE:   If there are GAC members -- in
particular, Korea or China or -- those are mainly the Korean,
Chinese, and Japanese TLDs that are concerned about this question of
the limitation to one, two, or three characters.

Korea, would you....

>>REPUBLIC OF KOREA:   Hi, I am advisor to the Korean government.

Particularly, three-character issue, I think China already
introduced and explained that issue.  So I don't want to reiterate.

And with the geographic issue, as we stated since Mexico meeting,
our position is two years, geographic -- I mean national related
names, like city and river and those things, then the entity -- I
mean the new gTLD applicant must get approval from Korean -- I mean,
its government or concerned authority.

That's our position.

Thank you.

>>BERTAND DE LA CHAPELLE:   Yes.

>>JAPAN:   Thank you, Chair.  I am from Japanese government.

I would like to say about geographical names in IDN space.  

In Japan, there are about 1,800 cities, and all -- almost 70% of
those city names, it's only one character or two characters in
Japanese character.

So in Japanese government position, we would like to say at least in
geographical TLDs, we'd like to use one character and two characters
in gTLD top-level domain.  Thank you.

>>BERTAND DE LA CHAPELLE:   May I ask one thing?  Is this one-, two-
, three-character limitation mostly a question for Korean, Chinese
and Japanese?  That's my understanding, at the moment it's this
triplet of scripts that pose the main question.

Do we have the same question in Arabic?  In the different scripts
that you use in India?  No?

And in Cyrillic?  If I may ask.

>>EGYPT:   In fact, in Arabic, we have two-letter words, but of I
don't see it as a pressing need right now.

>>BERTAND DE LA CHAPELLE:   Interesting.

>>EGYPT:   I cannot recall country names that would be of two
letters.  But we have two-letter words, and that's why abbreviation
did not work for our language, because abbreviation in two letters
lead to other words, other than what was intended.

>>BERTAND DE LA CHAPELLE:   One thing, in Cyrillic, there's no --
okay.

No, that's just to verify.

The point I want to distinguish clearly for the record following
this discussion, we have the question of the type of script that have
problem and those who have not.  What I understand is that there's a
sort of list that the CJK are the key issue; that Arabic may be an
issue but it's not a major problem; and that the other scripts do not
seem to be problematic in that respect.  Point one.

Second aspect is whether, if the constraint is being released for
the CJK, is it released for all types of TLDs or for certain type of
TLDs, in particular related to geographic names?

Does China, Japan and Korea wish to have the authorization to have
TLDs in one, two and three characters of any sort or only for the
country name or only for geographic names?

What is the feeling?  To take the opportunity to clarify this point.

Yes.

>>TAIWAN:  Let me talk about the Chinese domain name in Taiwan.  We
already have three country with Chinese domain name.  But each
Chinese character use two byte, not one byte.  So usually our
geographic name have two Chinese character.  That means it has four
byte.  But at this moment, with this kind of geographic, we have to
the special reserve for the government.  Only the government can
apply for a geographic name because the country or city government
can apply this kind of name.

So it up to the gTLD, I think at the moment, the Chinese character
would need four byte not two byte.

>>BERTAND DE LA CHAPELLE:   Can I ask Japan if you can précis what
you were saying earlier.  Would you like to see the possibility of
having one, two and three characters for all types of TLDs or only
for specific ones?

>>JAPAN:  Thank you, Chair.  It is very hard to say because already
it was said, Chinese characters, only one Chinese character had some
meanings.  For example, oot (phonetic) or schee (phonetic) like that,
there are a lot of Chinese characters, it has meanings.  

So it's very hard to say about that kind of things.  But in Japanese
government position, we would like to say at least for geographical
name, it -- we be allowed to use top-level domain.

Thank you.

>>BERTAND DE LA CHAPELLE:   So it could be summarized as a minimum
for geographic names, and the rest can be explored according to need.

>>JAPAN:   Yes.

>>BERTAND DE LA CHAPELLE:   Thank you.

May I ask China if you could précis this?

>>CHINA:   I want to say, I think because Chinese, one character
Chinese -- one Chinese character is -- have a lot of meaning for us,
so I don't think the restraint for the string is -- is necessary for
us.

And no matter for the geographic name or the popular name -- the
other names.  Yeah.

>>BERTAND DE LA CHAPELLE:   So fundamentally, you would like no
restriction for Chinese characters.

>>CHINA:   Yes.

>>BERTAND DE LA CHAPELLE:   One, at minimum, but....

>>CHERYL LANGDON ORR:   Izumi wishes to.

>>IZUMI AIZU:   Thank you again from the users' point of view and I
would like to echo what our Chinese friends just say.  My name is
Izumi, my first name.  It's only one character is used with maybe 12
strokes, given perhaps the several number of strokes if you use the
alphabet.  It's more complicated.

There are many things, like Zen.  It's a sort of the kind of
religion, that's one character.  Many common things, people's name or
product name, brand name, quite often use by only one character,
which has much more strong impression to people.

So -- But again, so the number of characters are not necessarily the
only component of a meaning semantically.  You can use strokes and
stuff like that.

So there's a lot of sort of diversity in the languages that should
be taken into account.

Thank you.

>>BERTAND DE LA CHAPELLE:   Thank you.

Ravi.

>>INDIA:  Thank you, Chair.

I'm just trying to get back to a little fundamental, in order that
I'm not misunderstood the issue.

I hope that the string length is not being discussed, because this
was one particular facet which was elucidated during the course of
the GAC discussion, that the acronymization and abbreviation is a
typical anglo phenomena, and it cannot be done so in Indian
languages.  The string length will vary according to the language,
even if the script is used similarly, because one particular script
is used by 11 languages in our country.  And the string length will
vary.

So I hope that the character and the string do not mean the same in
this particular context.  And the full name of the country, as would
be represented in that particular language, would mutatis mutandis be
applied when the IDN ccTLD is taken ahead.  Just a clarification.

>>BERTAND DE LA CHAPELLE:   Does that mean that for the different
scripts that are being used in India, which I know are many and cover
several language each, you would also wish that there is no
particular limit on the number of --

>>N. RAVI SHANKER:   Exactly.

>>BERTAND DE LA CHAPELLE:   Good.

Any additional comment from ALAC members, maybe, on this point? 
Whether there is an objection or an endorsement?

>>CHERYL LANGDON ORR:   To be honest, as far as I have measured in
our discussions through mostly the CC fast-track exercise, which we
often did blue, we are talking about from an end user or potential
end user point of view, it's only going to be most effective
introducing the next billion and the billion after that if there are
high degrees of trust and familiarity with what they are seeing.

So obviously, from our view, we want it to have a natural fit with
what is normal in the language and the script.

So that really says absolute support for everything we've heard.

>>BERTAND DE LA CHAPELLE:   Fine.

Geographic names now.

>>CHERYL LANGDON ORR:   You just love that, don't you?

[ Laughter ]

>>BERTAND DE LA CHAPELLE:   No, I think it's one of the fields where
the GAC position is sometimes misunderstood, so I would like to give
our -- my colleagues the opportunity to put forward and explain maybe
to an audience that hasn't heard it from the horse's mouth the reason.

Bill, would you like to explain or Ørnulf?  Ørnulf.

>>NORWAY:   Thank you, Chair.

The -- I think this discussion here shows very clearly that a lot of
the countries feel that the principle of subsidiarity is relevant for
these new top-level domains.  So at least our position, and I think
that is shared among a lot of other countries -- also for the new
IDNs, for cities or whatever -- it is the governments that should be
very much involved in these decisions.

And therefore, they should not be treated as ordinary gTLDs and more
as the same way as the existing ccTLDs regarding the principles, as
the GAC principles for delegation and administration of country codes.

So I think this shows that that is a very important issue, that that
principle should also apply for that.

But of course in the selection of the strings and so on, these are
new strings.  So of course there must be some work on checking that
the strings are okay with the root and so on.

But then when that is -- that work is done, these should be treated
and delegated in the same way as ordinary ccTLD delegation.

Thank you.

>>CHERYL LANGDON ORR:   We did have a little briefing this morning,
and I'm actually, later on, going to ask Vanda, because I wasn't at
that briefing and discussion, what, from our ALAC point of view, was
happening with the discussion we had on geographics, because I think
we are more likely to find mutualism than difference on these things.

But are we going to be talking just first or second level in the use
of geos?

>>BERTAND DE LA CHAPELLE:   Yeah, because you were mostly talking
about the first level there.

>>NORWAY:   Yeah, and my comments were mainly on use of top level,
on the geographic names on the top level, yeah.

>>CHERYL LANGDON ORR:   Because, of course, from Australia's point
of view, we've had geographic names for some time now.  AUCD is a
subsidiary, for want of a better word, under auDA control that
releases every addressable locality by name and by state.  So
addressable locality dot state dot AU is available for community use
only.

And I'm sure our geographic names board would get very excited if
that wasn't brought up.

So we use that within our CC.

We already have geographics right down to, and quite literally,
every addressable locality.  And we will be moving very shortly with
the success of these.  And it has been successful, to look at more
landmarks as well.

>>VANDA SCARTEZINI:   Okay.  So just remember that we mostly were
talking about second-level domain in the new TLDs.  And this is quite
another issue.

>>CHERYL LANGDON ORR: Excepting, Vanda, just to make it clear, under
our dot AU space, we would be concerned about confusion and our
market for the want of a better word.  There's a lot of tourism,
there's a lot of small business, there's a lot of community use
that's existing with geographic names within Australia right now. 
And Coonawarra as a second level is going to be a worry for the
existing koonwarra.vic.au.  That's what I'm flagging.

>>BERTAND DE LA CHAPELLE:   Ravi.

>>INDIA:  This is regarding the geo TLDs, for want of a better
description.

The overall perception in GAC was that geographic TLDs or geo TLDs
be treated analogous to the ccTLDs.

Now, I would just like to mention that in the ccTLD space, what we
have done is reserve a few geographic names within the country in the
dot IN registry.

I would tend to think that when the IDN ccTLDs do come in, mutatis
mutandis, whatever has been reserved in the ASCII TLD format would
have to necessarily be done so in the respective IDN ccTLDs for all
the respective languages.

So this is one particular.

I would think the IDN geo TLDs would be the emerging paradigm.

It's too early to say so, but I'm trying to look far into the future.

>>BERTAND DE LA CHAPELLE:   Stefano.

>>ITALY:   Okay.  Let me talk a little bit about the geographic
names in country codes.  For example, in Italy, if you have Tuscany,
for example, we have our internal rules that are different from
Australia and from other countries because every country code decides
the policy internally.

And we only allow, at the second level, regio, that is region, and
then Toscana.

So it is clear that with the new gTLDs, that the government of
Tuscany can say why should I have all my names under Tuscany region
dot IT.  So I can Tuscany, full stop.

And secondly, there is an interest that's growing from country to
country, I see that's quite different.  In certain countries, there
are a lot of regions, cities, or other geographic names that are
already preparing for applying.  In my city, is not so, but there is
a growing interest, of course.

So from what was declared, that maybe the expectation is to have
when the call for proposals will come out, if there will be, let's
say, 800 applications for new gTLDs, but from 100 to 200 will be
geographic.

This is something that was declared as an estimate, rough estimate.

And of course, this creates a number of problems.

And of course the governments will be involved.  But the kind of
problems are quite vast.  For example, name of the cities.  Even if
capital cities are repeated, maybe 100 or 200 times in Canada, in
Australia, in U.S. and so on.

So here, the problem is to find an agreement that no one will
complain.  Because if Roma -- there are a number of Roma around in
the world, and at least we have to find an agreement that the others
will not complain.  Because legally, there is not a uniqueness of the
name of a city that is protected in the world.

And I think that -- and then another point that we are discussing is
that in a country, if you take the example, for example, Catalonia
that is already a name that has been started -- What I'm saying is
that --

>>BERTAND DE LA CHAPELLE:   It's not Catalonia.  It's Catalan.  An
essential distinction.

>>ITALY:   Catalan for the language, but cat is a short that may be
considered a short name, three-letter name, for the region as well as
for the language.

>>BERTAND DE LA CHAPELLE:   Yes.

>>ITALY:   So it's a cultural one, I agree on that.

But the real point is that at least the Catalonia -- Catalan -- no,
Catalonia, had to prove the Spanish government did not oppose.  So
this is the point.

And similar thing could happen in other regions with other names. 
Like, for example, for those that are supposed to prepare already the
proposals, there are the Basque in Spain, or in some regions, there
could be names that are of separatist regions of a country.  So it
might be considered not a good idea to allow this.

And then you might have other names that are referring to
populations that are spread in different countries.

So this problem of geographic names will open a lot of geo politics
questions.

>>CHERYL LANGDON ORR:   Oh, yes.

>>ITALY:   And GAC, of course, will be, in a way or another,
involved, especially for contentious cases.  If not talking about
general names or names like -- or names like rivers, mountains.  Mont
Blanc is part in Italy and part in France, just to make an example.

So I want to make some practical ideas of the problems that we
encounter.  And there is not yet a very precise way to approach this.
Okay.

>>BERTAND DE LA CHAPELLE:   No, Stefano in the sake of time, I think
to make a distinction, the first level -- although it's a complex
issue, I think there is a relative agreement that has emerged coming
from the GAC principles that the local authority is the relevant
authorities have to be not only consulted by agreed.

The question that is more contentious at the moment is the second-
level protection.  And I'd be happy maybe if ALAC members have
questions that they want to ask to GAC members.

Adam.

>>ADAM PEAKE:   It's partly a question, but one of the interesting
questions about "cat" is if it was in Japanese, it would be in one
character, at least the animal would be.  I think that's correct.

And the question I have, really, about the second level and the
protection is really, at times, it sounds like you're trying to close
down choice.  I mean, the number of words that seem to be being
referred to here sounds like half a dictionary when you get down to
it.  And so I think that's the concern, is that it's excessive or it
sounds as though it may be.

>>BERTRAND DE LA CHAPELLE:   Maybe other comments?  Because we will
have half an hour left.  I'd like to keep some time for this.  So
maybe you can make a batch of comments.

>>VANDA SCARTEZINI:   Just remember some issues, that -- of course,
it's possible to have, as we discussed a little earlier, it's
possible to have some predefined situations where governments agree
how they will protect those names.

One point we raised was the time to have this process done, and the
time governments normally take to deal with a bunch of demands from
around the world and so on and getting some authorized form for
getting the name or not.  So this is something that gives us some
worry about if it will be practical and how we deal with that.

Brazil wants to talk.

>>BRAZIL:   Thank you.

>>CHERYL LANGDON-ORR:   I wonder why.

>>BERTRAND DE LA CHAPELLE:   Vitor.

>>BRAZIL:   Thank you.

In fact, I would like to refer to the way -- this preoccupation with
protecting names in the second level began in the GAC and to its
evolution.

Even though people say that governments used to take a long time to
make decisions, the fact was that the GAC was the first body within
ICANN to react and to present recommendations on new gTLDs.  It
happened as early as April 2007, in Lisbon.

And our initial recommendation was that there should be negative
lists of geographic names both in the first and the second levels so
that governments would previously block these sets of names.

And now --  At no cost.

And now -- so I think governments would have these names available. 
We would pay nothing to use them -- to block them, but they would
have to pay for them if they wanted to use them.

But now we evolved since it was said to us now more recently that is
not implementable, that this solution in the second level as you
proposed is not implementable because the list could be arbitrarily
lodged, then what we see now is that there is a twofold approach.  We
would block names in the second level starting from a relatively
short list that would be based on geographic -- on country names or
capital city names and just on United Nations official languages and
so on.

And the approach for the second level would be that governments
would have the right to object to the use of particular names in the
second level against a particular set of criteria.

So what we want to be assured in the contracts with the registries
is that registries are obliged to provide -- that registries are
obliged obey certain rules and against previously defined criteria
protect geographic names from abuse specifically.  

And these names outside this short list I mentioned, we would like
to have the right to object to uses which can be verified as really --
how I would say? -- really abusive of geographic names.

So I think this is a way to prevent unnecessary delay in approving
names, but, on the other hand, to ensure that governments want
against commonly agreed criteria want to find out their geographic --
once their geographic names are abused, these governments will have
the chance to get them protected.  I would like to be complemented by
other GAC representatives if my statements are not clear or if there
are aspects I did not cover.

But this is the present position of the GAC, having ways to protect
names from verifiable abuses.

Thank you.

>>CHERYL LANGDON-ORR:   Bertrand, I know we do need to move on.  But
we do have outreach.  And I was wondering if there's anyone else who -
- perhaps not even at the center table -- wanted to raise anything.

>>BERTRAND DE LA CHAPELLE:   Any other question on the -- on this
issue of geographic names?

>>CHERYL LANGDON-ORR:   If not, I might just read into the record to
raise the awareness amongst the GAC members one that's come in via
Skype.  And it seems like an innocent enough question, but it's one
worth thinking about.

Is there a requirement for new applicants for geographic TLDs to be
located within the territory?  And should it?

>>BERTRAND DE LA CHAPELLE:   Bill, European Commission.

>>EUROPEAN COMMISSION:   Not from us, actually.

I think to be very short, I think what we've said is that the
governments should be involved.  So it's up to them, actually.  I
mean, in some cases, they may well think it's very important that
they're in jurisdiction or, you know, they're owned by nationals in
that country.  And I can easily imagine in other countries that where
there is no -- you know, small South Pacific islands, perhaps, where
there's no indigenous industry there, that they're going to have to
rely on external service providers.

I just had a question, actually.  I -- I was very interested to hear
about the policy for dot AU, that you reserve all of the geographic
names, basically, at the second level.

Have you ever had complaints from Australian citizens that that
policy is inappropriate or overly restrictive?  Or do you get the
impression that they think it's quite a reasonable policy for the
registry to have pursued?  Because I --

>>CHERYL LANGDON-ORR:   Perhaps the Australian GAC member should
respond to that.

>>EUROPEAN COMMISSION:   Because I can see where this accusation is
coming from.  But I think sometimes we need to step back into the
real world in the DNS environment.

And if you look at the GAC principles, actually, I'd argue that
they're incredibly light, given the involvement of governments in
issues such as competition, such as trademarks.  There's all sorts of
restrictions that are very repressive that GAC could have placed on
that process.  We chose to -- the only issue we really chose to
highlight was geographic names.  And that's because we're very aware
as public servants that that's exactly the kind of thing that could
create an enormous amount of political tension in national
parliaments, administrations, if they discover that we've been
sitting in the GAC and we didn't highlight that as something where
the country concerned really ought to have some direct responsibility
for the allocation.

Just while I've got the microphone, sorry, one other thing I'd like
to throw in, because -- and this is a personal view, actually.  It's
not one we've discussed too much in the GAC.  But it seems to me that
as we have this debate, which is a very interesting one, I think part
-- the problem, as I see it, is that we're still trying to live with
this original dichotomy between gTLDs and ccTLDs.  Because somebody
mentioned the example of dot cat, which is very interesting, because
dot cat is a gTLD.  And in the same country, they have dot ES for
Spain.  And the Spanish registry can make its own registry policies. 
It can appoint its own registrars.  And it can work with the local
government and the local Internet community and doesn't do anyone any
harm.  It services the local community.  Whereas dot cat services an
even more local community, and yet it has to adopt ICANN consensus
policies, has to sell its names through ICANN-accredited registrars. 
And it was mentioned earlier on that the GAC had taken a position
that certain types of geographic TLDs should be treated like ccTLDs. 
And if we take the example of cities, I think that the policy logic,
I think, for us is that if you have a TLD which is specifically
within one jurisdiction, it should be treated like a ccTLD, that may
well mean much more than just a local government should be involved
in the selection process.  They should have a say in the redelegation
process as well if that is ever going to happen in the future.

It may even also mean that that registry should operate under
locally defined registry policies and appoint its own registrars.

So I think the consequences of following this line of logic are
quite significant.

But I'd be really interested to know if any ALAC members have had
that conversation or have any reactions.

Thank you.

>>CHERYL LANGDON-ORR:   Well, I think the ALAC members, because of
time here, will take that on notice.  And I'd be more than happy to
take off my ALAC chair hat and meet you in the corridor later and put
on my auDA director's hat and explain exactly how we funded AUCD,
which is by the release, the long-wanted release, of the geographics
in our other spaces.

>>BERTRAND DE LA CHAPELLE:  Two comments.  Brenton, do you want to
make a comment on the citizens' reaction in --

>>CHERYL LANGDON-ORR:   Did I behave, Brenton?  Was that milk for me?

>>AUSTRALIA:   Just to reinforce that, in fact, that process is
administered by the domain administrator, auDA, and they put a large
amount of resources into actually getting it right, and careful
consultation and all of those sorts of issues, and do quite a job.

But even with that, there are complaints at times.  And I guess this
goes to the point which a number of GAC members have heard me make
before, but that we have to be cognizant of the fact that this
process going forward has the potential, if it's referred to
governments on a regular basis, to be quite resource-intensive.  And
auDA does an excellent job and does put quite a few resources into
it.  And there are still complaints from various people that feel
that they're left out or don't get the right result or something like
that, that someone feels disenfranchised.

So that's our experience, basically, with the process.  And I think
governments around the room will have to be aware that they will be
doing that process.

>>BERTRAND DE LA CHAPELLE:   Thank you, Brenton.

I just throw as an idea that we might explore further making, in
that perspective, a relatively extensive collection of data about the
policies for the management of geographic names at the national
level.  In the ccTLDs, it might present very interesting patterns or
formats to study and take inspiration from.

>>SIVASUBRAMANIAN MUTHUSAMY:   I'm Sivasubramanian Muthusamy from
ALAC.  And this geographic names brings up a whole lot of questions
related to ownership of the geographic domain as also the
jurisdiction.  So at some point of time, it's possible for
governments to say that a person opting to register a geographical
domain is physically located in that particular geographic region,
and at a later point in time, it could also become possible to lead
to a situation that there is a concentration of users from a
geographical region, and even confinement of users from a particular
region to that particular domain name, at which point of time it
becomes possible to control the flow of information through the
Internet.  And it might also lead to a situation where a government
of a particular geographic region could say the content from this
region is for this region only and not accessible for a country with
whom we are at variance, and vice versa.

So are these questions examined?

These are not probably possible today.  But it could happen ten
years from now, 20 years from now, at a much later point in time.

>>CHERYL LANGDON-ORR:   Thank you, Siva.

>>BERTRAND DE LA CHAPELLE:   Janis, you wanted to make a comment.

>>LATVIA:   Comment and piece of information.

Comment on Bill's last remarks.

I don't think that dot cat covers part of Spain.  It covers part of
Spain, Andorra, and part of France.

And it was -- it was -- and I don't know where else Catalans live
around the world.  So when the TLD was released, it was released
under certain rules.  And this was gTLD rules.  Whether that should
be changed, that's a different question.  We can talk about it.

But just to be more precise on dot cat.

And piece of information.  Those guys who are promoting dot LAT for
Latin America, they have contacted me already half a year ago, asking
what would be the reaction of government of Latvia to their
application.  And after a round of consultations with the relevant
stakeholders in Latvia, we decided if dot LAT would be available in --
for registration in Latvia, we would not have any objections.  So --
because we considered Latin American region and Latvian region, there
won't be any competition, and we will not even try to reserve the
same names, because we are using different languages.  So --

>>BERTRAND DE LA CHAPELLE:   Thank you.

To occupy the time best, we may move to the third part.  Just wanted
for the record, again, for making the summary, we haven't talked
about categories of TLD, which is a whole issue.  But from the
discussion, I clearly see that geo domains present specific problems,
opportunities, that make them somehow a category in itself, even with
subcategories are we seeing the cultural and linguistic regions, the
cities and so on.  So just exploring the notion of geo domains as
being a category that may have special rules is probably something
worth exploring.

Getting to the last point, which was the ACSO meeting yesterday, you
know, the subject was institutional improvements, the functioning of
ICANN, and so on.

We have a quarter of an hour, which is a short period of time.

>>CHERYL LANGDON-ORR:   Thankfully short.

>>BERTRAND DE LA CHAPELLE:   Yes.

One element that seemed to emerge from the discussion as we saw in
the end is the question of how to discuss in a relatively
comprehensive manner in the coming months the institutional evolution
of ICANN, the reform of the PDP, from the reform of the PDP to the
post-JPA framework.

The floor is basically open on members of the ALAC and the GAC to
maybe give the feedback on what the session addressed yesterday and
how they see the way to move forward in terms of methodology as well.

Who wants to launch the first comment?

Maybe Sébastien, as you --

>>CHERYL LANGDON-ORR:   Don't do that to him.  He has another meeting.

>>BERTRAND DE LA CHAPELLE:   Sorry.  Who wants to take the floor?

Yes, Ravi.

>>INDIA:   Thank you, Chair.

We are living in interesting times.

As the Chinese proverb says.

>>BERTRAND DE LA CHAPELLE:   Which is a curse.

>>INDIA:   Post-JPA, what is going to be the shape of ICANN?  And
within that, what is going to be the shape of GAC?  That is one
particular thing which we have at this point of time in this
particular committee.

I'm also trying to look at another institutional mechanism, the IGF,
which is also through the throes of change or internal review, if I
may call so.  And that relates to what will be the status of IGF
after its five-year interim period.

Now, it is very important to understand as to the nature of ICANN
post-JPA.

If we do as management scenario planning, there's a plan A and a
plan B.  A plan A is that post-JPA, we may have a situation where
there is no agreement in force, which leads to an
internationalization of the ICANN.  I am going back to the hearing
which the president and CEO of ICANN was present and the letters
which have been posted by the chairman of GAC and the GAC members
made.  It reads that there could have been a situation where the
agreement may come to an end, as on 30th of September, and once it
does come to an end, we have a scenario where, like any other
international body or a multinational, it becomes quite distinct from
the not-for-profit corporation within the ambit of some local law. 
So as I would put it, that's scenario 1.

In that eventuality, the role of GAC undergoes a slightly different
paradigm, if I may call so.  And some of the issues have been
discussed in the GAC during the last few days.

The second scenario, I mean, to be, as we say in the sports
terminology, having all different options for every stage of the
game, so if we have status quo, a continuation of the same, then the
situation is as it is, but then the role of GAC also needs to undergo
a little more crystallization as a few discussions emerge whether we
would be just an advisory committee or moving beyond an advisory
committee to a decision-making body.  That is a different ball game
altogether, because within the corporate entity, another decision-
making body does not gel well, if I may say so.  An advisory
committee is the right type of apparatus, if one may call it.  

I am looking altogether differently at the IGF scenario.

If the IGF scenario, is it going to be a continuation of the IGF
apparatus as a nonoutcome-oriented body for a further period of five
years, that is an interesting facet to look forward to.  Sharm El
Sheikh will perhaps give us the direction where the IGF, as the IGF
community is proposing for the Secretary-General of the U.N. to
consider.

If scenario 1, plan 1 of the GAC and plan 1 of the IGF were to
occur, then it leads us to one particular format of action.

If the IGF were to become a full-fledged body, if I may call it so,
and we have a full-fledged multinational corporation in place in the
ICANN, it's a totally different scenario altogether.

So I can see out of the outcomes of this, there would be four broad
scenarios emerging.

Is there going to be a telescoping?  I'm just trying to look far
into the future.  Is there going to be a telescoping at some point of
the GAC and the IGF, which is a full-fledged body?  If certain
factors are preconditioned to it, that I do not know what it is going
to be, because I am also looking at the role in which the ITU is
getting into the Internet domain.  And this was evident during the
course of the IGF at Hyderabad when they were not exactly pleased
with the IGF way of doing things.  And I would like to think that ITU
would like to get back to the back-to-the-board situation.  So that
gets to the 1998 position of the ICANN-ITU imbroglio, if one may call
so.

So these are all the situations and scenarios that are there.

I mean, I'm looking at it in a very sporting manner in planning.

>>BERTRAND DE LA CHAPELLE:   There are very few games where you have
three players on the field actually interact.

>>CHERYL LANGDON-ORR:   Bertrand, looking at the enemy of us all,
which is time, and I would not dare respond and start that
conversation, this is a whole 90 more minutes you've just introduced
for us.  Perhaps that's something we could look at in exploring
mutual conversations in the future.

Unless somebody has a burning desire from the GAC to make a
statement, I would like to propose that we thank all of the
participants, and I'd like to personally thank Janis and you for
chairing, because you've got more people coming in.

>>BERTRAND DE LA CHAPELLE:   I'd like, actually, to -- before we
close, to look at the way it was terminated yesterday in the meeting
in the SOAC.

As you know, there's a document that has been probably produced by
now --

>>CHERYL LANGDON-ORR:   We haven't seen it.

>>BERTRAND DE LA CHAPELLE:   I haven't seen it, but that has been
produced by Patrick Sharry was the animator of the session.

One element that was raised during the session was this notion of
prioritization -- whatever the ugly word is -- prioritization of
issues.

As a matter of fact, I think one thing came out very clearly out of
the SOAC session and in the GAC discussions on Saturday, I think, is
that the issue of the institutional evolution or institutional
improvement is becoming an issue in itself that should be given high
priority because of the whole dimension.

The question that we're all facing is, what is the format for this
discussion?  And for your information, I understand that the board
Structural Improvement Committee is about to take the decision or has
already taken the decision to try to weave together a little bit more
the different review processes.  I don't know to what extent they
will be doing it.  But it's clearly going in that direction.

And one of the topics of continuing interaction, and, in particular,
one of the outcomes at the end of the session was that the SOAC --
the group of chairs could become interacting more with the Structural
Improvement Committee in order to define the processes moving forward.

So I just wanted to highlight this.  The SOAC session might help the
discussion move forward in a more communitywide manner.  That was the
point.

>>CHERYL LANGDON-ORR:   Another high point to end on.

Thank you very much.  And if my lot could quietly leave and let
these GAC rooms get back to the important business that they are
continuing.

Thank you very much.

>>CHAIR KARKLINS:   Dear colleagues, we are starting in 15 minutes,
3:45.

Please be back in the room.

(Break.)