Re: [DNSOP] draft-yao-dnsop-idntld-implementation-01.txt

[Eric Brunner-Williams <[e-mail]>]

I too have read the document.

Let N = the number of entries in the IANA root associated with the 
territories listed in the ISO 3166-1, and {N} denote that set.

One or more of Verisign, Afilias and NeuStar operate two or more ccTLD 
entries, each with an optional, not required, nominally distinct 
policy and set of registrants. The RW and CD registries share 
technical contact (and possibly related dysfunctional properties). Etc.

There exists a substantial class of SLD registrations which are 
present in multiple entries within {N}, and under the theory of 
"subsidiarity principle" offered by the chair of the ccNSO, it is 
possible for two or more ccTLDs to consist entirely of registrations 
of this class, and to have the same operator.

Therefore the DNAME or NS choice of mechanism is present whether or 
not any increase occurs to {N}. Granted, the likelihood of DNAME is 
much less likely than NS, but other than government or FOJ client 
acquisition, and IANA change request management, no technical or 
policy barrier exists to preference NS over DNAME as the choice of 
mechanism.

Next, an increase in the number of entries O(N/5) without a 
corresponding increase in N, expands the instances of multi-entry 
operations. It has been asserted, though the final policy guidelines 
are not yet available, that each instance in this step-wise increase 
in {N}, which will be an entry of the form "xn--*", will be operated 
by the operator of the existing corresponding entry in the IANA root 
associated with the territories listed in the ISO 3166-1.

As a policy matter, this assumption is problematic. Consider for 
instance the problems of the existing operators for .US or .CA in 
operating a "US-or-CA-in-Chinese" registry, or the existing operator 
for .CN in operating a "CN-in-Tibetan" registry, or the existing 
operator for .IL in operating a "IL-in-Yiddish" registry. It is 
possible that each of these example registry operators will have 
constraints which preclude users from creating persistent resource 
identifiers using these example non-Latin scripts used by non-trivial 
populations having a preferential association with the corresponding 
existing ISO 3166-1 entry. These are of course, just examples, and not 
intended to describe actual policy limitations or present or plan of 
record practice.

The problem is elided temporarily by the assumption that each 
government or FOJ will select only one (or two) additional strings to 
add to {N}, and so minority languages, and therefor multiple distinct 
policy goals, will not be present.

This increase is the ccTLD IDN "FastTrack".

Next after, an increase in the number of entries O(M*N), again, 
without a corresponding increase in N, expands the instances of 
multi-entry operations. It is not yet asserted whether each instance 
in this subsequent step-wise increase in {N}, which will be an entry 
of the form "xn--*", will also be operated by the operator of the 
existing corresponding entry in the IANA root associated with the 
territories listed in the ISO 3166-1.

This increase is the ccTLD IDN PDP.

This will present this problem more fully, whether the additional 
entries are in scripts which are non-Latin only, a restriction present 
in the "FastTrack", or non-Latin, and decorated Latin, and potentially 
even non-decorated Latin.

In general, DNAME as the choice of mechanism for multiple instances of 
entries in the IANA root associated with the territories listed in the 
ISO 3166-1 is unlikely to promote the use of minority languages as 
resource identifiers, as is NS, where the two or more delegations 
share a single or ordered hierarchy of policy goals.

Finally, there is the matter of equivalence classes within character 
repertoires which exist in work product of the IDNAbis WG, now in LC.

The SC/TC equivalence class is well known. Less well known, outside of 
the IDNAbis WG, is the Arabic and Persian YEH non-equivalance, and 
other examples, and other equivalence classes in other scripts.

By abuse of notation these are all commonly referred to as "variants", 
and by a similar abuse of goals ordering, "anti-phishing" using 
"variants" is frequently presented as a controlling design goal, 
rather than enabling the use of scripts to form persistent resource 
idenifiers, even by linguistic minorities in the territories 
associated with ISO 3166-1.

Independent of the limitations of DNAME, the NS choice of mechanism 
allows the possibility of distinct policies associated with two or 
more elements of {N} associated with a single ISO 3166-1 entry, 
possibly through physically distinct operators. This has been argued 
to be a weakness of the NS choice of mechanism. I hope I've conveyed 
my impression that there are foreseeable circumstances where a single 
policy over two or more "variants" is also a non-desirable outcome, 
independent of the choice of mechanism.

I don't know if there will be an application by the United States for 
a Cherokee Syllabary equivalent to "US" or by Canada for a 
Carrrier/Cree/Dene/Innu/Inuktitut/Siksika Syllabic equivalent to "CA", 
but as we look to the ASCII-only ISO 3166-1 use in the IANA root 
tending toward something approximating a sparse subset of the product 
of that and ISO 639, consistency for "anti-phishing", overlooking the 
expectations of the users forming and using persistent idenifiers, to 
the point of selecting which "variants" have no meaning other than 
visual dissimularity (or simularity, depending on the particular 
choice of edge case in the IDNAbis work product), and restricting the 
choices of identifiers (or more generally, vocabularies in scripts 
users might select, which may not exist in the "official" standards 
associated with a territory to which an ISO 3166-1 entry has been 
allocated.

Finally, there is the eventual non-step, monotonic increase of entries 
in the IANA root which are not associated with the territories listed 
in the ISO 3166-1. This number is presently quite small, but is 
conjectured to grow O(2xN) annually, or perhaps O(2xN) in year 1, and 
O(N) thereafter. Unlike the two prior anticipated increases in the 
number of entries, no bound is known, and at least one proposal for 
"single registrant" TLDs creates the possibility that the number of 
globally protected trademarks, O(10^^5) is a lower bound for this 
growth in the IANA root.

Absent any restriction, it seems reasonable that substantial numbers 
of "single registrant" TLDs could be implemented using DNAME, with 
each having a SLD set similar to the set of addresses defined in 
RFC2142 {info, marketing, sales, support; abuse, noc, security; ...}, 
disambiguated at the application layer by the mass-registry operator.

I've written this note because I'm not satisfied with the bivalued 
approach to the variant problem in the Yao draft, nor with the unitary 
semantic approach to variants offered, even by a single, unified 
registry operator, nor the implicit constraint of the operational 
problem as the number of entries in the IANA root associated with the 
territories listed in the ISO 3166-1 grows, and as the number of 
entries in the IANA root not associated with the territories listed in 
the ISO 3166-1 grows.

I'm sorry I can't be in Hiroshima so that I can attempt to field spit 
balls for such an excess of Layer 9 persiflage, and my typical bad to 
worse writing.

Like Andrew, I believe I know why the Yao draft had to be written, and 
unlike Andrew I think DNAME is the wrong answer, and the view that 
"any name must be _functionally the same_ as all the other variants of 
that name" concerns me as it appears to put one commercial interest 
above all non-commercial interests in IDN policy.

Written while interrupted by children and so on. All errors mine, 
everything correct stolen from others, etc.

Cheers,
Eric