Subject: [idn] IAB letter on IDNs and VeriSign

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 27 Jan 2003 13:14:06 -0800

ICANN has recently posted a letter from the IAB to ICANN on the ICANN 
web site. The letter is the IAB's response to the way that VGRS is 
currently running the .com and .net TLDs. Folks following IDNs should 
be interested in it.

<http://www.icann.org/correspondence/iab-message-to-lynn-25jan03.htm>

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Soobok Lee" <[email-masked]>
Date: Tue, 28 Jan 2003 13:27:10 +0900

<quote>
[14] At the core of all of the IAB's concerns is the architectural principle that the DNS is a lookup service which must behave in an interoperable, predictable way at all levels of the DNS hierarchy. Furthermore, as a lookup service it is such a fundamental part of the Internet's infrastructure that converting it to an application-based search service, as the deployed system does, is not appropriate even in the case where the query presented would not normally map to a registered domain.
</quote>

I have to accept IAB's concerns about VGRS solutions. But,  if such solutions will be timedout and 
phased out after 2 years and operated with care under IAB's new "operational guidelines", those harms can be
minimized, while it will give great boostup to plugins distributions. I expect ICANN will consider the 
bright side of the solutions and make balanced decisions. Many asian region  NICs are considering to
  put even non-ASCII labels in their zone (not IDNA-compatibile) with slightly different approaches, even
after they become fully aware of those caveats behind their approaches.

IDNA/stringprep/nameprep introduce confusions,collisions and uncertainty to the DNS systems much more 
than VGRS specific implementation/deployment solutions does ,as explained in ICANN BoD's last resolutions in 
Shanghai.. IESG/IAB are willing to justify that IDNA by supplemental Registrations guidelines ?
If IDNA can be justified in such a way, why not VGRS solutions ?   :-)
Still I hope IAB can express such consistent conservatism  also to IDNA/nameprep itself, which is
the source of all these hassles....

Soobok Lee

----- Original Message ----- 
From: "Paul Hoffman / IMC" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, January 28, 2003 6:14 AM
Subject: [idn] IAB letter on IDNs and VeriSign

>,

---

From: John C Klensin <[email-masked]>
Date: Tue, 28 Jan 2003 03:37:13 -0500

--On Tuesday, 28 January, 2003 13:27 +0900 Soobok Lee 
<[email-masked]> wrote:

> <quote>
> [14] At the core of all of the IAB's concerns is the
> architectural principle that the DNS is a lookup service which
> must behave in an interoperable, predictable way at all levels
> of the DNS hierarchy. Furthermore, as a lookup service it is
> such a fundamental part of the Internet's infrastructure that
> converting it to an application-based search service, as the
> deployed system does, is not appropriate even in the case
> where the query presented would not normally map to a
> registered domain. </quote>
>
> I have to accept IAB's concerns about VGRS solutions. But,  if
> such solutions will be timedout and  phased out after 2 years
> and operated with care under IAB's new "operational
> guidelines", those harms can be minimized, while it will give
> great boostup to plugins distributions. I expect ICANN will
> consider the  bright side of the solutions and make balanced
> decisions. Many asian region  NICs are considering to   put
> even non-ASCII labels in their zone (not IDNA-compatibile)
> with slightly different approaches, even after they become
> fully aware of those caveats behind their approaches.

> IDNA/stringprep/nameprep introduce confusions,collisions and
> uncertainty to the DNS systems much more  than VGRS specific
> implementation/deployment solutions does ,as explained in
> ICANN BoD's last resolutions in  Shanghai..

Soobok,

With the understanding that I'm not on the IAB any more and did 
not participate in the writing of that statement...

First, designing anything for the Internet on the assumption 
that it will be deployed and then "phased out after 2 years" 
just doesn't recognize reality.  We have had almost zero success 
in "phasing things out" when they are deployed only on servers. 
The problem is much worse when implementations require replacing 
software on client machines and the protocols are still vaguely 
operational.  Our last success in making a major and rapid 
phase-out solution was the "phase out" of NCP. That was 20 years 
ago and with the benefit of credible threats to remove any host 
from the network which did not comply.

