[itipanel] three areas of identifier innovation to consider

[Paul Vixie]

as a panelist it may seem that i'd have an inside channel for these, but
for the purpose of full transparency, i'm putting these in the public
record. these are my own views, and not necessarily those of any other
panelist or of the panel itself.

---

NOTE WELL: These are not engineering problems per se, and end users have
no representation within IETF other than indirectly through their
vendors. ICANN's tag line is "one world, one internet" and its remit is
to make the Internet better for end users. Thus, this venue for this
proposal.

1. IDN Considered Ambiguous

A. I18N was added to DNS by an open protocol development process within
IETF. The result is modal, in that ASCII names which can tolerate case
folding are expressed natively, whereas every other script is expressed
in "punycode", such as "xn--yfro4i67o". The expectation was that only a
user or operator or vendor who was motivated to use I18N domain names
would ever be required to implement the necessary "presentation layer"
to accept and display I18N names in their actual native scripts. This
expectation is wrong, in that many users who might wish to enter or view
native scripts will be unable to do so due to the age and/or
non-upgradability of their software. I suggest a non-modal alternative,
where even old-style ASCII domain names which depend on case folding,
ought to be encoded in the "punycode" format, in order to drive
end-system demand for software which can properly accept and display
I18N names.

B. Since domain names are frequently used as search anchors for product,
service, and company names, it is necessary that old-style "case
folding" be done for I18N. In the context of I18N names, this means
there can be only one on-the-wire encoding possible for each symbol. In
any situation where Unicode can express a symbol using multiple code
points, a single code point should be standardized for on-the-wire
representation and any alternative code point whose symbol expresses the
same meaning should either be prohibited or equivalenced. The intent
here is to protect the end user's interests by allowing them to enter a
domain name they have seen, and to have it actually be the same domain
name that they saw.

2. Identifier Stability and Transparency

A. Owing to the immense scale of the DNS which has been enabled by a
"too cheap to meter" business model among registries and registrars,
there is no cost barrier against abusive or criminal use of "throw-away"
domain names. Owing to the privacy problems perceived in traditional
"Domain WHOIS", it is now common for domain registrant details to be
unavailable. The combined impact of "throw-away" domain names and "WHOIS
privacy" is that all domain names appear to be equal in their safety and
value, even though most domain names (by simple statistics) are unsafe
and/or worthless. To make it possible for an end-user to pre-judge the
safety and/or worth of a domain name they might otherwise use in
communication, ICANN ought to standardize the at-scale automated
disclosure by registries of domain age and registrar identity. If an end
user wishes (for example) to filter their inbound e-mail or their
outbound web connections based on a domain name being "too new" or on a
domain name's registrar being "too abusive" it ought to be possible to
do so. Lookups of a domain's age and of the identity of its registrar
should scale as well as lookups in the DNS itself. There is no
counter-argument similar to "WHOIS privacy" against at-scale public
disclosure of domain age and registrar identity. The end users in whose
name this system is operated, have "a right to know."

B. Most registries and registrars now offer an extremely short
turn-around time on domain creation and domain modification. This was
once a competitive advantage but is now a competitive necessity. The
primary beneficiaries of this fast turn-around time are registrants who
are abusing the Internet and who must therefore consume a large number
of "throw-away" domain names, or whose small stable of domain names are
so controversial that they must move their DNS servers many times per
day or in some cases many times per hour. Since it's possible to imagine
a non-abusive beneficiary of fast domain creation and update times,
ICANN should standardize a responsible rate limit, which enables
necessary domain updates by responsible non-abusive registrants. For
example, registries might be required to limit the number of "name
server" (NS) and "delegated signer" (DS) changes for a domain to "two
times per week" on a sliding window basis. Any registrant who requires
an update more often than permitted by the rules, should be required to
confirm this by a high-cost method such as a phone call.

3. Disconnected and Local Operation

A. Networks which are only periodically connected to the Internet
generally use local naming systems such as Apple Bonjour or "/etc/hosts"
to make local connectivity possible even when no root name servers are
reachable. This can lead to collisions between local names and new GTLD
names, for example, ".CORP" and ".HOME". Users should be encouraged to
register Internet DNS domain names even for devices and services which
are not Internet-reachable, in order to prevent future collisions.
However, ICANN ought to support research and development of open
multi-vendor standards and technologies which ensure that completely
local connectivity does not depend on Internet access. This may be as
simple as standardizing a set of "hints" to be shared between local DNS
authority servers and local DNS recursive servers, or it may be as
controversial as changing the DNS root name server system to use a small
number of hierarchical anycast names and addresses so that a request for
an authoritative answer will be preferentially answered by an on-LAN,
in-building, on-campus, on-ISP, same-continent, or global server.
Special care must be taken to preserve DNSSEC validation no matter what
approach is taken.

B. When a user accesses a local service or a local device, they will
customarily use a shortcut name which lacks any dots. In formal Internet
definition, these are not domain names, since a domain name would have
at least one dot in it. Wide spread local convention, supported by
virtually all vendors, is to use a "search list" to find a fully
qualified domain name that matches the likely intent of the shortcut
name. For example, "www" might be found as "www.example.com". Mobile
devices offer a new challenge to this approach, which is that the
"search list" used at home might differ from the "search list" used in
the office or on travel. ICANN should support standardization in this
area, so that a user always gets an expected result from "search list"
processing. For example it might be better if "search lists" were only
available in real time and not in the background. This would make it
necessary to fully specify the fully qualified domain name of any
Internet resource needed in a configuration file, while still allowing a
user to use shortcut names when operating interactively. For even more
safety, a user should be required to confirm their intent when a
shortcut name is expanded to a fully qualified domain name using "search
lists".

===
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/itipanel/attachments/20131123/133c3a4b/attachment.html>