Subject: [dnsext] Second-order effects (was: One chair's focus)

From: Brian Dickson <[email-masked]>
Date: Tue, 25 May 2010 11:18:27 -0300

On Wed, May 19, 2010 at 11:58 PM, Andrew Sullivan <[email-masked]> wrote:

> Speaking only for myself.
>
>
> The questions I see before us come down to these:
>
>    1.  Is there a problem?
>
>    2.  Is it one that can't be solved already?
>
>    3.  Is it something we are in a position to solve?  (How completely?)
>
>    4.  What are the consequences of solving it?
>
>
 At the risk of invoking meta-discussion...

I think one thing we should all keep in mind, is the consequences of what we
do here, which
are second-order effects - those things which are the logical results, but
not necessarily obvious.

For example, we may provide solutions to IDN requirements, and we may
provide solutions for DNSSEC.

However, if in our choice of solutions for these, we don't take into
consideration that a non-trivial portion of those who want or need to have
both at the same time, i.e. DNSSEC IDN's, we risk putting those folks in a
difficult position.

Those using IDNs likely see those are essential, or at least necessary. They
may not have as strong a need or desire for DNSSEC.

If DNSSEC is more difficult, or more expensive, for those using IDNs, this
could act as a barrier to widescale deployment of DNSSEC. Or worse, it could
be seen as a slight by us, against the IDN community.

The main issue I can see, is the operational cost, if zone signing for IDNs
requires substantially more work, i.e. if each variant needs a separate
signature, when we have N x M x P type combinatorial expansion of possible
equivalent labels.
More work means compute cycles, and that means either less frequent zone
signing, or more expensive equipment to support signing - both of which are
impacted proportional to the product of the number of variants, something
which is finite but not necessarily a friendly number. N x M x P, for
example, is at least 8 (when N == M == P == 2), and can easily be much
larger.

So, I'd say it can be summarized as follows:

1. There is a problem, specifically scaling.
2. It can't be solved already.
3. It is something we are in a position of solving.
4. The consequences are an impact to either the current IDN-related
proposals, *or* an impact on recently-approved DNSSEC specifications (and a
correspondingly small deployed code base and user base)
5. The consequences of *not* solving it are as stated above - having zone
administrators needing to choose between no-IDNs, no-DNSSEC, or additional
cost.

Brian