Second, there is no reason to predict that ICANN will do 
anything that is sensible, measured, and that shows a good 
understanding of either the technical or the policy issues of 
IDN deployment -- rather than just the short-term politics or 
agreement that internationalization is good.  Certainly the 
resolutions adopted in Shanghai should not be considered good 
news in this respect.  Those resolutions basically say "there is 
a problem, we should proceed carefully, and the lifetime of the 
so-far-ineffectual committee should be extended to work on it 
without changes that will make it more effective".

> IESG/IAB are
> willing to justify that IDNA by supplemental Registrations
> guidelines ? If IDNA can be justified in such a way, why not
> VGRS solutions ?   :-) Still I hope IAB can express such
> consistent conservatism  also to IDNA/nameprep itself, which is
> the source of all these hassles...

At the risk of reopening a debate that was never satisfactorily 
resolved, if the issue is merely one of permitting non-ASCII 
characters to be used in identifiers, with those identifiers 
being placed in DNS labels, IDNA is fine.  It may even be more 
complex and protective than is needed for that purpose (just as 
the LDH rules were more than is needed for strict identifier use 
in ASCII). To my knowledge, neither the IAB nor the IESG have 
taken a formal position on whether registration guidelines are 
either necessary or sufficient to resolve any presumed problems 
with IDNA.  If, by contrast, someone is expecting IDNA to solve 
the most general of user-interface searching and navigation 
problems, that expectation is completely unrealistic.  I think 
just about everyone knows that is the case at this stage, if 
only because it is clear that the DNS is inadequate to solve 
that problem for names that are restricted to ASCII.  Some 
marketing organizations might like to pretend otherwise, but 
that doesn't make success in use of the DNS as a general-purpose 
search environment any more likely.

So your point was?

    regards,
      john

---

From: "Soobok Lee" <[email-masked]>
Date: Tue, 28 Jan 2003 18:37:24 +0900

----- Original Message ----- 
From: "John C Klensin" <[email-masked]>
> in "phasing things out" when they are deployed only on servers. 

Your viewpoint is right in general, but may not in this special case in which
the centralized deployment of  VGRS solution is based on gTLD servers.
gTLD server will remain under centralized control of ICANN forever.
If ICANN order "turn off the 8bit-query support " after 2 years, 
VGRS should follow. From then on, end users should install 
the plugins manually. I can't see any big problem here...

> from the network which did not comply.

The disputed problematic part of VGRS solutions is not the end user
plugins, but rather the use of central gTLD servers as plugin installation triggers. 
ICANN can control that so that such _special_ usage  end sometime.

> without changes that will make it more effective".

Yes.

> with IDNA

I hope to see their knowledgeful and thorough comments soon.

> If, by contrast, someone is expecting IDNA to solve 
> problems, that expectation is completely unrealistic. 

I agree. directory/searching should be layered above DNS.  but
such layer is not the mandatory one in IDNA nor ever mentioned
even though it is recognized as necessary one. There were many ideas
proposed around this issue, and i know there was even yours.
 
>  I think 

I feel that I have no more energy  to revisit this issue or resist the inertia.
Anyway , Don't we have proposed standards ?   :-)  
 
Soobok Lee

---

From: Steve Dyer <[email-masked]>
Date: Tue, 28 Jan 2003 10:14:08 +0000

>the plugins manually. I can't see any big problem here...

Surely 8-bit support is a current characteristic of DNS? - certainly BIND 
supports the transit of most ASCII 8-bit characters and this is good 
functionality.
It is the way that VeriSign has altered the functionality of DNS handling 
8-bit data in a normal fashion to using codes over 127 for their own 
corporate purposes that is the issue here.

We should not alter the functionality of standard DNS and neither should we 
accept the need for a client-side plugin to make an Internet protocol function.
We should also not accept a system which introduces duplication into the 
DNS - a DNS request should supply a single unequivocal answer.

