[CPWG] [registration-issues-wg] URGENT - WT5 proposal for 3-letter country codes

Sun Aug 19 20:58:52 UTC 2018

I thank you for outlining these facts sah.

-Carlton

On Sun, 19 Aug 2018, 12:15 pm Yrjö Länsipuro, <yrjo_lansipuro at hotmail.com>
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 at atlarge-lists.icann.org> on behalf of Greg
> Shatan <greg at isoc-ny.org>
> *Sent:* Saturday, August 18, 2018 2:05 AM
> *To:* Carlton Samuels
> *Cc:* cpwg at 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 at 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 at 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 at gmail.com>
> wrote:
>
>
>
> On Sun, Aug 12, 2018 at 12:14 AM Maureen Hilyard <
> maureen.hilyard at 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 at icann.org
> https://mm.icann.org/mailman/listinfo/cpwg
> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fcpwg&data=02%7C01%7C%7C71922f12645840e0b6a608d604fb1715%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636701873798768392&sdata=APUDV7sSQZbVFFQGBXmroQRq4t0eEK3pl0FhwGQ%2FR7s%3D&reserved=0>
> _______________________________________________
> registration-issues-wg mailing list
> registration-issues-wg at atlarge-lists.icann.org
> https://mm.icann.org/mailman/listinfo/registration-issues-wg
> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fregistration-issues-wg&data=02%7C01%7C%7C71922f12645840e0b6a608d604fb1715%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636701873798768392&sdata=XdXj7ryce%2FWs%2FJhCDPIKtXe6R6WPsCHZ%2BuDn0BBiQSI%3D&reserved=0>
>
>
>
> --
> Sivasubramanian M
> Please send all replies to 6.Internet at gmail.com
>
> _______________________________________________
> CPWG mailing list
> CPWG at icann.org
> https://mm.icann.org/mailman/listinfo/cpwg
> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fcpwg&data=02%7C01%7C%7C71922f12645840e0b6a608d604fb1715%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636701873798768392&sdata=APUDV7sSQZbVFFQGBXmroQRq4t0eEK3pl0FhwGQ%2FR7s%3D&reserved=0>
>
> _______________________________________________
> CPWG mailing list
> CPWG at icann.org
> https://mm.icann.org/mailman/listinfo/cpwg
> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fcpwg&data=02%7C01%7C%7C71922f12645840e0b6a608d604fb1715%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636701873798768392&sdata=APUDV7sSQZbVFFQGBXmroQRq4t0eEK3pl0FhwGQ%2FR7s%3D&reserved=0>
> _______________________________________________
> registration-issues-wg mailing list
> registration-issues-wg at atlarge-lists.icann.org
> https://mm.icann.org/mailman/listinfo/registration-issues-wg
> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fregistration-issues-wg&data=02%7C01%7C%7C71922f12645840e0b6a608d604fb1715%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636701873798768392&sdata=XdXj7ryce%2FWs%2FJhCDPIKtXe6R6WPsCHZ%2BuDn0BBiQSI%3D&reserved=0>
>
> _______________________________________________
> CPWG mailing list
> CPWG at icann.org
> https://mm.icann.org/mailman/listinfo/cpwg
> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fcpwg&data=02%7C01%7C%7C71922f12645840e0b6a608d604fb1715%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636701873798924646&sdata=tefFdq9s2ROK22bsz3B%2BB2eX0ShxHumqtwn6iuPA3No%3D&reserved=0>
> _______________________________________________
> registration-issues-wg mailing list
> registration-issues-wg at atlarge-lists.icann.org
> https://mm.icann.org/mailman/listinfo/registration-issues-wg
> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fregistration-issues-wg&data=02%7C01%7C%7C71922f12645840e0b6a608d604fb1715%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636701873798924646&sdata=J3gEzfwidT2dFMv5aAXSu3t0iPUbZL4s1zbBLV3tAXc%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cpwg/attachments/20180819/ea5990e8/attachment-0001.html>