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

[Asmus Freytag]

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/67899daf/attachment.html>