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

Tue Aug 14 08:02:34 UTC 2018

Sent from my mobile
Kindly excuse brevity and typos

On Tue, 14 Aug 2018, 07:46 Bastiaan Goslings, <bastiaan.goslings at ams-ix.net>
wrote:

>
> > On 14 Aug 2018, at 00:52, Seun Ojedeji <seun.ojedeji at gmail.com> wrote:
> >
> > On Mon, 13 Aug 2018, 13:08 Bastiaan Goslings, <
> bastiaan.goslings at ams-ix.net> wrote:
> > Hi Greg,
> >
> > Thanks a lot.
> >
> > Without having any knowledge when it comes to history/context/previous &
> ongoing (WT5) related discussions, the points you raise make sense to me.
> And until someone manages to convince me otherwise, I agree with you and
> therefore do not support Carlos’ recommendation.
> >
> > With regard to the:
> >
> > > Personally, I would be in favor of a recommendation that makes the
> current 3166 3-letter codes “unreserved" and open for applications, with a
> restriction that any application that seeks to associate the TLD with the
> related country or territory requires the consent or non-objection of that
> country or territory.
> >
> >
> > I do not know what this ‘restriction’ would look like specifically, but
> to me it almost sounds like you solved the .amazon case ;-)
> >
> > SO:  An applicant sure wouldn’t want to associate a TLD with a related
> country in his/her application if that will indeed pose a bottleneck for
> them, so I don't think Greg's proposal actually restrict anything in
> practice.
>
>
> Maybe, and that is why I made the reservation, not knowing what the
> restriction would (neet to) look like. It would of course have to be
> enforceable.
>

SO: Hence it still seem the proposal of Carlos may still be the closest
implementation scenario.

>
> > If the intent is to provide some level of restrictions then applicant
> certainly shouldn’t be a determinant of that.
>
>
> I have not given this any thought but I’d imagine one can make the
> requirement part of the application procedure and have the applicant sign
> for this. And if then later on the TLD can demonstrably be ‘associated with
> the related country or territory’ that would be a breach of contract and
> the applicant would no longer be allowed to run the TLD. And e.g. would not
> be entitled to a refund of the application fees.
>

SO: Hmm...I guess the extent of the "demonstration" needs to be defined and
unambiguous. I think in most cases looking at the TLD string should
immediately demonstrate if it's related to the country/territory or not. It
will become more complicated when the relationship is checked based on the
applicant or the purpose of the string, both of which can be easily "gamed".

Regards

