[LAC-Discuss] ALAC Statement on IDNs

[Carlton A Samuels]

-------> [ENGLISH] Original message in english

Dear Colleagues:

Here following, the full statement from ALAC on IDNs delivered to the ICANN
Board.  The statement is available as a pdf document in English from the
wiki.

Kind regards,
Carlton
-------------------------------------------------------------------------
At ICANN San Juan Meeting in July 2007, the Board requested that that the
ICANN community including the GNSO, ccNSO, GAC, and ALAC provide the Board
with responses to the published list of issues and questions that need to be
addressed in order to move forward with IDN ccTLDs associated with the ISO
3166-1 two-letter codes in a manner that ensures the continued security and
stability of the Internet. The Board requested status reports regarding
progress by the conclusion of the ICANN meeting in Los Angeles in October
2007.

ALAC is hereby respectfully presenting to the Board the status report, which
synchronizes the comprehensive discussions and comments from the user
community (please refer to ALAC IDN Working Group). ALAC appreciates and
cherishes all the contributions and reiterates the commitment to work
collaboratively with other constituencies, including the GNSO, ccNSO and
GAC, to explore both an interim and an overall approach to IDN ccTLDs
associated with the ISO 3166-1 two-letter codes.

Q.1: Which ‘territories’ are eligible for an IDN ccTLD?

Despite its problems, the ISO-3166 two-letter code list is the least
controversial definition of cc available. So we believe that this list
should serve for the moment until consensus on another definition is
reached. This does not mean that ALL those listed need to implement IDNs.

Q.2: Should an IDN ccTLD string be "meaningful"?

The word 'meaningful' should be interpreted to mean describing the
territory, economy or country specified by the two-letter code. In this
narrow sense the answer should be yes. We are not referring to acquired
secondary, often commercial, meanings attached to certain ccTLDs not
describing the intended territory.

Q.3: How many IDN ccTLDs per script per territory?

One should aim for just one IDN string per per script per territory at the
first stage in order to get the project moving. There may be cases where
different languages within a given territory use the same script and have
different representations for the territory name in that script. In such
cases, if there is demonstrated demand for more than one IDN, one
possibility is to 'bundle' the various representations as one IDN ccTLD.
This would involve having more than one representation in the root but
should solve the local problem.

Q.4: How many scripts per territory?

The number should eventually be decided by the local Internet Community
through sufficient, transparent and multi-stakeholder consultation
mechanism. IDNs are designed to serve the people who use the specific
scripts other than ASCII. Without prejudice to the ICANN IDN Guidelines on
technical constraint, non-ASCII script users should have the freedom to
decide whether to reflect thier native scripts in the DNS. However,
realization of this final and idealistic solution will be a long process
involving complicated technology and policy development. Given that
non-ASCII users have been waiting too long for IDN deployment, it is
suggested to adopt a fast-track experimental solution in the short term.
Under this short-term solution, the Internet community in each ccTLD
territory may choose only one IDN script for deployment. The one script
chosen should be out of genuine consensus of the local community, carefully
defined in terms of variants or homographs.

Q.5: Number of characters in the string?

This question is correlated to Q.2. Although ccTLDs in ASCII are expressed
in two-letter codes listed in ISO 3166, the number of charaters in IDN
ccTLDs cannot and should not be pre-defined. A ccTLD will be meaningless if
it cannot reflect the link with a certain territory. However, many ccTLDs,
once expressed in the non-script scripts, cannot reflect the territory links
in two-letter format. Forced abbreviations could cause confusion or even
distortion. Therefore, the number of characters in the IDN string should be
decided by the local Internet community and technically subject to the IDN
guidelines.

Q.6: Are there any ‘rights’ attached to a given script?

