[CPWG] [registration-issues-wg] URGENT - WT5 proposal for 3-letter country codes
Marita Moll
mmoll at ca.inter.net
Sun Aug 19 18:56:02 UTC 2018
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 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 <mailto: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 <mailto: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 <mailto:6.Internet at gmail.com>> wrote:
>
>
>
> On Sun, Aug 12, 2018 at 12:14 AM Maureen Hilyard
> <maureen.hilyard at gmail.com
> <mailto: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 <mailto: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
> <mailto: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
> <mailto:6.Internet at gmail.com>
>
> _______________________________________________
> CPWG mailing list
> CPWG at icann.org <mailto: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 <mailto: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
> <mailto: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 <mailto: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
> <mailto: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>
>
>
>
> _______________________________________________
> CPWG mailing list
> CPWG at icann.org
> https://mm.icann.org/mailman/listinfo/cpwg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cpwg/attachments/20180819/61e7063b/attachment-0001.html>
More information about the CPWG
mailing list