ICANN/DNSO
DNSO Mailling lists archives

[ga]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [ga] Re: ICANN & Stability


Alexander and all assembly members,

  Although the explanations that Alex provides below are to a small degree
correct, they are also overly simplistic as well.  (See more below
Alex's comments/statements ).

Alexander Svensson wrote:

> At 17.09.2002 14:58, DannyYounger@cs.com wrote:
> >Stuart,
> >
> >As a reasonable man, do you plan to protect the stability of the Internet by
> >acceding to the reasonable request for these nameserver updates while the
> >ICP-1 policy is re-examined?
>
> This standoff is painted a bit too dramatic by both sides.

  Perhaps, and than again perhaps not.  First Alex, let's not forget
that ICANN's ICP-1 is not broadly supported by the stakeholders/users
and does not, and never has enjoyed any form of consensus amongst
the Registry part of those stakeholders/users.

>
>
> ICANN is insisting on a principle (first a zone transfer, /then/
> a nameserver), although it probably does not expect that giant
> ccTLDs like .de/DENIC have malformed root zones which the ccTLD
> operator does not check for RFC compliance.

  RFC compliance is silly really as RFC are not standards and never
have been nor were intended to be.  RFC's are Requests for Comments,
nothing more.

>
>
> The ccTLDs are insisting on a principle (no zone transfer to
> IANA), although they probably do not expect ICANN to use the
> data for illicit purposes and they can get written assurances
> required by national privacy laws.

  National privacy laws do and should supersede anything ICANN
wishes to impose upon the ccTLD's or for that matter any TLD what
so ever in any country.

>
>
> The main problem is the lack of detailed and accepted procedures.
> RFC 1591 is not clear: "There must be a primary and a secondary
> nameserver that have IP connectivity to the Internet and can be
> easily checked for operational status and database accuracy by
> the IR and the IANA." Operational status and database accuracy
> can be checked in various ways. The controversial ICP-1 is
> supposed to contain only existing policies; however, this
> specific policy has only been enforced from time to time during
> 1999-2001. It is understandable that ccTLD operators perceive
> this as a new requirement -- for them, it /is/.

  ICP-1 is not a broadly excepted policy.  Unless or until it is
it is not really relevant as to the newness of it to any registry.

>
>
> The issue behind the problem is of course the ccTLD-ICANN
> relationship. Some ccTLDs continue to talk to ICANN like customers
> of a provider of root services, because that's what they want
> it to be. ICANN continues to talk to ccTLDs like the Guardian
> of the DNS, rigidly applying its requirements even -- or rather:
> especially -- in cases where swift action is needed.

  Good point here.  The ccTLD's are correct.  ICANN is not.
The White Paper and the MoU make the nature of this relationship
clear.

>
> ICANN seems to think: If we allow one change of a nameserver
> entry without exercising our rights, we might lose them.
> Some ccTLD seem to think: If we allow ICANN to inspect our
> zone files, we accept some form of ICANN "supremacy" forever.

  And both assumptions could not be further from actual operational
fact or good practice.

>
>
> In the end, we need to discuss the ICP-1 requirement again,
> without the question of precedents obscuring the view.

  Precedents never obscure an accurate view.

>
> CENTR states: "Whilst some tests could be conducted on the zone
> file - such as for syntactic correctness - we do not believe
> they are of sufficient importance to justify the need for zone
> transfers." (http://www.centr.org/news/ICANN-AXFR.html)
> ICANN a.k.a. IANA states: "Proper DNS configuration of all TLD
> zones is a global, not just a local, issue."

  I agree with this view, and it is logical.  However others may not.

>
> (http://www.iana.org/faqs/tld-zone-access-faq.htm)
>
> Why not set up a small, technically oriented task force with
> people from ICANN and ccTLDs to find out what checks ICANN
> would have performed, how these checks could be performed
> without transferring zone files or at least in a much more
> secure way. If the ccTLDs have to be content with a written
> assurance by ICANN that their data will not be misused,
> ICANN should equally be content with a written assurance by
> the ccTLD operator that a suite of consistency tests has
> been performed according to mutually agreed procedures.
> Of course, some ccTLDs may actually prefer to have ICANN
> perform the tests independently.

  This would be a good approach if and only if ICANN was
trusted.  However presently ICANN has shown clearly that
it is not to be trusted.

>
>
> Best regards,
> /// Alexander
>
> --
> 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

Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup - (Over 127k members/stakeholders strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@ix.netcom.com
Contact Number: 214-244-4827 or 972-244-3801
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208


--
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



<<< Chronological Index >>>    <<< Thread Index >>>