Re-sending TXT form of Proposed IDNA2008 Transition Idea

John C Klensin klensin at jck.com
Tue Dec 15 05:52:52 CET 2009



--On Monday, December 14, 2009 20:06 -0500 Eric Brunner-Williams
<ebw at abenaki.wabanaki.net> wrote:

> Hmm. We can tell we're not in San Francisco as the locus of 
> irresponsibility isn't registries ...
> 
> Seriously John, there are registries, and registries, from the 
> repurposed toys to the highly responsible, and there are
> registrars  and registrars, from the domainer shells to the
> highly responsible.

Agreed.  Completely.

> There is no benefit to a registrar, or a registry, in what you
> expect  of either. This is not a fault of individual
> registrars, or individual  registries, so when looking for
> root causes, try to look to  fundamental incentives. Try and
> complete a sentence that begins with  "Honesty towards ICANN
> is ..." and doesn't end "wasted effort."

Again agreed... and part of the point I was trying to make... I
think.

> I don't think it is necessary to invent a "registry service"
> to as the  preferred solution to registrant desires to
> register additional  domains. I didn't think it was necessary
> to invent a "registry  service" as a solution to registrant
> desires to synchronize the expiry  and renewal dates of
> domains.
> 
> It may just as well be implemented as a registrar service, and
> on that  distinction registries, and registrars, pay no small
> amount of attention.
> 
> It ICANN wants to incent registries it need only look to the
> registry  desire to offer IDNs. If ICANN wants to incent
> registrars it need only  look to the registrar desire to offer
> IDNs. Don't screw around playing  with the two dimes, look to
> fundamental incentives.

Of course, ICANN incentives vis-a-vis the vast majority of the
ccTLDs aren't worth those two dimes.   While they could, in
theory, make contractual requirements on IDN TLDs, such TLDs
will, almost by definition, not have large installed based of
names that were created under an assumption of IDNA2003-like
mandatory mapping behavior.

> Apropos of EPP and bundling, I proposed containers, they were
> in XRP,  it was a natural fit for bundles, and no one else at
> the time thought  EPP needed anything more than a single unit
> transaction type.

Yes, I remember that discussion.

I'm not sure, but I don't think we disagree about the situation,
the incentives, or the benefits.    The only points I was trying
to make to Steve and others were:

	* In practice, there is no such thing as variant
	bundling that can be automated at the registrar or
	registry without requiring any activity or participation
	of the registrant.
	
	* If one decides to do something as part of the
	registration process, blocking registration based on
	something already registered is far easier
	technologically and operationally than building and
	utilizing any sort of "these names are linked together
	as a group" bundling model.

	* If one does decide to do something to group names
	together and keep them grouped, it either needs to be
	done entirely at the registry (by rejecting attempts to
	register names that belong to the group by come from
	other registrants) or requires facilities in the
	registrar-registry interface that are not part of the
	standard EPP model.

Whether or not any given entity is going to make the decisions
implied by the second or third points above is another matter.
I don't know how ICANN would create adequate incentives if they
wanted to, I don't know it (as Steve hypothesizes) the
expectation of future paid registrations would help, and all I
can guess about the mechanisms that someone would choose is the
obvious -- that things that are easier and less costly to do
will generally require a lower level of incentives than things
that are relatively more difficult, more complicated, or more
expensive.  

Finally, I am pretty sure that having an IETF WG, most of whose
members have little knowledge of how large-scale all-delegation
or mostly-delegation domains are operated, isn't going to be
taken seriously if it starts writing global requirements on what
zone administrators must do.  Analyzing various cases and
explaining why some options are better than others under
specified circumstances is another matter, but that advise will,
at best, be accepted to the extent to which the analyses and
reasoning make sense to the operators.

> I'm now concern with how this discussion is going.

Me too.

    john





More information about the Idna-update mailing list