IDNs are not only online identifiers but non-English speaking people's
culture expression on the Internet. In IDN implementation, social
responsibility should outweigh commercial interests. In the long run, any
selection of IDN scripts or operation should be subject to the language
community's self-determination. Some language community has already been
well-organized, which defeats the suspicion that local community cannot be
defined. However, for the purpose of the fast-track experimental deployment,
some fast-track consultation mechanism may need to be created, such as
object or appeal system.
If the question means whether any priority right should be given any
language group where the script set is shared by several languages, no
rights or priorities should be given to any one language group using the
script. Where possible, variants of a script should be treated as separate
scripts to avoid this problem, but then IDN implementation would require
measures to combat homographs and phishing.
CCTLDs--even IDN ccTLDs--should maintain the linkage with specific
territories and may well restrict registrations outside the territories.
Thus, it should be the language community within the territory of a ccTLD
that are consulted for the IDN ccTLD matching to that ccTLD. Given the
unique territorial nature of CCTLDs, even in share-script circumstance, IDNs
for ccTLDs should not be a big problem among the language communities that
share some scripts in different ccTLD territories because their IDN ccTLDs
must be in different stings anyway. What's important that one ccTLD should
not be entitled to interfere the selection of IDN ccTLD in another territory
that use the same scripts or share some scripts.

Q.7: Should a list of IDN ccTLD strings be mandated?

A universal mandating should not be implemented at the initial stage. Users
have the right to use IDNs rather than a duty to do so. Neither the
automatically converting ISO 3166 into an IDN list solution is far from
being realistic: this would impose some ccTLDs that have no demand for IDN
use to implement them, which is obviously contradictory to the purpose of
IDNs. Also, compiling a mandatory list would slow down the IDN development
process. The crucial question at this stage is how the local community
consensus can be reached in case IDN implementation is necessary.
One solution to that is the proposal by APTLD, which states that it is
important to allow each interested existing ccTLD to propose ONE string and
provide six months for Internet community at Large including the ‘affected’
Communities and Governments to voice possible objections and/or comments. If
no serious reservations are aired then the string may go into the root.
However, even though a list of IDN ccTLD can be complied through the
one-string-one-ccTLD approach it cannot be a final solution, and if made
mandatory, it will cause serious rivalry between different script users in
one ccTLD territory. Issues related to that include: What makes one script
may be chosen over others in a multiple-script ccTLD territory? Is this
reflected in the local cultural or social policy/strategy? How those
minority script users can protest against this and will they protest?

Q.8: Who picks a string for a territory in the absence of a mandated list?

As stated in the Q7, each existing ccTLD should be allowed to propose one
string and to provide six months for the Internet Community at Large to
express their views/concerns/comments. It is mandatory to include the local
community in the consultation process in deciding the string. Public
review/objections regarding the proposed ccTLDs strings should be opened and
transparent.

Q.9: What coordination should exist between the different actors?

There is no doubt that coordination of the main issues related to IDN ccTLD
strings is needed. One of the most important aspects in this coordination
process would be a proper balance between the general rules vs. level of
autonomy at the "territory" level. At the initial stage, there can be
implemented a bottom-up vs. informal coordination model, which based on the
Lessons learned vs. Good models would further develop into more
global/formal coordination model if needed.

Q.10: Who can apply to have the IDN ccTLD delegated or to be the delegate
for that ccTLD and,who decides on the delegation?

CcTLD Manager ( Sponsoring Organization ) should have the right to apply for
a delegation of IDN ccTLD, while ICANN should ensure that the local internet
community has been consulted and that a local multi-stakeholder agreement
have been reached on the IDN ccTLD Delegation and the public policies issue
related to IDN ccTLD.

Q.11: Should there be an agreement between ICANN and the IDN ccTLD operator
on the operation of the IDN ccTLD string?

This Question looks simple but represent a very complex and sensitive issue,
IDN ccTLD operators should agree to a set of rules and operational
guidelines to be followed in order to insure stability and interoperability
of the DNS.

Q.12: Is the operation and management of an IDN ccTLD different to that of
an existing ccTLD? Such that there be specific global technical requirements
related to running the IDN ccTLD?

