Another thoughts on TRANSITIONAL

Vint Cerf vint at
Sun Dec 6 15:39:18 CET 2009

- list

you should really consider writing a brief handbook titled:

"The Art of the Elegant Kludge"



On Dec 6, 2009, at 9:36 AM, Eric Brunner-Williams wrote:

> Registry operators, generally, solicit guidance on a variety of  
> issues, from utility and necessity of sub-minute changes of resource  
> associations, to character set transitions, whether "new" or already  
> available and possibly modified.
> A recommendation in this area could be made, and if made, could be  
> useful.
> Wholesale transition experience exists. The end-of-life transition  
> of a vendor's propriatary row-based ASCII encoding scheme testbed, a  
> set of some 10^^6 labels. The end-of-life transition of several name  
> spaces, starting with .arpa and continuing through .su, again,  
> affecting sets as large as 10^^6 labels.
> The alternative design choice removes general semantics from  
> delegation within an anchored graph, inherent to the design of the  
> DNS, and places some semantics in other, distinct mechanisms.
> As Andrew recently pointed out, there are no unowned errors, no  
> RNAMEs not under the control of some zone operator.
> Ergo, +1.
> The trajectory of label expansion has been a decade now in the IETF,  
> longer if one includes the charset work, subsequently abandoned, or  
> about the same as the trajectory of making delegations have proof  
> properties. For a variety of reasons, one of which is the  
> tediousness of the "ICANN Problem", the label expansion work has not  
> taken place in the DNSEXT WG and its predecessors. As I sit and  
> write this note, I cannot see how the DNSSEC work, as convoluted and  
> tortured as it has been, could yeild a "secure solution" to inherent  
> and pervasive defects in some assumed property, if the "solution"  
> applied to an arbitrary sparse set of delegations, through some  
> application specific, and necessarily externally specified,  
> mechanism or set of mechanisms.
> Kludge is the term of art for such things.
> Eric
> Vint Cerf wrote:
>> i think alireza has the right idea here. It should be possible to  
>> plan  registrations
>> under IDNA2008 rules on a registry by registry basis (I mean  
>> registry  in its
>> most general sense, not just TLD) and to do them in such a way  
>> that  takes
>> into account awareness that IDNA2003 and IDNA2008 compliant software
>> will persist, in parallel, for a considerable time. In some ways,  
>> this  is the same
>> kind of problem that IPv4 and IPv6 pose from the deployment point  
>> of  view.
>> v
>> On Dec 6, 2009, at 2:16 AM, Alireza Saleh wrote:
>>> I think TLD operators can help to solve this problem. In current
>>> situation, we should accept that some incompatibilities may occur in
>>> lower level of labels which are not under the control of the TLD
>>> operators. I think the only way to do the transition is at the  
>>> time  that
>>> registries start registering domains under the IDNA2008 regulations.
>>> Registries should take an appropriate sunrise system before   
>>> introducing
>>> domain-registration under INDA2008. For example,
>>> 1) Stop registering IDN names or check IDNA2003 version of each
>>> registration against their database and if it exists , do not  
>>> allow  that
>>> registration
>>> 2) Contact current label owners who have domain names including
>>> MAYBE-CANDIDATE characters and ask them whether they want INDA2008
>>> variant of that or not
>>> 3) Begin normal registration after this Sunrise-Transitional  
>>> period  passed
>>> This may require  close co-operation between ICANN and IETF to   
>>> publish a
>>> guideline for that transition including policy and technical   
>>> solutions.
>>> It may also require revisiting the EPP protocol or add an  
>>> extension to
>>> that.
>>> - Alireza
>>> Andrew Sullivan wrote:
>>>> On Sat, Dec 05, 2009 at 10:55:37AM +0330, Alireza Saleh wrote:
>>>>> I don't understand what the protocol is trying to solve. If  
>>>>> this  is the
>>>> The idea behind what I suggested is just that a zone operator can  
>>>> say
>>>> what their policy is, and clients can learn that, in a  
>>>> generalized  (or
>>>> generalizable) way.  I fully admit it's a giant and expensive  
>>>> means  to
>>>> the end, but it's the only way I know of signalling between the end
>>>> points in this otherwise mostly-stateless interaction.
>>>>> a domain-name and not only TLDs or SLDs
>>>>> that are directly under the control of zone operators.
>>>> Surely every single existing RNAME in the DNS is directly under the
>>>> control of some zone operator?
>>>> A
>>> _______________________________________________
>>> Idna-update mailing list
>>> Idna-update at
>> _______________________________________________
>> Idna-update mailing list
>> Idna-update at

More information about the Idna-update mailing list