Re: [ga] Re: ICANN & Stability

[eric@hi-tek.com]

Stuarts' post seems almost surreal.  It clearly shows a complete lack of
reality.
After many years in fields such as Ministry, Law and Philosophy and a degree
in psychology I recognize this as one of two things and probably a combination
of both - delusion and deception.
That is a problem but the bigger one is that it appears to be a collective
problem.

eric

Karl Auerbach wrote:

> On Mon, 16 Sep 2002, M. Stuart Lynn wrote:
>
> > .. Three of the ccTLD requests for migration have not yet been completed
> > because the ccTLD operators have (despite repeated requests) failed to
> > cooperate in allowing the IANA to perform technical checks as provided
> > by longstanding IANA policy.  See the FAQs at
>      ^^^^^^^^^^^^^^^^^^^^^^^^
> > <http://www.iana.org/faqs/tld-zone-access-faq.htm> for a description
> > that we recently posted summarizing for ccTLD managers the policy, its
> > longstanding basis (documented back to RFC 1591 in March 1994), and the
> > means by which those seeking to change the policy should proceed.
>
> Longstanding? No. By-ICANN fiat? Yes.  Technical foundation: Absent.
>
> This so-called "longstanding" policy appeared as if by magic from
> ICANN/IANA (can you tell the difference? I guess is that the ICANN label
> means that there is a least a pretense, albeit usually merely a pretense,
> of public comment.)
>
> RFC 1591 says nothing about requiring zone transfer access so that
> ICANN/IANA may dredge to an unlimited degree in the subsidiary zone's
> data.
>
> The extremely limited validation that is needed to check that a DNS
> delegation works can easily be done by running actual DNS queries rather
> than by demanding the right to rummage through a ccTLD (or gTLD's) entire
> database.
>
> It inconsistent for ICANN to claim on one hand that net stability (a term
> never defined by ICANN) requires that ICANN intrude into the zone files of
> ccTLDs to evaluate the "quality" of that zone data while on the other hand
> that that apparently long delays (such as have occurred with .nz) have no
> such impact on net stability.
>
> I would like to know the *precise* techical basis for the assertions made
> in http://www.iana.org/faqs/tld-zone-access-faq.htm that flaws in
> subsidiary zones (such as a ccTLD) can have a negative impact on the
> parent zone.  (A variation of this same assertion has been made with
> regard to the euphonically named NTEPPTF report.)  As far as I can tell,
> such claims are specious and without merit.
>
> If DNS were as feeble and weak as ICANN asserts then the net would be open
> to a vast denial of service attack - bad people could bring down the net
> simply by building incorrect zone files.  But for more than a decade
> people have been building bad zone files, creating lame delegations, and
> pointing NS and glue records into never-never land.  Yet DNS and the net
> still run.  Why?  Because in DNS, the flow of control is from the top down
> (the way ICANN likes) rather than from the bottom up.  Errors in
> incorrectly configured subsidiary zones do not propogate upwards.
>
> The limit to ICANN's needs for quality in root data is merely to ensure
> that the delegation records for a subsidiary zone (e.g. a ccTLD) are
> correct and that any glue records are valid.
>
> As usual, ICANN looks for reasons to tread where ICANN ought not be
> treading - ICANN is like a telephone repairman who insists that repairing
> your home telephone requires that he have unlimited ability to inspect the
> bedroom and other private living quarters.
>
> To withhold updates to ccTLD delegation information because the ccTLD
> operators refuse to acceed to unjustifiable and excessive intrusions from
> ICANN is improper.
>
>                 --karl--
>
> --
> This message was passed to you via the ga@dnso.org list.
> Send mail to majordomo@dnso.org to unsubscribe
> ("unsubscribe ga" in the body of the message).
> Archives at http://www.dnso.org/archives.html

--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html