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

Thu Aug 16 16:29:18 UTC 2018

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cpwg/attachments/20180816/268b7bb5/attachment-0001.html>