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

Fri Aug 17 23:05:59 UTC 2018

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-1799Strategy, 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
>>>> _______________________________________________
>>>> registration-issues-wg mailing list
>>>> registration-issues-wg at atlarge-lists.icann.org
>>>> https://mm.icann.org/mailman/listinfo/registration-issues-wg
>>>>
>>>
>>>
>>> --
>>> 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
>>>
>> _______________________________________________
>> CPWG mailing list
>> CPWG at icann.org
>> https://mm.icann.org/mailman/listinfo/cpwg
>> _______________________________________________
>> registration-issues-wg mailing list
>> registration-issues-wg at atlarge-lists.icann.org
>> https://mm.icann.org/mailman/listinfo/registration-issues-wg
>>
> _______________________________________________
> CPWG mailing list
> CPWG at icann.org
> https://mm.icann.org/mailman/listinfo/cpwg
> _______________________________________________
> registration-issues-wg mailing list
> registration-issues-wg at atlarge-lists.icann.org
> https://mm.icann.org/mailman/listinfo/registration-issues-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cpwg/attachments/20180817/6922e908/attachment-0001.html>