Regards

Steve Dyer

---

From: "Michael Froomkin - U.Miami School of Law" <[email-masked]>
Date: Tue, 28 Jan 2003 09:29:03 -0500 (EST)

I do not think we should adopt such a defeatist attitude in the face of
what is generally incompetence and self-interested regulation.  

> gTLD server will remain under centralized control of ICANN forever.

[OB merits: Not that this means I support VRSN in this case -- but I don't
think ICANN is either the answer or a necessarily a permanent fixture.]

-- 
		Please visit http://www.icannwatch.org
A. Michael Froomkin   |    Professor of Law    |   [email-masked]
U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
+1 (305) 284-4285  |  +1 (305) 284-6506 (fax)  |  http://www.law.tm
                        -->It's cool here.<--

---

From: "Soobok Lee" <[email-masked]>
Date: Wed, 29 Jan 2003 00:08:22 +0900

----- Original Message ----- 
From: "Michael Froomkin - U.Miami School of Law" <[email-masked]>
To: "Soobok Lee" <[email-masked]>
Cc: "John C Klensin" <[email-masked]>; <[email-masked]>; "Paul Hoffman / IMC" <[email-masked]>
Sent: Tuesday, January 28, 2003 11:29 PM
Subject: Re: [idn] IAB letter on IDNs and VeriSign

> > gTLD server will remain under centralized control of ICANN forever.

I happily do this:  s/ICANN/ICANN or its successor/; 
I forgot that ICANN has been allowed another 1 year  from US DoC...   Sorry to hurt your mind.
 
Soobok

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Jan 2003 10:38:08 -0500

> what is generally incompetence and self-interested regulation.  

That's what I keep telling myself about the US government.  Though I'm still
not sure what else to do about it.

> think ICANN is either the answer or a necessarily a permanent fixture.]

I'd like to believe the same is true of VRSN, which has historically been much
more abusive and far less subject to any useful kind of scrutiny than ICANN.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 29 Jan 2003 11:09:51 -0800

Michael,

"Defeatist" implies a battle about the DNS administrative model.

If you can point to a credible technical proposal for a DNS
administrative model that does not hinge on a centralized, core
authority over the namespace, please feel free to produce it. After this
many years of debate, it is noteworthy that none has been forthcoming.

d/

ps.  "credible" means that the specification is thorough, has been
subject to extensive technical review, and has garnered significant
support within the Internet technical and administration communities.

Tuesday, January 28, 2003, 6:29:03 AM, you wrote:
MFUMSoL> I do not think we should adopt such a defeatist attitude in the face of
MFUMSoL> what is generally incompetence and self-interested regulation.

>> gTLD server will remain under centralized control of ICANN forever.

d/
-- 
 Dave <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 t +1.408.246.8253; f +1.408.850.1850

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 30 Jan 2003 13:05:44 +0100

>many years of debate, it is noteworthy that none has been forthcoming.

Without even quoting the way all this was created, I can do that without 
any problem: ICP-3.
I quote : "it [does not] preclude the ultimate introduction of new 
architectures that may ultimately obviate the need for a unique, 
authoritative root."

Please, let not confuse the management of the Postel Legacy "interneted" 
system with specific targets and rules (which worked well) and the 
management of the world e-network system "cataneted" into a single 
"netcontinuity" (we will come back on these key words below). There is no 
opposition, just work to carry in common.

>support within the Internet technical and administration communities.

"credible" certainly means such an extensive technical review but most of 
all it requires the "responsible experimentation [which] is essential to 
the vitality of the Internet" (ICP-3). This is why "to ensure that 
community-based policies take precedence [.] ICANN encourages responsible 
experimentation designed to further advance the Internet as a useful, 
stable, and accessible medium for the public good." (final sentence of the 
ICP-3 document).

