Indeed. I echo your thought.
Very well written by Yrjo.
Best Regards,
Anupam Agrawal
| ISO/IEC JTC1 SC7 - Secretariat |
| Corporate Industry Forums & Standards Cell | Tata Consultancy
Services | T: +91 33 6636 8561; VOIP: 433 8561; M: +91
990 399 2838 |
From:
"Marita Moll"
<mmoll@ca.inter.net>
To:
cpwg@icann.org
Date:
20-08-2018 11:53
Subject:
Re: [registration-issues-wg]
[CPWG] URGENT - WT5 proposal for 3-letter country codes
Sent by:
"registration-issues-wg"
<registration-issues-wg-bounces@atlarge-lists.icann.org>
Excellent points. Some of these
abbreviations become so common we don't even see them anymore. They are
just there and we know intuitively what they stand for. Thank you.
Marita
On 8/19/2018 7:15 PM, Yrjö Länsipuro wrote:
Dear Greg, all,
The geo-use of ISO 3166 3-letter
codes today includes many applications that come pretty close to
the end-user. One can assume a certain level of awareness of them and of
their connection to the relevant countries, especially to one's own.
All machine-readable travel documents (passport,
visas) indicate the nationality of the bearer using the ISO-3166
3-letter code.
The International Olympic Committee
uses ISO 3166 3-letter code for teams from 129 countries, FIFA for
teams from 152 countries.
For 27 countries, the international car
licence plate code equals the ISO 3166 3-letter code.
ISO 3166 3-letter code is also used for
countries by World Integrated Trade Solutions databases, which serve
the World Bank, WTO, UNCTAD, UN Statistical Commission, International Trade
Centre... A few end-users there, too.
Using ISO 3166 3-letter codes as TLD's
not connected with the relevant country would inevitably invite end user
confusion.
Best,
Yrjö
From: registration-issues-wg <registration-issues-wg-bounces@atlarge-lists.icann.org>
on behalf of Greg Shatan <greg@isoc-ny.org>
Sent: Saturday, August 18, 2018 2:05 AM
To: Carlton Samuels
Cc: cpwg@icann.org
Subject: Re: [registration-issues-wg] [CPWG] URGENT - WT5 proposal
for 3-letter country codes
Carlton,
I think you are thinking about ISO-3166 in a way that doesn’t reflect
the history, as I understand what happened. When the idea of country-related
TLDs came up, nobody wanted ICANN (and its predecessors) to be “in the
business” of deciding what is or isn’t a country, nor did they want to
get into the business of inventing or deciding what constituted the appropriate
country-related TLD (or to resolve possible overlaps like Austria/Australia).
So they “borrowed” the ISO 3166 list of countries and territories to
deal with the first issue, and they borrowed the ISO-3166 2-letter codes
to resolve the second issue. The 3-letter codes were just left alone and
were never part of the TLD discussion, TLD policy, etc.
So, rather than this being a restriction of some previously decided matter,
we are really talking about an expansion beyond the 2-letter codes by affirmatively
assigning ISO 3166 3 letter codes a new formal role in TLD policy and decision-making.
It also means we would be making a geo-friendly value judgment regarding
the relative merits of various possible TLD uses for 3-letter strings that
have other meanings and also function as 3-letter codes. So, the jam band
community and the jazz jam session community and the jam manufacturers
(and home jam makers) all become second-class behind Jamaica, which already
has a 2-letter ccTLD and other options (.JAMAICA, for instance). Maybe
these are not particularly compelling alternatives, but consider .IOT,
with the Internet of Things such a burgeoning area of Internet expansion....
I don’t have a neat suggestion to end this with, but we do need to face
the issue of whether, for end users, the potential geo-use is always the
most beneficial.
Best regards,
Greg
On Thu, Aug 16, 2018 at 12:29 PM Carlton
Samuels <carlton.samuels@gmail.com>
wrote:
Very interesting indeed.
SO ISO 3166-1 defined three (3) sets of
country codes; 2-letter, 3-letter, and 3-digit.
ISO 3166-1 is the authoritative baseline
for country coded TLDs. So now, the proposition is that we accept that
this baseline is restricted purely to the use of the 2-letter codes. Question
is, why so?
If I were a ccTLD administrator and since
this is so much like the land grab of that time, I would have been forced
to paraphrase and grouse as allegedly the Bourbon King of France did at
the Treaty of Tordesillas " am I not a Christian and a Prince?"
[Disclosure: At one time I was the one with the binding authority at .jm].
My previous attempt to pass on my own view
with a tongue-firmly-in-cheek reference to 'jam' seems to have missed the
mark. So now, let me be crystal clear. I am for a blanket reservation of
all strings pertaining ISO 3166-1 with those already delegated grandfathered.
Why, anything else will only encourage speculation like my proposal to
go to the Prime Minister of Jamaica and ask his support for delegating
the 3-letter code for Jamaica - 'jam' - to me. It is a opportunity that
is pregnant with gaming possibilities. But that might be too firm and a
bridge to far for all to accept.
So, I can live with my friend Carlos Guiterrez's
proposed language; not totally satisfying but close enough to principle
for an embrace.
-Carlton
==============================
Carlton A Samuels
Mobile: 876-818-1799
Strategy, Process, Governance, Assessment & Turnaround
=============================
On Tue, Aug 14, 2018 at 9:16 PM Justine
Chew <justine.chew@gmail.com>
wrote:
These are my thoughts on the issue of ISO
3166-1 3-letter codes:
I too believe that WT5 is fully competent to deal with the issue
of whether, when and how strings identical to the existing ISO 3166 3-letter
codes could be applied for and delegated, though at the rate WT5 is going,
the position may very well end in a recommendation that it be chartered
for deliberation by (yet) a(nother) GNSO PDP WG.
Notwithstanding,
3-letter strings on ISO 3166-1 standard
I don't believe it is desirable for any un-delegated 3-letter strings currently
on the ISO 3166-1 standard to remain unavailable for application in the
next round. However, I am not convinced that an outright claim can
be made that "there is no "tradition" of ISO 3166-1
3-letter codes being used for top level domain names connected with the
related countries and territories". Jorge Cancio suggested
that Switzerland does (in some way) and also some of these codes overlap
with others, eg those used by the IOC in the Olympic Games.
In any case, I take the view that by virtue of ICANN being represented
on the ISO 3166-1 Maintenance Agency, there should be at the very least,
some moral obligation by ICANN to recognise and treat (in the first instance)
all such 3-letter strings which exactly match the ISO 3166-1 3-letter codes
as a representation of the corresponding assigned country.
I have also noted that exceptions need to be considered -- as in the case
of the Union of Comoros, for which ".com" is no longer available
-- for which an alternative 3-letter string should be made available for
application by applicants who either represent the Union of Comoros or
which received letters of support/non-objection from the Union's government
should they wish to apply for a 3-letter string for a purpose associated
with the Union. This exception would also need to be made available for
any country that is put onto an updated ISO 3166-1 standard, where
the assigned 3-letter code is no longer available.
As for 3-letter codes which also have generic meanings or said to be subject
to lost opportunities, I think 3-letter code country designations should
be prioritised -- think of them as "superlative" special nouns.
So as an eg .IOT, would be a "superlative" special noun of the
British Indian Ocean Territory, superlative to the special noun of The
Internet of Things. In other words, country names trumps everything else,
and accordingly, the concept of intended use does not apply.
As to who should be allowed to apply, in sharing concerns for terms which
have not been defined by Carlos per se, I too am concerned about who is
meant by "public interest/public benefit entities"; that could
be any entity, as Greg suggests, which claims to act in public interest/public
benefit. In this respect, on using the relatively successful cases of city
name gTLD applications as inspiration, I don't see the harm in opening
up application to anyone/any entity whereupon the " relevant government
or public authority or ccTLD manager" can also apply and if there
is contention, then curative mechanisms already in place kick in to assist
in resolution of such contention. In the same breath, if an entity
which is not the "relevant government or public authority or ccTLD
manager" applies, then that application should be subject to the requirement
for a letter or support or non-objection from the relevant government or
public authority. This could in my opinion best facilitate the application
for 3-letter strings which match ISO 3166-1 3-letter codes under a preventive
and curative 'safeguards' framework.
Also there is nothing to say that the relevant government or public
authority and an applicant cannot arrive to some understanding in respect
of the application, including terms and conditions of the gTLD (downstream
even) should the application be successful. The kind of partnership framework
which Maureen reminded us of is an appealing resolution mechanism. Of course,
this would depend on the attitudes of the parties concerned, but don't
other things suffer the same fate? Also, the suggestion of time limits
for response by a government or public authority is a good one IMO.
Perhaps, to facilitate (if one must insists upon it) a 'prioritisation'
of applications by a "relevant government or public authority
or ccTLD manager", I wonder if a Sunrise Period would be a feasible
option. Possibly a difficult consideration, since application windows are
typically tight as it is, not to mention the need for effective pre-launch
marketing.
Lastly, I too don't wish to wade into the discussion of 'expanding the
territory of ccTLDs' -- it is clear in my mind that all 3-letter strings
(whether they match ISO 3166-1 3-letter codes or not) would be treated
as gTLDs and not ccTLDs. The realm of ccTLDs remains in the 2-letter sphere.
3-letter strings NOT on ISO 3166-1 standard
I also don't believe it is desirable for any un-delegated 3-letter strings
NOT currently on the ISO 3166-1 standard to remain unavailable for application
in the next round. They should not be reserved and should be made
available for application, with a pre-defined resolution mechanism to deal
with exceptions arising out of changes to the ISO 3166-1 standard over
time.
Regards,
Justine Chew
-----
On Wed, 15 Aug 2018 at 03:44, Sivasubramanian
M <6.Internet@gmail.com>
wrote:
On Sun, Aug 12, 2018 at 12:14 AM Maureen
Hilyard <maureen.hilyard@gmail.com>
wrote:
Hi everyone
If you have been following the discussions
in WT5 you will see that there has been a lot of controversy over the GNSO
consensus process on Country and Territory Names and how best to come to
a decision on each of the key issues that are being discussed.
With regards to an agreement over 3-letter
country codes, Carlos Raul Gutierrez has proposed the following suggestion
to help this process move forward, I believe we should consider his proposal
as a reasonable compromise considering all the discussion that has taken
place and send our support (or otherwise) to our ALAC co-Chair. The ALAC
views could be coordinated by the CPWG leads but will be required by
Tuesday??.
This is urgent, as it appears that consensus
calls will be received by the co-Chairs during the week and as they
will have to prepare for the next WT5 meeting on the 22nd, it would be
good to include an ALAC opinion as well.
“Dear Annebeth,
As you have heard me (too) many times before,
I admire the track record of preceding, clearly focused public interest
3 letter geo-TLDs, like the ones from Catalonia in Spain, Brittany's in
France, and Serbia's 3 letter TLDs
Now that I re-stated my rationale for such
a clear-cut public interest case in an email to Rosalia (for geo use ONLY,
accessible -i.e. cheap- and non-profit), I hereby submit to the WT my final
revised language suggestion, which is ONLY applicable for 3-Letter codes.
It would substitute the following final paragraph in the relevant section
which deals with 3-Letter codes: “The SubPro may want to consider recommending
whether any future application/revision/delegation process to be established
(either generic or restricted to the Geographic categories only), should
determine if, when, and how specific interested parties, such as relevant
public international, national or sub-national public authorities, may
apply for country and territory names"
My suggestion for a FORWARD looking option
is:
“ICANN may only consider applications
of ISO 3166-1 Alpha 3 Letter Codes submitted by relevant governmental authorities,
ccTLD managers and public interest/public benefit entities.”
+1. And, as Alpha3
Letter Codes become a new stream of ccTLDs, ICANN could impress upon the
relevant local government authorities and ccTLD managers to agree on a
common minimum set of DNS rules, conventions and best practices in the
operation of this new stream of ccTLDs, as distinct from the 2 characters
country codes, some operated well, some not so well, some in tune with
the way the DNS works, some pulled in a different direction. Governments
are right in considering ccTLDs as their space, but in the past some ccTLDs
in some countries were transferred to external entities within or out of
their countries, some ccTLD went out of control irrespective of who operated
them; It became difficult for ICANN perhaps even promote Security and Stability
measures such as DNSSEC. If alpha3 codes are deemed as a new stream
of ccTLDs, it then becomes an opportunity for ICANN to delegate them as
a more integrated TLD class within the DNS, somewhere between the somewhat
detached 2 character ccTLD and the fully coordinated gTLDs. An example
result of such an approach would be an alpha3 application criteria that
might look for technical expertise or a contract with an accredited Registry
Service Provider with relevant ccTLD experience; while there may be more
elaborate criteria, the respective countries may have country specific
policies for operation of the alpha3 codes except where such national policies
are NOT in sharp contrast with the general principles of the DNS.
Sivasubramanian M
This paragraph is, in my view, a sensible
part of a forward-looking recommendation that could go ahead with broader
WT consensus. And if it does not, please make sure it is recorded as an
objection against a permanent restriction of the delegation of the ISO
3-Letter list.
Thanks to all,
Carlos Raúl Gutiérrez"
_______________________________________________
CPWG mailing list
CPWG@icann.org
https://mm.icann.org/mailman/listinfo/cpwg
_______________________________________________
registration-issues-wg mailing list
registration-issues-wg@atlarge-lists.icann.org
https://mm.icann.org/mailman/listinfo/registration-issues-wg
--
Sivasubramanian M
Please send all replies to 6.Internet@gmail.com
_______________________________________________
CPWG mailing list
CPWG@icann.org
https://mm.icann.org/mailman/listinfo/cpwg
_______________________________________________
CPWG mailing list
CPWG@icann.org
https://mm.icann.org/mailman/listinfo/cpwg
_______________________________________________
registration-issues-wg mailing list
registration-issues-wg@atlarge-lists.icann.org
https://mm.icann.org/mailman/listinfo/registration-issues-wg
_______________________________________________
CPWG mailing list
CPWG@icann.org
https://mm.icann.org/mailman/listinfo/cpwg
_______________________________________________
registration-issues-wg mailing list
registration-issues-wg@atlarge-lists.icann.org
https://mm.icann.org/mailman/listinfo/registration-issues-wg
_______________________________________________
CPWG mailing list
CPWG@icann.org
https://mm.icann.org/mailman/listinfo/cpwg
_______________________________________________
CPWG mailing list
CPWG@icann.org
https://mm.icann.org/mailman/listinfo/cpwg
_______________________________________________
registration-issues-wg mailing list
registration-issues-wg@atlarge-lists.icann.org
https://mm.icann.org/mailman/listinfo/registration-issues-wg
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you