Due to the Language and cultural sensitivity, in both Technical and
administrative aspects the operation of an IDN ccTLD might be slightly
different from the management of existing ccTLD, in order ensure consistency
and stability the preference should be that the existing ccTLD operator
could be the new IDN ccTLD operator unless the local internet community have
objections on the current ccTLD operator and requested a delegation of IDN
ccTLD to a new sponsoring organization.


=========================================================================
Carlton A. Samuels
CIO & University Director of IT
c/o MITS, The UWI at Mona
5 Gibraltar Camp Way, Kgn 7
Mobile: (876) 818-1799
Work:   (876) 927-2148


-------> [PORTUGUESE] TRADUCAO AUTOMATICA NAO REVISADA DO ORIGINAL EM inglês

Caros Colegas:

Aqui seguindo, a indicação cheia de ALAC em IDNs entregada à placa
de ICANN. A indicação está disponível como um original do pdf em
inglês do wiki.

Consideração amável, Carlton
Na reunião de ICANN San Juan em julho 2007, a placa pediu que aquela
a comunidade de ICANN including o GNSO, ccNSO, GAC, e ALAC fornece a
placa com as respostas à lista publicada das edições e as perguntas
que necessitam ser dirigidas a fim se mover para a frente com ccTLDs
de IDN associou com os códigos two-letter do ISO 3166-1 em uma
maneira que assegurasse a segurança e a estabilidade continuadas do
Internet. A placa pediu os relatórios de status a respeito do
progresso pela conclusão da reunião de ICANN em Los Angeles em
outubro 2007.

ALAC por este meio está apresentando respectfully à placa o
relatório de status, que sincroniza as discussões e os comentários
detalhados da comunidade de usuário (consulte por favor ao grupo de
funcionamento de ALAC IDN). ALAC aprecia e estima todas as
contribuições e reiterates o compromisso para trabalhar
collaboratively com outros círculos eleitorais, including o GNSO, o
ccNSO e o GAC, para explorar  um ínterim e uma aproximação total
aos ccTLDs de IDN associados com os códigos two-letter do ISO 3166-1.

Q.1: Qual ' os territórios são elegíveis para um ccTLD de IDN?

Apesar de seus problemas, a lista de códigos ISO-3166 two-letter é
menos definição controversa do centímetro cúbico disponível.
Assim nós acreditamos que esta lista deve servir para o momento até
que o consenso em uma outra definição esteja alcançado. Isto não
significa que TODO O aqueles alistaram a necessidade executar IDNs.

Q.2: Deve uma corda do ccTLD de IDN ser "significativa"?

A palavra ' significativa ' deve ser interpretada para significar a
descrição do território, da economia ou do país especificados pelo
código two-letter. Neste sentido estreito a resposta deve ser yes.
Nós não estamos consultando a secundário adquirido, frequentemente
comercial, os meanings unidos a determinados ccTLDs que não descrevem
o território pretendido.

Q.3: Quantos ccTLDs de IDN por o certificado por o território?

Um deve apontar para apenas uma corda de IDN por por o certificado por
o território no primeiro estágio a fim começar mover-se do projeto.
Pode haver os casos onde línguas diferentes dentro de um uso dado do
território o mesmo certificado e tem respresentações diferentes
para o nome do território nesse certificado. Nesses casos, se houver
uma demanda demonstrada para mais de um IDN, uma possibilidade deve '
empacotar ' as várias respresentações como um ccTLD de IDN. Isto
envolveria ter mais de uma respresentação na raiz mas deve resolver
o problema local.

Q.4: Quantos certificados por o território?

O número deve eventualmente ser decidido pela comunidade local do
Internet através do mecanismo suficiente, transparente e da
multi-parte interessada do consultation. IDNs é projetado servir aos
povos que usam os certificados específicos à excepção do ASCII.
Sem preconceito aos guidelines de ICANN IDN no confinamente técnico,
os usuários do certificado de non-ASCII devem ter a liberdade para
decidir-se se refletir certificados nativos mais thier no DNS.
Entretanto, o realization desta solução final e idealistic será um
processo longo que envolve desenvolvimento complicado da tecnologia e
de política. Dado que os usuários de non-ASCII têm esperado
demasiado longo pela distribuição de IDN, sugere-se para adotar uma
solução experimental da rápido-trilha no termo curto. Sob esta
solução a curto prazo, a comunidade do Internet em cada território
do ccTLD pode escolher somente um certificado de IDN para a
distribuição. O um certificadoescolhido deve ser fora do consenso genuíno da comunidade local,
definido com cuidado nos termos dos variants ou dos homógrafos.

