Subject: Re: [dnsext] we've been assuming that only one label matters

From: "George Barwood" <[email-masked]>
Date: Mon, 4 Jan 2010 09:24:12 -0000

----- Original Message ----- 
From: "Michael Graff" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, December 27, 2009 11:43 AM
Subject: Re: [dnsext] we've been assuming that only one label matters

> I personally think it's a tool issue, and no protocol changes need to
> happen.  I don't see why the IETF needs to solve a problem using
> protocol when it's fairly clear to me that any real solution involving
> protocol changes is more or less a non-starter.

I agree ( now that Michael has been brave enough to put his head above the parapet ).

DNS has always recognised that Latin upper and lower case letters are equivalent,
and this has historically been implemented on the server side.

There is apparently a need to define a normalisation rule for more complex equivalences.

I suggest this is best applied client side, either by humans knowing the rules, or in software.

Increasing the complexity of the resolution process strikes me as a bad idea.

George

---

From: Douglas Otis <[email-masked]>
Date: Mon, 04 Jan 2010 12:13:55 -0800

On 1/4/10 1:24 AM, George Barwood wrote:
> On 12/27/09 11:43 AM Michael Graff wrote:
>
>> I personally think it's a tool issue, and no protocol changes need
>> to happen.  I don't see why the IETF needs to solve a problem
>> using protocol when it's fairly clear to me that any real solution
>> involving protocol changes is more or less a non-starter.
>
> DNS has always recognised that Latin upper and lower case letters are
> equivalent, and this has historically been implemented on the server
> side.
>

Agreed.

This could be done using a non-hostname label such as "_here" to handle
the DNAME node issue that would be placed within the referenced zone.  A
new resource record type could produce the same effect, without
modifying existing DNS protocol behavior, although it could provide some
optimizations.

Imagine the mess if zone cloning were used to handle case folding,
especially when considering TLDs.  Offering a visible feedback to those
entering a "non-preferred" form of a name seems like a good way to keep
them informed of the "official" site.

