Changing the values of domain names and the need for mapping

John C Klensin klensin at jck.com
Fri Feb 20 20:48:02 CET 2009


--On Friday, February 20, 2009 09:23 -0800 Paul Hoffman
<phoffman at imc.org> wrote:

>> In order for us to be able to
>> articulate constraints that the registries will need to
>> implement, the registries first need to tell us how they
>> intend to implement those constraints. ??
> 
> We are proposing changes that will change the DNS operations
> of registries and registrants. 

First of all, IDNA, by definition, does not change DNS
operations.  DNS operations occur in terms of A-labels and the
interpretation (and associated operations) of a given A-label
does not change at all between IDNA2003 and IDNA2008.  The
number of different strings that could have produced a given
A-label does change, but that is not a _DNS_ operational matter
and, for an arbitrary IDN string that involves some mapped
characters, that number can be large.

IDNA is a matter of how _applications_ interpret strings that
are to be converted into something that can be treated as a
domain name.   That is why you folks gave it that name.

Second, there is already a fairly clear IETF position on variant
mechanisms and related issues in handling character or label
combinations that, in the view of the relevant registry and its
constituency, could be problematic.   Independent of the handoff
Cary mentions (which dates back to an IAB-IANA decision in the
80s that DNS policy was a zone and IANA matter, not an NWG-IETF
one) the IESG quite explicitly declined to have what became RFCs
3743, 4290, and 4713 considered on the standards track because
they were out of IETF scope.   All three were published as
independent submissions as a result.

> We can
> 
> a) demand they operate in one particular fashion
> 
> b) list some acceptable operational changes (and possibly some
> unacceptable ones as well)
> 
> c) let them guess what they should do
> 
> Right now, we are at (c).

No, we are somewhere in the vicinity of (b).  Consider Sections
7.1.1 and 7.2 of Rationale-06.  I believe that material goes at
least as far as it can go without intruding on business
decisions and decisions that need to be made in the context of
the situations of individual zones.  If your view differs,
please propose and justify text.   But the implication that we
have been ignoring the issue is simply incorrect.

> In the IETF, making protocol changes that affect operations of
> something as valuable as the DNS and not giving any
> operational advice is rare. If we want to do either (a) or
> (b), we either need to come up with the operational changes
> ourselves or hear from the affected parties about what they
> are thinking. I believe the latter is better.

See above.
 
>> The largest part of those plans involve marketing and client
>> relations issues that cannot possibly be of concern here.
> 
> We fully disagree here. The largest part of the plans is how
> to operationally handle the mapping / bundling / binding of
> the names.

Our obligation stops at identifying the situation and possibly
alternatives.  Even the latter goes beyond what the IETF has
been willing to do in the past.   Which alternative a zone
administrator adopts (if any) is up to the zone and whatever
policies affect it.  Remember that one of the design goals of
the DNS was distributed administration and distributed policy
definition, not IETF making of this sort of policy (or even of
interpretation and mediation among registries about their
policies).

> That may be true, but it is not what we are talking about. We
> are talking about how, operationally, a registry can give a
> new name to a registrant that already registered a previous
> name, and how, operationally, that registrant will have to
> handle two names that are supposed to act in an identical
> fashion.

First of all, the determination that "two names are supposed to
act in an identical way" is a decision to be make by per-zone
policy makers and their constituencies and not by the IETF.
That was, you will recall, the whole point of the DENIC
comments: having the additional ability to use the character,
rather than having it mapped out of the IDN space, is useful to
the registry and how to handle it relative to other characters
and existing registrations is the registry's problem.  

Note also that the distinction about registry policy making
predates both IDNA and ICANN.   Zones adopt rules about what can
and cannot be registered, how names and hierarchies are
structured, when aliases can be used, and so on all the time,
and the original DNS operations specs assumed they would do that
(again, this is the "distributed administrative hierarchy"
issue).  Those decisions become an IETF matter only if they are
actually disruptive of DNS operations or the operations of
protocols with which they are intended to operate.  If you argue
that the TLDs are somehow different and it is their behavior
that we must specify, then I contend you are strengthening
Cary's point (and that of Eric and others) that this is about
business decisions and relationships, not DNS operations.  

     john



More information about the Idna-update mailing list