[UA-discuss] GNSO requested deferral of IDN Guidelines 4.0 Vote - CPH / Registrants impact

Sat May 11 21:12:20 UTC 2019

The ccNSO is a membership body of ccTLDs.  The gNSO has a variety of participants – including registries – but not generally ccTLDs.

D

From: UA-discuss <ua-discuss-bounces at icann.org> On Behalf Of Asmus Freytag
Sent: Sunday, 12 May 2019 8:58 AM
To: ua-discuss at icann.org
Subject: Re: [UA-discuss] GNSO requested deferral of IDN Guidelines 4.0 Vote - CPH / Registrants impact

Delaying the IDN Guidelines will just mean more registries will register more "non-standard" labels and make it harder to implement something that's reasonably secure for everyone.

Anytime you change the registration policies for an existing registry, you will have to figure out how to grandfather existing, delegated labels (if any).

My understanding was that the guidelines were intended primarily for newly established registries, but I'd love to find out whether this understanding is wrong for some reason.

The GNSO represents the "ccTLDs" and they would just love to continue with "innovations" like emoji domain names. I would love to see some concrete cases of existing registrations  for ccTLDs that are reasonable labels that would be impacted.

Anyone know?
A./

On 5/10/2019 2:31 PM, Roberto Gaetano wrote:
Hi all.
This email from Jothan makes a good point about the impact caused by changing the standard about managing variants.
I was wondering whether we have a report on how variants are managed by different IDN registries.
Somebody can point me to such a source?
Thanks,
Roberto

On 30.04.2019, at 23:27, Jothan Frakes <jothan at gmail.com<mailto:jothan at gmail.com>> wrote:

The GNSO just sent a letter to request that the vote on adoption of the IDN Guidelines 4.0 be deferred

There is some UA pain that will come from these Guidelines we should be completely aware of.

It is important to identify the manner in which standards can impact the contracted parties, such as the Registries and Registrars, but getting even further out the supply chain into registrants and Internet users, there are some impacts to them as well as their audiences.

If the new standard causes something that was a separate registration to become a variant of another registration, or invalidates an existing registration, this is a bad outcome for the innovators, developers, and early patrons that supported the internationalization of the namespace.

Part of what the objective of UA is, to my reckoning, is to increase engagement and support of coding projects that will require adoption of standards that may not immediately hold levels of RoI to them, and they are looking for reasons not to do them.

These new guidelines are good - and needed - they are the result of many people's hard work, time and wisdom, and address many solutions.  The approach of pushing these out is problematic.  Further, there seems no recourse for those (even if statistically small) who may be impacted adversely, lose their domain, or have it be invalidated (and thus REVERSE their UA experience)

There is potential impact to existing TLDs, and most notably to registrants of second level names where there are registrations using former standards that become unsupported or invalidated.

A very important challenge we face with the UA effort is inspiring developers to implement IDN and EAI as we help globalize the Internet through our work.

IF the approach on standards will be to invalidate some portion of the community of registrations like this, there must be attention to how this impacts existing innovators.

Innovators worked to drive the standards and increase awareness - and the invalidation or deprecation of a registration that someone has carried for a number of years (some are 15+ years) is the precise opposite of a reward for early support, and it is going to send a very loud message to developers.

I believe that further review is needed by registries on the technical impacts of the changes, but any delay can help ICANN and the community address the disenfranchisement factor.

This should be important to UASG - we need developers to embrace the additional effort that they have to invest in their work to consider IDN, EAI and other things.

-Jothan

Jothan Frakes
+1.206-355-0230 tel
+1.206-201-6881 fax

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20190511/d6dc20ff/attachment.html>