Re-sending TXT form of Proposed IDNA2008 Transition Idea

[John C Klensin]

--On Monday, December 14, 2009 18:18 -0500 Steve Crocker
<steve at shinkuro.com> wrote:

> 
> On Dec 14, 2009, at 6:09 PM, Warren Kumari wrote:
> 
>> 
>> 
>> Warren Kumari
>> ------
>> Please excuse typing, etc -- This was sent from a device with
>> a tiny   keyboard.
>> 
>> On Dec 14, 2009, at 3:44 PM, Steve Crocker
>> <steve at shinkuro.com> wrote:
>> 
>>> John,
>>> 
>>> With the caveat that I haven't given this deep and lengthy
>>> thought   and
>>> I haven't discussed this with anyone else, the model and
>>> value proposition I have in mind is the following.
>>> 
>>> The variants represent a potential for new revenue if either
>>> the existing registrant or a new registrant is willing to
>>> pay for it.  As a marketing strategy, the registrar can
>>> choose to register the variants for a period of time.  This
>>> would be a loss leader, but the costs would be minimal if
>>> the registry and ICANN cooperated to waive their fees.
>>> 
>>> The technical detail would be for the registrar to send to
>>> the registry the same set of records associated with the
>>> base name.  This would be independent of whether the
>>> registrar were also the DNS operator or web service provider
>>> for the registrant.

Note that EPP doesn't support any notion of "bundling".  So what
the above really says is that the registrar sends each name
sequentially, hoping that no one else registers one of those
names first.    One can easily imagine other arrangements, but
the vast majority of the require specialized registry databases
and, usually, registrar interfaces to them.

>>> The registrants would all be notified but wouldn't have to do
>>> anything.  When the time period expires, the registrant
>>> could choose to keep none, some or all of the variants.

We discussed the problem with this at some length last week.  To
review, if the registrant "doesn't do anything", then the status
of the variant names will, depending on what the registrar
actually does to create these names, be one of:

-- a lame delegation
-- a delegation to a registrar-administered zone and hence,
except when the registrar is managing the existing/base zone for
the registrant, not a situation that users will perceive as an
alternate name
-- even if the registrar is the zone administrator, those
applications that require that an application server know the
names by which it will be called (a list that includes SMTP
email and, for all practical purposes, web servers) aren't going
to provide a satisfactory user experience unless the registrant
does a lot more than "not anything".


>> Um, to me this seems fraught with danger... Some registants
>> will   register variant-A, but many of their users will think
>> of them as   variant-B. After the timeout, many registrants
>> won't realize how   many users have been reaching them as
>> variant-B, variant-C, etc, and   they will choose not to
>> renew them, and suddenly their users cannot   reach th
>> anymore... Yes, the registrant *should* be able to figure  
>> out how users think of them, but....

In practice, "registrant doesn't do anything" so badly
overconstrains the problem as to make the above irrelevant.  The
users who think of them a variant-B (and variant-C, etc.) will
be in no danger because the references won't work.

> Is this worse than having the burden on the registrants right
> away?  I don't have any religious feelings about this.  I'm
> just looking at this in terms of the practical problem of
> communicating with and educating the zillions of registrants.
> On the day the split takes place, if the variants are not
> registered, whomever has been using a variant to reach the
> registrant will suddenly find it's not working.  She will then
> have to figure out that she needs to type ss instead of ""B"
> -- apologies for the crude approximation of sharp-s -- in
> order to make things work.  Equally, the registrant will have
> to pay attention to the need to register some or all of his
> variants.

This interacts with the conversation Gerv and I had earlier
today about when the switchover in clients ought to occur
relative to whatever it is that registries decide to do and
whenever they decide to do it.

> It's a trade off of when the pain comes and who suffers.  Vint
> suggested each registry could control the timing of when the
> change happens within its own registry.  In the same vein, I'm
> suggesting that some registries might choose to encourage
> prophylactic registration of variants.  I guess each registrar
> can choose whether to take advantage of it if the registry
> offers it.

A registry can, fairly easily, decide that it is going to reject
registration applications for a name that, if interpreted
according to "the other" rules, would conflict with it.  In some
respects, that is just an odd case of today's model: if the name
is already in the zone, no one else can register it.   That is
Vint's proposal in its most raw form.  A registry can also
permit such registrations iff the registrant is the same (after
figuring out what "the same" means, which is part of Patrik's
point).  That is a little more work and, in essence, Vint's
proposal as circulated.  With about the same amount of work, but
in a different part of the operational systems,  the registry
can impose a proactive warning and waiting period for such named
(that is my alternate proposal). 

None of those options requires that the registry maintain
variant-bundle databases, sort out rules about partial transfers
of bundles, encourages registries to do things (without the
registrars asking) that require registrants to take action to
avoid making the Internet and its applications behave in an
unstable and unpredictable way.  Nor do they require extensions
to registrar-registry protocols that no one has started to spec
yet, at least in the IETF.   I still don't see the model that
makes things that do impose those requirements work.

best,
    john