The point you make well is that the Internet *administration* community 
must approve it. This means that the experimentation must also be societal 
(all what we commonly name "mission creep") and political (the governance 
of the name space, GAC, etc), "within a community-based framework (such as 
the IETF)" (ICP-3). This is the purpose of the dot-root project: to set-up 
and propose a well identified real life test bed for the global community 
(anyone welcome to join and help) to test possible progresses in the global 
DNS management area. Because the IETF alone is not equipped to address 
layers 8 and above. This is why we keep informing the IETF (an informative 
draft author would be welcome) as no technical solution can become a 
consensus outside of the IETF.

The two dangers we face are obviously:

- the confusion of the "Internet administration community" with ICANN (may 
be renaming ICANN after Internet Community for Administration of Names and 
Numbers would help). The current americanism of ICANN is a layer 9/10 
issue: it should not result into the layer violations we experiment (under 
the subtle form of pressures to protect us against ... such possible 
violations).

- the other one is to confuse the international and the legacy namespaces 
rules too fast. Since 1984 (when Internet entered the International 
namespace through the RFC 920, which in turns legitimates ICP-3, [cf 
ICP-3.1 para 4]) things have stayed the same ("status quo") on the Internet 
side, while they changed outside and the whole world's e-network 
distribution changed with the web application. This means that aggregation 
cannot be carried only in resuming the initial arrangements: but it may 
certainly take advantage,
a) from the initial experience, from a good analysis and understanding of 
the Postel's system
b) from a seriously engaged testing by the largest number,
c) including people not familiar with IETF (developing countries which have 
particular needs, specialized community (could be TLDs) SLDs, etc.

There are basically two directions. Status quo and a slow and progressive 
enlargement of the number of TLDs. This will not go very far since the only 
model ICANN knows is the current TLD contracted/yearly subscribed DN model 
imposed on the Internet by accident, rather than planed, to address a 
closed private interconnected environment (what Vint referred to as 
"internetting").

The second model is a parallel root server deployment, under mutual 
consistency control. The key issues to work on and test are:

- the root file automated maintenance from the TLD Managers' data (this 
call for a long testing
permitting to check the accuracy and the stability of the result).

- the meaning and check of what "consistency" technically ,societal and 
politically means.

This model may obviously take advantage from the initially netcontinuity of 
the Intl namespace as created and managed by Tymnet for the monopolies 
under the FCC/ITU rules and with the concerted support of the ISIS 
(Operators/Large private nets) Clubs. And from of what Louis Pouzin 
explained about "catenet", catenating the different namespaces - what lead 
in a way to the OSI.  Also from the experience of the global roots.

But the final solution will obviously be a common, commonly tested, 
commonly approved, commonly used one. Commercial ventures in the namespace 
such as Verisign and New.net are necessary to keep moving but are post 
probably not to be the final model (IMHO the final model calls for 
life-long, free community oriented, legally protected, network pointers of 
the mnemonics, trade marks, personal names - the way they were created 
(1977/78) and the way Internet implemented them (1984)). In the respect of 
the users', markets', states' demands, of the DNS implementation, and of 
every experiences.

Now, the IDNs should have had no real bearing of this, as they should have 
been transparent to the DNS. Unfortunately the WG-IDN proposition is not 
transparent to the DNS both technically (as you know IMHO it introduces a 
cross left to right hierarchy in the namespace though the ACE label) and 
administratively (the babel name issue). Also it is not proposed in 
consistence with the global URL architecture. This leads to the above 
mentioned necessity of a real life testing and of a plug-in solution.

In having only considered the punycode aspect and not the global problem 
(market expectation, technicalities, operations, deployment, economical 
model, user architecture, network architecture, collateral innovation 
possibilities, real world market habituses, de facto technologies standard, 
legal and cultural impacts, etc..) it left others such as Walid and 
MicroSign to work on them. The problem is the ROI of that work. You cannot 
expect an investor to work everything, for everyone for free. So instead of 
a community (GPL) solution worked out, experimented and deployed together 
we have reached the present situation.

What is the way out?