Q.5: Número dos caráteres na corda?

Esta pergunta é correlacionada a ccTLDs de Q.2. Embora no ASCII seja
expressado nos códigos two-letter alistados em ISO 3166, o número
dos charaters em ccTLDs de IDN não pode e não deve ser predefinido.
Um ccTLD será sem sentido se não puder refletir a ligação com um
determinado território. Entretanto, muitos ccTLDs, expressados uma
vez nos certificados do non-certificado, não podem refletir as
ligações do território no formato two-letter. As abreviaturas
forçadas podiam causar a confusão ou mesmo a distorção.
Conseqüentemente, o número dos caráteres na corda de IDN deve ser
decidido pela comunidade e tècnica pelo assunto locais do Internet
aos guidelines de IDN.

Q.6: Há alguma ' direita unida a um certificado dado?

IDNs é não somente identificadores em linha mas expressão da
cultura do pessoa falador non-Inglês no Internet. Na execução de
IDN, a responsabilidade social deve compensar interesses comerciais. A
longo prazo, toda a seleção de certificados de IDN ou a operação
devem ser sujeita ao self-determination da comunidade da língua.
Alguma comunidade da língua bem-tem sido organizada já, que derrota
a suspeita que a comunidade local não pode ser definida. Entretanto,
a fim a distribuição experimental da rápido-trilha, algum mecanismo
do consultation da rápido-trilha pode necessitar ser criado, como o
sistema do objeto ou da apelação. Se a pergunta significar se
qualquer direita da prioridade deve ser dada qualquer grupo da língua
onde o jogo do certificado é compartilhado por diversas línguas,
nenhuma direita ou prioridade devem ser dadas a qualquer um grupo da
língua usando o certificado. Onde possível, os variants de um
certificado devem ser tratados como os certificados separados para
evitar este problema, mas então a execução de IDN requereria
medidas combater homógrafos e phishing. CCTLDs -- mesmo ccTLDs de IDN
-- deve manter o enlace com territórios específicos e pode jorrar
restringe registos fora dos territórios. Assim, deve ser a comunidade
da língua dentro do território de um ccTLD que é consultado para o
ccTLD de IDN que combina a esse ccTLD. Dado a natureza territorial
original de CCTLDs, uniforme na circunstância do parte-certificado,
IDNs para ccTLDs não deve ser um problema grande entre as comunidades
da língua que compartilham de alguns certificados em territórios
diferentes do ccTLD porque seus ccTLDs de IDN devem estar em stings
diferentes de qualquer maneira. O que é importante que um ccTLD não
deve ser intitulado para interferir a seleção do ccTLD de IDN em um
outro território que usa os mesmos certificados ou compartilhe de
alguns certificados.

Q.7: Deve uma lista de cordas do ccTLD de IDN ser exijida?

Exijir do universal não deve ser executado no estágio inicial. Os
usuários têm a direita usar IDNs melhor que um dever fazer assim.
Nenhum o ISO automaticamente convertendo-se 3166 em uma solução da
lista de IDN é longe de ser realístico: isto imporia alguns ccTLDs
que não têm nenhuma demanda para que o uso de IDN os execute, que é
obviamente contradictory à finalidade de IDNs. Também, compilar uma
lista imperativa retardaria abaixo o processo do desenvolvimento de
IDN. A pergunta crucial neste estágio é como o consenso local da
comunidade pode ser alcançado caso que a execução de IDN é
necessária. Uma solução ao esse é a proposta por APTLD, que indica
que é importante permitir que cada ccTLD existente interessado
proponha UMA corda e forneça seis meses para a comunidade do Internet
em grande including as comunidades e os governos ' afetados ' às
objeções possíveis da voz e/ou comenta. Senenhum reservations sério é arejado então a corda pode entrar na
raiz. Entretanto, mesmo que uma lista do ccTLD de IDN possa complied
com a aproximação da um-corda-um-ccTLD não pode ser uma solução
final, e se feito imperativo, causar o rivalry sério entre usuários
diferentes do certificado em um território do ccTLD. As edições
relacionaram-se ao esse incluem: Que faz um certificado pode ser
escolhido sobre outro em um território do ccTLD do
múltiplo-certificado? Está isto refletido no policy/strategy
cultural ou social local? Como aqueles usuários do certificado do
minority podem protesto de encontro a este e protestarão?

