Subject: GA-DIGEST V1 #1436
From: [email-masked] (GA-DIGEST)
To: [email-masked]

GA-DIGEST        Wednesday, September 25 2002        Volume 01 : Number 1436

----------------------------------------------------------------------

Date: Wed, 25 Sep 2002 00:24:11 EDT
From: [email-masked]
Subject: [ga] Antitrust Violations

The registrar constituency recently held a meeting in Amsterdam.  By 
definition such a meeting is a collaboration of competitors which per se is 
not a violation of antitrust law.  However, if such a meeting results in the 
collusion among parties to an agreement to reduce services below what would 
likely prevail in the absence of the relevant agreement, this would 
constitute a violation of the "Antitrust Guidelines for Collaborations Among 
Competitors" issued by the Federal Trade Commission and the U.S. Department 
of Justice, and might well be actionable.

The minutes of this meeting (posted on the registrars' website) contain the 
following statement:

"Palage: Current ICANN structure allows some people to have influence over 
how we conduct our business. Nothing prevents the IP or other constituency 
from framing rules that make impossible a diverse reseller network. Several 
slippery slopes we are looking at. Therefore it is vital that registrars be 
perceived as holding the power to pay the bills. Registries and registrars 
have not seen eye to eye on many issues. However, contracting parties can 
agree to have certain proposals not become policy." 

A collusion on the part of registrars with registries to not allow certain 
proposals to become policy is assuredly an antitrust violation, as without 
such collusion such proposals might well result in enhanced Community 
services.  I would like to give Michael Palage an opportunity to discuss this 
matter in depth before it becomes necessary to take further action.

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

------------------------------

Date: Wed, 25 Sep 2002 01:19:33 -0400
From: "John Berryhill" <[email-masked]>
Subject: RE: [ga] Antitrust Violations

>
> A collusion on the part of registrars with registries to not
> allow certain
> proposals to become policy is assuredly an antitrust violation,

No.  Fixing prices among competitors is an antitrust violation.  Are you
saying that every lobbying organization in Washington is engaged in
anticompetitive collusion?  When the automobile manufacturers pool their
lobbying efforts to dissuade Congress from raising fuel efficiency
standards, they are not violating anti-trust law.  Business associations,
professional societies, and standards organizations all involve cooperative
efforts among economic competitors to regulate practices and policies.  They
are not colluding to fix prices.

One of the things I believe Mr. Palage was driving at was the disconnect
between the standard domain registration contract terms required in the
registrar accreditation agreement, which assumes a registrar-registrant
relationship, and the practice among some up and coming registrars of
building a business model around a registrar-reseller-registrant
relationship.  However, putting specific words into his mouth on the basis
of abbreviated minutes which he may not have read or approved is hardly
fair.

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

------------------------------

Date: Wed, 25 Sep 2002 01:45:20 EDT
From: [email-masked]
Subject: [ga] Re: Antitrust Violations

First set of comments in reply to Ray's question, with the following set in 
response to John Berryhill:

regarding the comment that "Therefore it is vital that registrars be 
perceived as holding the power to pay the bills." -- I take this to be a 
reference to the fact that the only "power" the registrars enjoy is the power 
of being perceived to be paying for 55% of ICANN's total budget.  

In reality, the registrars are aware that ICANN planned to shift payment 
responsibility away from the registrars and into the sole hands of the 
registries from whom collection would be far easier.  

Consider these excerpts from the Minutes of the May 4, 2001 Registrar 
Teleconference: 

"Concern over fee structure.  Attempting to remove registrars from ICANN 
billing, because certain registrars are not paying.  What registrars are not 
paying?  Under the proposed agreement the registry will be liable to ICANN 
for registrar fee component. Therefore, registry will bear enforcement 
obligations. Arguably registries 
could collect this new fee component upfront instead of in the rears." 
http://www.icann-registrars.org/pdfs/Minutes-teleconference-4-may-2001.PDF

Further comment on this topic was provided in the Stockholm Registrar minutes:

"Rob Hall then provided an update of the ICANN budget committee. He noted 
that the registrar representatives succeeding in maintaining the status quo 
regarding payment terms. There was a push by ICANN to shift payment 
obligations from the registrars to the registry. There was grave concern 
among registrars that this would dilute our voice in the process."  
http://www.dnso.org/clubpublic/registrars/Arc01/doc00034.doc 

Registrars like to think that its "their money" that is making these 
payments, even while we all know that it comes directly from the registrant 
registration fees.  They are scared by the prospect that they will lose power 
if all payments are instead collected by the registries.  In such a case they 
could no longer claim any special treatment based upon the fact that they 
allegedly provide ICANN with the bulk of its funding.

- ---------------------

John, you should well know that fixing prices is only one element in 
antitrust cases.  I refer you to 
http://www.usdoj.gov/atr/public/guidelines/redir5.htm for other relevant 
considerations.  Contrary to your assumption, Mr. Palage was driving at 
something other than the disconnect to which you have referred -- he was 
specifically commenting on the ERC proposal to grant contracting parties 
voting rights equivalent to the collective remainder of the GNSO 
constituencies.   This would allow registries and registrars effective veto 
power over the proposals put forth by the rest of the community (as the other 
constituencies could never attain the requisite two-thirds vote needed for a 
consensus policy if such a proposal was thwarted by this particular 
self-interested bloc).

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

------------------------------

Date: Tue, 24 Sep 2002 23:31:29 -0700 (PDT)
From: Rick Wesson <[email-masked]>
Subject: Re: [ga] Re: Antitrust Violations

Danny,

You can make things better.

I've watched your posts over the last few weeks; your doing your research
but still coming up empty.

Might I suggest you start posting proposals along with your commentary so
that we can evaluate your insiteful comments with a method to a better
place/way/procedure.

everyone can point fingers, make accusations and spread FUD, those that
can do the "real work" of developing proposals, and moving them through
some consensus development process are the folks that should be
encouraged.

whom do you want to be?

- -rick

On Wed, 25 Sep 2002 [email-masked] wrote:

> First set of comments in reply to Ray's question, with the following set in
> response to John Berryhill:
>
> regarding the comment that "Therefore it is vital that registrars be
> perceived as holding the power to pay the bills." -- I take this to be a
> reference to the fact that the only "power" the registrars enjoy is the power
> of being perceived to be paying for 55% of ICANN's total budget.
>
> In reality, the registrars are aware that ICANN planned to shift payment
> responsibility away from the registrars and into the sole hands of the
> registries from whom collection would be far easier.
>
> Consider these excerpts from the Minutes of the May 4, 2001 Registrar
> Teleconference:
>
> "Concern over fee structure.  Attempting to remove registrars from ICANN
> billing, because certain registrars are not paying.  What registrars are not
> paying?  Under the proposed agreement the registry will be liable to ICANN
> for registrar fee component. Therefore, registry will bear enforcement
> obligations. Arguably registries
> could collect this new fee component upfront instead of in the rears."
> http://www.icann-registrars.org/pdfs/Minutes-teleconference-4-may-2001.PDF
>
> Further comment on this topic was provided in the Stockholm Registrar minutes:
>
> "Rob Hall then provided an update of the ICANN budget committee. He noted
> that the registrar representatives succeeding in maintaining the status quo
> regarding payment terms. There was a push by ICANN to shift payment
> obligations from the registrars to the registry. There was grave concern
> among registrars that this would dilute our voice in the process."
> http://www.dnso.org/clubpublic/registrars/Arc01/doc00034.doc
>
> Registrars like to think that its "their money" that is making these
> payments, even while we all know that it comes directly from the registrant
> registration fees.  They are scared by the prospect that they will lose power
> if all payments are instead collected by the registries.  In such a case they
> could no longer claim any special treatment based upon the fact that they
> allegedly provide ICANN with the bulk of its funding.
>
> ---------------------
>
> John, you should well know that fixing prices is only one element in
> antitrust cases.  I refer you to
> http://www.usdoj.gov/atr/public/guidelines/redir5.htm for other relevant
> considerations.  Contrary to your assumption, Mr. Palage was driving at
> something other than the disconnect to which you have referred -- he was
> specifically commenting on the ERC proposal to grant contracting parties
> voting rights equivalent to the collective remainder of the GNSO
> constituencies.   This would allow registries and registrars effective veto
> power over the proposals put forth by the rest of the community (as the other
> constituencies could never attain the requisite two-thirds vote needed for a
> consensus policy if such a proposal was thwarted by this particular
> self-interested bloc).
>
>
>
> --
> This message was passed to you via the [email-masked] list.
> Send mail to [email-masked] 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 [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Wed, 25 Sep 2002 02:48:40 EDT
From: [email-masked]
Subject: Re: [ga] Re: Antitrust Violations

Rick, 

You may recall that the White Paper stated:  "Governance. The organizing 
documents (Charter, Bylaws, etc.) should provide that the new corporation is 
governed on the basis of a sound and transparent decision-making process, 
which protects against capture by a self-interested faction."

Contracting parties are by definition a self-interested faction.  The recent 
ERC plan to change the voting structure of the GNSO allows for the 
decision-making process to be captured by this group of "contracting 
parties".  Why should we support this naked power grab that enhances the 
voting power of registries and registrars at the expense of the rest of the 
constituencies?

You want a proposal?  Fine.  Adopt the proposed Resolution #2 cited at 
http://www.dnso.org/clubpublic/council/Arc11/msg00044.html which deems any 
variation from the principle of equal stakeholder constituency representation 
and votes in the proposed GNSO council as unacceptable.
- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Tue, 24 Sep 2002 23:55:17 -0700 (PDT)
From: Rick Wesson <[email-masked]>
Subject: Re: [ga] Re: Antitrust Violations

Danny,

I can't support your motion because I'm not in-favor of the Constituency
concept. I lobbied strongly against the constituency model as far back as
'98 in Monterey Mexico, where we decided on equal representation in the
constituency model.

It hasn't worked, its not going to work.

- -rick

On Wed, 25 Sep 2002 [email-masked] wrote:

> Rick,
>
> You may recall that the White Paper stated:  "Governance. The organizing
> documents (Charter, Bylaws, etc.) should provide that the new corporation is
> governed on the basis of a sound and transparent decision-making process,
> which protects against capture by a self-interested faction."
>
> Contracting parties are by definition a self-interested faction.  The recent
> ERC plan to change the voting structure of the GNSO allows for the
> decision-making process to be captured by this group of "contracting
> parties".  Why should we support this naked power grab that enhances the
> voting power of registries and registrars at the expense of the rest of the
> constituencies?
>
> You want a proposal?  Fine.  Adopt the proposed Resolution #2 cited at
> http://www.dnso.org/clubpublic/council/Arc11/msg00044.html which deems any
> variation from the principle of equal stakeholder constituency representation
> and votes in the proposed GNSO council as unacceptable.
>

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

------------------------------

Date: Wed, 25 Sep 2002 00:59:42 -0700
From: [email-masked]
Subject: Re: [ga] Re: Antitrust Violations

Danny be fair warned,
Free legal advice is bad advice!
e

[email-masked] wrote:

> First set of comments in reply to Ray's question, with the following set in
> response to John Berryhill:
>
> regarding the comment that "Therefore it is vital that registrars be
> perceived as holding the power to pay the bills." -- I take this to be a
> reference to the fact that the only "power" the registrars enjoy is the power
> of being perceived to be paying for 55% of ICANN's total budget.
>
> In reality, the registrars are aware that ICANN planned to shift payment
> responsibility away from the registrars and into the sole hands of the
> registries from whom collection would be far easier.
>
> Consider these excerpts from the Minutes of the May 4, 2001 Registrar
> Teleconference:
>
> "Concern over fee structure.  Attempting to remove registrars from ICANN
> billing, because certain registrars are not paying.  What registrars are not
> paying?  Under the proposed agreement the registry will be liable to ICANN
> for registrar fee component. Therefore, registry will bear enforcement
> obligations. Arguably registries
> could collect this new fee component upfront instead of in the rears."
> http://www.icann-registrars.org/pdfs/Minutes-teleconference-4-may-2001.PDF
>
> Further comment on this topic was provided in the Stockholm Registrar minutes:
>
> "Rob Hall then provided an update of the ICANN budget committee. He noted
> that the registrar representatives succeeding in maintaining the status quo
> regarding payment terms. There was a push by ICANN to shift payment
> obligations from the registrars to the registry. There was grave concern
> among registrars that this would dilute our voice in the process."
> http://www.dnso.org/clubpublic/registrars/Arc01/doc00034.doc
>
> Registrars like to think that its "their money" that is making these
> payments, even while we all know that it comes directly from the registrant
> registration fees.  They are scared by the prospect that they will lose power
> if all payments are instead collected by the registries.  In such a case they
> could no longer claim any special treatment based upon the fact that they
> allegedly provide ICANN with the bulk of its funding.
>
> ---------------------
>
> John, you should well know that fixing prices is only one element in
> antitrust cases.  I refer you to
> http://www.usdoj.gov/atr/public/guidelines/redir5.htm for other relevant
> considerations.  Contrary to your assumption, Mr. Palage was driving at
> something other than the disconnect to which you have referred -- he was
> specifically commenting on the ERC proposal to grant contracting parties
> voting rights equivalent to the collective remainder of the GNSO
> constituencies.   This would allow registries and registrars effective veto
> power over the proposals put forth by the rest of the community (as the other
> constituencies could never attain the requisite two-thirds vote needed for a
> consensus policy if such a proposal was thwarted by this particular
> self-interested bloc).
>
> --
> This message was passed to you via the [email-masked] list.
> Send mail to [email-masked] 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 [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Wed, 25 Sep 2002 03:44:31 -0700
From: Jeff Williams <[email-masked]>
Subject: Re: [ga] Re: ICANN & Stability - Motion and second

Jefsey and all assembly members,

  I second this motion.

J-F C. (Jefsey) Morfin wrote:

> However it is nice that the father of the Internet, the President of the US
> Government International Agency for the Internet and the Germany NIC
> President relate on this mailing list, I find very sad the reasons why the
> USG root information is no more maintained acurately. BTW this now makes
> the open roots the authoritative source about legacy TLD entries.
>
> A network is a system for everyone to relate together, it is very sad that
> it is today a system for people in charge of the Internet network stability
> to oppose. We - the users - do not want a new Network split.
>
> I therefore submit the following motion to the GA
>
> "
> ICANN is requested to make sure that nameservers IP address changes are
> reflected in the shortest delays (ie less than 36 hours) in the USG root
> servers system master file.
>
> ICANN is requested to keep informed the Internet Global Community if it
> becomes temporarily unable to maintain that minimum level of quality of
> service.
>
> ICANN is requested to present in the shortest delays a secure scheme
> permitting the IP address changes decided by the TLD Managers to be
> incporated into the USG root file in less than 48 hours after recieving the
> TLD Mamager information.
> "
> jfc
>
> On 19:46 24/09/02, Sabine Dolderer/Denic said:
>
> >Dear Stuart,
> >Dear Vint,
> >
> >(-> cc Elisabeth can you please forward my mail to the NC)
> >
> >
> >On 22.09.2002 05:26 "M. Stuart Lynn" <[email-masked]> wrote:
> > >
> > > Dear Thomas:
> > >
> > > Thank you for your note and your concern.
> > >
> > > You may be aware of the note (appended) that Vint Cerf and I have
> > > sent to the Names Council. We believe it is important to have a
> > > considered technical review of this issue that takes all viewpoints
> > > into consideration.
> > >
> > > Stuart
> > > _____________
> > >
> > > Dear Names Council:
> > >
> > > Over the past few weeks, questions have arisen regarding the IANA
> > > practice of obtaining and reviewing TLD zone files at the time of
> > > changes in the nameservers listed for the TLD in the root zone. The
> > > various points of view expressed suggest to us that it would be
> > > productive to re-examine the objectives for this practice and to
> > > consider alternative means by which those objectives might be reached.
> > > The principal motivation for this practice has been to improve the
> > > quality of the DNS service by validating the format of the
> > > TLD zone files to ensure correct configuration.
> >
> >you should also mention that there are views validating the format of
> >zonefiles has no technical value, is not needed and can therefore be
> >skiped.
> >
> > >
> > > Considering that this examination has until now tended to be done by
> > > the IANA only when a TLD nameserver is being transferred to a new
> > > operating site, we believe it is appropriate to ask the Committee on
> > > Security and Stability (SAC) to look into the matter and to develop a
> > > longer-term recommendation as to what would be the most sound technical
> > > practices to follow to promote better DNS stability; and to provide an
> > > interim recommendation while the broader issues are being explored.
> > > Since this, however, involves domain names, we would want to enquire
> > > whether the DNSO concurs with this approach before asking the SAC to
> > > undertake this analysis.
> >
> >Technical stability of DNS relys much more on the realtime performance of
> >the related server and a timly and redundant answering from different
> >places in the Internet. These things have nothing to do with zonefile
> >information but with long term monitoring and underlying network
> >infrastructure. But even this is in my opinion up to the operator of a TLD
> >and his community.
> >
> > >
> > > Historically, the goal of the practice has been to improve the
> > > quality of data in the DNS.  Pursuing the RFC 1591 policy that the
> > > IANA should make checks to verify nameserver "operational status and
> > > database accuracy",
> >
> >The only database which IANA has to maintain is the database who operates
> >which TLD and what are the related nmameservers. For DE this information is
> >DENIC and a set of nameservers. To check the operational status of our
> >nameservers before entering them in the IANA database you simply has to ask
> >them if they felt authorativ for .de (dig @dns.denic.de .de). I am not
> >aware of other databases which IANA maintain and which they have to check
> >for accuracy.
> >
> > > the IANA follows the practice of obtaining
> > > and technically reviewing TLD zone files as part of the technical checks
> > > it performs when nameserver changes are requested. Although checks for
> > > the most severe database misconfigurations can be performed by other
> > > means, many less severe errors have been detected through this review.
> > > The ordinary result of finding one or more of these less severe errors
> > > is to proceed with the root-zone change, to alert the ccTLD manager of
> > > the error, and to request that it be remedied.
> >
> >If a ccTLD manager wants to optain additional service from IANA like
> >assistance in error checking then it has to be discussed and can be done as
> >long as it didn't took too much ressources. For professional assistance
> >these kind of consultancy services should be left to others like  Men &
> >Mice or others who offer these kind of services on a professional
> >commercial base.
> >
> > >
> > > DNS data accuracy continues to be an important, and by some measures
> > > increasingly urgent, goal.  Recent "Domain Health" surveys conducted
> > > by Men & Mice <http://menandmice.com/6000/6350_eu_survey.html> and
> > > <http://menandmice.com/6000/61_recent_survey.html> have reported
> > > surprisingly high performance error rates in reviews of subdomains
> > > within various TLDs.
> >
> >As Men & Mice is a commercial company offering DNS configuration assistance
> >I am sure that they will welcome your support for their service ;-).
> >
> > > While DNS quality at the TLD level appears to
> > > be much better, discussions at the November 2001 ICANN security
> > > meeting and the Domain Health surveys have demonstrated that it is
> > > important that the community work continuously to maintain and improve
> > > DNS quality.
> >
> >I am sure that you have also learned from that survey that the .DE-zone is
> >quit healthy and thats why we are doing some checks similar to those I
> >discribed above. But we are doing this without checking the zonefile as
> >this - as I pointed out earlier - not needed for the check of DNS quality.
> >
> > > Particularly with increasing requirements from the broader
> > > society for security and trustworthiness within the DNS, it is important
> > > for the ICANN community to develop and implement practices that promote
> > > high-quality DNS data at all levels, and with a higher frequency than
> > > only at times when nameserver changes are contemplated.
> >
> >I am not really convinced. Usually one tries to have a balance between the
> >benefits and the costs of something. Currently a gTLD-level and a lot of
> >ccTLDs there are no checks at all when a domain is inserted in the TLD.
> >DENIC does at least check our delegated domains for nameserver consitency
> >but we didn't check if siemens.de or ibm.de are doing this also. I have
> >some understanding that IANA does also check nameserver consistency at
> >their level and I would recommend to siemens.de and ibm.de to do that also.
> >But I don't think it's DENIC's task to enforce this within siemens.de and
> >ibm.de and I don't think it's IANA's to do so for .de.
> >
> > >
> > > Although with cooperation from the TLD managers (which has historically
> > > been quite high)
> >
> >Historically the DNS software was unable to supress unsolicited
> >zonetransfers and the TLD managers were not asked (at least not between
> >1994 and now, when I am operating it). You shouldn't interpret this a
> >cooperation.
> >
> > > the current IANA practice has served to locate and
> > > allow correction of many DNS errors, recently four TLD managers have
> > > denied the IANA download access to the zone files for their TLDs.
> > > Without having the zone files, there is no reasonably practical method
> > > for a third party to perform some checks of database accuracy.
> >
> >As you have no access to our database it is unclear to me how you want to
> >perform checks if the zonefile we produce is reflecting our database
> >correct.
> >
> > > This
> > > disagreement has resulted in an unfortunate standoff situation that,
> > > perversely, frustrates attempts to locate and correct TLD configuration
> > > errors, and at the same time potentially introduces additional DNS data
> > > errors through configuration mismatches between the DNS data in the root
> > > zone (which remains unchanged) and the affected TLD zones (assuming the
> > > TLD manager proceeds to change the TLD zone).
> > >
> > > This debate has prompted some very helpful initial ideas from the
> > > community regarding possible changes in practices that might be better
> > > suited to achieve the goal of improved DNS data accuracy.  As pointed
> > > out by Thomas Roessler
> > > <http://www.dnso.org/clubpublic/ga/Arc11/msg00206.html>, the current
> > > timing of technical checks may not be optimally suited to the goal
> > > of improving DNS data quality.  As one of us (Stuart) has pointed
> > > out, a strong argument can be made that TLD integrity checks would
> > > be more effective, and the process for making root-zone updates
> > > streamlined, by developing a possibly distributed and delegated process
> > > for performing TLD zone-file reviews on a periodic basis
> > > rather than as part of technical checks performed at the time of
> > > nameserver changes.
> > > <http://www.dnso.org/clubpublic/ga/Arc11/msg00210.html>
> >
> >I think you should also point out in your summary that also while some
> >(Stuart) suggested to performe these checks periodically. Some (CENTR,
> >LACTLD, ccTLD constituency at their meeting in Bucharest, and others on the
> >lists) suggest to stop checking the zones immediately.
> >
> > >
> > > It appears to us that the issues about what practices should be
> > > followed by the IANA, TLD managers, and other participants in the
> > > ICANN process to promote improved DNS data quality is one that is ripe
> > > for examination.  We believe that technical focus of these issues
> > > makes it appropriate to have at least the initial examination and
> > > analysis conducted by the ICANN Security and Stability Advisory
> > > Committee.
> >
> >One big step to improve DNS data quality is to proceed changes in the root
> >much more timely.
> >
> > >
> > > Because the issues also concern domain names (the focus of the DNSO),
> > > however, we would like feedback about whether the Names Council believes
> > > for any reason that it is inappropriate that they be referred to the
> > > Security and Stability Advisory Committee.  Because an early resolution
> > > of these issues would be helpful to all concerned, we would appreciate
> > > your considering the appropriateness of the referral at your earliest
> > > convenience.
> >
> >As this issue is very important for ccTLDs I would also recommend not to
> >decide things without their support.
> >
> >
> >Sabine
> >
> > >
> > > Our mutual interest is to take the opportunity occasioned by these
> > > discussions to encourage the development of more effective methods for
> > > improving DNS data quality at all levels in the system.
> > >
> > > Regards,
> > >
> > > Vint Cerf
> > > Chairman
> > >
> > > Stuart Lynn
> > > President and CEO
> > > _______________
> > > --
> > >
> > > At 3:49 PM +0200 9/19/02, Thomas Keller wrote:
> > > >This mail is being sent on behalf of the Technical Advisory Council of
> > > >DENIC (TACD) which represents the .de registrar community.
> > > >
> > > >Dear Stuart,
> > > >
> > > >with dismay the TACD has noticed that the crucial and long awaited
> > > >changes of the root name servers for the zone .de have not taken place
> >to the
> > > >current day. It even appears that the whole process has come to a stop
> >due to
> > > >misunderstandings between ICANN in fulfillment of its IANA functions and
> > > >the Board of DENIC as well as other ccTLD registries.
> > > >
> > > >To judge about the reasons of the current misunderstanding is out of the
> > > >scope of the TACD but the TACD strongly believes that a mere dispute can
> >not
> > > >be a reason for ICANN to deny a simple technical implementation for any
> >ccTLD
> > > >registry as long as this registry is acting in favor of the local
> >internet
> > > >community.
> > > >
> > > >Therefore the TACD would like to emphasize DENICs request to perform the
> > > >necessary steps as soon as possible.
> > > >
> > > >Please note that not performing the requested changes is not only a
> > > >severe political issue but also jeopardizes the german Internet related
> >and
> > > >Internet dependent industries. All internet business, not only in
> >Germany, is
> > > >built on a foundation of trust that all Internet services are
> > > >reliable and dealt
> > > >with in a highly responsible manner. For the DNS as one of these
> > > >services, if not
> > > >the most important one, not updating the root name servers is
> >endangering
> >this
> > > >trust and might lead to cutbacks of Internet related business,
> > > >impacting  guiltless
> > > >companies and employees. This is a situation which cannot be tolerated
> >by
> > > >TACD nor by the DENIC community which TACD represents.
> > > >
> > > >Out of the above mentioned reasons the TACD wants to urge ICANN to
> >rethink
> >its
> > > >position on this issue and move their political playing field towards a
> >ground
> > > >where no uninvolved party may be harmed.
> > > >
> > > >Tom Keller on behalf of the Technical Advisory Council of DENIC
> > > >
> > > >-
> > > >
> > > >Thomas Keller
> > > >
> > > >Domain Services
> > > >Schlund + Partner AG
> > > >Erbprinzenstr. 4 - 12                                    Tel.
> > > >+49-721-91374-534
> > > >76133 Karlsruhe, Germany                                 Fax
> > > >+49-721-91374-215
> > > >http://www.schlund.de                                   [email-masked]
> > > >
> > > >
> > > >
> > > >
> > > >Am 16.09.2002 schrieb M. Stuart Lynn:
> > > >>  You are assuming, Danny, that the assumptions that underlie
> > > >>  Elisabeth's proposed resolution are correct. They are not. Perhaps
> > > >>  you might be interested in the facts before forming your
> > > >>  "impressions".
> > > >>
> > > >>  There is no threat to Internet stability.  Soon after KPNQwest
> > > >>  announced its suspension of operations, RIPE NCC agreed to assume
> > > >>  operation of the ns.eu.net nameserver (which had formerly been
> > > >  > operated by KPNQwest), and has committed to continue that operation
> > > >  > for as long as necessary to migrate secondary nameservice to other
> > > >>  nameservers. That nameserver has been operating for quite some time
> > > >>  in a sound and stable manner.  The IANA has given priority to
> > > >>  handling requests to migrate from the KPNQwest nameservers, and as it
> > > >>  happens 38 of the 41 requests that have been received to migrate
> > > >>  nameservice from ns.eu.net have been satisfactorily completed.
> > > >>  (Incidentally, 37 of the 38 ccTLDs that have been migrated have no
> > > >>  contractual relationship with ICANN.) There are several other ccTLDs
> > > >>  that have not yet requested to migrate, and the IANA is in the
> > > >>  process of suggesting that they move along to suitable substitute
> > > >>  nameservice as well.  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.
> > > >>
> > > >>  To reiterate, however, there no threat whatsoever to Internet
> > > >>  stability, since the ns.eu.net nameserver continues to function
> > > >>  perfectly.
> > > >>
> > > >>  Stuart
> > > >>
> > > >>
> > > >>  At 4:05 PM -0400 9/16/02, [email-masked] wrote:
> > > >>  >Stuart,
> > > >>  >
> > > >>  >Having read the text of Elisabeth Porteneuve's proposed resolution
> >on
> >name
> > > >>  >server updates (reprinted below), I can't help but get the
> >impression
> >that
> > > >>  >either ICANN/IANA staff is thoroughly incompetent or that you are
> >engaged
> > > >>  >in
> > > >>  >the process of blackmailing the ccTLD community.  It would seem to
> >me
> >that
> > > >>  >some discussion on this topic is warranted as the assertion has been
> >made
> > > >>  >that ICANN itself has threatened the stability of the Internet (a
> >subject
> > > >>  >that I presume you would take seriously).  As the President and
> >Chief
> > > >>  >Executive Officer of this Corporation, that ostensibly deems the
> >stability
> > > >>  >of
> > > >>  >the Internet to be its highest priority, can you comment on why your
> >
> >staff
> > > >>  >has failed to process these updates?
> > > >>  >
> > > >>  >Best regards,
> > > >>  >Danny
> > > >>  >
> > > >>  >
> > > >>  >Whereas the ICANN Evolution and Reform Committee (ERC) has published
> > > >>  >its second implementation report,
> > > >>
> > >
> > >http://www.icann.org/committees/evol-reform/draft-mission-core-values-02s
> > ep02.
> >
> > > >>  >
> > > >>  >htm
> > > >>  >
> > > >>  >Whereas the stability of the universal Internet has been part of
> > > >>  >permanent preoccupations since the White Paper document,
> > > >>  >http://www.icann.org/general/white-paper-05jun98.htm
> > > >>  >
> > > >>  >Whereas on 28 November 1998, both the USG and the ICANN committed
> > > >>  >to abide by the principle of Internet stability in the MoU,
> > > >>  >http://www.ntia.doc.gov/ntiahome/domainname/icann-memorandum.htm
> > > >>  >
> > > >>  >Whereas the ccTLD Managers has been awaiting since years
> > > >>  >for correct IANA ccTLD database services, as explicitly specified
> > > >>  >in the Amendment 2 to the MoU of 11 September 2000, requesting
> > > >>  >for "Documentation of IANA procedures for root zone editing,
> > > >>  >root zone generation, and root zone WHOIS service".
> > > >>  >
> > > >>  >Whereas the ccTLD IANA Service Requirements has been restated
> > > >>  >once more in Bucharest on 25 June 2002 and approved unanimously,
> > > >>
> > >http://www.dnso.org/constituency/cctld/ccTLDbucharest-communique.html
> > > >>  >
> > > >>  >Whereas the ERC reaffirms that "Preserve and enhance the operational
> > > >  > >stability, reliability, security, and global interoperability of
> > > >>  >the Internet" is on top of the list of ICANN Core's values,
> > > >>  >
> > > >>  >Whereas the global interoperability and stability of Internet
> >depends
> > > >>  >on the TLD name servers,
> > > >>  >
> > > >>  >Whereas the recent bankruptcy of KPNQwest, providing secondary
> > > >>  >services to several ccTLD Registries requested for prompt actions
> > > >>  >on IANA side to update the name servers records as requested by
> > > >>  >the ccTLD Managers,
> > > >>  >
> > > >>  >Whereas there is widespread dissatisfaction of ccTLD Managers about
> > > >>  >the ICANN failing to its IANA Function duty, and several name
> >servers
> > > >>  >updates pending since three months (since June 2002),
> > > >>  >
> > > >>  >The NC therefore resolves that:
> > > >>  >The stability of universal Internet is in danger and request
> > > >>  >ICANN to take immediate actions to update ccTLD name servers
> >entries.
> > > >>  >
> > > >>  >http://www.dnso.org/clubpublic/council/Arc11/msg00035.html
> > > >>
> > > >>
> > > >>  --
> > > >>
> > > >>  __________________
> > > >>  Stuart Lynn
> > > >>  President and CEO
> > > >>  ICANN
> > > >>  4676 Admiralty Way, Suite 330
> > > >>  Marina del Rey, CA 90292
> > > >>  Tel: 310-823-9358
> > > >>  Fax: 310-823-8649
> > > >>  Email: [email-masked]
> > > >>  --
> > > >>  This message was passed to you via the [email-masked] list.
> > > >>  Send mail to [email-masked] to unsubscribe
> > > >>  ("unsubscribe ga" in the body of the message).
> > > >>  Archives at http://www.dnso.org/archives.html
> > > >>
> > > >
> > > >gruss
> > > >
> > > >tom
> > > >        O /
> > > >       /|    o
> > > >       / \  \|/
> > > >     wenn ein kind eine blume pflueckt ist das schoen.
> > > >  wenn alle kinder eine blume pfluecken ist die wiese leer.
> > > >
> > > >
> > > >
> > > >Content-Type: application/pgp-signature
> > > >Content-Disposition: inline
> > > >
> > > >Attachment converted: Macintosh HD:Untitled (????/----) (000738DB)
> > >
> > >
> > > --
> > >
> > > __________________
> > > Stuart Lynn
> > > President and CEO
> > > ICANN
> > > 4676 Admiralty Way, Suite 330
> > > Marina del Rey, CA 90292
> > > Tel: 310-823-9358
> > > Fax: 310-823-8649
> > > Email: [email-masked]
> > > --
> > > This message was passed to you via the [email-masked] list.
> > > Send mail to [email-masked] to unsubscribe
> > > ("unsubscribe ga" in the body of the message).
> > > Archives at http://www.dnso.org/archives.html
> > >
> > >
> >--
> >Sabine  Dolderer
> >DENIC eG
> >Wiesenhüttenplatz 26
> >D-60329 Frankfurt
> >
> >eMail: [email-masked]
> >Fon: +49 69 27235 0
> >Fax: +49 69 27235 235
> >
> >
> >--
> >This message was passed to you via the [email-masked] list.
> >Send mail to [email-masked] to unsubscribe
> >("unsubscribe ga" in the body of the message).
> >Archives at http://www.dnso.org/archives.html
> >
> >
> >
> >---
> >Incoming mail is certified Virus Free.
> >Checked by AVG anti-virus system (http://www.grisoft.com).
> >Version: 6.0.386 / Virus Database: 218 - Release Date: 09/09/02

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 [email-masked]
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 [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

End of GA-DIGEST V1 #1436
*************************