Another thoughts on TRANSITIONAL
Vint Cerf
vint at google.com
Sun Dec 6 15:39:18 CET 2009
- list
Eric,
you should really consider writing a brief handbook titled:
"The Art of the Elegant Kludge"
:-)
v
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 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
>
More information about the Idna-update
mailing list