Next in IDNs: Linguistic Diversity in the Internet Root

23 October 2013 - A Workshop on Diversity in Bali, Indonesia

Also available in:
Full Session Transcript

The following is the output of the real-time captioning taken during the Eigth Meeting of the IGF, in Bali, Indonesia. Although it is largely accurate, in some cases it may be incomplete or inaccurate due to inaudible passages or transcription errors. It is posted as an aid to understanding the proceedings at the session, but should not be treated as an authoritative record.

 


   

 

    >> Good afternoon, ladies and gentlemen.  Welcome to workshop 32.

  Next in eye DNS, Linguistic Diversity in the Internet Root.

    This workshop is organised by ICANN in collaboration with AP ral lo,

  with an a community of Internet users from the Australia region.  My

  name is -- I'm raim raip raim.  We're going to discuss a project that

  is being implemented by ICANN.  This enables the introduction of IDN

  into the root zone which allows access to IDN top level domains.  What

  we will do is share some information about the project, tell you why

  ICANN has this project.

    What the procedure is for enabling the introduction of IDN variance

  into the root zone.  What is the status of the project.  And then we

  will invite comments from community representatives on what they think

  about this project and how it will affect the language communities

  around the world.

    And we will also get an idea what the var vants are for Arabic, the

  Han script, the Chinese language and Japanese as well as indic.  We

  will start with executive vice president and chief technology user

  of -- participating remotely.

    RAM, if you are on line, #34r50es go ahoed.

    >> RAM MOHAN:  Thank you very much.  I hope you can hear.  So

  Rinalia, thank you very much for inviting me to this session.  It's --

  both this session has important importance in terms of what the sense

  of what we're trying to do but also the -- of what we're trying to do.

  When only 27 of the world speaks English, which uses ASCII as its

  underlying script, it seems obvious that the DNS needed to move to

  support local languages and scripts.

    Certainly through ICANN and the ICANN community the need to add

  linguistic diversity to the Internet was established quite clearly.

  But as with all things technical, it has taken us just over a decade in

  order to achieve an overnight success.

    In having IDNs, international domain names at the -- delegated at the

  top level of the root system.

    Let's speak for a minute about the strategic intent of the root zone

  label generation root project.  Before we get into speaking about label

  generation, just a quick idea of what -- why they're really trying to

  do label generations at the root.

    The fact is that for each language it is represented underneath it by

  a script, by a written form that is then converted into a digital wave

  that is adapted DNS and resolvers can understand and interput.  What

  was clear was that at the root zone, swi a very unique resource, we

  didn't have a list that clearly represented for each of the languages

  that we wanted to have on the root to have what were the rules and what

  were the representations in the digital format of these characters that

  form the language.

    The IDN variant TOD project was established by the ICANN board in

  2010.  And what this project allowed was the creation of a

  multistakeholder project that was tasked to develop solutions and to

  implement -- fine the implement rules of processing.  So that we could

  have the delegation of IDN variant top loader names in the root zone.

    Now, the mult stakeholder model has been a key part of the creation

  and the development and the deployment of the root zone label

  generation rules procedure.

    Now, as you know, ICANN in general works pretty hard on deploying

  solutions, identifying solutions as well as deploying them by using a

  community oriented multistake hold r model.  The IDN TOD programme and

  the variant part, IDN variant TOD programme is quite a good case study

  in the development and deployment of the multistakeholder model and

  multistakeholder system.  To start with, various languages and

  scripts -- script systems that were selected for study, analysis and

  creation of the table, language tables and language rules, this pulled

  in 66 experts from 29 countries and territories around the world.  But

  expertise in the area of DNS, IDNA, linguistic, security and stability

  as well as policy, operations and registry and registrar perspective,

  and to some extent, perspective from the end user and the Internet

  users' point of view.

    ICANN also created an issues report that looked at the risks and

  looked at the methodologies for ruling out top level domains using IDNs

  that had variants associated with them.  And that too brought together

  representatives from the various case study teams who were volunteers

  and who were members from all around the world, from various

  communities.

    In addition to the participation that was -- that came together by

  technical and linguistic experts and security experts from around the

  world, the community at large has also been directly engaged.  The at

  large advisory committee has organised several extremely useful and

  well attended workshops on the topic of IDN topical domains, usage of

  top kag domains using wide bands, the deployment of variants using at

  the IDN top level.  And in addition to that there have been public

  comment periods, conference presentations and discussions.

    And all of this has happened not only inside of the ICANN context,

  but also in other multistakeholder Flora such as the IPF.

    So in conclusion, the -- this entire project is a strategic intent

  for ICANN and the ICANN community, but most importantly ( it's of

  urgent need for the world's multilingual community.  Not deploying IDNs

  at the top level has for years been a key criticism of the mono oral or

  mono -- model of the DNS and for the first time in a long time we're

  moving in a historic way from having only ASCII and only English or the

  romance language that was entered at the top level, we're moving to

  have local languages also available at the top level.

    Now, technically keep in mind that DNS only knows ASCII, so even the

  local languages eventually for computers, they get translated into an

  ASCII equivalent, into a special code called quni code.  That's a

  technical detail.  When it comes to the end user, with for the first

  time we're looking at the ability to type in an entire website address

  in local language, to send an email that is written completely in your

  own local language, whether it is a left to right language or a right

  to left language.  That is historic, and that is also something that

  has been built with the multistakeholder model at the core of it.

    Back to you, Rinalia.

    >> RINALIA ABDUL RAHIM:  Thank you, RAM.  I think that was very

  valuable.  I think -- she could type a domain name all the way in

  Arabic and be able to use variants if this project is successful.  To

  understand what the procedure is, this famous procedure, I invite

  Andrew Sullivan, principal art tekt of Dyn to share the procedure with

  us.  And he's here not because he's with Dyn, but because he's one of

  the lead consultants that helped develop this procedure itself.  So if

  you do not like it, you can tell him so.

    Go ahead.

    >> ANDREW SULLIVAN:  That's right, it's all my fault.  Thank you very

  much.

    That's fun -- so I'm going to go very quickly here at the beginning

  to give some reminder of the context of this before we go on.

    So to begin with, the DNS is a tree structure and it's got all these

  different levels and it was developed a number of years ago, in fact in

  1980s, it's fundamental to the way everything works on the Internet.

  U-can't do stuff without it.  If you don't have the DNS, you're out of

  luck and this is why people wanted labels other than simply ss ki in

  there.  Next, please.

    Remember in the DNS they're made up of these little segments, called

  labels.  And these labels, whether it's way to the left or -- next --

  even the right most one, they're just labels.  All the same kind of

  thing.  So there's nothing special about any particular label.  And

  this is important to understand.  The piece of the domain name is not

  particularly important.  It turns out of course there is a practical

  consequence, technical consequences at the top level because of the way

  the top level is used.  The reason for that is that it's got this

  common root.

    So in the DNS we have these things delegations, and delegation can

  happen anywhere.  What happens is you take part of the name space and

  give it to someone else.

    This can happen, you know, anywhere in the tree, including even far

  down in the tree.  So this is an important other thing that is you give

  away chunks of the name space and you don't have any control inside the

  space that you've just given away.  Another fundamental point.

    Finally, we've got this one root, and this is one root by definition

  when people talk about alternate roots they are amaking a complaint

  about math.  This is just a fact of directed graphs.  And so there's

  this one root.  And that means this is a completely unique zone on the

  Internet.  And that's the key thing here that we have to have one

  common set of rules for this zone because everybody in the world has to

  share it whether they like it or not.

    That's the reason that we need this.

    All right.  So we came up with this idea about the label generation

  rules.

    And what this is, we start with some fundamental things.

    Yes?  You want me slower.  All right.

    So we've come up with the label generation rules, and we're starting

  with the basic facts of the DNS.  The first thing is DNS names are not

  words, they're mnemonics.  They're useful things.  But of course

  mnemonics have to be useful to someone, which means that for you to be

  able to use them, you need to be familiar, it needs to be a familiar

  and recognized writing system and naturally if you don't use ASCII in

  your everyday life, of course those letters are not very useful for you

  and that's the reason why we need today do this.

    We have to remember that the existing rules for the DNS already

  restrict some labels.  So in the DNS historically you weren't allowed

  to use the word "can't with an apostrophe, you can't put the word argh

  in there with an ex complamgs point because they are's not words.

  There's just a bunch of mnemonics there.

    We have new label, the IDNA labels, it's new, that means you need

  more rules.  That's the reason we need these rules.

    Now, another important thing to understand is that these label

  generation rules work on code points.  So there's more than one thing

  you could have done here.  But the way that this actually works just

  technically is it works on code points.  Code points are a little bit

  of of technology.  Normally you think you're writing in characters or

  in words, but when you encode this in a machine, you've got to encode

  it in a character set.  This character set that we're using is called

  uni code and uni code is made up of code points and these code points

  have funny names like this.  U plus 0065, that's a code point.  That

  corresponds to an E.  And Uplus 0638 is the Greek small letter Sy.  So

  these are just code points in every code, every letter that you can

  write has one or more code points.

    There can be multiples.

    I said there can be multiples.  Isn't this fun?

    There is this problem when you have more than one code point and it

  can be more than one code point as a reader, a competent reader cannot

  tell the difference between one and the other, or it can be more than

  one code point whereas a competent reader you can see the difference,

  but you think they're the same thing.

    One way or the other, you've got in some writing systems a case where

  different code points can sometimes be interchanged one for the other.

  They can be exchanged.

    So one example is simplified in traditional try knee but there's

  other examples, lots of other examples.

    What we want to do in this procedure is present allocation of any

  label to competing applicants.  ( This is any label in the root zone,

  only for the root zone, not making rules about further down the tree.

  That stuff has been delegated away.  And we also want to allow the

  possibility of some variants, IDN variants that match each other and

  going to be used by people always to go to the ofrj applicant.  Both of

  these features.  That's what the label generation rules are about.

  They define these variants and their possible disposition, in order to

  do that you've got to have the list of all the code points.

    So we developed a list of the allowable code points.  Had is the

  squalled repertoire.  We developed rules for using this repertoire.

  And the point of this is not to have a bunch of rules for whatever

  people want right now.  ( You don't want ad hoc rules that are subject

  to political discussion every time.  You want a rule set that allows

  you to accommodate the pew it your developments, minimize the risk to

  the root zone and make sure these rules are automatic.  When something

  new comes along, because new characters ged added to uni code from time

  to time, you want to make sure they can be accommodated in the system

  too.

    Now, it turns out that the Internet architecture board had a view

  about what you should do in this case.  And the reason for this is that

  the Internet architecture board previously had something to say about

  how the top level ought to be managed and prior to that there were very

  old documents that said something about what should be in the root

  zone.  If we were going to expand, since this is something everybody on

  the Internet needs to use all the time.

    Came up with the principals on the side.  The key one, the one that

  is most important to take away, conservatism was the number one lelgd

  pel to stick too here.  When you Rand into any case where you weren't

  shoe how it was going to work or whether it was going to work all the

  time or useful all the time, the best thing to do was not to do that.

  Not to use that code point.  Not to use that label because everybody in

  the world has to share this -- this resource.

    So it's one thing to say way down in your local zone, you know, have

  all kinds of crazy labels you want.  But if you're going to have

  something that everybody in the world has to share, what you have to do

  is use the minimum thing that you can put in there while nevertheless

  accommodating people so they can use labels according to familiar

  writing systems, they can actually use them.

    Next, please.

    There's a flow chart here that gives you a picture of what the IDN

  root zone works, this label generation rules procedure.  The basic

  thing is you have generation panels and they come up with proposals

  much then you've got this integration panel.  And the integration panel

  is supposed to be universal world experts who are suppose today achieve

  agreement among these competing proposals.  The proposals are not

  supposed to compete with one another, from time to time you're going to

  get cases where different language communities either use the same

  letters or use letters that sort of bump up against one another, and in

  that case you need to make sure -- you don't need to decide one in

  favor of the other, what you need to do instead is coordinate to make

  sure that nobody's ox is getting gored to much.  We want to make sure

  that all the oxes wonder around happily.  That sometimes mean you say

  no to people, but the reason you have to do that is because you know,

  this is a common resource and we've got to share it.  And at the end of

  this you spit out this label generation rules and it defines these

  things there on the slide.

    Okay.  Why do we have only one set of rules?  Is.

    As I have said repeatedly but I'm going to hammer you with all of

  this because it's been one of the things people keep complaining about,

  it's only one zone and it's a common zone.  We can't get away from it.

  Everybody has to have it.  And therefore we need one set of rules and

  we need only one set of rules for the entire zone in case there are

  collisions in the different rules.

    The generation panels are volunteers and they're supposed to get

  together.  This is supposed o to be very much a bottom up process.  The

  goal of this is to represent community interests and also to make sure

  that he have woo he particular writing expertise.  Invite these outside

  experts and so on, and that will work.

    The integration panel is supposed to be really serious experts in the

  various technologies that are being used here.  So DNS, IDNA, uni code,

  linguistics.  They're supposed to accept these generation panel

  proposals and supposed to put them together and finally come up with a

  common set of rules.  And importantly, they're supposed to make

  decisions unanimously.  So they're not allowed to make decisions -- I

  know, I'm running out of time --

                (Chuckling)


      but I'm not going too fast, exactly.

    Finally, you've got this output -- and this is the overall repertoire

    for the roolt, divided into subrepertoires by script and

    these labels are constrained to be wholly within a

    subtagged repertoire.  You've got these things that

    somehow get a linguistic piece with it.  I didn't write

    these slides, so -- I would have been shorter.

    Finally, and this really is the last thing I have to say, only some

    labels, some writing systems have variants.  And variants

    are defined globally not by subrepertoire.  Despite the

    repertoire you says everything in this label has to be in

    the same writing system, variants actually cut across the

    entire set.  And this is all in a machine readable format.

    It can be processed automatically.  I'm sorry I went over.

    >> RINALIA ABDUL RAHIM:  Thank you, Andrew.  And ICANN has actually

  started the implementation of this project.  And acram ala is here to

  tell us what the status is.  And he is the president of the ICANN's

  domain division, which coordinates the coordination of this project.

  Go ahead, ak RAM.

    >> Thank you for coming here and listening to this important topic.

  I'll leave them to the end.  The integration -- the implementation of

  this procedure is actually well underway.  We have actually started

  with the integration panel, which has been launched.  And melt already

  earlier in October.

    They are working on setting up the repertoire or the bigger set of

  what the LGR set could be.  They are also putting their -- you know,

  putting their arms around the maximum set.  They are looking at the

  label evaluation rules so that everybody can do the same, follow the

  same procedures.  They are also looking at the format for submitting

  LGRs to the integration panel.  So that doing the guidelines for how

  the generation panels will interact with the integration panel.  On the

  generation panels there was a call for generation panels to be formed.

  We've received statements of interest already from different stricts.

    Once these -- once a script or a group of people get around the

  script and decide to form a panel, that panel will be seated and

  immediately after that they can start their work.

    So we're expecting the first panel to be launched before the end of

  the year.

    Now, that depends on the, you know, how quickly the committee can

  organise itself around the scripts if it wants, and that if want toss

  develop.

    Today we have a lot of scripts inmremented in the DNS.  We have nine

  scripts that are included in the new GTLD applications and there are

  already another eight that are included in the CCTLD eye DNS.  We

  expect the generation panel will be formed to make all of these and

  there is no reason why we can't implement additional generation panels

  if other scripts would like to start their work earlier.

    I want to say that we're behind.  There's no question about that.

  Ideally all of this work should have happened before the DNS was

  started.  So that it would have been designed with all of the scripts

  in mind.

    So that the rules that are set took into account all of the different

  scripts.  But we are where we are.  And I think this is very important

  work and we're just scratching the surface.

    We talk about doing this work for only the root, but I think once

  this work is done, then there will be a large implementation for this

  work.  I think a lot of the TLDs will take that aadopt these LGRs for

  their second level and third level.

    I think there is a lot of implementations where once we set the rules

  for variants, these variants rules will also apply downstream.  So

  there is -- this work is just the beginning of a lot of advantages for

  other scripts and the Latin script.  And I'm looking forward to

  actually seeing more progress on this.  And hopefully we can take

  advantage of these rules to start thinking in a lot of different areas

  with multiple script mentality.  I give an example.  There is a lot of

  rpns in the TMCH.  These rpms are thought of in just ASCII.  Rpms

  stands for rights protection mechanisms for trademark holders.

    So when you think about these mechanisms and they -- the way they're

  developed, they're developed by a mentality and a thought of English or

  Latin script.  Once we get the same applications or -- of TLDs and IDNs

  that go into TMCH, there will be an advantage because nobody's thinking

  in those different scripts what are the variations that should be

  protected.  For example for a trademark.

    So just start from there, you can see how we're so far behind.  We

  need to catch up.

    So -- thank you very much.  I will be happy to take questions later.

    >> RINALIA ABDUL RAHIM:  Thank you, ak RAM.  Would I would like to do

  now is invite comments from three representatives from end user

  communities.  They represent the language communities of Arabic,

  Chinese and Indic script.  That's you.

    And we have Mohammed El about a shir, bMohamed El Bashir, he has some

  slides.  He waes supposed to be here.  Unfortunately there was a dns

  attack on his registry and he had to be in Qatar to take care of it.

  Therefore he's participating with us remotely today.

    Maureen, do you have his slides here?

    Yes.  Is he online he's not online.  Okay.  So he's not online right

  now.

    Okay.  The dns atacted and intervened and took him away.  We'll go to

  the next person, then.  Hong Xue.

    >> HONG XUE:  Thank you, good afternoon, ladies and gentlemen.  My

  name is.

    >> HONG XUE:  A law professor from Beijing normal University.  Where

  time goes fast.  I remember 13 years ago in 2000 when the word number

  one, word first, language-based IDN consultant, consortium was

  established in Beijing.  I was one of the drafters of the charter along

  with professor Wu, sitting over there across the table.  But CDNC is a

  first community based -- language community based IDN process to deal

  with the variants and the other IDN variant technical issues.  I guess

  that's very good community based initiatives.  And in 2000, ICANN stab

  established a first working bored chaired by Mr. Katu osinabu.  Made a

  first submission to this working group and made the first policy

  proposal on IDN TLD management.  I was the pen holder of this first

  mission but idea primarily came from madam hu, ching hunk who is

  president of -- China and has been accredited to the hall of fame by

  athought this year.  We propose that for IDN variants management it

  should being absolutely based on language communities proposals and

  issues.  And we propose rough policy issues such as for IDN TLDs, ICANN

  which go to the easier part first, think about IDN cyst TLD first

  before identifying -- after 30 years our proposal has become a reality.

  We're so happy yesterday, the first group of Chinese ID N TLD has gone

  alive.

    So this is very much positive achievement.

    I'd like to go to a few principles that's been experienced by Chinese

  community, even though we're not very good at summarizing these

  principles but it has been enshrined in practicing.  One is

  community-based.  It must be based on the language community.  Language

  community is a concept first raised by Chinese language community.  In

  that first submission to ICANN.  And I hope I can do -- ICANN retains

  these historical documents.  And we could refresh our institutional

  memory.  It seems it can be fun anywhere in ICANN that size.

    Language community is open concept much it is not defined by language

  sofrnt.  That's ridiculous.  If you speak that language, you are in

  that community.  So we are often joking that there is a bigger

  English-xeeking community in China than United States.  So as far as

  you speak that language, you, that language community, and certainly it

  should be a bottom up process.  Think about the CDNC Chinese domain

  name consortium.  A he can it kal community.  It's thot by government.

    And thirdly it should be multistakeholder.  CDNC is a very

  interesting organisation.  Professor Wu and I were the founders, among

  the founders.  We're now only observers.  It is multistakeholder was

  due there but we are now observers, in civil society it is now only

  open for the full membership for registries.  Primarily CCTLE -- but we

  can call it a multistakeholder organisation.  And also last but not

  least it should be consensus based.  I know from the readers how to

  deal with disputes.  I strongly dislike disparity resolution.  Even

  though I'm a lawyer.  It is consensus based, it should find common

  dominator accepted most widely in the community.

    Even the code point permissible in this DNS system, especially root

  level, it should be really acceptable to that community because it's

  user in that community is really going to use those codes.  Thanks.

    >> RINALIA ABDUL RAHIM:  Thank you, Hong.  I think later in Edmon's

  presentation he will give the example or case study how the Chinese

  language in the Han script language came together to resolve their

  differences.  Next I would like to invite Satish Babu.

    >> SATISH BABU:  Thank you, I am from the international -- software

  in India.  I will be speaking from the perspective of a user, as --

  especially from south Asia for the technology aspects we have senior

  people from both the government and technology side of things from

  India.

    So I'll steer clear of the technology aspect.

    First of all I'd like to say that IDNs actually is a very important

  compliment of multilingualism which reaffirms the universal access that

  we have been talking about since yesterday.

    As far as India is concerned, we have a lot of complexity with about

  22 languages, with about 19 of them using 11 scripts.  So again imagine

  the whole idea of -- 11 ought mattic scripts and three Arabic scripts

  much we have problems of one to many and many to one.  Some languages

  using multiple script, some scripts being used by several languages.

  One for example is used by nine different languages.

    Now, these actually kind of pose several complexities.  In addition,

  we also have issues with things like rendering with multi tear lifts,

  baseline shifting, homo graphs and homo phones.  We don't have the

  issue of low word upper case.  But we also have issues like with pretty

  kind of unique to Indic languages, with 0s and so on.  Some languages

  do not have all the letters.  Translation is sometimes difficult.  One

  language not from India but the Urdu language uses the same script, the

  naslik script which is vertical, it goes up as you write.  It's a very

  beautiful kind of representation.  And this last week we were reading

  that that script is dying out because computers are not able to support

  that particular script.  And the community is actually really concerned

  about the loss of the diversity.

    So we have, you know, several issues of both encoding and rernding

  which are -- because of the fact that we have these many languages.

    Now, as far as the procedure is concerned, we have some general

  recommendations.  The first recommendation is the mechanism specified

  by the procedure for the oversight of this whole process is the public

  comments.  We are aware that public comments causes a kind of

  multistakeholder organisation, that is the only way we can go.

  However, we would like to highlight the fact that there are some

  weaknesses of this model as well.  For example can be ensured that the

  participation of all 11 stakeholders is effected.  You know, all the

  logistics and mechanics of this procedure.  I would like to flag the

  issue as one that requires perhaps a little more work to ensure that

  there is transparent representative activity or action that goes on in

  this public comment process.

    The other issues that there is a lot of interest in India from -- on

  this issue of the IDNs, international domain names, there is, as you

  can see, has been mentioned already, we are quite active in terms of

  the already GTLD representative right now and also delegated, they

  have -- have already been delegated.

    Now, in the issue of the panels, the problem is that the fragmented

  kind of language communities in India, as very different from what Han

  mentioned in terms of Chinese, for example, a fairly homogenous kind of

  community, how are we going to ensure that the communities are aware of

  these processes and how do we -- what are the facilities that we have

  at hand to ensure that the participation of all these communities is

  ensured? ?

    That I think is something that we have to -- we're not clear, but

  sitting in India, in fact the corner of the country, we do not see a

  process of facilitation that exists for the smaller language

  communities.  In the -- like in Hindi and all, are not very sure, but

  smaller communities there is this issue that the process is not

  transparent and participants as of now.  I would like to flag that as

  also an issue of concern.  That in a very, very diverse country like

  India, one has to take care of.

    Thanks very much.

    >> RINALIA ABDUL RAHIM:  Thank you, Satish.  After this we would like

  to get the presentations from the expert panel and I would like you to

  get ready.  You're starting first.  You want to come here and present.

  And while he's setting up, do you have a response, ak RAM, in terms of

  what is ICANN doing to facilitate, the smaller ones, how are they

  getting to know about the project, and are we doing anything about the

  weakness of the public comments?

    >> Ak RAM:  Weaknesses of the public comments.  Yes, I can as looking

  into the public comment process, ICANN in the community, we've done

  multiple reviews on that and continue to improve the process.  (.

    We would like to see the public comment in multiple languages, but

  right now the majority of the public comments that we get are actually

  in -- in English and we haven't seen a lot of demand for other scripts

  into -- in the public comment.

    Nonetheless, an area that we're more than willing to investigate and

  look into.  Today as I mentioned on the -- on the LGR, there are about

  17 panels that we're expecting to be working on different scripts.  We

  don't have any outreach programmes right now other than the grassroot

  outreach programmes that you guys are doing to reach out to other

  communities and see if there's anything interested.  But we are more

  than willing to participate and help if there are any communities that

  want to do a -- form a panel on a script that's not -- that hasn't been

  mentioned at this time.

    So please let us know.  And if you need any help, we'll figure out a

  way to help you in it.

    >> RINALIA ABDUL RAHIM:  Yes, thank you, akRAM.

    ROM would like to make a comment.  Go ahead.

    >> RAM MOHAN:  For the previous comment for more communities and

  languages, I guess my perspective is that the need and the interest has

  to be reflected from the community into the process.  As akRAM said,

  the process is quite open for fulfilling these needs.  When we -- what

  I think a quite a bit of the initial start-up -- righting wrongs, even

  in the local language community.  If you look for example at the one

  script, I think it would be important to get together and define what

  needs to be done to represent it in the DNS.  And then come into the

  process.  Because the process is welcoming and embracing of all the

  various languages on the representations.  You know, on the DNS, so

  long as you can get to unique representations.

    >> RINALIA ABDUL RAHIM:  Thank you, RAM.

    Are you ready now, Sarmad?

    Sarmad Hussain is going to make a presentation about the Arabic

  community and the work that they're doing and to give you some idea of

  the variants in Arabic.  He is professor of computer science and head

  of the language of engineering, University of engineering, Pakistan.

    >> SARMAD HUSSAIN:  Thank you, Rinalia.  I will give an overview of

  what is the latest progress as far as IDNs and variants are concerned

  for Arabic script.  Just to start with a little bit of history, the

  community work for Arabic script actually started long time ago, back

  in 2002.

    But the more recent work started again when the IDN RFCs were revised

  in 2008 the Arabic script community came together again and formulated

  a group to look at the relevant issues related to international -- it

  was a develop phone group by the name of -- Arabic script idea group.

  The group worked for a couple years.  It had participation from

  multiple countries, pull pel languages.  And were able to come together

  and do the relevant homework.  Which as I will share later was then

  taken up by other initiatives later in the stream.  (.

    In around 2009 the first track process was started, and many of the

  communities, countries which were using -- which are using Arabic

  script actually used the fast track process to apply for the local

  strippings, strings in Arabic script.

    The initial homework which was done by Asfik was eventually used by

  these communities to develop language tables.  They weren't called

  language tables at that time.  They're now called language generation

  rules.  And they were submitted to ICANN along with the applications.

  And many of those obviously ccTLDs, have been approved and many of them

  are now delegated and working.

    So later on there was a start of Arabic variant issues project.

  Arabic -- sorry, generally variant issues project and Arabic was one of

  the languages selected as a case study.  There was a team formulated in

  2011 which worked in -- in 2010 and delivered a report on Arabic issues

  with Arabic script as far as variants were concerned.

    This work was actually in continuation with what the initial work,

  which was started by aswig.

    Further down once the issues were identified, they were -- the

  community also contributed to the user experience study done by the

  variant issues project.  And currently it has now coming together.  It

  has actually come together again as a task force on Arabic script IDNs.

  I will talk a little more about it towards the end of this

  presentation.

    I think one of the things which I'm trying to present here is that

  the Arabic script community actually has been very active for many,

  many years now.  It has done a lot of homework.  And it's actually now

  very ready to actually go and do the next step and develop the LGR and

  start getting the variants.

    Okay.  Just to give an overview -- I'm not going to get into details

  of this, this is all documented in reports.  Elsewhere.

    But there are lot of -- the idea of variants, which Arabic script

  has.  There's three large high level categories.  You can have

  characters which are duplicately encoded but have exactly the same

  shape.  They have some characters have shape in all context, same shape

  in all contexts, some have same shape in certain contexts.  And there

  are also characters which have similar shapes, not same shapes but

  they're still confusing for user communities.  And then there are these

  third kind of characters which are totally different in shape, but the

  user communities consider them as the same.

    So there are all these different kind of variants which exist and it

  needs to be tackled with as far as generational label, generation rules

  as concerned for Arabic.

    So there is obviously a need for this.  Soez you see Pakistan written

  there.  Even though it looks exactly the same way, it has internally a

  different set of code points.  So these two things will look the same

  to the user, but will need to be -- the current system would consider

  them as different strings.  It should not be considered.  They should

  not be considered as different strings.  So some mechanism through

  variants should obviously need to be introduced to map these onto each

  other.

    There are about 120 such cases in Arabic script so far which have

  been identified for further discussion.  And they need to be eventually

  worked out for -- by the community.  And then all the variants which

  are generated, they need to be eventually -- some of them at least need

  to be located because different user communities use different

  keyboards.  And so some people will be, for example, typing 0643 and

  some peep will be typing 0689.  So you cannot allocate one and block

  the other and so on.

    And then there is real need so out of the 16 CCID applications, with

  ICANN right now, four have applicant -- four have requested for

  variants.  So that's like 25 percent.  So variants are needed.  Though

  they are need, they also pose some challenges which need to be

  obviously addressed.  Again there are multiple layers of these

  challenges within the processes, within the tools, within the user

  applications.  Obviously for example one of the key things is a string

  may have more than 500, 600 variants.  So how do you decide which

  variants to activate and which variants not to activate?

    Some of those challenges obviously need to be met eventually.

    So let me now come to the last part of my presentation.  Which is

  focussed on what -- what are we doing now.

    So as I said, based on the history, there has been homework done but

  that work now needs to conclude into what is labeled generation rules

  set for rule zone.  But -- root zone.  Generation are not only needed

  for root zones, also for other notes down the tree.

    So the community's actually come together through middle -- actually

  a strategy group formed by ICANN.  It's called middle strategy working

  group.  And it's actually formulated, dedicated task force to not only

  look at LGR, but actually look at Arabic script ideas holistically in

  larger context.  LGRs is root zone LGR is obviously the first thing

  which this task force is going to take up.  But it is not going to take

  this up in isolation.  It's going to look at Arabic domain labels

  for -- in other contexts as well.  For example second level LGRs,

  universal stablt of Arabic IDNs and so on.  It's going to take up many

  more things.

    Just to give you a little more introduction of this task force,

  it's -- its membership is open shall it's community based.  There was

  actually a public call done for it.  ( In August and September time.

  Applications were received.  Everybody who had applied was incorporated

  in the task force.  It's a rolling process.  Is' not something which

  was closed in September.

    To ensure -- so the task force was formally announced at Arabic IGF,

  two in Algeria recently.  We've actually been making sure that there is

  diversity in this task force.  So currently we have 20 members and 15

  from 15 different countries.  We started at about 15 members from about

  12 countries.  But we were missing some significant representation from

  languages which are not covered.  So we have been able to go out, we

  reached out to people who worked with those languages, invited them to

  join the task force and brought them on board.  Now actually the task

  force covers a reasonable variety of languages which include languages

  across southeast Asia, south Asia, Middle East, north Africa and sub

  Saharan Africa.  And I will conclude here.  Thank you very much.

    >> RINALIA ABDUL RAHIM:  Thank you.  Akshat Joshi Joshi will present

  on Devanagari.

    >> AKSHAT JOSHI JOSHI:  I will be giving you an overview of various

  cases through the Devanagari study went.  Before I get started I would

  like to give you an overview of Miss Organisation that is Cdek.  We are

  based in India and we are working on multiple level computing.  Most of

  the operations are based on language processing.  And why we are

  working on IDNs is we had initially been working on the Indian IDNs and

  IDN, CCTLD.  And we have been working with the parent organisation with

  the dot IDNcctld.

    We have mrn planning on working on -- and we have done fairly good

  amount of ground work for that.  There were some issues that came up

  when we talk about launching IDNs in Indian languages and subsequently

  even when as the new programme launched, the need for identification of

  issues for Indian languages was filled by ICANN as well and then this

  project started.

    So there's a bit of background.  I have just roughly divided this

  presentation into four parts.  Initially overview, then we go into the

  issues, solutions and some of the probable resolutions which will take

  to the final groups on NGR for the Devanagari.  Devanagari script is

  basically a -- it has alphabets and syllables.  The main components of

  the writing system are consonants, which are standard -- stand alone

  consonants.  There are vowels, which are accompanied by associated die

  creddic marks.  I will just view -- this image over here, just using

  glimpse of what -- where it is possible combinations that can be done

  with a root character.  I will just try to elaborate a bit on this.

    This is the highlighted part, the base character.  And what is

  surrounding that, these are the various characters which can be

  associated with this base character to form multiple shapes.  This is

  the Devanagari script as representative.  And here are other scripts

  like this is Bangla, and most of the other scripts.  These all are

  scripts basically having the same parent script that is Brami, the

  founding principles of these scripts are almost similar, even though

  individually they are a bit different.

    So when the project started, there was discussion regarding whether

  we should only go for the Devanagari or some associated scripts.  But

  then it was thought of that we'll start with the Devanagari and since

  the Devanagari has the same structure and similarities as other family

  based scripts, most of the issues will be applicable equally to the

  other scripts as well.

    Entering into the issues part, I will just try to stress upon the

  point about why visual similarities are concerned for the Devanagari

  script.  When by the numbers, the Devanagari typically has 37

  consonants which are general use.  15 vowels which combine with the

  consonants.  And 14 vowel signs.  There is just a bit of math over

  there.  Let's say that with these many characters we have 6951 basic

  shapes.  Which a normal user can understand.

    And then there is another concept of concern too.  Base consonants

  join with each other to form a different combination, visual

  combination.  If we add up that thing here, what we end up actually is

  in 57,000 different shapes.  Which a user can understand.  Not all

  57,000 are in use, but if you go by the -- whatever is the general

  usage, it still stands at 25,000 unique shapes.  A regular font has 500

  basic glyphs, out of which the characters are composed.

    And then there are even more complex levels that are not even going

  into that level.  But these are the number of shapes that are possible

  in the Devanagari languages.  And with these many shapes, the visual

  similarities definitely becomes a prime concern.

    Apart from visual thing, there are foe nettic variants in Devanagari

  based languages.  So the example over here is the word Hindi in two

  different forms.  It's just that it has different storage, but while

  pronouncing, it is the same for everybody.  There are additionally

  linguistic variants as well.  So recently Bombay has changed its name

  from Bombay to mum bye.  For many people this is kind of variant.  When

  it doesn't matter whether they are talking in terms of Bombay or mum

  bye, they are talking about the same city and they know it.  For them

  it's not much of a different thing.  (.

    But what is the ground situation when it comes to the Devanagari

  script since it is a complex script, there are many accents to play in

  these scripts represented in the digital medium.  And some of the prime

  actors here are Internet browsers and the operating systems.  For all

  these to happen, it is not as same as like in script.  There is an

  original component that operating system inserts into the system that

  is rendering engine and it varies from each operating system to

  operating system.  That amounts to the differences in individual

  appearance of the characters.  Coming to the solutions part, this was

  one of the founding principles that whatever is the solution that would

  be proposed, it has to be -- the decision has to be definitive,

  nondisputed, and it has to be programmatically implementable.  Because

  the domain registration work, it's an automatic system and we cannot

  have a manual intervention into it.

    Ground relates about the kinds of variants we have is foe nettic

  variants, those are not definite.  Because dialect changes, phonetic

  variants change for people.  Those cannot be -- cognitive difference,

  some say mom bay and mum bye are different -- but it may not make

  difference for somebody else.  Visual variants are something which can

  be handled pro ma'am mat particularly but it calls for another thing to

  be resolved.  And had an is achieved through a term known as whole

  label evaluation roots.  I will try to touch upon that in my last

  slide.  (.

    So what ultimately the resolution will turn to.  It was that we can

  do visual variants and they can be accommodated into this process.

    But one of the key things that was discussed when we were discussing

  the visual variants is there an already existing ICANN process which

  deals with similarity.  Whenever string is delegated, there is string

  similarity tool that is -- which gives the similar look and feel of the

  already existing -- a primary thought is if something needs to be added

  it can be added to enhance that process.  But this visual similarity

  analysis calls for a given that is there are certain ways in which

  these languages are represented.  And if somebody wants to create

  something which looks similar to an already existing thing, that can be

  generated out if it is not a valid construct.

    So having a valid construct for a popular domain in the Devanagari

  based languages is definitely needed and that will be achieved through

  this whole level evaluation tools for the Devanagari.

    I have just given an example.  Like the second word is not well

  formed.  Even the third one is.  Whenever there would be some kind of

  validation that would be performed on this labels, and only those will

  pass the system which are valid as per the whole label evaluation

  roots.

    So these are two things that we have discussed and agreed upon that

  may happen.  Ultimately the decision will be they can recommend the

  community comes together and they discuss whatever the possible

  solutions.  But we think this should be sufficient for the case.

    Thank you.

    >> RINALIA ABDUL RAHIM:  Thank you, Akshat.  I forgot to introduce

  him.  Quite a few.  Akshat Joshi Joshi is project engineer from the

  centre for advanced developing community in India where ICANN

  established a centre of excellence for DNS security.  Josh yosh yes.

    >> RINALIA ABDUL RAHIM:  Yes.  Congratulations.  Next is Edmon, are

  you noted?

    Okay.  And Edmon Chung is CEO of DotAsia and chief engineer of

  society Hong Kong.  Edmon Chung thank you, Rinalia, and as I bring up

  my presentation -- one?

    It's already open.  Thank you.

    >> EDMON CHUNG:  ( I'm going to be going -- okay.

    So thank you, Rinalia, and Saverages rmad.

    I will talk a little about the experience from the Chinese community

  especially on driving the development on the Han script IDNs.  I

  thought I would start out with talking about what is an IDN variant?

    In fact unfortunately to disappoint you, one of the things that the

  community has really found ought is that it's sort of an elusive thing.

  So in the true spirit of the Internet and this multistakeholder

  approach that we talked about, this is kind of a -- we're not achieving

  full agreement on what an IDN variant is.  But if we can have enough

  agreement to work towards, you know -- to work together, that's really

  what it is.  But I still want to -- seeing some new faces around --

  this is kind of the worst, easiest to understand way to talk about IDN

  variants, I guess.

    It's that imagine that the capital letters and small letters are

  technically different on the DNS.  We might need to have policies to

  make them the same in a way.

    So this is a situation with simplified and traditional Chinese where

  we identified the issue.  Don't take that analogy too far because it

  will break down a lot of ways.  But that's the easy way to understand.

    So what they are, I guess a way to summarize that, these are things

  that have linguistic origins.  They're different characters that are

  being used.  Because of certain technical limitations of the DNS and of

  how we use the DNS, there are policy implementations that are required

  to implement IDN variants so that it is better used by Internet users

  when they use the Chinese domain name, for example.

    Hong already mentioned about the CDMC, the Chinese consortium formed

  in 2000 and a couple IETF RFCs were -- were created from the work.

  And -- along with other people as well.

    One is called the jet guidelines for IDN, another focus more on

  Chinese domain names.

    Another thing that is of importance, I guess, is a couple of IDN

  tables were submitted by C. N. Nick and T. W. Nick respectively.  And a

  couple years ago dot Asia ourselves also submitted a table that

  essentially put together the CN table and TW table.  And here is why.

  And I explain it because it's very relevant for our discussion at the

  root.  Which Andrew mentioned.  So as a basic, the policy is that if

  you applied for a simplified Chinese string or domain name, you would

  get the traditional Chinese string as well.

    As a variant.  And you would have reserved other types of strings

  that are basically generated from the table.  The challenge then for

  operating as a GTLD versus a CCTLD is that in the CN, TW, and also in

  this case Japanese tables, they have a context based on the TDL, krfrjs

  cTLD, like dot J. P., you would expect the Japanese, dot c n.  That's

  Chinese.  In the case of Asia, or TDLdsz.  There is no such context.

  And therefore additional considerations need to be made.  And such

  considerations need to be made both on utilizing simplified Chinese

  together with traditional Chinese as well as the overlap with Japanese

  Condi characters.  Here's a quick example of one of the characters

  which is somewhat interesting.  And this is a character that can mean

  here or development.  And there's also a Japanese congi character

  related to the set of Chinese characters.  And these are -- this is

  some of the issue -- one of the issues or actually one of the main

  issues that the -- when we talk about ( I guess Han script or Han

  characters are being used in the IDN in the root or in a GTLD context,

  we will probably need to consider the simplified Chinese context,

  traditional Chinese context, as well as Japanese congi context.  And

  although I've, you know -- talk about this as if there's a lot of

  problem, I think the community has spent the last 13, 14 years working

  out the solutions.  And I'm glad to -- well, at least I'm hopeful to

  say that we're quite confident that we have a pretty solid solution set

  based on policy implementation for IDN variants much.

    But that being said, I actually just before that -- one of the things

  that I wanted -- did want to bring out as well that you heard about

  Chinese both simplified and traditional and you heard about Japanese

  congi, one somewhat popularly used Han character usage in Korea, which

  is Korean Honja is not discussed.  Thaus that's because there is a very

  strong consensus in the community from Korea that Korean honja will not

  be aused or allowed for registration in the Korean IDN context and

  therefore they're not included.

    As a summary, the Han character IDNs really we're talking about --

  when we talk about in the GTLD context and that I guess that relates to

  the root context as well, we're talking about the sort of intersect

  or -- intersection or union of simplified Chinese, traditional Chinese

  and Japanese congi characters.

    And that brings me to I think what -- something that's even more

  important, I think, for this programme as well.  Which is the user

  experience.  Because ultimately the IDN variants are implemented,

  policies are implemented to enhance the user experience.  There are

  certain challenge, Internet user, registrants, registrars, hosts, how

  do they deal with the different variants that are essentially distinct

  DNS entries but how do they host it so that it's considered the same

  domain by policy or by somewhat with the same applicant -- with the

  same registrant?

    How do registrars and registries handle it?

    With that actually it relates very much to a problem which generally

  called the universal acceptance of DLDs or universal acceptance of

  IDNTDLs in this process?

    Similar problems, similars points of failures where ISPs might choke

  on IDN variants or TDLs.  There's a common interest being built between

  the ccTDLs and the country code domains and top level domains shall the

  key message I want to bring forward is this really requires

  industrywide collaboration.  And it's not just an ICANN issue and it is

  the whole user community and the technical community issue.

    So really what we're talking about is that a lot of times interfaces

  or applications, they have preset certain lists of TLDs.  You see a

  drop down box and if the new top of domain or new IDN top level domain

  is added, that field needs to be compatible.  Another type of scenario,

  if you try to sign on to a social network, for example, your email

  address or your URL, will that database accept IDNs?

    There's also the search engines and search engines have different

  components, the search results, the advertising results, and you know,

  some other results.  Will they accept IDNs especially variants, IDN

  variants as well?

    How do they relate?

    Emails of course, that's one of the top usage or domain names as

  well.

    And how would they -- how would email clients react?

    Why are they not accepted?

    A number of reasons why.  A lot of them are based on technical

  origins.  One of the reasons that we found is that a lot of

  applications or interfaces utilize hard coded list, they're not easily

  updated.  They might use different lists that are out there.  That is

  not fully synchronized with the ICANN root, the single root that Andrew

  mentioned about as well.

    And there are certain applications that check this length of the

  string.  So you know applications expect that top level domains are

  either two characters or three characters long.  But with an IDN

  because of the Puni code, the technical implementation it would be much

  longer.  How would these play?

    And of course there are other sort of gatekeepers as well.  Like spam

  filters, like invalid email addresses or invalid domain names.  Systems

  are out there that would need to know about IDNs that would need to

  know about IDN variants as well.

    With that, what has been done?

    Actually the ICANN SACK, this is not an entirely new issue, it's an

  issue that has been anticipated for a long time.  When new GTLDs were

  introduced, info and dot museum, some of the issues surfaced.  And the

  SCAK came out with a report, with a number of recommendations.  ICANN

  has implemented a number of them.  Not all of them have been

  implemented.  A couple of them that -- that has been implemented

  inclusion a TLDverification code that ICANN has produced and hopefully

  more people will be using it many there's also a draft set of outreach

  materials that are being developed.  And frankly, a joint working group

  between the CCNSO, and GNSO is putting out a number of recommendations

  to -- and Hopefully this will be -- the process will be completed and

  the two councils will be presenting this -- these set of

  recommendations to -- back to the board, ICANN board.  One of the key

  recommendations there is to at least get our own act together.  Because

  what is interesting is that we look at some of the registries and

  registrars who offer IDN TLDs, they themselves have their own systems,

  may not be fully compliant or may not be fully embracing IDN TLDs or

  especially IDN variants in like email addresses or like name server

  records for domain names.  This is an issue.  Beau the acceptance of

  IDN TLDs, and especially the accent tans of IDN variant TLDs.  Or

  variants in general.  This is an issue that unless we address it as a

  whole, will continue and will be amplified, especially when we see IDN

  ccTLDs being implemented now and of course we recently heard -- know

  that IDN GTLDs are also being implemented into the root.  So with that,

  thank you.

    >> RINALIA ABDUL RAHIM:  Thank you, Edmon.  I think it would be fair

  to say that universal acceptance is probably the highest on the end

  user community agenda in terms of problem.

    So I'd like to go around the room and see if there are any questions

  or concerns.  And I know we're running out of time, but I will take a

  little bit more time.

    Any questions?

    Is your hand up?

    I see Olivia and then Huru.

    >> Owe life yo: .  Of lecture.  We've spoken about universal

  acceptance and user -- user ability by the user community.  What's the

  status with regards to the actual applications running and their

  ability to use those new IDNs?

    Email, Web browsers, et cetera?

    I sew know some perform some verification and some might not call for

  any more.  Is there any status on this as well?

    >>

    >> ANDREW SULLIVAN:  The short answer is that on the Internet,

  because it's a permissionless system, there's end to end, the

  innovation is really at the edges.

    It's very difficult to guarantee universal acceptance of anything.

  What we do know is that we went through a round of this back in 2001

  when we added some top level labels that were longer than

  traditionally.  And they haven't worked consistently everywhere, some

  of them still to this day.

    So I think we should expect that there are going to be some barriers

  and there's going to be some difficulty.  Not because they won't work

  in the DNS, but because they won't work in certain applications or

  something like that.  There's nothing to do about that except to

  encourage people not to do that.

    I will say there are some technical work going on to try to

  discourage some of the sis at the presents that have traditionally been

  used in order to do this.  Including some work just to toot my own

  horn, some work I have tried to push through the ITF in order to

  suggest a new way of tracking what is a legitimate top level label and

  what is not.

    >> RINALIA ABDUL RAHIM:  Thank you, Andrew.  I think RAM also wants

  to respond to that question.  Go ahead, RAM.

    >> RAM MOHAN:  Just a wrap-up, not a question itself.  So I can

  take -- raim thank you for that question.  Huru, you had a question?

    >> Thank you.  This is Huru, from the J. P.  I have a question about

  the requirement for the variants.  Today's session I think is mainly

  focussed on the definition of IDN variants.

    On top of that, there should be some requirements such as -- as

  Andrew said, allowing location of some IDN variants to the same

  applicant.

    So it's related to the last part of Edmon's presentation.  Or they

  may be touched on Edmon's presentations in a way.

    But on top of that, then a need of some requirement, or is there any

  possible further requirements for the resolution of the variants?

    Of the domain name such as variants of a domain name should be

  reserved to the same IP address?

    Which may be good from the aspect of user experience.

    Was this kind of topic discussed?

    Maybe I'm wrong but universal acceptance seems to be now focussed on

  the unique user experience across TLDs, but how about the user

  experience among variants?

    >> EDMON CHUNG:  If I got your question correctly, you're talking

  about a potential discussion about a requirement for handling IDN

  variants and how it's put into the DNS.

    The current -- at least my current thinking or at least the Chinese

  experience is to say that on a registry point of view, to allocate it

  to the same applicant, and also to delegate to the same set of name

  serve offers.

    As to the IP address that is being used, if you are talking about an

  end resource like a website, or a Web -- resource, I personally think

  that might not be what -- at least at the ICANN level, registry level

  we should be regulating or trying to at least make a definitive

  coordination.

    I think if we allocate it to the same applicant and delegate to the

  same set of name servers, that should provide the -- enough kind of

  package for users and registrants as well.

    I put out an example.  Like for example in simplified Chinese and

  traditional Chinese nooez, it is quite possible, in fact we are seeing

  that happen is that the -- the registrant for a domain name would set

  the simplified Chinese to Web servers in China and set the traditional

  Chinese to Web servers in Hong Kong or Taiwan.  So the end record, the

  IP address of the resource may not be the same.

    But in set of name servers on the registrant should be the same.

  So...

    >> RINALIA ABDUL RAHIM:  Thank you, Edmon.  I think RAM wants to

  respond to Huru's question, is that right?

    >> RAM MOHAN:  Thank you very much.  I think this is an area where

  one size does not fit all.  Depending on the local, depending on the

  registry, and most importantly, depending on the user community (, the

  decision needs to be made as to whether variants should point to the

  same place or to other places.

    In general I agree with Edmon that it's not an area for regulation.

  But at the same time I think it's important to note the distinction

  that within the registry it might be very useful to have consistency

  over policy about what happens to variants.  But across registries,

  there probably ought to be a space for variation depending on locale,

  community, and type of TLD.

    >> RINALIA ABDUL RAHIM:  Are you happy with that response, Huru?

    Any other questions around the table?

    I'll look to this side first.

    Go ahead, clep clep clep.

    >> OLIVIER CREPIN-LEBLOND:  Thank you, very much.  I understand the

  Chinese one has reached the end of its work -- there might not be an

  end to the work.  Ongoing work in the Chinese one.  An Arabic one

  started.  Is there a calendar of the start of other task forces with

  regard to other scripts as well?

    >> We just talked about that.  We opened, we made a call for

  application for the panels.  That are going to form the LGR for each

  script.  And that just happened in July.  So we'll see -- we received a

  few.  We expect the first panel will be formed before the end of this

  year.  And so we expect about 17 scripts that will participate.  So

  we're waiting for that to happen.  So it's just happening now.  So...

    >> EDMON CHUNG:  Just to clarify, I think owe life yea, you are

  you're asking there has been a lot of community work done in different

  communities and Chinese started way -- a long time ago.  But the LGR

  process in the root, that is just beginning.  (.

    So each of those panels are just being formed.  So none of them -- I

  don't think any of them have been formed yet.  So it will be formed.

    And -- but the work will not be wasted.  I mean work from the

  community from long time could be utilized and hopefully quickly come

  to conclusion with those panels.

    >> ANDREW SULLIVAN:  A key piece of this, though -- I just wanted to

  emphasize this because I don't think I made it clear earlier.  A key

  part of the design and part of the reason there's this complicated

  two-Phase sort of permit procedure is that the integration panel can

  actually start producing label generation rules before all of the

  characters in the world have been considered.

    So the -- part of the point of the design is to make it possible that

  if, for instance, people -- the Chinese community and the Arabic

  community and -- maybe just those two -- are ready.  And nobody else

  has done any work yet.  You know, everybody in the world doesn't have

  to wait until all of the languages in the world have been solved.

  Because the truth of the matter is we know that there are some

  languages that are active in the world and they're encoded in Uni,

  code, their writing is in Uni code, there are no speakers on the

  Internet and though don't care about those labels and they're not going

  to show up.  We wanted to have a system that allowed that.

    >> RINALIA ABDUL RAHIM:  You have a follow upquestion, owe life yea?

    >> OLIVIER CREPIN-LEBLOND:  It's very short.  Who to contact or where

  to go if you want to get involved.  There's a lot of people who have no

  idea but they know something's happening and I think it would be good

  to make it clear what's their first point of contact?

    >> So the team in charge of that in ICANN staff is Niela and

  Nicoletta, if I'm not mistaken.  They are able to facilitate this.

  There is a lot of information online on the ICANN.org website on that.

    >> RINALIA ABDUL RAHIM:  Any other questions around the table?

    Before we go, Andrew, can you clarify -- because some people have

  commented on it -- there seems to be the lack of an appeal process.

  For example, in a generation panel submits proposal, it is rejected by

  the integration panel and integration panel provides an explanation.

  And somehow the community is not happy.  What is the recourse?

    >> Sul there are three thing toss say about that.  This is actually

  the expression of the conservatism principle.  The point of having this

  integration panel and its unanimity provision is there is this

  conservatism principle.  If you have people who have doubts and they're

  presumably widely regarded experts, not just random people, then

  they're in a position to say, you know, there's this problem and the

  conservatism principle says that we think there's a problem, we can't

  go ahead.  That's the reason for it.  You're right near's not an appeal

  process but there is sort of an endless loop that can go there.  (.

    Right?

    (Sullivan) so there is intended to be actually public negotiation of

  this.  And this is the reason that it depends on the public comment

  period and so on.  Because the integration panel doesn't just get to

  say no, go away.  They have to defend themselves in public.  And if

  they can't defend themself, then at some point the integration panel is

  ill legitimate and the answer is you file the integration panel.

    So the idea is really genuinely that this be a multistakeholder

  process that is held in public and open and transparent.  And if

  openness and transparency doesn't solve our problem for the operation

  of the root zone, then we don't have a recourse.  We're out of luck at

  that point.  And I think that that's actually just the truth about

  this.  There is no way that we can come along and say no, we're going

  to cut the baby in half and make the decision.  You don't get to do

  that.

    So unfortunately you know, that's not a very satisfying answer.  Veng

  we would like to have an appeals process many but my feeling when I was

  working on this -- because I remember having discussions about this at

  the time, my feeling always was, as soon as I -- as soon as we invernt

  an appeals process the next day it will be to invent the appeals

  process for the appeals process and eventually we get to the turtles

  all the way down.  So I thought we could stop at the first turtle.

    >> RINALIA ABDUL RAHIM:  Thank you.  We've come to the end of our

  session and RAM would like to wrap the session up.  Go ahead, RAM.

    >> RAM MOHAN:  Thank you.

    While many items roo he main in local languages, as in natural home

  domain system, the need for the full expression of humankind, language

  system and the Internet domain name system is critical.  This is

  important work.  But it's also complex work, as you saw from the

  panelists.  So therefore we should expect this work will take some time

  to come to fruition.  But of the very large number of things that

  organisation ought to do in the public interest, nothing else feels as

  important as enablement of languages in the domain name system.  After

  all, what is more natural than being able to express yourself in your

  own language and in your own script?

    So Rinalia, thank you for putting this together and I hope the

  session was a value to everybody.

    >> RINALIA ABDUL RAHIM:  Thank you, RAM.  Please join me in thanking

  the panelists and also for your patience in joining us today.

                (Applause)

                -END-