Q.8: Quem escolhe uma corda para um território na ausência de uma
lista exijida?

Como indicado no Q7, cada ccTLD existente deve ser permitido propôr
uma corda e fornecer seis meses para a comunidade do Internet em
grande para expressar seu views/concerns/comments. É imperativo
incluir a comunidade local no processo do consultation em decidir a
corda. O público review/objections a respeito das cordas propostas
dos ccTLDs deve ser aberto e transparente.

Q.9: Que coordenação deve existir entre os atores diferentes?

Não há nenhuma dúvida que a coordenação das edições principais
relacionadas às cordas do ccTLD de IDN é needed. Um dos aspectos os
mais importantes neste processo da coordenação seria um contrapeso
apropriado entre as réguas gerais contra o nível da autonomia no
"território" em nível. No estágio inicial, lá pode ser executado
um bottom-up contra o modelo informal da coordenação, que baseou nas
lições aprendidas contra modelos bons se tornaria mais mais mais
modelo da coordenação de global/formal se necessitado.

Q.10: Quem pode se aplicar para ter o ccTLD de IDN delegado ou para
ser o delegado para esse ccTLD e, que se decide no delegation?

O gerente de CcTLD (organização patrocinando) deve ter a direita
aplicar-se para um delegation do ccTLD de IDN, quando ICANN dever se
assegurar de que a comunidade local do Internet esteja consultada e
que um acordo local da multi-parte interessada estêve alcançado no
delegation do ccTLD de IDN e na edição de políticas públicas
relacionados ao ccTLD de IDN.

Q.11: Deve haver um acordo entre ICANN e o operador do ccTLD de IDN na
operação da corda do ccTLD de IDN?

Esta pergunta olha simples mas representa um muito complexo e a
edição sensível, operadores do ccTLD de IDN deve concordar a um
jogo de réguas e dos guidelines operacionais a ser seguidos a fim
segurar a estabilidade e o interoperability do DNS.

Q.12: São a operação e a gerência de um ccTLD de IDN diferentes
àquela de um ccTLD existente? Tais que houvesse umas exigências
técnicas globais específicas relacionaram-se a funcionar o ccTLD de
IDN?

devido à língua e à sensibilidade cultural,  em aspectos técnicos
e administrativos a operação de um ccTLD de IDN pôde ser
ligeiramente diferente da gerência de ccTLD existente, em ordem
assegura a consistência e a estabilidade a preferência deve ser que
o operador existente do ccTLD poderia ser o operador novo do ccTLD de
IDN a menos que a comunidade local do Internet tiver objeções no
operador atual do ccTLD e pedir um delegation do ccTLD de IDN a uma
organização patrocinando nova.


=========================================================================
Carlton A. Samuels CIO & diretor da universidade dcEle c/o MITS, O UWI
na maneira do acampamento de Mona 5 Gibraltar, móbil de Kgn 7: (876)
trabalho 818-1799: (876) 927-2148


-------> [ESPAÑOL] TRADUCCIÓN AUTOMÁTICA NO REVISADA DEL ORIGINAL en ingles

Colegas Queridos:

Aquí siguiendo, la declaración completa de ALAC en IDNs entregada al
tablero de ICANN. La declaración está disponible como documento del
pdf en inglés del wiki.

