Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same")

From: "Jeffrey A. Williams" <[email-masked]>
Date: Mon, 30 Aug 2010 12:43:25 -0500 (GMT-05:00)

Paul and all,

  Sorry Paul but I have to disagree with your contention
as well ICANN's 'Problem Statement'.  That 'Problem Statement'
is in effect a political one that does not address the 
current demand.  IDN's of many variations are coming wheather
or not ICANN likes it as such decisions are of particular
national/nations interest.  Therefore syncrinization into
the name space via a DNS hack is preferrable if not
necessary. ISO3166 TLD's namespace is and has been out of date
now from a public demand standpoint for a few years.  Multipul
IDN TLD name spaces already exist most o which are not syncronized,
some will perhaps never be, and those that will or wish to be
will not relinquish their established customer base easily
or simply based on ICANN's desire.  Same is and has been true
for other non IDN TLD's for several years now AND was acknowledged
by DOC/NTIA way back in 2002.

-----Original Message-----
>From: Paul Vixie <[email-masked]>
>Sent: Aug 30, 2010 11:10 AM
>To: [email-masked]
>Subject: [dnsext] regulatory problem statement (was Re: ... as "the same")
>
>> Date: Mon, 30 Aug 2010 10:44:34 +0200
>> From: Stephane Bortzmeyer <[email-masked]>
>> ...
>> Unless you claim that *every* IDN TLD require synchronization of content
>> (something that not everyone will agree with) *and* that this
>> synchronization requires a non-provisioning method to be done, something
>> that you often repeat but which is not true.
>
>ICANN's regulatory regime (such as it is) makes adding "new tld's" difficult.
>it is very hard to create a new IDN TLD which isn't synchronized to a current
>one since this would run afoul of competitive issues ("why does CNNIC get so
>many TLD's and my national name registry get so few?") and also commercial
>issues ("you're calling that an IDN TLD but it is basically another .COM for
>a specific language and has no relation to any ISO3166 TLD's namespace.")
>
>it is comparatively much easier for ICANN to create synchronized IDN TLD's
>since they are just new windows into an existing namespace.  provisioning
>hacks are not a strong enough guaranty that synchronization will occur --
>ICANN is doing it now just to get things started but they will not do it for
>the many hundreds/thousands of IDN TLD's yet to come.
>
>if everybody here could expand their horizons a bit, stop looking at this as
>a simple engineering problem where the simplest/cheapest solution is usually
>the right one, then we'd stop seeing the repeated refuge of "just use a
>provisioning hack and stop asking for a protocol change".  that will not work
>since the problem statement is in ICANN's regulatory regime not in the DNS.
>
>ICANN has been uncharacteristically clear about this, and yao has explained
>it several times, and i've explained it at least once.  no provisioning hack
>of any kind will answer ICANN's problem statement.  please stop proposing it.
>
>> Please provide hard facts, not just hand-waving about IDN. We can
>> deploy IDN (actually, it is already done) without xNAME. 
>
>done.  (again.)
>
>> Domain synchronization is not an IDN issue. (I would like to have
>> bortzmeyer.fr and bortzmeyer.org synchronized, even if they are ASCII
>> names.)
>
>sounds as if you'd appreciate SHADOW then.  but, IDN TLD's have regulatory
>issues that your personal domain does not have, so, the situations are not
>similar.
>

Regards,
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Mon, 30 Aug 2010 17:21:49 -0500 (GMT-05:00)

Paul and all,

  I think your right that ICANN in particular is not
going to go along with "provisioning hacks" as will not
some larger and more complex domain holder could want to 
do multivendor as you say below.  But some more complex 
domain holder may do so if the reward could be seen worth
the precieved risk on the business side of the equation.

  The above said for me anyway and others I know of, 
wheather or not ICANN goes along or likes "provisioning hacks"
or not is irrelevant to what is underway or already exists
in the wild now.  However some more complex domain name holders
may be less 'Hivish' and see significant rewards looking
at taking some advantage of "provisioning hacks" that arn't
already doing so but not advertizing they are.  >;)

-----Original Message-----
>Sent: Aug 30, 2010 3:23 PM
>Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") 
>
>> Date: Mon, 30 Aug 2010 20:19:18 +0100
>> From: Alex Bligh <[email-masked]>
>> ...
>> Or, is what you are saying, that if ICANN proposes a technical solution
>> for a political problem, and says jump, we should merely ask how high?
>
>neither.  i'm saying that the DNS is not just a technological device, it
>is also extant as an economic and political device.  the root and its TLDs
>have always been handled differently than private domains.  we've already
>pulled DNSSEC off the rails once for TLD's (see 5155) and once for the root
>(see RFC 5011) so i'm just not ready to hear that we won't take real world
>needs into account when doing our engineering.
>
>in fact an engineer who doesn't take real world needs into account cannot
>succeed.  (see <http://oreilly.com/catalog/opensources/book/vixie.html>.)
>
>> To the specific point:
>> 
>> > provisioning hacks are not a strong enough guaranty that
>> > synchronization will occur
>> 
>> From a technical point of view, I am far from convinced that
>> synchronization is a good thing, whatever ICANN thinks.
>
>ICANN (speaking of the community, not the staff) is a hive mind and you can
>not usefully ask what it thinks.  i'm describing its (reality) constraints.
>
>> If it is, what ICANN gives, ICANN can take away, and thus a contractual
>> solution is perfectly possible.
>
>that's a pure engineering mindset speaking, and i strongly suggest otherwise.
>
>> If this (strong guarantee of synchorization) is the only reason to do
>> this, I would say "don't do it".
>
>it's not the only reason.  and when i proposed SHADOW i had other uses in
>mind, such as the symmetry i'd like to have in the namespaces at VIX.COM,
>VIXIE.ORG, VIXIE.SF.CA.US, and maybe others i'm forgetting here.  the only
>difference is, for me personally, provisioning hacks can also be used.  but
>ICANN is not the only entity for whom that's not true.  any larger and more
>complex domain holder could want to do multivendor in a way that would make
>the "provisioning hacks" approach really expensive (in TCO terms.)
>

Regards,
Jeffrey A. Williams

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 31 Aug 2010 13:34:31 -0500 (GMT-05:00)

dave and all,

-----Original Message-----
>From: David Conrad <[email-masked]>
>Sent: Aug 30, 2010 10:49 PM
>To: Andrew Sullivan <[email-masked]>
>Cc: [email-masked]
>Andrew,
>On Aug 30, 2010, at 3:42 PM, Andrew Sullivan wrote:
>> Where exactly is ICANN's problem statement?  As one of the chairs who needs to agree to herd this work through the IETF, I'd like to see it.
>
>An understandable request.  While not "ICANN's problem statement", I gather you do not believe http://tools.ietf.org/html/draft-yao-dnsext-identical-resolution-00 is sufficient?
>
>> The only actual evidence we have from ICANN is that they _can_ do what they thought the synchronization stuff would achieve with provisioning, because in fact they already have.
>
>I believe the concern is that this is analogous to the person who fell off the Empire State building being heard to say "So far, so good" as he passed each floor on the way down...

ROFLMAO!  My father used to make this same analogy in some situations for
years before his death!  The problem with it is that even when the person
reaches that sudden stop at the bottom, he/she doesn't know if the situation
is still good because his/her death is immediate.  
>-drc

Regards,
Jeffrey A. Williams