>
>
>
> >
> > > On 13 Aug 2018, at 06:28, Greg Shatan <greg at isoc-ny.org> wrote:
> > >
> > > Here is an email (further down) I just sent to the WT5 list.  In the
> context of this discussion, I agree with Carlos that ISO 3166 3-letter
> codes shouldn't be reserved from delegation.  The bold move would be making
> them available in this round, in some fashion to be determined, but it
> seems we don't have the time to give the options the attention they
> deserve.  If we don't go that far, we could make some statement encouraging
> future groups to do something, but I have become wary of the idea of trying
> to prejudice that future discussion, since we don't have time to give the
> options the detailed discussion they deserve.
> > >
> > > I've considered Carlos recommendation:
> > >
> > > “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.”
> > >
> > > I have several problems with this.  First, why give ccTLD managers a
> role here?  I presume Carlos means the "relevant ccTLD managers", but even
> then, the relationship between ccTLD manager and government varies wildly
> from ccTLD to ccTLD.  I don't want to open a discussion about what's right
> or wrong about that (that is truly outside our remit), but there is no
> reason to replicate that witeh 3-letter codes.  Second, where these
> 3-letter strings have other applications, why eliminate these from
> consideration?  And if you don't why prejudice them and privilege
> governmental authorities?  Some of these could be far more useful and
> relevant than a country-related 3 letter gTLD.  A glaring example is .IOT
> for an Internet of Things TLD.  Finally, who are these "public
> interest/public benefit entities"?  I suppose this is also intended to be
> limited to "relevant" ones, but that opens a can of worms over identifying
> which ones are "relevant" and what "relevant" means.  Can I found a
> non-profit corporation and bid for .IOT?
> > >
> > > I think that, if we don't have the time to do this right, we should
> recommend that a future GNSO Working Group deal with the issue of
> "unreserving" 3 letter codes and leave it at that.
> > >
> > > Greg
> > >
> > > Other email below:
> > >
> > > A few thoughts on the ISO 3166 3-letter codes.
> > >
> > > First, WT5 is fully competent to deal wit the issue of whether, when
> and how strings identical to the existing ISO 3155 3-letter codes could be
> applied for and delegated.  These are in the gTLD space.
> > >
> > > Second, I would strongly object to any restriction on 3-letter strings
> that DO NOT match existing ISO 3166 letter codes.  The "original" gTLDs
> were three letter strings -- .com, .net, .org, .gov. .mil, .int, .edu.
> > >
> > > Third, there is no "tradition" of (or technological reason for) ISO
> 3166 3-letter codes being used for top level domain names connected with
> the related countries and territories.  So why make that assumption now?
> > >
> > > Fourth, I agree with Farzaneh that adding current ccTLD operators into
> the mix as part of the privileged class makes this recommendation an
> unfathomable mess.  This is not the time or the place to discuss the myriad
> ways that ccTLD operators do or don't relate to the countries that the
> ccTLD is related to.  And let's certainly not get into the issues raised by
> ccTLDs that function as gTLDs but are beyond the reach of gTLD policy.
> Let's just keep the ccTLD situation "unique" and move away from that
> electrified fence.  Replicating the current ccTLD situation in the 3-letter
> space would be a gross error in judgment.
> > >
> > > Fifth, there are over 45 current ISO 3166 3-letter codes that are
> equivalent to strings with other meanings -- words in English or other
> languages, currently delegated gTLDs, or acronyms.  Why should the future
> of these 3 letter strings have anything to do with any countries, where
> they have other significant meanings?  Of course, nothing prevents a
> country or territory from applying for the related 3 letter code.  The 3
> letter codes with other meanings are:
> > >
> > > CODE
> > > Meaning
> > > Related Country or Territory
> > > AGO
> > > English word
> > > Angola
> > > AND
> > > English word
> > > Andorra
> > > ANT
> > > English word
> > > Netherlands Antilles
> > > ARE
> > > English word
> > > United Arab Emirates
> > > ARM
> > > English word
> > > Armenia
> > > BEL
> > > Italian word
> > > Belgium
> > > BEN
> > > First name
> > > Benin
> > > BRB
> > > Acronym for “Be Right Back”
> > > Barbados
> > > CAN
> > > English word
> > > Canada
> > > COD
> > > English word
> > > Congo, the Democratic Republic of the
> > > COG
> > > English word
> > > Congo
> > > COM
> > > Current gTLD
> > > Comoros
> > > CUB
> > > English word
> > > Cuba
> > > DOM
> > > First name (short for “Dominic”); BDSM term
> > > Dominican Republic
> > > ESP
> > > Acronym for “Extra-Sensory Perception”
> > > Spain
> > > EST
> > > Word in various languages
> > > Estonia
> > > FIN
> > > English word
> > > Finland
> > > FRA
> > > Italian
> > > France
> > > FRO
> > > English word
> > > Faroe Islands
> > > GAB
> > > English word
> > > Gabon
> > > GEO
> > > English word
> > > Georgia
> > > GIN
> > > English word
> > > Guinea
> > > GUM
> > > English word
> > > Guam
> > > GUY
> > > English word
> > > Guyana
> > > HUN
> > > English word
> > > Hungary
> > > IOT
> > > Acronym for “Internet of Things”
> > > British Indian Ocean Territory
> > > IRL
> > > Acronym for “Internet Resource Locater” or “In Real Life”
> > > Ireland
> > > JAM
> > > English word
> > > Jamaica
> > > KEN
> > > First name
> > > Kenya
> > > KIR
> > > Drink
> > > Kiribati
> > > LIE
> > > English word
> > > Liechtenstein
> > > LUX
> > > English word
> > > Luxembourg
> > > MAC
> > > Popular line of computers
> > > Macao
> > > MAR
> > > English word
> > > Morocco
> > > NCL
> > > Acronym for “National Consumers League” or “Norwegian Cruise Lines”
> > > New Caledonia
> > > NOR
> > > English word
> > > Norway
> > > PAN
> > > English word
> > > Panama
> > > PER
> > > English word
> > > Peru
> > > POL
> > > Short for “Politician”
> > > Poland
> > > PRY
> > > English word
> > > Paraguay
> > > QAT
> > > Narcotic leaf
> > > Qatar
> > > SAU
> > > German word
> > > Saudi Arabia
> > > SUR
> > > French word
> > > Suriname
> > > TON
> > > English word, French word
> > > Tonga
> > > TUN
> > > English word
> > > Tunisia
> > > VAT
> > > English word; Acronym for “Value Added Tax”
> > > Holy See (Vatican City State)
> > >
> > > I would recommend that we either make a policy determination now,
> including a statement of rationale, or that we just leave this for a future
> process.  A tossed-off non-recommendation that seeks to limit or prejudice
> future policy work is really the worst of both worlds, and should be
> avoided.
> > >
> > > Personally, I would be in favor of a recommendation that makes the
> current 3166 3-letter codes "unreserved" and open for applications, with a
> restriction that any application that seeks to associate the TLD with the
> related country or territory requires the consent or non-objection of that
> country or territory.
> > >
> > > _______________________________________________
> > > 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/20180814/60094c3a/attachment-0001.html>