Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work

[Brian Dickson <[e-mail]>]

I think we are (all) in agreement, to some degree.

Here's what I'm trying to say, obviously not clearly enough to date:

There are currently mechanisms with limited ability to "deliver"
multiple names for the same data: CNAME and DNAME.
Those are limited mechanisms, which do not handle all cases.
And also, quite importantly, they do not in and of themselves support
DNSSEC validation without additional work by the Signer.

There are also brute-force means by which multiple names can be
enumerated, which does not use any DNS protocol elements.
Brute force, however, puts the burden on maintaining parallel zones on
the registrant.

The problem is scaling.

What we don't yet have, in terms of problem statement, is an answer to
what the scaling requirements are.

If the answer is "two", then likely no protocol work is needed. Two
scales nicely. I do not believe "two" is the answer, however.

If, on the other hand, the answer is P (as in P vs NP), polynomial
scaling, then I think we need to contemplate providing solutions in
the WG.

An example of polynomial is the expansion of regular expressions of the form:
{$A|$B|$C|...}
where
$A == $x.{$a|$b|$c}.{$d|$e}
$B == {$f|$g}.{$h|$i}.{$j|$k}
$C == $y.{$l|$m}.$z
and so on.

We haven't *yet* been given that as a requirement, at least from ICANN
or other groups.

However, if the real world users, i.e. registrants and end-users,
expect to be able
to refer to things by such multitudes of names, and get "the same" answers,
then scalability issues suggest having the technological means of
keeping the zones
completely identical is a firm requirement. And I believe that means
DNS protocol work,
either directly to do this, or indirectly to support non-DNS
implementations, e.g. literally
by means of indirection.

I also believe that *use* of DNS protocol technology envisioned needs
to be optional, and that
the brute force and existing CNAME/DNAME solutions all need to be
allowed and supported.

One size does not fit all.

And the sizes currently available do not include XXL, which is the real problem.

Brian

On Sat, Apr 10, 2010 at 8:36 AM, Eric Brunner-Williams
<[e-mail]> wrote:
> On 4/9/10 10:36 PM, Brian Dickson wrote:
>> ...
>> ICANN are concerned with the root and TLDs, but there ends their mandate.
>
> Please see rfc1591. In particular Section 3, parts 2 and 3.
>
>> ...
>> The TLDs need to provision and serve whatever is mandated by ICANN.
>
> ICANN is a California domiciled 501(c)(3) corporation which enters
> into contracts with what it calls "registry operators" (aka
> "contracted parties"). Contracts do not contain "mandates", unlike
> regulations. ICANN is not a regulatory body, authorized by some
> specific enabling legislation.
>
> In broad terms, ICANN has contractual relationships with some (about
> 20) "registry operators" (far fewer actually independent "registry
> backend service providers", seven I think, pre-coffee), and memorada
> with some other "registry operators".
>
>> ...
>> And the registrants, particularly in the IDN space, need something of
>> real value,
>> especially beyond just the TLDs, to make it worth doing IDNs in the first place.
>
> The overwhelming bulk of that particular work has already been done,
> first in the IDNA WG, completed seven years ago, and more recently in
> the IDNAbis WG, recently completed.
>
> The problem statement here is either an administrative convenience
> statement for arbitrary similarity, or the edge cases arising from a
> very limited number of equivalent (in some sense) code points in the
> third-party repertoire, or the specific case of intelligibility and
> therefore equivalence (in some sense) of arbitrary substitution of
> code points in two sub-repertoires, commonly denoted "Simplified" and
> "Traditional" Chinese (aka "SC/TC equivalence").
>
> The utility of non-LDH labels, even if bootstring encoded from an LDH
> alphabet, and available only through presentation, does not depend on
> any work this group can conceivably take.
>
> Eric
>