Respeto bueno, Carlton
En la reunión de ICANN San Juan en julio de 2007, el tablero
solicitó que ése la comunidad de ICANN incluyendo el GNSO, ccNSO,
GAC, y ALAC provea del tablero respuestas a la lista publicada de
ediciones y las preguntas que necesitan ser tratadas para moverse
adelante con los ccTLDs de IDN se asoció a los códigos two-letter de
la ISO 3166-1 de una manera que asegura la seguridad y la estabilidad
continuadas del Internet. El tablero solicitó informes con respecto a
progreso por la conclusión de la reunión de ICANN en Los Ángeles en
octubre de 2007.

ALAC está presentando por este medio respetuosamente al tablero el
informe, que sincroniza las discusiones y los comentarios comprensivos
de la comunidad de usuario (refiera por favor al grupo de
funcionamiento de ALAC IDN). ALAC aprecia y acaricia todas las
contribuciones y reitera la comisión para trabajar de colaboración
con otros distritos electorales, incluyendo el GNSO, el ccNSO y el
GAC, explorar un interino y un acercamiento total a los ccTLDs de IDN
asociados a los códigos two-letter de la ISO 3166-1.

Q.1: ¿Cuál los ' territorios son elegibles para un ccTLD de IDN?

A pesar de sus problemas, la lista de código two-letter ISO-3166 es
la menos definición polémica del cc disponible. Creemos tan que esta
lista debe servir para el momento hasta que el consenso en otra
definición se alcanza. Esto no significa que TODO EL ésos enumeraron
necesidad de poner IDNs en ejecucio'n.

Q.2: ¿Debe una secuencia del ccTLD de IDN ser "significativa"?

La palabra ' significativa ' se debe interpretar para significar
describir el territorio, la economía o el país especificados por el
código two-letter. En este sentido estrecho la respuesta debe ser
sí. No estamos refiriendo a secundario adquirida, a menudo comercial,
los significados unidos a ciertos ccTLDs que no describen el
territorio previsto.

Q.3: ¿Cuántos ccTLDs de IDN por la escritura por territorio?

Uno debe apuntar para apenas una secuencia de IDN por por la escritura
por territorio a la primera etapa para conseguir la mudanza del
proyecto. Puede haber los casos donde diversas idiomas dentro de un
uso dado del territorio la misma escritura y tiene diversas
representaciones para el nombre del territorio en esa escritura. En
tales casos, si hay demanda demostrada para más de un IDN, una
posibilidad es ' liar ' las varias representaciones como un ccTLD de
IDN. Esto implicaría el tener de más de una representación en la
raíz pero debe solucionar el problema local.

Q.4: ¿Cuántas escrituras por territorio?

El número se debe decidir eventual por la comunidad local del
Internet a través del mecanismo suficiente, transparente y del
multi-tenedor de apuestas de la consulta. IDNs se diseña para servir
a la gente que utiliza las escrituras específicas con excepción del
ASCII. Sin prejuicio alguno para las pautas de ICANN IDN en
constreñimiento técnico, los usuarios de la escritura de non-ASCII
deben tener la libertad para decidir si reflejar escrituras nativas
ma's thier en el DNS. Sin embargo, la realización de esta solución
final e idealista será un proceso largo que implica el desarrollo
complicado de la tecnología y de política. Dado que los usuarios de
non-ASCII han estado esperando demasiado largo el despliegue de IDN,
se sugiere para adoptar una solución experimental de la ra'pido-pista
en corto plazo. Bajo esta solución a corto plazo, la comunidad del
Internet en cada territorio del ccTLD puede elegir solamente una
escritura de IDN para el despliegue. La una escrituraelegido debe estar fuera del consenso genuino de la comunidad local,
definido cuidadosamente en términos de variantes o de homógrafos.

Q.5: ¿Número de caracteres en la secuencia?