IMHO we have reached a situation where those concerned in real their IP 
protection, businesses, large non-profit organizations (ccTLDs, specialized 
SLDs, i-dns, Verisign, Microsoft, Walid, etc. may be with chips 
manufacturers, GAC, WTO due to the industrial and trade management impact 
though the impact on the URL) should sort out a practical solution based 
upon an open/GPL plug-in architecture standard agreement, preserving their 
innovation and commercial rights but insuring a stable, secure and 
innovation capable solution.

This will certainly have an impact on the DNS in three ways :

- the ultimate support of Unicode names in the DNS you call for
- the support of network extended services in the DNS area (DNS+) I work on
- the support of many new script TLDs replicating the ASCII TLDs as we see 
that John's propositions and my clumsy patch cannot go really through 
without a complete review of the internetting architecture (what is maybe 
also under way?)

Now, what are the alternatives. All this has to be tested.

- Either it is tested on a local basis (China, Far East) with solutions and 
experiences staying local to this area plus to a limited number of 
commercial ventures supporting them,

- Or all these experiences can aggregate into a common project such as 
dot-root or a super consensus, and solutions, experience and innovation 
will be open to all. I push for that otherwise we will have a technology 
split of the nets.

IMHO the whole future of the Internet is at stake and parts of the world 
industrial development as adressing and human infterfaces are key part of 
many system/appliances design. The ill presentation of some parts of ICP-3 
have screened the most positive parts of the document and lead ICANN 
orignated delays and confusion, as if Stuart Lynn had not had the time to 
read it.

jfc

---

From: "Michael Froomkin - U.Miami School of Law" <[email-masked]>
Date: Thu, 30 Jan 2003 08:44:57 -0500 (EST)

*sigh*

This is a troll.  As you well know, there are two issues:

1. merits of centralization
2. abuse of centralized power.

Let's hypothesize agreement on the virtues of (1) which, whether or not
they are worth the costs, are indisputably real.  I, for one, have never
argued in favor of any system that would result in name collisions.

That leaves (2).

I have on a very large number of occasions written about the cures to (2)
without in any way harming the virtues properly deriving from (1).  The
beneficiaries and fellow travelers of the dominant faction in ICANN
wish, of course, to confuse the two issues, but they are in fact quite
separate.

In short, you can have centralization, and a single root, without ICANN.
Indeed, we did it before ICANN, and we'll do it after ICANN.

Incidentally, your definition of credible is risible in this context.  
The issue is in almost no way whatsoever technical once one agrees on the
single root aspect.  It is almost entirely political (and economic!).

As for consensus, my sense at the last INET meeting was that there was a
rough consensus that ICANN was a failure.  There were, however, divisions
as to whether it was a dangerous failure or just an ugly one.

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Jan 2003 09:07:30 -0500

> In short, you can have centralization, and a single root, without ICANN.

Yes, you can.  The real question is whether, given the political forces in
play, you can improve much on ICANN in practice.  My assesment has been, and
continues to be, that if you try to create a replacement for ICANN you are far
more likely to do significantly worse than significantly better.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 30 Jan 2003 07:05:41 -0800

Michael,

The main effect of your clarification is to show that you want to pursue
a topic that is irrelevant to the venue and topic.

This is a technical venue and the topic is a technical matter.

You already use plenty of other venues for your ICANN-bashing mantra.

d/

Thursday, January 30, 2003, 5:44:57 AM, you wrote:

MFUMSoL> 1. merits of centralization
MFUMSoL> 2. abuse of centralized power.

MFUMSoL> Let's hypothesize agreement on the virtues of (1) which, whether or not
MFUMSoL> they are worth the costs, are indisputably real.  I, for one, have never
MFUMSoL> argued in favor of any system that would result in name collisions.

MFUMSoL> That leaves (2).

d/

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 30 Jan 2003 07:40:11 -0800

>In short, you can have centralization, and a single root, without ICANN.

And this discussion is relevant to the IDN WG in what way?

--Paul Hoffman, Director