Tip:
Highlight text to annotate it
X
Cerf: Okay, welcome back.
Now we get to jump into another angle
in all of our discussions,
and that's standards,
which have implicitly been part of our discussion,
but no so explicitly, so...
[man speaking indistinctly]
[laughter]
Yeah, sure.
[laughter]
So, I've asked...
I've asked Zaheda Bhorat,
who is responsible for managing and sort of overseeing
what's happening in the standards world for us,
to manage--organize and manage this session.
So, Zaheda, I'll turn this over to you to get started.
Bhorat: Okay, thanks, Vint.
Can we have the slides?
So standards are at the core of the Internet,
and a reason why we as Google exist.
We depend on the standards that make the Internet work.
And standards provide the platform
on which we, as Google, innovate
and what enables us to deliver
one service everywhere around the world.
So if you were surprised
to see "standards" on the agenda today,
and the condolences from the middle of the room there,
you know, you're probably right.
They do tend to get overlooked as part of the plumbing
and maybe because we take them for granted.
Standards are not what makes the headlines,
and so it's very often that nobody talks about standards
unless something breaks.
They develop through active, collaborative communication
between experts in the field,
from researchers, educators,
communications between network operators,
Internet vendors,
and typically the issues are raised and resolved
without users of the technology being aware.
Today we have a panel that have worked very closely
addressing the challenges going ahead
that will make the Internet simply continue to work,
so we and others can continue to innovate
and allow an even greater growth
than we've seen in the last decade.
Our panelists between them--
we just learned in the break here,
actually only just between two of them--
have over 80 years of experience in the standards development.
And we'll start with an overview
of the standards world,
followed by a quick look
at Google's participation in standards development,
and then three of our experts will highlight key areas--
DNS, IDN, and IPv6,
three issues that have already been discussed earlier today
just very lightly.
And these are areas where Google is active,
and they're significant
to a healthy and open Internet of the future.
So with that, let me introduce John.
So... [laughs]
Sorry, not John, Tony.
I got confused there.
[man speaking indistinctly]
[laughter]
So I actually got bios for my speakers,
and decided to create cloud tags for them,
because there was so much information,
such great accomplishments,
that I just wanted you to have a few minutes
to look at these tag clouds.
Rutkowski: Hmm. Wow.
[laughter, speaking indistinctly]
Oh.
I think that's an artifact of the way colors are displayed.
man #1: Can I see a show of hands real quick
on who can see the blue as being about six inches deeper?
Rutkowski: Yeah.
man #1: Okay.
I've never seen an image quite like that.
man #2: Is it defocused?
Is that what's causing the effect?
man #3: No, no, it's the way your eye focuses.
It's a retina thing.
[laughter]
man #1: Did it come from staring at screens too much, or is it--
Bhorat: Oh, this is a great--
It's a great app on the Web called Wordlet,
which I used to create these slides.
Rutkowski: Cool.
Anyhow, you know, I'm friend of Vint's
and been around.
[laughs]
Actually, there's three white beard--
no, four white beards that we have here.
So there's just a couple of slides here,
what I called
Why, Where, What of Network/ICT.
The term "ICT" is increasingly used today
to sort of describe information communications technology,
so, you know, for a lack of a better name
of sort of packaging all this stuff up.
This one is to answer the question
why we subject ourselves to this.
So the second slide is really the biggie,
which is sort of what the echo system looks like today.
I thought I'd do this...
You know, I had preceded to say, you know,
why we subject ourselves to this,
and it seemed to me
that everything falls into these categories,
which is what I call
"Legal system instrumentalities."
So one of them is, you know,
it's public infrastructure requirements
especially relating to cyber security,
and there are all kinds of mandates
that are typically associated with that
to affect services required by governments and citizens.
So there's a lot of this stuff
that ends up being mandated for one reason or another,
and then there's promoting competition,
something near and dear to Google's heart.
Contractual compliance and liability mitigation,
which is something that's sort of in everyday use
in terms of, you know,
relationships between different commercial players.
They're used in conjunction
with the contracts that are involved.
And also in this category
is actually the IETF,
sort of realized at one point,
is avoiding restrictive intellectual property claims.
And so those are a set of things
which is--you can, I think, conveniently put
under the rubric of legal system instrumentalities,
as to why one does standards.
The other big category is
"Enterprise and National/Regional Strategies,"
and this is-- the first biggie
is creating large marketplaces and platforms for innovation,
which, again, would, I think, be one
that would be near and dear to Google's heart.
And then the second one is what I call
implementing or parenthetically preventing
sustainable competitive advantages.
So if you want to create--
If you're a company
and you want to basically take your pride and joy
in terms of your specifications
and infuse them into the right standards
as standards for the rest of the world to use,
that's a way to do it.
The "or preventing" thing is a little--
When I worked for Sprint,
Sprint actually joined a bunch of standards bodies
for the sole reason of watching what AT&T was doing.
[laughs]
And in fact, I think MCI had the same problem
with respect to the RBOCs.
So that's it.
That's where we--yeah.
Cerf: So, Tony, one thing that's missing from this picture
is the word "interoperability,"
and, for me,
that's probably one of the most important motivations
for creating and using standards.
Does that fit here?
Is that part of the creating large marketplaces
and platforms for innovation?
Is that where you would capture that notion,
or does it belong somewhere else in this lesson?
Rutkowski: It's probably several places.
One is promoting competition,
and the other is a mandate for public infrastructure.
I say, "especially cyber security,"
but interoperability is the other one
that's classically associated with public infrastructure.
If you look at, you know,
any of these bodies, like ITU that's been around
for 150 years,
they've got it in their charter.
That's the reason they exist, is to promote interoperability.
So the next one is kind of the fun one.
This is a kind of a classic "you are what you eat,"
and obviously we all
have participated or followed lots of standards bodies
over our careers.
I, perhaps, have been fortunate or unfortunate
to probably participate in more than many.
And in fact, this chart was actually done
in the early 1980s when I was at the FCC.
And in the office of science and technology,
we're trying to understand what was out there
in terms of standards bodies,
and one of my jobs on the side
was to sort of follow what was going on,
so this was my kind of cheat sheet,
which became subsequently institutionalized
in various other lights,
like publishing telecommunications magazine,
or being at the IT or whatever,
and it sort of grew and became ever more complicated.
This is a somewhat simplified version.
The last of the really complex versions
was done in 1994, and I sort of gave up.
It just became too complicated,
and in fact, one of the problems here
is each one of those major bubbles
has all kinds of sub-bubbles and sub--
It's basically a tree of different groups,
and there's kind of a backplane in which they--
they're all connected together in various complex ways.
So depicting that is very, very difficult.
But what I tried to do here
is organize this in several ways.
One is-- Not sure if you can read this.
Probably not.
[man speaking indistinctly]
Oh, yeah, yeah. That's true.
Down here, I literally--
So trend one, a rise of the specialized forums,
followed by some convergence.
So I think what's happened since 1994
is there's been a proliferation of these,
and then a convergence over the last several years.
And that's a subject of long discussion,
but one is what I would call is a...
man: All domestic clusters?
Rutkowski: Yeah.
man: This is a reading test for us to help you.
[speaking indistinctly]
Rutkowski: So...
so that--that's...
man: You can't read it from too close.
Rutkowski: Yeah.
So that's a simple--
that's a typical domestic cluster.
So it's basically these--
one can call them bottom feeders--
to the major international organizations,
and then kind of one of the classics is ATIS.
This was a--
I confess, when I was at the FCC,
we actually created ATIS,
which was probably-- which made sense at the time,
because its role was actually to open up
the SS7 infrastructure.
Cerf: This was after the dismemberment of AT&T.
Rutkowski: Right, right.
So they needed something
to basically open up that process,
and it was made very open.
Anyone could go. Anyone could participate.
Anyone could follow.
You know, the standards were freely available,
and their mission in life was basically the FCC told them,
"Thou shalt create open-network standards
for the SS7 infrastructure." Yep.
man: Yeah, Tony--
Sorry, I don't see any microphone,
so I'll just shout.
What about the mold of sort of industry...
What your graph doesn't show
is the funny quasi-industry role.
For example, when you were making this slide
in the mid 1990s,
the answer was that CableLabs
was far less important than at homes lab.
That is, in fact, at home
was giving the Good Housekeeping seal of approval
for the industry,
not CableLabs or anybody else.
That's declined somewhat, I think,
but I wonder how much that plays a role
in the ecosystem here--
whether they just sort of occasionally pop up,
or do they come back and go away and--
Rutkowski: Well, you notice "CableLabs" is right here.
man: Yeah.
Rutkowski: In a somewhat larger circle.
man: Yeah.
Rutkowski: Because they have become important
for the entire industry,
and very cleverly, the guy who--
the guy who headed CableLabs, *** Green,
had an international vision,
and he, like, cut a deal behind the scenes with ETSI,
to have ETSI bless CableLabs standards
so that whatever they did
effectively became global standards.
In fact, he also went into the ITU-T,
chaired the group that dealt with cable standards,
and said, "Well, just bless CableLab standards."
So they have very cleverly
basically, you know, engaged in this strategy
of achieving global dominance,
which has been helped by the fact
that the cable industry
basically funds full-time engineers
to help develop the standards,
and they didn't make the mistake of,
you know, not making them available.
You can download all their standards,
you know, on their Website.
So they did--They sort of did all the right things.
ETSI and the three GPP groups
sort of did the same clever kinds of things.
After getting beat up--
They saw the--the stuff that Vint and I were doing
in the early '90s, you know,
with respect to evangelizing
the availability of open standards.
They finally got it, started doing it,
and as a result,
3GPP is one of the really major playing grounds these days
for mobile standards.
They have meetings every couple months.
Hundreds of people, hundreds of documents.
And they've even spun off the IMS forum.
So, you know, stuff is split between that venue now
and 3GPP.
Even the doc--
[man speaking indistinctly]
I think to disrupt--
Probably the latter.
I think the interesting game,
and it's sort of, like, the last live--
you know, and one of the meta-issues,
revolves around cyber security.
So I think that's gonna be a...
a significant disrupter.
The other one, interestingly enough,
is still, believe it or not,
this issue of open availability of standards.
You know, ISO SC27,
which is, you know,
security and cyber security,
is meeting in Beijing right now.
Does anyone have any idea
what documents exist at that meeting?
They're almost impossible to get.
Even if you're part of the process,
it's just horrendous.
And then they turn out these standards,
and they sell them, you know, for 500 bucks a pop
to take a look at them,
and, you know, most of them, you know,
frankly probably suck.
And so, you know,
they're putting themselves out of business.
So that still remains kind of a disrupter.
There's another disrupter that I sort of get to
at the end too, which is interesting.
One is the availability of standards.
The other is availability of the registration
and the information and the extensions and stuff
that's created by standards,
and I think that's gonna be a--
over time, in the next couple years,
a big disrupter as well.
And, you know, I'm sort of proud to say
that actually both--
ICANN, in terms of running IANA these days,
as well as the ITU-T's TSB,
have been playing a leading role there
in implementing systems
in which you can basically get real-time access
to the, you know, registration information.
I think that's gonna be important
from a cyber-security standpoint as well.
In terms of the grouping,
the size is a variable.
I've tried to approximately locate these things
in clusters of subject matter
in how they deal with each other.
Down in the lower left-hand corner,
there's sort of a gaggle of what I would call the forums,
and I've got some of them on there,
TM forum, multiservice forum, CAB forum.
I've got some domestic ones
that effectively are international, like NIS.
A lot of NIS security standards
are pretty much international standards these days.
There's DHS MITRE standards,
which are important for cyber security.
Liberty, Open Group-- there's all these.
And then, you know, there's--
And then these domestic clusters,
it's intended to sort of point out
that there's these clusters in most major countries
of kind of mirror organizations
that have relationships with these--
with at least the bigger international ones.
And then last but not least,
you notice the big circle I have here,
"APP Development Forums"?
I think that's another really interesting phenomenon
over the last 15 years.
It was sort of started, I think,
you know, at Sun, by some of the stuff,
you know, Eric did--Microsoft.
The private companies that were big enough
to really control sort of major pieces of the marketplace
effectively made their standards open and created
application-development communities,
even, for example, RSA.
RSA, some of the key security standards are still--
are open, but they're still RSA standards.
Vint?
Cerf: Tony, since you're not down here to answer questions,
I'll channel you from the floor.
NGN and IMS strike me as being inimical
to a lot of what the Internet tries to do,
but I could be wrong about that.
Would you care opine on the risk factors
associated with NGN and IMS
and, you know, how effective is this activity?
How potentially disruptive can it be?
If it's a serious problem,
is there anything we can do to counter it?
Rutkowski: If I were Google--
Yeah, I know.
The Inter--well...
[sighs]
They are a serious factor.
In the I--EG, the ITU-T today,
the biggest group is Study Group 13, which is NGN.
Cerf: What's the relationship between the NGN forum
and the ITU-T?
Rutkowski: The NGN forum
is actually a kind of a little sideshow
of where some of them--
some of the NGN folks play.
Most of the real NGN work,
and this would be, like, a sub-bubble, goes on in--
It actually started in ETSI TISPAN.
And then the ITU-T spun up Study Group 13.
ATIS now at the US domestic level
is mainly--significantly oriented around NGN.
So there's this whole NGN community
of standards bodies,
and they have a somewhat different view of the world
that they're trying to sell
as the security solution.
Cerf: Are you saying NGN is being sold
as a security solution?
Rutkowski: Absolutely.
Cerf: Can we get a microphone over here?
Rutkowski: It's being sold as a combination
of standards and relationships
amongst NGN companies,
and I thought one of the--
one of the really neat things
was a document that's actually coursing its way
from ATIS to Study Group 13
as we speak
that defines what
a service-provider identifier is--
or service-provider identity, actually.
And one of these--It was sort of divided into three pieces.
You're in the club or outside of the club
or you're an AMP developer.
And so I sent a note to these guys.
I said, "What's this 'in the club,'
and who determines that?"
No answer.
But I think it epitomizes, if you will,
the mind-set and the potential problem.
Klensin: Well, I agree about the mind-set.
A lot of what we've also been seeing
from the "NGN community"
is a tremendous amount of Internet applications
at an NGN base
and a tremendous amount of,
"Well, let's say the sounds dinosaurs make
when talking about circuits,"
and the old vocabularies about,
"Well, that was a nice network for research purposes,
"but now we need to grow up
and become the real data network again."
And the things which are going on in that vocabulary
are thinly disguised OSI
from when OSI was a thing.
And I see this as either a rather different threat
or not wanting to be standing next to the dinosaur
when he finally realizes he's dead
or extinct or whatever other vocabulary you want to use.
And at least from my standpoint, the question would be
how can that extinction process be sped up?
Rutkowski: Well, I'll say,
I span multiple communities,
and I understand the antipathy.
On the other hand,
these guys have survived, you know,
this major, cosmic disaster, right?
So they're still there,
and there are a lot fewer ISPs,
so these guys now, in a way,
are in an enhanced position as survivors.
So, if you will,
the threat ought to be taken seriously.
And believe it or not,
they got tons of bucks spent in lobbying in Washington
and in very clever strategies
to dominate a lot of the four.
But I would say the example, John,
is not OSI, per se,
because OSI could be argued
to be sort of relatively neutral.
The example is--
And I can--I was at the FCC when the RBOCs and AT&T
brought in the intelligent network.
And the intelligent network was supposed to be
sort of the original cloud, right?
And everything was supposed to be in that cloud.
And the FCC in 1985 came out with Computer 3
and said, "Okay, if you're gonna head down this path,
"these are gonna be the rules of the road.
"It's gonna have to be an open infrastructure,
with no anti-competitive hooks,"
and that's what Computer 3 mandated.
I know it well,
because I actually floated the memo in the FCC
and wrote that portion of the notice of rule making
and then sort of oversaw the process.
I see history simply repeating itself,
and I think there needs to be an effective strategy
to ensure that a closed model for this stuff
doesn't become the norm.
Klensin: Well, that's exactly my concern.
And I have much more fear than I do animosity,
but I was wondering about your thoughts
as to how to make what you just suggested happen.
Rutkowski: [sighs]
That's a fairly lengthy discussion.
And some of it's starting to happen
in sort of the Washington dialogue
with the network neutrality stuff.
In fact, in many ways,
that's reminiscent of the concerns
that were expressed
when the whole intelligent-network thing
was floated in the early '80s.
But there is so much of this
going on all over the world
in all these major fora,
and last but not least,
Korea and China participate significantly in these fora,
and they have an enormous amount of economic power
so that's gonna be a significant driver as well.
Cerf: Okay. All right. What?
man: I'm ahead of you.
Cerf: Oh, I'm sorry. Go ahead.
man: I was floating intelligent network
for Northern Telecom in the early '80s,
and there really, I think, is an essential difference.
Namely, that was an attempt by us
and the other telephone companies
to grab computing away from user-owned data centers
and later desktop computers.
Whereas this, the computer companies
that are gonna supply cloud computing,
are sort of peers of the users.
They're not part of the network infrastructure
in the sense of AT&T, MCI, et cetera.
Rutkowski: Oh, I don't disagree,
but I'm saying their vision of cloud computing
would be somewhat different.
It would be the NGN cloud,
in which they basically...
Cerf: They perform all the applications
inside of their infrastructure.
Rutkowski: Right, right.
Cerf: I want to have this discussion,
but I want to have it
after the other people have had a chance to speak.
What I'm very interested in doing
is understanding much more fully the risk and the threat
and whether we can do something about it,
because I'll be damned if I want those dinosaurs
to take over control of the Internet.
It's not acceptable.
Rutkowski: Okay.
Let me flip to the last slide.
Bhorat: You have about two minutes.
Rutkowski: Yeah, okay. This is not all-inclusive.
It's some of the things that I've been sort of--
either I see as major developments--
I'm spending a lot of time.
One is cyber security,
and part of that is
infrastructure-based capabilities.
Incidentally, I would put things like EVcerts,
which I mentioned.
Forensics and vulnerability acquisition analysis
and exchange capabilities.
And there's the infrastructure protection LI routine,
data network management.
Whatever you think about LI or retained-data stuff,
if you're in Europe,
that's a major directive.
Profoundly effects the network infrastructure,
and you got to be compliant.
But how that's implemented, I think, will--
you know, there's variables, and there can be differences.
I don't know why I put "responsive measures."
I...
That's a-- I can't figure that out.
Persistent, flexible, global trust anchors,
I think, is a meta-challenge
that we haven't sort of figured out entirely,
but it's gonna become really important
as the Internet scales globally and ubiquitously.
The CAB forum people are trying to deal with this
on a day-to-day basis
with, you know, who can issue an EVcert
and what happens when things go wrong.
You got the same problem with cyber forensics--
you know, who those forensics and vulnerabilities
can be shared with
and on what basis.
That's all time-dependent.
You know, your friends today
may not be your friends ten years from now.
Or what happens 100 years from now?
I think we need to increasingly think
in those kinds of time scales.
My personal pet thing, as I discussed already
and as Vint knows from sort of our joint exploits
beginning in the early '90s,
is real-time access to standards,
and late registrations is important.
And the last one I think is important,
because, you know, going forward,
we need to, I think increasingly,
think of this in terms of a world
of a China-centric Internet.
You know, if you extrapolate on all the variables,
it doesn't take very long to get to a state
where, you know, from either an economic
or a physical presence
or users or whatever kind of measurement you want to use,
China plays a dominant role.
I know certainly for my son, who's based in Nanjing,
you know, he lives in a China Internet world.
And it's robust,
but it has kind of different dynamics,
and one of the, I think, more disconcerting things I see
in the US and the West
is there's very little, if any, appreciation of that.
So that's my...
[speaking indistinctly]
Bhorat: Thanks, Tony.
And just a note to my other panelists,
that that was not seven minutes.
[laughter]
So as Vint added,
yeah, I work in the research organization at Google
on coordinating and leading our standards efforts,
and this is my bio up there.
My focus areas being on document standards.
I also represent Google at the Insights executive board,
and OASIS as well.
So here's a list of some of the standards
that we participate in at Google.
It's kind of hard to represent all the standards on a slide,
but I don't think this is, by any means, complete.
But they're very important to Google,
especially open standards,
as we're strong proponents of openness on the Internet,
and that's also what enables interoperability
and the innovation that drives Google.
So some of the standards have a direct impact
on how we deliver our service.
And getting a standard in place is very important,
as much as getting code right,
and that's something that certainly Vint, I know,
has been a strong proponent in Google
and driving that message here.
We have a lot of active Googlists participating,
and we've been collecting information
about where the work is happening.
So as we go through the slides,
I'll give you reference points, especially for the Googlers,
of where you can go,
but we would love to know more,
if there's anything missing in our information.
So much of the work that's carried out
is actually in the various committees,
and as I started to learn more
about the various standards committees
and attending something like the IETF meetings,
I also learned that it just takes a lot of time,
a lot of challenges, and a lot of people,
some money.
Just the conversation
that is happening here over the break was travel.
Just there's an amazing amount of travel
between participants in the standards world.
And also, lots of disagreements as well.
Just as in Google
we have intellectually stimulating conversations
where people need to defend their position,
those are the same conversations
that happen in the standards world.
And the Internet standards
have a really direct impact
on the way the Internet evolves,
and we really want to make sure
that Google is an integral part of that,
so this next slide...
shows our participation.
And the large bubbles are actually the working groups
and also people,
so it's a good correlation
between how many people and the activities.
And you can see that both the IETF and W3C and JCP
are the largest ones there,
and then some of the smaller organizations
have maybe one or two people participating.
So you can see with W3C,
their goal is to...
through the creation of Web standards and guidelines,
and the goal of the IETF is to make the Internet better,
and you can see the sort of strong focus.
There's also work happening
in some of the relatively newer organizations,
like OpenSocial, OpenWeb, OpenID,
and Dirk Clinton is doing a great job leading that.
Over in Google Earth and Google Maps,
so the Open Geospatial Consortium
and Khronos Group,
the KML 2.2 was formerly announced
as a OGC standard
on April 13, 2008.
And in the Khronos Group,
we're actually working with COLLADA,
which is a 3D XML file standard.
And of course new areas such as health,
where the focus there is meeting medical record standards
and in transport and automotive.
And then some of the organizations
you might be familiar with,
like IEEE, IEC, and Unicode Consortium.
So Mark Davis is a very strong representative for Google
in that area.
So I mentioned IETF is the largest one.
Here's a bunch of working groups that we participate in,
and actually Vint is a chair
on the IDNABIS
international domain names working group
and works in there with a bunch of Googlers,
including Harald Alvestrand,
who actually is the Google lead for IETF.
And it's an interesting organization,
in that my involvement with IETF
just started about a year and half ago,
and I was very pleased to see
how open and how collaborative the group is.
All the communication happens there through email
and not just face-to-face meetings,
although the meetings help fund the organization.
Everything and anything is publicly available
within the IETF,
and with IPR, anyone can implement.
Anyone can see the basis of the discussion,
and nothing is really secret.
Much of what happens there is also available
and under, you know, a fair, equitable RAND IPR policy.
So we'll be covering the IPv6
that Erik will be talking about,
and that happens within the IETF,
and the DNS work that John Klensin is working on
is also within the IETF.
And here's a bunch of standards
that were active in W3C.
HTML--Ian Hickson is our key lead there for Google,
and he pretty much says HTML is the Web,
and so that's his kind of tagline.
And Accessibility is another one that kind of runs--
Although this is featured here in W3C,
there are working groups over at ISO, OASIS,
and a bunch of other organizations,
and many of these are not working in isolation.
They do actually work and collaborate
across the different groups.
So this is for Googlers to go to go/standards.
This is where all the information is.
We've been collecting this for some time,
and I don't think this will ever be complete,
so please help us keep that up to date.
And also talk to the various product teams
just to try and map the standards
alongside the products,
and asking the Google Apps team what standards were important,
and so here's a cloud tag that showed up.
OpenSocial, HTML, OAuth, OpenID featured very highly,
as well as, you know, the expected ones,
such as CSS.
And there's JavaScript and Atom Publishing.
So with that, let me pass over to John Klensin,
who will talk about his work
over at the IETF.
Klensin: [speaking indistinctly]
Sorry?
Klensin: You have my mind boggled by this picture.
[laughter]
Bhorat: Well, you did send me a very large bio.
man: That's what happens when your resume gets Wordled.
[laughter, indistinct speech]
man: I didn't post the URL for that.
[laughter]
Klensin: Hi, I'm John Klensin,
and to paraphrase other people today,
I've done some stuff over the years.
I refer you to the previous slide.
I'm gonna talk a little bit today
about the process of internationalizing
Domain Name System.
The DNS was originally defined
in terms of taking any string of octets as a name,
but that approach and that capability
has rarely been used in practice,
and the protocols suggest a preferred form for names.
And that preferred form
basically consists of ASCII letters
and digits and the hyphen,
with some additional restrictions.
One of the things I've discovered over the years
as one looks at these things,
there are different types of standards projects.
There are those that are basically engineering
with technology targets in this area,
in which there's agreement about the problem,
focus, and usability by somebody
and a focus on consistent and well-defined results.
Those are the easy ones.
There may be disagreements,
but we have criteria for trying to resolve
those disagreements.
We also have ones in which the major issues
turn into culture and languages and environments,
and standardization's extremely difficult.
DNS internationalization falls into that space,
which I'll talk a little bit more about in a few minutes,
and then we've got a third group,
which is sometimes
indistinguishable from the second,
where what goes on is mostly
about political posturing and politics.
And standards work in that area works very, very badly,
because there are no agreed criteria
for when one is finished
or when one is successful or when one should move on.
The DNS internationalization work...
follows that second model,
and sometimes it feels like the third.
As I said earlier,
the Domain Name System itself has always been eight bits,
but the applications from long before
there was a Domain Name System
have imposed ASCII restrictions.
The DNS has ASCII-specific matching rules,
in spite of the fact that it's normally octets,
there's a funny rule.
And the funny rule says
that if the octet has the leading bit as zero,
then the assumption is that it's an ASCII character,
and it gets matched to the servers
in a case-independent way.
And if leading bit is one, it isn't.
There's no definition specification
of what "isn't" means,
and it means that as one starts looking
at characters outside the ASCII,
undecorated, Latin-character set,
matching rules become difficult,
and the DNS doesn't know anything about it.
As we've tried to look at the Domain Name System
and tried to figure out how to make it
more adaptable to languages in the script
besides ASCII and maybe English,
we've discovered there's disagreement
about what the problem is.
If the Domain Name System
is actually about network identifiers,
network-facing identifiers,
identifiers for things on the network,
then the names themselves aren't names,
they're protocol identifiers,
and internationalization doesn't make any sense.
It should be done somewhere else.
We keep coming back to that one.
The second possibility
is that this is really about mnemonics for things,
and mnemonics in non-ASCII scripts make a lot of sense,
because you ought to be able to write your mnemonics
in your own language, more or less.
And the third possibility
is really about cultural elements.
And language becomes very important,
and correct spellings become very important,
and all sorts of other things become very important,
and that problem is not resolvable.
But that doesn't mean that people don't want to resolve it.
DNS is just hopeless.
The other conflict about this all the way along
was whether to go for a very quick solution,
whatever "quick" means,
versus trying to make a solution
which was compatible with long-term architecture
of a decent identifier system.
In different language, that's the difference
between grafting some internationalization stuff
onto a basically ASCII Domain Name System
versus internationalizing Domain Name System.
We chose the first one.
It's an architecturally disastrous decision,
but possibly the right thing to do.
Because there are cultural issues in this,
or perceived cultural issues in this--
And the people who see the cultural issues
don't want to believe
that there are any other possible ways
of looking at this.
When tradeoff decisions,
or engineering decisions, are made,
those decisions make people passionately unhappy.
Some of those decisions are seen as international conspiracies
against particular languages or groups.
We've often said that sometimes the best solution
is one which makes everybody equally unhappy.
In this particular situation, that doesn't work.
Everybody believes that they get to be
more unhappy than anybody else.
So we end up with unrealistic expectations.
People pretend they'd like to write the great novel
in their language in DNS labels.
And they want to use very precise language
and very precise terminology,
and they want to have arguments about semantics.
They want to do language-sensitive matching,
and culturally local language-sensitive matching.
If the spelling rules differ from my country to your country,
then the DNS should match those things
or not match those things,
depending on how I feel about your country.
If you don't know how to make that work
from an engineering standpoint,
you're beginning to understand
the problems we're facing here.
So we end up making choices
on a "least rotten" technology.
There are no good solutions.
The decisions which were made
optimized for minimum disruption and rapid deployment.
The people who argued for this technique
assumed that we would have universal IDNs
two years after the standard was written.
Well, let's see, that would have made it 2005.
It's past that.
There are new excuses.
One of the things which gets laid on top of this
is people who will stand up and say
the reason why we don't have the Internet
widely deployed in my country
is because we don't have good enough IDNs,
or we don't have top-level IDNs,
or we can't spell properly in IDNs yet.
What their excuse will be when they get that,
I don't know, but I'm sure there will be one.
And as a consequence of those decisions,
all of this work gets done on the applications
and not on the DNS.
Decisions which were made in 2002, 2003,
said all the work was gonna be done in the applications,
that nearly any Unicode character
in Unicode 3.2 was gonna be permitted,
that we were going to solve problems
by mapping many characters into other characters
at the applications layer.
The rules are based upon some Unicode operations.
But ultimately the tables are unique to IDNA.
They're unique to this particular standard.
That means that if you have a set of rules
which deal with Unicode elsewhere in your application,
those rules are guaranteed to be different
than the rules used for IDNs.
Once one gets through doing that particular mapping process,
which in the process legitimized characters
which could not be typed on terminals anywhere in the world,
because they mapped it
to something else which maybe could,
legitimized symbols, line-drawing characters,
punctuation, dingbats,
we ended up with things
that don't display consistently across the world,
which cannot be typed consistently across the world
valid in domain names, sort of.
Once one gets to those strings,
the result is mapped into an ASCII-compatible form,
which looks like-- to the DNS--
like letters, digits, and a hyphen...
or two.
And the assumption is that that's a good idea,
because un-upgraded applications
think it's an ordinary domain-name label.
And then you end up with a bunch of rules
about how it's gonna be displayed.
And the other interesting decision
about that display process
is the rules ignored every operating system
I know of from Multex forward.
In most of our languages and operating systems,
if you want something displayed,
you call a routine, and you say, "Display this."
And the routine does not come back to you and say,
"I have no way of representing that particular character,"
because it doesn't know.
But the assumption was that we could take these things in
and convert them back
to something which wasn't necessarily what the user typed
and pass it out to the screen and have it rendered.
Maybe.
All of this had some unanticipated effects.
One of the unanticipated effects,
in addition to that bad assumption
about operating systems,
is that when you move from worrying
about circa 90 characters
to circa 100,000,
a lot more things look like a lot of other things,
and bad guys figure that out.
Gee.
So the people who develop the applications
decided they had to protect their users from this nonsense,
and naturally enough, they overreacted.
So now we've got a layer on top of the protocol
which starts applications, Web browsers, and other things
figuring out what it's safe to display.
And if they decide something is not safe to display
under criteria which are basically different
for every Web browser out there,
they display the internal ACE form.
And what that does to a user who says,
"I always want to be able two write my name
in its correct spelling in a DNS label,"
that user gets the improvement
from a miserable ASCII transliteration of that name
to a totally unintelligible
and unpronounceable coded string.
And for some reason,
that's not considered an improvement.
In addition to that,
this raises a whole series of policy issues.
What we've had since the beginning of the DNS
is guidance to people who are managing zones,
or in our later terminology,
operating registries,
that says probably you shouldn't register anything in the DNS
which doesn't consist of letters, digits, and hyphens
with those rules,
unless you have some specific reason for doing so,
because the applications won't handle it.
But the enforcement has been strictly a registry matter,
plus the application enforcement of--
if you don't follow the rules, it won't get though SMTP
and other things.
As we move to this other set of characters,
we end up with policy issues of a similar nature,
and those policy issues get interpreted
by every registry on the Internet
potentially differently,
all tens of millions of them.
So the register under user will express consistent behavior--
Or the application which expresses consistent behavior
is in very big trouble,
and especially very big trouble
because of all of these interesting mapping rules.
So we're now trying to drain the swamp,
and we're doing it unfortunately with an eyedropper.
We are working at a new version of IDNA.
[laughter]
It would be faster but distasteful.
We've had an old rule that 10% of certain problems
takes 90% of the work.
With this work, it's turned out that 2% of the problems
takes 95 to 98% of the work.
What we're trying to do
is ultimately a few small simplifications.
We're trying to get this notion
that if you have a character in Unicode,
you should be able to write it in DNS
back to the notion
that maybe that 1971 letters, digits, and hyphens rule
really ought to be extended into this space
so it's letters and digits
and very little else in these names.
The code word for that is an inclusion-based model
versus exclusion-based model, if you hear those terms.
We're trying to get rid of the mappings
so that the coding
from the internal form to the external form
is reversible.
So the user types something in,
it gets converted to the internal form,
it gets converted back.
It is actually what the user expected to see.
For some reason, users like that.
We're trying to make a few more languages useful.
There's some coding rules in the old thing
which completely eliminated the possibility
of using coupled languages and scripts.
Now we're trying to clean up a few other details.
In a perfect world,
that would take about two weeks.
We're about two years into that two weeks.
And we're still having the old arguments
about natural language, about novel writing,
about words, about matching rules.
We still have the nasty policy problems
that will get solved in inconsistent ways.
There's no way to make them go away in this world.
And we're discovering a new problem
which is that every bug and design misfeature
in the original version is now a feature
which people are arguing has to be preserved,
because somebody used it.
And that includes not only the misfeatures of the design,
but the decisions which various implementations
and implementers made
to exceed the standard and move beyond it
in ways which show up in files
and are supported by at least some browsers.
That's an important general problem,
because in a world where somebody says,
"Well, somebody violated the standard,
and somebody else decided to support that violation,
and therefore it can never change,"
is a world in which one can never make progress,
and I don't know what one does in that world.
Thank you.
Yeah.
man: We only have time for one question.
Bhorat: Yeah, we have two more speakers to go.
So we will do questions at the end.
Klensin: But you know where to find me
if you don't get a chance otherwise.
man: I was just struck by the similarity
of the SMTP debate
and making email eight-bit compatible,
but one can divert.
man #2: But you can answer that after the--
Klensin: Uh, yes.
[laughter]
Dam: All right.
My name is Tina Dam.
I work for ICANN,
and I'm in charge of IDNs at ICANN.
I've been at ICANN for about six years,
and only the last couple of years,
my sole focus has been on IDNs.
So you can imagine I don't count that much
in the number of the 80-year experience of the entire panel,
but in any event...
When it comes to ICANN and IDNs,
we look to the IETF for technical standards.
And particularly, as John has talked about,
the IDNA is the most important one.
There also is a couple of other technical standards
that become important when it has to do
with implementation and functionality of IDNs,
at least one of which is currently missing,
which you'll see in a little bit.
I just have a couple of slides, and I'm gonna try to be brief,
because we need more time for questions, I think.
Since we're a little bit of a diverse group,
I just thought I would make sure
that we're sort of, like, on the same page.
The first version of the IDNA protocol
came out in 2003,
and what that means is that we actually have had IDNs
existing since 2003
under the technical standards for Web protocol.
The email clients is something that we're beginning to see,
which is under experimental implementations.
But everything in the domain-names base
has, so far, been on the second level,
and because of that,
the focus within ICANN
is now to get IDNs at the top level.
That creates some challenges,
since the protocol is under revision
at the same time, as you'll see in a little bit.
The little box there is just further illustration
of what it is that we have and what we're going towards.
I'll say, probably slightly more positive
than John has been saying,
that IDNs actually have existed and functioned really well
for lots of different language communities,
but particularly those that are basing their languages
on the Latin script, or the extended Latin scripts.
So when you move into something
like Korean, Chinese, Arabic, or so forth,
they don't have as much experience,
or implementation experience,
as you see in the Latin and extended Latin script,
because of the fact that you have to change the script
when you type things in.
I mean, it becomes more difficult, right?
One thing is that, for Arabic speakers,
that you have to type things in in ASCII or Latin today.
Another thing is if they have to switch between the two.
So they're waiting for the top level.
They're waiting for the entire string
to be in their script or language,
if you want to talk about it that way.
We have actually had the IDN TLDs in the roots
since 2005, September.
That test, 11 strings were put in the root
just to see how it worked,
and they work fine.
I can show you some more pointers to it,
where you can find it, if you're interested.
But in any event,
the top level, we have three processes.
The middle one here
is something that's under policy development,
so I'm not gonna talk a lot about that.
That's for ccTLDs
for long-term internationalized versions of that.
But the top one and the bottom one--
the top one is what we typically refer to as "fast track,"
and it's for internationalized country code top-level domains.
It's a limited round.
It's intended to be faster
than this middle one that's under policy development.
This is not expected--
The policy of this is not expected to be finished
until at least a couple of years still.
So to fast-track is to give those countries
and territories that are ready
and really have an express need--
you know, what they're looking for.
Non-Latin script only,
matching the ISO3166 list,
and the string that's applied for
and potentially becomes a label as a TLD
must match the country or territory name.
So there is a lot of different restrictions in there.
The bottom process is new gTLDs,
and that can be internationalized as well.
The main thing to say about that,
there's a lot of stuff going on
in the implementation of that process.
The main thing to say, I think,
is that, from an IDN perspective,
an IDN gTLD or an IDN ccTLD is essentially the same thing,
from a technical point of view.
There is no difference between the two,
and because of that,
the technical requirements are also the same
in those two processes.
I'm not gonna talk much more about the gTLDs per se.
I mean, we've had a couple of rounds
at ICANN implementing new gTLDs.
This next round is intended to be
a much larger round that will continue rolling.
So it's not a one-off implementation.
But it doesn't really have much to do
with the standards as this panel is talking about.
So this is my last slide,
and it's basically just to give you
a quick overview of what I believe
are the main technical issues we have ahead
in getting this finished.
And it goes both for ccTLDs and gTLDs.
The first one--And they're not in any particular order.
The first one is variant allocational blocking.
What do we do with these variant, top-level domains?
At second level, we have different approaches.
Some are allocating, some are blocking.
Some give out all variants for one price and so forth.
There's all kinds of different models.
But what do we want to have in the root?
I put up a couple of examples,
and I should say right away
that neither China nor Pakistan have said,
"This is what we want," publicly.
They've said, "This is what we're interested in,"
but, you know, ICANN is not open for applications yet,
so none of this is formal.
They've said publicly,
"This is what we're interested in."
You can see the difference
between the two strings for China.
They both mean China.
One is simplified Chinese,
the other is traditional Chinese.
The one for Pakistan you probably can't,
or at least you shouldn't be able to.
[man speaking indistinctly]
The difference is-- I can't reach that, but...
I thought I could. I usually can.
Can I use this?
Oh, here we go.
This character that kind of looks--
that looks a little bit like an S--
I mean, if you're an English native speaker, anyways--
it's actually two different characters.
One is used primarily if you're in Saudi Arabia.
The other is used for most other speakers in Pakistan.
So there are two different ones.
So there are two different Unicode characters,
different Unicode code points,
so obviously the string becomes different in the DNS
even though you can't see the difference.
So what do we do with those things?
And here's the technical standard
that doesn't exist that I mentioned early on.
We don't have a technical solution to alias them,
because obviously you would want--
If those two existed as TLDs in the root,
you would need them to be aliased.
I mean, they would need to be the same thing, right?
I can't have Tina dot one,
and then one of you will have Tina dot the other one.
I mean, you can't-- It looks the same, right?
So that's an open topic
that's being discussed right now.
The other one is number of characters in a label.
And I can see my--
The little square there was supposed to be an arrow.
On a PC it's an arrow, I guess.
So for ccTLDs,
we're used to having two characters in the label.
And now that we're opening up for the fast track,
you can have a whole country name,
so you can have actually very long strings,
and in any event, because they're IDNs
and they get converted to accent dash dash
in the IDNA protocol,
they're longer than two characters, right?
Obviously.
In gTLDs,
we've been used to seeing three-plus characters.
Early on, I guess mostly just three characters,
but now we're getting more used to three-plus.
We've all seen the acceptability and usability problems of that.
My personal email address is under .info.
It doesn't always work.
Things like that become problems when you look at standards.
Question mark is what I put after the gTLD list.
In the new process, do we see one-character gTLDs?
You know, at the top-level extension?
Two-character, three-character, and three-plus-character?
And while this is something
that's more related to how do you implement this process-wise
and what can people apply for,
it still is a technical issue when you look at the name space
and how things are working and functioning
and what we're used to seeing.
So both from an application space,
but also from a user experience space.
Third topic is the IDNA technical standards revision
that John talked about.
And this is difficult, right?
I mean, ICANN has been asked many times
what are you gonna do
if you're ready to launch these two processes
to implement new TLDs
and the INDA protocol revision is not finished?
Are you just gonna take out IDNs and say,
"Well, fast track disappears completely, right?
"'Cause it's only IDNs.
gTLDs, should it only be ASCII?"
And so far, our position on that
is that we do have a technical standard,
and it is working,
so we are gonna go ahead,
but we're gonna proceed cautiously
and add some more technical requirements
around what strings we're gonna allow in the root.
But that relates into timing.
And that's quite a difficult topic as well.
The fast track is expected to launch
around some time in Q4, 2009.
The new gTLD applications process
is anticipated to launch in Q1, 2010,
and there is no fixed deadline for either one of them.
But that's coming up really soon, right?
And when we talk about
a protocol revision that's under way,
well, we're not just talking
about the technical standard being finished.
We're talking about getting it implemented
into these processes,
getting it implemented into applications
so it actually works for the users.
So you can talk about different layers
of when is this all gonna work,
and if we were to wait at ICANN
until technical standards are implemented--
I don't know what to call it--
broadly in applications?
Well, we would wait forever, right?
So for me, it's more of the chicken and the egg,
and I believe that the user have a lot of power in this,
and I think the user,
when they see, wrong, difficult,
faulty behavior in some applications,
they're gonna move to others that are more secure.
But unless we hold back and we don't move forward,
you know, nothing is ever gonna progress,
and it won't take us anywhere.
So,
yeah, I, you know,
it's gonna be difficult to do something
without that revision to be completed,
but that's where we stand today.
So that's all I had.
Is that--What is it? About seven minutes?
Maybe a little more.
I can talk about IDNs forever, so I'm sorry.
And I like being part of the--
or a new member of the standards body,
even though there was, uh, condolences early on.
[laughter]
Klensin: Tina, just very quickly,
if you had a rich enough set of fonts,
not only would those two characters display differently
because they have different code points,
but so would several of the other characters
which have the same code points.
Dam: Yeah, so--and just, like, a quick feedback on that,
I mean, there is a lot of topics on this
that I didn't touch on at all.
There's the fonts, there's all kinds of other stuff
in application layer.
There's guidelines that are not technical standards,
but sit on top of the technical standard.
There's, you know, a multitude,
and I'm happy to talk about any of it
with anybody that is interested in more on IDNs.
Kline: So we can look forward
to dingbats and Zapf Chancery domain names?
Is that what you're telling me?
Klensin: Not if I can help it.
Kline: Right, yeah. Cold day in hell, right?
My name is Erik, Erik Kline,
and I work some IPv6 for Google
thanks to Vint Cerf and Stephen Stuart.
So I'm gonna try to take my seven minutes here
and keep it to that.
So...
Just--I don't know how much of this
I really need to go into,
why we're sort of doing IPv6.
The costs here are not necessarily costs,
by the way, that are true to us.
There are costs running IPv4 that will continue to increase
buying carrier-grade NAT devices,
buying public addresses.
These costs will only decrease,
and most likely this affects ISPs more than it will us,
but it'll affect our users.
The opportunities here
are actually quite a lot of them, and I just--
There's an operational simplicity
to not having to deal with NAT that's really, really nice.
There's several million devices
that are IPv6 only right now
that we can talk to.
There are several million devices
that are IPv6 only that we can't talk to,
'cause they're in walled gardens,
but if the walls come down,
then we'll have multiple millions of more devices.
We can also do crazy things like, uh,
there was talking earlier
about SSL and then also cloud computing.
We could assign every single App Engine application
its own 64-bit host ID,
and it could have its own unique address
at every single data center that we run,
and it could have a SSLcert for every single app.
There would be no problem whatsoever
with a space that large.
And if we ran out of 2-to-the-64 applications,
we would just remove, you know,
one bit from the network, and do it all over again.
And of course, there's a lot of personal interest
in keeping the Internet open
and not wanting to have things locked down.
We don't know what the next great application is,
but we want to be ready for it.
And of course, it serves our users.
It behooves us to take measures we can now
so we don't have to worry about it later.
A very, very brief history.
Not terribly...
Well, it's an eye chart.
[laughs]
But in December at IETF 70 Mark Townsley said,
"Well, I don't know what to do about IPv6.
"Maybe we'll just challenge Google
"to have IPv6 by IETF 73 in November of '08
when they're hosting it."
And I sent email off from the preliminary floor,
and in January we served
our first Google over IPv6 query,
and we had IPv6 at Google.com
by March for the IPv4 blackout hour,
because IPv4 blackout hours
were somehow very popular, although very painful.
And we followed it up by having our first--
We served Google over IPv6.
we served quad As for dub-dub-dub and Mail
and a few other things.
To IETF 73, and actually while I was there,
Eric Vink from Cisco was like,
"Oh, you're a client.
"I was just doing some tcpdumping on my Mac,
"and I was saying, 'Wow,
"'somebody's going to Gmail over IPv6. Who's that?'
"And then I tcpdumped some more,
and then I realized it was me."
[laughter]
And, of course, I didn't really remember him,
so when I ran into Eric Vink in January of '09
in Barcelona at Cisco networkers,
I told him that same story,
and says, "Yeah, that was me."
And we announced the Google over IPv6 program in January,
and we had a conference recently a couple weeks ago,
and we added maptiles, actually,
which gave us this nice little 3-X increase in traffic
in about a few minutes.
Some IETF things that we're sort of following,
believe it or not,
NAT is probably possibly coming into IPv6.
There's a lot of passionate debate about this.
I have my own thoughts, obviously.
VRRP is something we're interested in.
I could only find a couple of-- two dead drafts, so...
But the convergence of not wanting to wait
for neighbor and usability discovery
for when the router goes down
to keep the TCP flow would be great.
Most important for us, actually,
probably are the non-native
access and transition methods that people are working on--
NAT64 including the DNF64 component.
6RD we like.
We have a million and a half or more IPv6 users in France.
Two and a half million.
And they're all 6RD users.
We want to see that one pushed
to be a standard as well.
And we have a few other things that we track.
This is just IPv6 things.
Obviously there's a great deal more.
So we've been running an experiment
to see what connectivity is like.
About a third of a percent of the Internet
is actually capable of doing IPv6,
and about a tenth of a percent
will actually break if we add a quad A
to www.google.com.
These numbers are kind of--
especially the broken number,
that's a very difficult number to measure.
I would take that with a grain of salt.
Suffice it to say it has an impact
that we're not really willing to win just yet.
So here's growth over time.
It amounts to about .1% increase every eight months,
so we'll be done in about 8,000 months.
So it's all good. We're on time.
[man speaks indistinctly]
Yeah, well, you know, it's quite possible.
Comcast has a large deployment
that they're in the middle of doing.
If you can actually get to the NTT devices,
every single home and NTT has-- fiber to the home a slash 48.
So we can get to a great number of devices in theory.
We've been monitoring how users get to us.
Unfortunately, about two thirds of them
get to us over 6to4.
And various other statistics I won't go into.
We launched Google over IPv6, of course,
and you can go to the website
and see these really neat graphics
about how if your DNS resolver is in our white list,
we'll serve you quad As.
Otherwise, you look just like the rest of the Internet,
and you don't,
'cause we don't want to break you.
And this is, actually, probably--
This is the last slide,
and this is a graph courtesy of David Louer.
There's actually four lines to look at.
The top one, very faint,
is all of the search over IPv6,
and the next blue one below it,
the darker blue one, is the same with 6to4
and Teredo tunneling mechanisms removed.
The red line is actually two red lines.
Those are IPv6 searches
of Google over IPv6 users,
people who are actually enrolled in our program,
and you'll notice that there's another line
that is with tunnel and 6to4 removers--
Sorry. With Teredo and 6to4 users removed,
and we have no Teredo and 6to4 users by design,
or virtually none.
So you can see that we currently have
about two thirds,
three quarters of the IPv6 Internet enrolled
in Google over IPv6.
We have some appearing arrangements
and other things that are coming up,
and we're seeking out the ASNs that connect to us
to figure out how we can serve those.
And so we'll grow Google over IPv6
until we serve all of the IPv6 Internet,
but we're not really seeing the IPv6 Internet--
the size of the IPv6 Internet growing yet, so...
[man speaks indistinctly]
Can I say more about Google over IPv6 rules?
I mean like what qualifies?
Cerf: Who's allowed to do that,
or what are the criteria?
Kline: Oh, sure.
It's essentially production quality IPv6 connectivity
between us and them.
Preferably two paths,
preferably no tunnels.
Is that correct, Stephen?
[man speaks indistinctly]
It's mandatory. Yeah.
And you have to commit to production quality IPv6 support.
You have to treat an IPv6 outage
with the same degree of severity
you would treat an IPv4 outage.
And you have to be willing
to troubleshoot problems when your users report them.
And we're happy and willing to work with anybody
if problems are reported,
but they have to be willing
to take those support calls as well.
So we've had great success.
We've got, like, 50 organizations.
We have about 250,000
unique IPv6 addresses per day that we see.
So lots of universities,
Department of Defense, research engineering networks.
Lost of places in Europe.
I think we're still bringing a few places in Asia.
It depends on network buildup.
But...yeah.
Is that under seven?
All right.
Hopefully I didn't sound like a legal disclaimer
at the end of a radio ad.
Bhorat: So if we could just have all of the panelists
out in the front,
we've got time for Q and A.
man: I have mixed feelings
about internationalized domain names,
because on one hand they make the Internet available
to various populations
that are not literate in latent scripts,
but on the other hand,
they result in more balkanization of the Internet,
and for the rest of humanity, so to say,
it becomes kind of a world garden.
So what is your take?
Is it a net positive or a net negative effect
in terms of global impact?
Klensin: It certainly is.
[laughter]
My--it's--it's gonna be immensely useful.
It and some other internationalization efforts
which are more or less related
are going to be immensely useful for getting communities
that are not now connected well enough
to communicate with anybody,
communicating among themselves.
I refuse to think of that as balkanization,
because I think that kind of thing
ultimately opens things up.
At the same time,
the optimism behind all my pessimism
and cynicism about this
is that I think that there are lots of people
who have expectations
for problems that IDNs are gonna solve,
that as these things deploy,
people will figure out that they do not solve.
And what I say at other forums
and might as well say here
is the problems which this stuff is going to cause
because of difficulties in matching
'cause of some of these other things
sort of cause Google...
in the sense that users today,
much more so than even we anticipated
a half a dozen years ago,
are going to the search engines
because it's getting harder and harder
to try to guess domain names.
This internationalization stuff
is going to drive that problem up astronomically,
and as a consequence,
my guess is that what we will see,
once this settles down,
no predictions how long that'll take,
is things returning to where, philosophically,
they arguably belong,
with domain names being used
as mnemonics and network-facing identifiers,
and much more use of search engines,
intentionally populated directories.
A whole series of other things
at that closer-to-the-user layer,
where you can actually do semi-linguistic things
for the user-level stuff.
And it's probably unfortunate
that we have to waste the amount of time and resources
that will go into doing this exercise to get there,
but I think this'll sort itself out,
and I don't see a balkanization problem
for that reason,
but it doesn't have to do with the IDNs themselves.
They're...sunk.
Dam: Okay, I'm just gonna make a quick addition to John's.
John and I actually agree on most things,
and we almost also agree on this one.
I'm gonna say that I think it already is useful.
IDNs are already useful,
and they're gonna continue to be useful.
I also don't see balkanization.
So on top of John's argument for why,
let me give you an example of it.
What if you have a website that contains
let's say solely Arabic content,
and in a school in one of the Arabic-speaking nations,
the kids were told to go and check out this website
and do some homework or study or research
or, you know, whatever level school you're in--
university or smaller classes,
but told to go to this website.
Well, the website address is in ASCII characters.
That makes no sense to me.
And enabling that address in Arabic characters
is not balkanizing anything.
It's just making it more accessible and usable
for that particular community
who would go to that site.
[man speaks indistinctly]
Klensin: You're not losing a sense of global community
to anybody who's now part of that community,
for exactly the reason that Tina's talking about.
We're adding people who find it extremely difficult
to access the network now,
who one might hope can gradually be brought in
to the global community,
but this is another two pieces of the example.
The place where IDNs are the most useful now
are that if somebody in the U.S.
is naming a set of machines
as Tom, ***, and Harry dot some domain
dot some TLD,
there are immense advantages
if you happen to be in some place
which is not English-speaking
and Tom, ***, and Harry are not natural strings,
to do that locally.
We're seeing tremendous use
in third and fourth and fifth-level domains
within enterprises and various parts of the world
of this machinery for that kind of mnemonic use.
I think that's extremely useful today,
and it's permanent.
The other side of the equation Tina just mentioned
is that Arabic school child
is going to have to type "http://,"
and then do a left-to-right to right-to-left switch,
and type some Arabic characters,
and then do a left-to-right and right-to-left switch,
and type a slash,
and that's a nightmare,
and that's one of the places where, as I say,
my expectation is it's gonna sort itself out
in ways that are beyond the expectations
of the strongest advocates of IDNs today.
Dam: So you actually don't have to type that today,
but if you want to do FTP, for example, then you do.
Klensin: Or https.
Dam: Yeah. Well, if you want the S on it, then you do.
But for the http, you don't.
But that's a technical standard problem.
But I'm gonna challenge you
to go and see if you can type one of the Chinese addresses in
for example, if that's a language that you don't speak.
See how difficult that is for you today.
If you can figure out
if I'm gonna supply you with an address
that's Chinese characters-- .cn for example.
If you can figure out how to type that in,
then I agree with you.
[man speaks indistinctly]
Klensin: Yes, but...
man: So I'm gonna tweak John for just a moment,
and then I've got a serious question.
The tweaking is you used
"Tom, ***, and Harry dot something" as your example.
There's an Internet standard
for example domain names.
It's example.com, example.org,
and it's actually written up.
[laughs]
Just teasing.
The more serious question which I raised earlier,
when you went through your discussion
of where we ended up on the IDNN process,
the interesting thing to me
was that almost every branching point,
every point you describe
is a point of difficulty.
Maps to the problems that we had 15 years ago
in going to eight-bit SMTP
and internationalizing the content of email
so people could write in their preferred languages in email,
and what was interesting to me
was that the internationalization of email
took about 18 months, roughly.
And yet you're describing,
with all the same problems,
with many of the same actors in many respects,
and yet in this case, we went--
for international domain names, we ended up with a solution
that was not correct the first time around,
whereas in email we got it right
when we finally did it.
And I'm wondering how much is that
an evolution of the standards process,
and that we have added ever more parties
and made it ever harder to do the things that we did.
For example, during the email one,
we ended up putting U.N. as SMTPs are, right?
And is that no longer feasible?
You know, can you no longer dictate to a standards committee
and say, "You have to decide on this,
and that's out of scope,"
or is this just representing
a harder problem space?
Klensin: It's a harder problem space.
The first thing which makes it a harder problem space
is that with MIME and SMTP,
we had levers on this.
We could specify language and tags.
We could specify-- In retrospect,
in many years, retrospectively, a mistake,
but we could specify the particular
character set in use.
We could use the SMTP model
to start--to start negotiating extensions
between a client and a server.
And perhaps, most important of all
relative to comments I was making earlier,
we were perfectly willing to say to people,
"If you are non-conforming beyond this particular point,
"nobody made any promises to you,
"and your life has just become miserable,
and that's too bad."
This one is different for all of those reasons.
We could have--And you know enough about the DNS.
We could have gone the other path.
We could have said, "Okay, this set of rules
"applies label type zero
"and class IN,
"and that's obsolete.
"We have a transition strategy,
"and it's now labeled type three,
and class something else."
And now we're talking about a transition strategy,
one we get--we've got an internationalized DNS.
The first thing which made this different
was that there was a great sense of urgency
driven by external political pressures.
And the people who designed IDNA
and were pushing for that solution
believe that we'd have this fully deployed around the world
and fully supported in applications
by three years ago.
And we are not close.
Partially because of some other things.
How long it would have taken to deploy that DNS solution,
I don't know,
but it's harder to deploy DNS second.
You know how long that's taken.
If you don't do something that radical,
you don't have any way to communicate it to the DNS
that one of these weird things is going on,
and it effects all the applications
across the board,
not just SMTP--
clients, servers, gateways, relays.
So it's harder for all those reasons.
In addition, with the SMTP stuff,
partly because the Internet was much smaller
in terms of interested parties,
we didn't have quite as many people
who thought that this was a cultural problem
rather than technical problem with SMTP.
As long as we solved it in some way that would work,
they were happy.
As I mentioned to somebody earlier,
I spent a number of years of my life
working on data about nutrient composition of foods.
And one of the things we discovered
about food naming and food nomenclature
and recipes and food composition data,
is the number of people in the world
who have opinions on those subjects
are roughly equal to the number of people in the world
who eat...ever.
As soon as we've gotten into these
"my-language, my culture, my spelling rules" arguments
with the DNS, we're in a situation
very close to that food problem.
The number of people
who think that they're entitled to have opinions
whether they know anything or not
is roughly equal to the number of people
who use the Internet.
Plus a whole lot of people who don't use the Internet
but have opinions anyway.
And that makes a very, very much more difficult context.
man 1: Question.
Why not just have Google front-end IP addresses?
[laughter]
man 2: I just had a question back here,
and it's just sort of a follow up,
which is sort of
what is the latest state of thinking
about, like, long-term capacity of standards bodies
to deal with these quasi-political problems?
And I say that with, like, sort of two dimensions to this.
One is, you know, on the one hand,
if you're taking on problems
that arguably have this kind of policy dimension,
how do you make sure you have
the right stake holders in the room?
And then but the other piece of it
is how do you make sure
that these bodies that arguably have been doing very well
like IETF over time,
you know, within a certain approximation,
you know, how do you survive the arrival of lobbyists?
I say that as a lobbyist for Google.
And I'm thinking about the OOXML example,
you know, as a good example.
You know, political football,
political theater as a problem
for standards bodies.
Klensin: I think the first thing you do is
you figure out how to tell the difference.
And we're getting better at that,
but not yet good at it.
Where telling the difference is the difference between
a technical argument or a technically grounded argument
and somebody trying to use one of these arguments
to advance either a particular agenda,
particular narrow agenda
or narrow technical agenda
or a political agenda.
Knowing the difference helps.
The other answer to that question
is the light you see coming towards you
in the tunnel is not a train,
it's an ocean liner.
I don't know, and I think the recent IDN experience
certainly doesn't leave me to be optimistic,
although I assume that we will work it out.
man: None of this is new.
I mean, you can go back to 1870,
when they were arguing over the original digital code,
which was Morse code,
versus the other codes available.
I think even Rhonda Crane, as I recall, at MIT
wrote a whole book on this,
on broadcast standards.
You compartmentalize it, live with it.
[man speaks indistinctly]
Klensin: We have gotten less good
at the version of rough consensus
which involved taking somebody out behind a barn.
man: So you touched on DNSSEC,
and one comment about the difficulty of deployment,
but I have a question that was brought up,
and maybe it's a naive one,
but with all these proliferation
of internationalized names
that have these different characters and displays
and all that stuff,
I have, you know, this concern
about whether there's DNSSEC behind it,
and am I going to the right place or not,
and if there's disparity in the deployment of this,
you know, DNSSEC takes even longer, let's say,
than we might expect,
I would imagine the software
to have options that say,
"Well, just disable all this stuff.
I don't want to even take the risk associated with it."
Do you think that will happen?
Klensin: The first answer is
that some software has already done that.
You just don't see it in an obvious way.
The second is that for better or for worse,
one of the advantages of IDNA
is that only thing in the DNS
is stuff that to any piece of the DNS itself
looks like letters, digits, and hyphens.
And as a consequence,
all of the difficulties here--
The user facing difficulties here
are invisible to DNSSEC,
'cause as far as DNSSEC is concerned,
this is just, you know,
strings of octets with the usual expected stuff in them.
Dam: Just-- So in addition to that,
just in case that there could be anything else going wrong,
and I agree with John.
I mean, it's just letters, digits, and hyphens,
so there wouldn't be any problems.
But we actually signed the dot test IDN TLDs
that are in the root, and everything worked smoothly.
I mean, there was no problems at all.
man: But there's a difference between you signing it,
and then people verifying against that signature.
Dam: Yeah, I agree.
And dot test is not that broad.
man: Yeah, and it's not a technical question
about can the DNS processes to it.
It's about out at the end software,
and at the end, you know, stuff,
how people will react to it.
Klensin: At the ends,
one of the reasons why several of us have been pressing
to get the mappings out of this thing
is precisely because there's no way to verify
with DNSSEC or anything else
that the thing which was looked up
is actually the same as the thing the user typed,
if somebody is invisibly underneath the user...
man: Doing special things.
Klensin: Doing special things.
But the strongest push for doing those mappings anyway
despite that problem
is coming out of this company
as a consequence of trying to make certain
that millions of web pages
which took advantage of that mapping stuff
will continue to work in an orderly and predictable way.
This is a real tension.
Bhorat: Okay.
I think, in the interest of time,
we're gonna have to thank you for all your questions
of the panelists.
It's--Okay.
man 1: Hopefully the microphone works.
I heard your response to him saying, you know,
"How do you type 'http,'
go from right to left, left to right?"
Turns out, my wife actually surfs,
she doesn't work here at Google,
and, not surprisingly,
she's never typed "http" in her life.
So it was interesting that you were challenging
these people to do things that my wife never does.
There's an old saying that there are few problems
for which one extra level of indirection,
won't offer a resolution.
And he said it jokingly,
but it seems a little bit true.
He commented, "Why don't you let Google front-end?"
And the truth is,
when my wife wanted to go look at a site,
she actually didn't type dub-dub-dub.
She didn't even do that part.
She just typed "Chase bank,"
and magically, she got something that led her there.
And the truth is,
this is actually how people surf and get around,
so I'm a little bit lo--
man 2: I do that too.
I don't think it has anything to do with...
man 1: Yeah, no. It's--Okay.
So, fundamentally,
I think it was a false--
I think it was a straw man that you set up there,
and I'm really wondering--
Maybe I'm being incredibly arrogant here.
Dam: No, no, actually, I said,
"You don't have to type 'http.'
"If you want the S on there,
then you have to type it," but you don't type "http."
man 1: No, you don't, actually,
because it turns out when I type "Vanguard,"
it automatically redirects me.
And no one types-- Well, not no one.
[no audio]
Klensin: That your wife is normal,
and that those of us who actually know
what a URL looks like
are becoming an increasing rarity,
and that every time
a new top-level domain is added,
it's more confusion about where to look
if you're name guessing.
And what that does is, as I said earlier,
is basically cause people to go to the search engines.
Usually Google.
To the extent which people go to the search engines,
this discussion about IDNs
and the protocol work on IDNs is irrelevant,
and that's good news.
And good news for the community,
not just for Google's bottom line.
So it means that long-term,
the role of these things
is much, much narrower
than the assumption being made
by the people who claim that if only they had IDNs,
they'd have more people on the Internet.
This is gonna end up being a very important niche
having more to do with network management
and network resources than users typing names.
I think.
Dam: So I just want to clarify.
I actually didn't say anything
that was in disagreement with what you said.
I said you don't have to type that in.
Maybe if you do FTP you do, but...
man: Sorry, just since--as we're stopping,
I just wanted to ask why we still need
DNS in the browser.
I mean, what Jim is talking about, what you mentioned,
there's no need for DNS in the browser at all.
[indistinct speech, laughter]
The DNS can exist, but I don't think
it should be a user-specific...
woman: For those of you who are staying for dinner...
Bhorat: Yeah, can we leave that one to dinner conversation?
Thank you.
[applause]