Esta pregunta se correlaciona a los ccTLDs de Q.2. expresan Although
en el ASCII en los códigos two-letter enumerados en ISO 3166, el
número de charaters en ccTLDs de IDN no puede y no debe ser
predefinido. Un ccTLD será sin setido si no puede reflejar el
acoplamiento con cierto territorio. Sin embargo, muchos ccTLDs,
expresados una vez en las escrituras de la no-escritura, no pueden
reflejar los acoplamientos del territorio en formato two-letter. Las
abreviaturas forzadas podían causar la confusión o aún la
distorsión. Por lo tanto, el número de caracteres en la secuencia de
IDN se debe decidir por la comunidad local del Internet y técnico
conforme a las pautas de IDN.

Q.6: ¿Hay las ' derechas unidas a una escritura dada?

IDNs es no solamente identificadores en línea pero expresión de la
cultura de la gente de discurso no-Inglesa en el Internet. En la
puesta en práctica de IDN, la responsabilidad social debe compensar
intereses comerciales. En el funcionamiento largo, cualquier
selección de las escrituras de IDN o la operación debe estar
conforme a la autodeterminación de la comunidad de la lengua.
Bien-han organizado a una cierta comunidad de la lengua ya, que
derrota la suspicacia que la comunidad local no puede ser definida.
Sin embargo, con el fin el despliegue experimental de la
ra'pido-pista, un cierto mecanismo de la consulta de la ra'pido-pista
pueda necesitar ser creado, por ejemplo sistema del objeto o de la
súplica. Si la pregunta significa si la cualquier derecha de la
prioridad se debe dar al cualquier grupo de la lengua donde el sistema
de la escritura es compartido por varias idiomas, las ningunas
derechas o prioridades se deben dar a cualquier un grupo de la lengua
usando la escritura. En lo posible, las variantes de una escritura se
deben tratar como escrituras separadas para evitar este problema, pero
entonces la puesta en práctica de IDN requeriría medidas de combatir
homógrafos y phishing. CCTLDs -- incluso ccTLDs de IDN -- debe
mantener el acoplamiento con los territorios específicos y puede
manar restringe registros fuera de los territorios. Así, debe ser la
comunidad de la lengua dentro del territorio de un ccTLD que se
consulta para el ccTLD de IDN que empareja a ese ccTLD. Dado la
naturaleza territorial única de CCTLDs, uniforme en circunstancia de
la parte-escritura, IDNs para los ccTLDs no debe ser un problema
grande entre las comunidades de la lengua que comparten algunas
escrituras en diversos territorios del ccTLD porque sus ccTLDs de IDN
deben estar en diversas picaduras de todos modos. Cuál es importante
que un ccTLD no se debe dar derecho para interferir la selección del
ccTLD de IDN en otro territorio que utiliza las mismas escrituras o
comparta algunas escrituras.

Q.7: ¿Debe una lista de las secuencias del ccTLD de IDN ser asignada
por mandato?

Un mandato por mandato del universal no se debe poner en ejecucio'n en
la etapa inicial. Los usuarios tienen la derecha de utilizar IDNs más
bien que un deber para hacer tan. Ni uno ni otro la ISO
automáticamente que convierte 3166 en una solución de la lista de
IDN está lejos de ser realista: esto impondría algunos ccTLDs que no
tienen ninguna demanda para que el uso de IDN los ponga en ejecucio'n,
que es obviamente contradictorio al propósito de IDNs. También, la
compilación de una lista obligatoria retrasaría el proceso del
desarrollo de IDN. La pregunta crucial es en esta etapa cómo el
consenso local de la comunidad puede ser alcanzado en caso de que la
puesta en práctica de IDN sea necesaria. Una solución a ese es la
oferta por APTLD, que indica que es importante permitir que cada ccTLD
existente interesado proponga UNA secuencia y proporcione seis meses
para la comunidad del Internet en grande incluyendo las comunidades y
los gobiernos ' afectados ' a las objeciones posibles de la voz y/o
comenta. Sino se ventila ningunas reservaciones serias entonces la secuencia
pueden entrar la raíz. Sin embargo, aunque una lista del ccTLD de IDN
se puede conformar con el acercamiento de la uno-secuencia-uno-ccTLD
no puede ser una solución final, y si está hecho obligatorio, causa
rivalidad seria entre diversos usuarios de la escritura en un
territorio del ccTLD. Las ediciones se relacionaron con ese incluyen:
¿Qué hace una escritura se puede elegir sobre otras en un territorio
del ccTLD de la mu'ltiple-escritura? ¿Está esto reflejada en el
policy/strategy cultural o social local? ¿Cómo esos usuarios de la
escritura de la minoría pueden protesta contra esto y protestarán?

