Another thoughts on TRANSITIONAL

[Eric Brunner-Williams]

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 alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/idna-update
> 
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
> 
>