Allowing a TLD to create "equivalent" domains would then mean all domain
owners for that zone would need to acquire multiple certificates, and
zones.  This is not a nice thing to do.  Zone cloning would reduce cache
hit rates and reduce performance.  This would also mean more systems
would be necessary to support existing users, and would offset a few
Moore's Law generations of benefits thereby demanding more resources for
reduced performance.  An attitude perhaps emblematic of monopolies. :^(

-Doug

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 4 Jan 2010 17:02:36 -0500

No hat.

> reduced performance.  An attitude perhaps emblematic of monopolies. :^(

The latter remark walks precariously close to dismissing the entire
problem with an _ad hominem_ attack on the problem-claimers by
claiming they're just interested in profit.  I'm sure you didn't mean
it that way, though.

As several people have pointed out in the case at least of domain name
variants due to IDNA considerations, the plain fact is that all of the
negatives listed above are already problems _today_, except that there
is no automatic mechanism to make any of this work and that, in at
least some cases, the answer is simply that the user just can't get to
the domain that the user can type in.  So, as bad as the apparent
latent _ad hominem_, the objections aren't even realistic, since
they're already true.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 04 Jan 2010 15:58:54 -0800

> latent _ad hominem_, the objections aren't even realistic, since

Andrew,

While we agree there is a problem, asking for a specific solution 
"as-if" it were the _only_ solution motivated the comment based largely 
upon uncontested issues, IMHO.  Wasting resources has been emblematic 
behavior of those not challenged by competition.  Even assuming there 
was some practical manner in which to introduce zone cloning, affected 
users may not be happy with its resource costs.  My comments were not 
intended to play on emotions nor to denigrate those posing a question 
presupposing a zone cloning solution.

Not starting with a reasonable problem statement may have prematurely 
narrowed discussions with respect to zone cloning being seen as the only 
viable solution for syntactic or synonymic uncertainty confronting the 
use of IDNA.  Narrowing focus in this manner does preclude consideration 
of what might be less problematic and wasteful alternatives.

ACE label accommodation of Unicode in DNS was a disruptive change for 
many clients.  Timidity in not wanting to go back to those that just 
implemented these changes and ask for more is understandable.  However, 
reliance upon a zone cloning solution in DNS will further increase 
future difficulties when consolidating name resolution services.

-Doug

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 5 Jan 2010 10:00:13 -0500

On Mon, Jan 04, 2010 at 03:58:54PM -0800, Douglas Otis wrote:
> upon uncontested issues, IMHO.  

I don't understand: what specific solution do you think is being asked
for?  I have asked people to _think about_ and _discuss_ one possible
general area where we might make an extension to the DNS.  One result
of that thinking and discussion could surely be, "We think this is a
bad idea and we shouldn't do anything (more) here."  It's perfectly
legitimate to take the position that nothing should be done.  In my
view (and I say this not just as an individual, but also in my
capacity as a chair), it is quite another matter to suggest that the
very question is wrong, that we shouldn't even talk about it, and that
the only reason anyone might be interested in this is out of some
monopoly interest.  On a personal, no-hat note, the charge of
monopolism particularly bothers me in this case, because it's a
complete red herring.  _Someone_ is going to have to publish a given
zone, and though you can whittle away at how many things that body
does, zone publication is still a natural monopoly.  Sprinkling
magical competition dust over such monpopolies, as anyone with a
passing acquaintance with economic history knows, mostly just
increases costs, diminshes benefits, and usually results in broken
service.

> use of IDNA.  

Two things about this remark:

    1.  We are groping our way _toward_ a problem statement.  That's
    why we're having a discussion.  I take seriously the objection
    that the problem is underdefined right now.  Yes, we need to fix
    that, but we're not going to do it by refusing to talk about what
    the problem and solution spaces might look like.

    2.  This WG discusses changes to the DNS protocols.  It is not a
    forum for general discussion of ways to accomplish fun things with
    namespaces.  One of the conclusions we might draw is, "Yes, there
    is an interesting problem here, and it needs to be fixed, and we
    thing $SOMEONE should do it," where $SOMEONE is not-us and maybe a
    new WG or maybe an existing WG or maybe implementers of tools or
    maybe some class of people I haven't thought of.

> implemented these changes and ask for more is understandable.

Maybe you're unaware that an entire WG is in the throes of finishing
up, which WG was chartered precisely to ask those that just
implemented to go back and do something else, more complicated; and
that the publication of the resulting documents is held up exactly
because of the angry reaction from implementers about
backward-incompatible changes.  There are practical issues on all
sides.  All we can do is work on the issues for which we are
responsible, and come back with our best efforts.  Surely we can do
better than, "Not a problem!  Evil monopolist!  Go away!"

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Tue, 05 Jan 2010 11:34:21 -0500

> On Mon, Jan 04, 2010 at 03:58:54PM -0800, Douglas Otis wrote:
... _Someone_ is going to have to publish a given
> does, zone publication is still a natural monopoly.

Well, not to quibble completely unnecessarily, the original SRS 
proposal (Crispen, Crocker, Gaetano) did envision competition in the 
"registry function", rather than in the "registrar function", which is 
the model the US DoC selected for attempting to transform a 
competitive, single-source contract (the successor to the SRI-NIC 
contract) into a competitive market. So, as is, the registries are all 
monopolies.

Assuming that, hypothetically, VGRS operated the [a-m] spindles for 
some zone, and CORE operated the [n-z] spindles for the same zone, the 
construction of a single complete zone file from the union of two 
disjoint partial zone file fragments has multiple solutions.

So, not a "natural monopoly", but pretty natural assuming the SRS 
never ment shared _registry_ service, and always ment shared [access 
to unshared] registry service. There's probably only the four or so of 
us who remember.

   Sprinkling
> increases costs, diminshes benefits, and usually results in broken

Note, it isn't unreasonable to revisit the early Clinton 
administration deregulation decision and return to a monopoly registry 
service. The only unreasonable part is leaving that monopoly in the 
hands of an unregulated for-profit private actor.

>      the problem and solution spaces might look like.

Actually I think it is overspecified if the problem scope is 
restricted to "variants", I think the area of application is larger, 
and as an example, when proposing .nyc (it went to the City on 12/23), 
I proposed that the projections of two other zones (.museum and .coop) 
in either the flat, or hierarchical namespace(s) of .nyc be present by 
policy, and ease of implementation suggests that each registrant have 
the choice of managing only one set of resources for which two or more 
names map to.

For those keeping score, this is an application of the reciprocal 
cross registration that CNNIC, TWNIC, HKNIC and MANIC proposed to 
ensure that "unbundled" registrations resolved correctly across the 
four CDNC participant registries in mid-2001. Registry scoped bundling 
(of SC/TC mappings) is an alternative mechanism, and the one deployed 
today.

>      maybe some class of people I haven't thought of.

+1.

> better than, "Not a problem!  Evil monopolist!  Go away!"

+1.

Eric

---

From: Douglas Otis <[email-masked]>
Date: Tue, 05 Jan 2010 11:50:11 -0800

On 1/5/10 7:00 AM, Andrew Sullivan wrote:
>> "as-if" it were the _only_ solution motivated the comment based
>> largely upon uncontested issues, IMHO.
>
> I don't understand: what specific solution do you think is being
> asked for?

Paul Hoffman's statement on 12/14/09:
After denouncing a suggestion that application layer redirection
might offer a solution he said:

"For those who are on namedroppers but not IDNAbis: think of the two
FQDNs with a single owner who wants the two names to be synonyms.
ibm.com and ibm.net is a reasonable example. It does not matter how the
two names came into existence; in fact, that is a rathole that is not
relevant to the question."

This concept has since been called "zone cloning" or "cloning zones".
Zone cloning might place burdens upon users when applied at the TLD,
which, was the motivation for seeking a better solution, as explained in
Hiroshima.

> I have asked people to _think about_ and _discuss_ one possible
> bad idea and we shouldn't do anything (more) here."

Of course, more can be done. Solutions other than zone cloning have been
offered as well.  Can they be discussed as well?  Whether a solution is
found on the client or the server appears to be the crux of the matter.

This _does_ require an understanding as to why two names came into
existence, where implementing a redirection rather than a zone cloning
mechanism would conserve resources.  In addition, any client side
solution would provide better scaling characteristics as well.

There also appears to be misconceptions with respect to the resource
impact zone cloning at the TLD or SLD could entail.

> It's perfectly legitimate to take the position that nothing should
> be done. In my view (and I say this not just as an individual, but
> also in my capacity as a chair), it is quite another matter to
> suggest that the very question is wrong, that we shouldn't even talk
> about it, and that the only reason anyone might be interested in this
> is out of some monopoly interest.

You have misunderstood.  There are consumer related issues where
monopolies have been emblematically insensitive.  As such, these areas
of likely insensitivity should not be overlooked, especially in respect
to requisite resources.

> On a personal, no-hat note, the charge of monopolism particularly
> bothers me in this case, because it's a complete red herring.
> _Someone_ is going to have to publish a given zone, and though you
> can whittle away at how many things that body does, zone publication
>  is still a natural monopoly.  Sprinkling magical competition dust
> over such monpopolies, as anyone with a passing acquaintance with
> economic history knows, mostly just increases costs, diminshes
> benefits, and usually results in broken service.

The comment was intended to make proponents of a zone cloning solution
sensitive to resource impacts this could have on those then needing
to publish multiple domain names under a list of TLD and SLD cloned
names.  A zone cloning solution will subsequently require a significant
increase in the number of servers required to support DNS and the
reliant services.  This group should remain sensitive to the impact upon
requisite resources.

>> Not starting with a reasonable problem statement may have
>> prematurely narrowed discussions with respect to zone cloning
>> being seen as the only viable solution for syntactic or synonymic
>> uncertainty confronting the use of IDNA.
>
> 1.  We are groping our way _toward_ a problem statement.  That's why
> we're having a discussion.  I take seriously the objection that the
> problem is underdefined right now.  Yes, we need to fix that, but
> we're not going to do it by refusing to talk about what the problem
> and solution spaces might look like.

Such as why multiple names exist?

> namespaces.  One of the conclusions we might draw is, "Yes, there is
> an interesting problem here, and it needs to be fixed, and we thing
> $SOMEONE should do it," where $SOMEONE is not-us and maybe a new WG
> or maybe an existing WG or maybe implementers of tools or maybe some
> class of people I haven't thought of.
>
>> ACE label accommodation of Unicode in DNS was a disruptive change
>> for many clients.  Timidity in not wanting to go back to those
>> that just implemented these changes and ask for more is
>> understandable.
>

Agreed.  There is no desire to make anyone's task more difficult, but 
that alone should not determine the ultimate architecture.

-Doug