Q.8: ¿Quién escoge una secuencia para un territorio en ausencia de
una lista asignada por mandato?

Según lo indicado en el Q7, cada ccTLD existente se debe permitir
proponer una secuencia y proporcionar seis meses para la comunidad del
Internet en grande para expresar su views/concerns/comments. Es
obligatorio incluir a la comunidad local en el proceso de la consulta
en decidir a la secuencia. El público review/objections con respecto
a las secuencias propuestas de los ccTLDs debe ser abierto y
transparente.

Q.9: ¿Qué coordinación debe existir entre los diversos agentes?

No hay duda que la coordinación de los puntos principales
relacionados con las secuencias del ccTLD de IDN es necesaria. Uno de
los aspectos más importantes de este proceso de la coordinación
sería un equilibrio apropiado entre las reglas generales contra el
nivel de la autonomía en el "territorio" llano. En la etapa inicial,
allí se puede poner en ejecucio'n un bottom-up contra el modelo
informal de la coordinación, que basó en las lecciones aprendidas
contra buenos modelos se convertiría más lejos en más modelo de la
coordinación de global/formal si estuvo necesitado.

Q.10: ¿Quién puede aplicarse para hacer el ccTLD de IDN delegar o
para ser el delegado para ese ccTLD y, que decide sobre la
delegación?

El encargado de CcTLD (organización que patrocina) debe tener la
derecha de solicitar una delegación del ccTLD de IDN, mientras que
ICANN debe asegurarse de que hayan consultado a la comunidad local del
Internet y de que un acuerdo local del multi-tenedor de apuestas se ha
alcanzado en la delegación del ccTLD de IDN y la edición de los
órdenes públicos relacionadas con el ccTLD de IDN.

Q.11: ¿Debe haber un acuerdo entre ICANN y el operador del ccTLD de
IDN en la operación de la secuencia del ccTLD de IDN?

Esta pregunta parece simple pero representa un muy complejo y la
edición sensible, operadores del ccTLD de IDN debe convenir un
sistema de reglas y de pautas operacionales que se seguirán para
asegurar estabilidad y la interoperabilidad del DNS.

Q.12: ¿Es la operación y la gerencia de un ccTLD de IDN diferentes a
la de un ccTLD existente? ¿Tales que haya requisitos técnicos
globales específicos se relacionaron con el funcionamiento del ccTLD
de IDN?

debido a la lengua y a la sensibilidad cultural, en aspectos técnicos
y administrativos la operación de un ccTLD de IDN pudo ser levemente
diferente de la gerencia del ccTLD existente, en orden asegura
consistencia y la estabilidad la preferencia debe ser que el operador
existente del ccTLD podría ser el nuevo operador del ccTLD de IDN a
menos que la comunidad local del Internet tenga objeciones en el
operador actual del ccTLD y solicitara a delegación del ccTLD de IDN
a una nueva organización que patrocina.


=========================================================================
Carlton A. Samuels CIO y director de la universidad de ÉL c/o MITS,
El UWI en la manera del campo de Mona 5 Gibraltar, móvil de Kgn 7:
(876) trabajo 818-1799: (876) 927-2148




Intercomprehension aid service 
 Check the rules for better use: http://funredes.org/tradauto/index.htm/rules 

Serviço do dae de compreensão 
 Verificar as réguas para o uso melhor: http://funredes.org/tradauto/index.htm/reguas 

Servicio de ayuda a la intercomprensión 
 Leer las reglas para un mejor uso: http://funredes.org/tradauto/index.htm/reglas