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

GA-DIGEST        Thursday, September 19 2002        Volume 01 : Number 1426

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

Date: Wed, 18 Sep 2002 22:05:59 -0700
From: Jeff Williams <[email-masked]>
Subject: Re: [ga] icannatlarge.com

John, Joanna and all assembly members,

  Joanna, I am afraid that John has you here.  Indeed icannatlarge.
is technically in violation of current US Trademark Law.  It is
also so as John points out that ICANN is not defending it's mark either.
I am also surprised that ICANN has not filed a UDRP on ICANNATLARGE.COM.

  John, Joanna also has a valid point as well given the history, that
ICANN has in effect neglected it's responsibility and betrayed
stakeholders/users whole scale and globally.

John Berryhill Ph.D. J.D. wrote:

> Greetings Joanna,
>
> It is a very simple issue.
>
> Does ICANNatlarge have a license to use ICANN's trademarks?  Your answer, in
> about 500 or so words, is "no."
>
> A former Chair of the ICANN Board does not have the authority to grant a
> trademark license, and she wouldn't have had that authority even when she was
> chair.  As Mr. Cerf is fond of explaining, individual board members are not
> entitled to make decisions on behalf of the entire corporation, and Mr. Cerf
> is willing to go to court over that principle (whether or not it applies to
> the dispute actually being litigated).  It doesn't matter if Esther Dyson
> donated, what Mike Roberts thought was a good idea, or how much Denise
> Michelle was paid by whom or for what.
>
> Similarly, trademark licenses are not granted by the collective group of
> cronies you call "ICANN players", and I am completely familiar with the
> history of the effort.
>
> ICANNatlarge.com is not authorized by or affiliated with ICANN, and its use
> of ICANN trademarks is misleading, deceptive and dilutive.  You either have a
> license or you don't, and it is clear that you don't.
>
> But, keep up the good work, since if ICANN does not act to enforce its
> federally registered trademarks, then it will lose them.  In ten years, we'll
> all be ICANN.
>
> Regards,
>
> John
>
> --
> 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

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

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

Date: Thu, 19 Sep 2002 14:29:17 +1200
From: "Peter Dengate Thrush" <[email-masked]>
Subject: [ga] Re: on politics and trust

Dear all,
I am not aware of any such letter.

I have received nothing from Jonathan.

Regards

Peter Dengate Thrush
Barrister
Wellington

644 499 8959
64 21 499 888

fax  644 471 0672

- ----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Saturday, September 14, 2002 2:01 PM
Subject: on politics and trust

> Jonathan,
>
> In your letter to Peter Dengate Thrush (posted to the Council list) you
make
> the reasonable suggestion that <<maybe the "politics" could be ramped down
by
> all>>.
>
> I draw your attention to the Bucharest ccTLD Response to the Committee on
> Evolution and Reform's Blueprint for ICANN Reform in which the following
> request was made:  "In the spirit of "bottom up" development, the ccTLDs
> prefer to continue using the established name for this SO, ("ccSO") which
is
> used in all of our documentation, website domain name, committee names and
> lists, and which reflects the cultural and historical language of the
> internet."
>
> In spite of this eminently reasonable request, the ERC continues to offer
> barbs by pointlessly changing the name of the Supporting Organization for
the
> ccTLD community, the latest version being "ccNSO" referenced in the ERC's
> Second Implementation Report.
>
> Ramping down the politics is a two-way street.  Perhaps you could also pen
a
> similar letter to your fellow Board members who lately seem to be the ones
> engendering this unfortunate climate.  You might also ask them to provide
> some actual answers to Peter's questions.
>
> You have asked Peter to work proactively to rebuild trust, yet by the day
it
> becomes harder and more foolish to trust the Board.  Frankly, I have to
ask,
> why should we?  We have had no indication that the Board is committed to
> honoring the consensus view of the Community (as was demonstrated by the
> Board decision on WLS).  If we can no longer count upon you to act in our
> best interest (and this is not the first time that you have unilaterally
> rejected DNSO recommendations), then please explain to us why you should
> warrant our trust.
>
> We too are listening.
>

- --
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: Thu, 19 Sep 2002 09:02:13 +0200 (CEST)
From: Marc Schneiders <[email-masked]>
Subject: Clean up your own mess before messing with others (Re: [ga] Re: ICANN & Stability)

On Wed, 18 Sep 2002, at 17:48 [=GMT-0700], Karl Auerbach wrote:

> On Wed, 18 Sep 2002, Alexander Svensson wrote:
>
> > This standoff is painted a bit too dramatic by both sides.
>
> I disagree; I find this issue to be extremely important from several
> points of view.  ICANN's claims are technically incorrect

As is it's own zonefile in comparison with the org zone as far as
nameservers is concerned. I have pointed this out before on this list. It
is still the case. Why don't they clean up their own mess before messing
with others?

How on earth can we let some body check our zones if it cannot do its own
right? And does not even correct it, after having been pointed to the
problem... ICANN seems completely deaf and incorrectible.

; <<>> DiG 8.3 <<>> icann.org. ns @ns.isi.edu

;; ANSWER SECTION:
icann.org.              1D IN NS        venera.isi.edu.
icann.org.              1D IN NS        ns.isi.edu.
icann.org.              1D IN NS        ns.ripe.net.
icann.org.              1D IN NS        ns.apnic.net.
icann.org.              1D IN NS        ns.icann.org.
icann.org.              1D IN NS        rip.psg.com.
icann.org.              1D IN NS        svc00.apnic.net.

; <<>> DiG 8.3 <<>> icann.org. ns @a.gtld-servers.net

;; ANSWER SECTION:
icann.org.              2D IN NS        NS.ISI.EDU.
icann.org.              2D IN NS        NS.RIPE.NET.
icann.org.              2D IN NS        RIP.PSG.COM.
icann.org.              2D IN NS        SVC00.APNIC.NET.
icann.org.              2D IN NS        VENERA.ISI.EDU.
icann.org.              2D IN NS        NS.APNIC.NET.

- --
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: Thu, 19 Sep 2002 09:22:08 +0200
From: "Philip Sheppard" <[email-masked]>
Subject: [ga] BC Telephone Conference

This is a multi-part message in MIME format.

- ------=_NextPart_000_0036_01C25FBE.073DA2A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Danny,=20
the purpose of the BC teleconference is to agree on a final version of =
the BC position. Thus the outcome of the call will be made public in the =
posted final version of the paper. If other issues arise on the call we =
will also publish a meeting report.
Philip

- ------=_NextPart_000_0036_01C25FBE.073DA2A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Danny, </FONT></DIV>
<DIV><FONT size=3D2>the purpose of the BC teleconference is to agree on =
a final=20
version of the BC position. Thus the outcome of the call&nbsp;will be =
made=20
public in the posted final version of the paper. If other issues arise =
on the=20
call we will also publish a meeting report.</FONT></DIV>
<DIV><FONT size=3D2>Philip</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

- ------=_NextPart_000_0036_01C25FBE.073DA2A0--

- --
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: Thu, 19 Sep 2002 04:20:57 -0700
From: Jeff Williams <[email-masked]>
Subject: Re: Clean up your own mess before messing with others (Re: [ga] Re: ICANN & Stability)

Marc, Karl and all assembly members,

  You got that right Marc!  Joe Baptista pointed this problem
out over a year ago now as did Jim Fleming.

  To me and many of our [INEGroup] members as well as it seems a number
of other stakeholders/users, that the ongoing incompetence of the ICANN
staff still continues in this and several other areas that have been
discussed
recently, namely DNS security and IPv6 security holes...

Marc Schneiders wrote:

> On Wed, 18 Sep 2002, at 17:48 [=GMT-0700], Karl Auerbach wrote:
>
> > On Wed, 18 Sep 2002, Alexander Svensson wrote:
> >
> > > This standoff is painted a bit too dramatic by both sides.
> >
> > I disagree; I find this issue to be extremely important from several
> > points of view.  ICANN's claims are technically incorrect
>
> As is it's own zonefile in comparison with the org zone as far as
> nameservers is concerned. I have pointed this out before on this list. It
> is still the case. Why don't they clean up their own mess before messing
> with others?
>
> How on earth can we let some body check our zones if it cannot do its own
> right? And does not even correct it, after having been pointed to the
> problem... ICANN seems completely deaf and incorrectible.
>
> ; <<>> DiG 8.3 <<>> icann.org. ns @ns.isi.edu
>
> ;; ANSWER SECTION:
> icann.org.              1D IN NS        venera.isi.edu.
> icann.org.              1D IN NS        ns.isi.edu.
> icann.org.              1D IN NS        ns.ripe.net.
> icann.org.              1D IN NS        ns.apnic.net.
> icann.org.              1D IN NS        ns.icann.org.
> icann.org.              1D IN NS        rip.psg.com.
> icann.org.              1D IN NS        svc00.apnic.net.
>
> ; <<>> DiG 8.3 <<>> icann.org. ns @a.gtld-servers.net
>
> ;; ANSWER SECTION:
> icann.org.              2D IN NS        NS.ISI.EDU.
> icann.org.              2D IN NS        NS.RIPE.NET.
> icann.org.              2D IN NS        RIP.PSG.COM.
> icann.org.              2D IN NS        SVC00.APNIC.NET.
> icann.org.              2D IN NS        VENERA.ISI.EDU.
> icann.org.              2D IN NS        NS.APNIC.NET.
>
> --
> 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

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

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

Date: Thu, 19 Sep 2002 12:05:37 +0200
From: Thomas Roessler <[email-masked]>
Subject: [ga] [fwd] [council] Deletes issues paper for consideration at the Names Council telec onference on 3 October 2002 (from: [email-masked])

fyi

This will also be a topic during the Shanghai meeting of the GA.
- -- 
Thomas Roessler                        http://log.does-not-exist.INFO/

- ----- Forwarded message from Bruce Tonkin <[email-masked]> -----

From: Bruce Tonkin <[email-masked]>
To: [email-masked]
Cc: Deletes Issue Identification Working Group <[email-masked]>
Date: Thu, 19 Sep 2002 19:18:17 +1000
Subject: [council] Deletes issues paper for consideration at the Names Council telec
	onference on 3 October 2002
Envelope-to: [email-masked]
Delivery-date: Thu, 19 Sep 2002 11:22:28 +0200
X-No-Spam: whitelist

Hello All,

The attached issue paper has been prepared by a small team comprising:

Bruce Tonkin
Alexander Svensson
Ross Wm. Rader 
Ram Mohan
Jordyn A. Buchanan
Liu, Hong

The intent of this paper is to stimulate discussion within the DNSO
constituencies, and will be used as a basis for the Names Council to
determine whether to initiate a policy development process for this issue.
The Names Council will discuss and vote on this issue during the
teleconference of 3 October 2002.   Please forward this paper to the
relevant constituency and GA mailing lists.

Regards,
Bruce Tonkin

DELETES ISSUE PAPER

Recent policy development activity in relation to studying transfers in
the transfers task force, providing advice on the Verisign Wait List
Service proposal, and in considering the redemption grace period
proposal has highlighted a range of issues associated with current
delete processes within the gtlds.

Issue 1: Uniform delete practice after domain name expiry by registrars 
========================================================================

The ICANN Registrar Accreditation agreement
(http://www.icann.org/registrars/ra-agreement-17may01.htm) contains the
following clause:

"3.7.5 Registrar shall register Registered Names to Registered Name
Holders only for fixed periods. At the conclusion of the registration
period, failure by or on behalf of the Registered Name Holder to pay a
renewal fee within the time specified in a second notice or reminder
shall, in the absence of extenuating circumstances, result in
cancellation of the registration. In the event that ICANN adopts a
specification or policy concerning procedures for handling expiration of
registrations, Registrar shall abide by that specification or policy."

The above clause leaves open a deadline for deleting a name (and hence
making it available for registration by others) after a domain name is
not renewed.

For the com/net/org registry, the registry operator auto-renews domain
names at the expiry date of a domain.  There is then a 45 day grace
period following the expiry date, when a registrar may delete a name,
and be credited for the renewal fee.  Most registrars tend to explicitly
delete names before the end of the 45 day period, although some do not,
and often names are retained within the registry for an indeterminate
period of time for various reasons.  Sometimes names are withheld from
the market for periods beyond a few months. 

Lack of consistent practice in this area may, amongst other things,
cause substantial potential confusion among registrants.

From
http://www.icann.org/tlds/agreements/verisign/registry-agmt-appc-16apr01.htm
#3

"2.3 Auto-Renew Grace Period

The Auto-Renew Grace Period is a specified number of calendar days
following an auto-renewal. An auto-renewal occurs if a domain name
registration is not renewed by the expiration date; in this circumstance
the registration will be automatically renewed by the system the first
day after the expiration date. The current value of the Auto-Renew Grace
Period is 45 calendar days."

The .biz and .info agreements have similar provisions.

In contrast the .name agreement
(http://www.icann.org/tlds/agreements/name/registry-agmt-appc-5-02jul01.htm)
states:

"The .name Registry Operator does not support an Auto-Renew Grace
Period. Upon the expiration of the term of a domain name registration or
SLD E-mail address registration, the registration is cancelled unless
its term has been explicitly extended by the sponsoring registrar."

Some registrars choose to undelegate a domain name (ie remove it from
the zonefile) so that a registrants email and web services may be
suspended. This often assists in contacting a registrant that has failed
to renew a domain name.  Other registrars may delete the name without
further warning if the name is not renewed.

Some registrars choose not to delete a name even if it has not been
renewed, if there is a dispute (for example UDRP) process underway.
There may be other circumstances where a registrar may not want to
delete the domain name after expiry, even though the renewal has not
been paid.

The end result of the above situation is consumers do not have a
consistent environment for the process of deleting a name.  This applies
to consumers that have a domain name that is expired (they have no idea
how long they have to attempt to renew the name before it is deleted),
and those consumers that desire an existing domain name that is no
longer in use (they have no idea when the name may become available).

Lack of consistent practice in these areas may, amongst other things,
cause substantial confusion among registrants.

A possible policy action is to consider a uniform delete process amongst
gtld registries and registrars.

Issue 2: Deletion following a complaint on WHOIS accuracy 
=========================================================

The ICANN Registrars Accreditation agreement
(http://www.icann.org/registrars/ra-agreement-17may01.htm) requires
registrars to maintain the accuracy of WHOIS information, and to require
a registrant to update inaccurate information.  Note clause 3.7.7.2
states:

"3.7.7.2 A Registered Name Holder's willful provision of inaccurate or
unreliable information, its willful failure promptly to update
information provided to Registrar, or its failure to respond for over
fifteen calendar days to inquiries by Registrar concerning the accuracy
of contact details associated with the Registered Name Holder's
registration shall constitute a material breach of the Registered Name
Holder-registrar contract and be a basis for cancellation of the
Registered Name registration."

Recent pressure on registrars to comply with the clause above in
response to complaints about the accuracy of WHOIS data, may have the
unintended consequence that it could be exploited by those that want to
obtain a domain name from a current registrant.  The introduction of the
proposed Wait List Service may make this a more attractive option.

Given that registrars often have trouble contacting registrants at the
time of domain name renewal due to a registrant not maintaining
up-to-date contact information, the 15 day period may be inadequate and
out of proportion to typical 45 day grace periods available during the
renewal process following expiry.

A possible policy action is to review steps that should be taken by a
registrar to contact a registrant that has not maintained accurate
contact information, which may include a period where the name is first
undelegated before it is deleted, and may include a delete period that
corresponds to grace periods allowed in issue (1) above.

Issue 3 - Registry delete process 
=================================

After a registrar issues a delete command to a registry, registry
operators have various methods for actually deleting a name.
Registrants have also developed various approaches for predicting when
the name will actually become available for registration - although this
isn't an exact science. Typically some registrants (or
registrars/resellers on their behalf) scan changes in the zonefile for
an early warning that a domain name is about to be deleted, they then
send repeated add commands to the registry when they believe that the
name may become available.  Over time this has led to performance issues
for both the registry operator and registrars, as many commands are
executed to try to obtain a deleted name.

Some registrars have suggested that they would like to see a uniform
process for the actual deletion of a domain name.  In this process they
would like to see the registry operator periodically publish a list of
names that are scheduled for deletion, and an exact time or time range when
the
deletion will occur. In addition, some registries would like to see a
standard method for the addition of names, such as a round-robin queue
system, to help alleviate problems from add storms, and to provide an
equitable manner of domain name reallocation.  This may result in a fairer
market for obtaining these names, and may ensure that the "add" storm is
confined to a small
segment of time.

A possible policy action is to determine a uniform process for a
registry to delete and reallocate names that ensures that the market is
equally
informed of the names about to be available, and schedule for when the
names are available.

Issue 4 - Reversal of renewal transactions
==========================================

With reference to the Renew/Extend grace period of the .com Registry
agreement:
http://www.icann.org/tlds/agreements/verisign/registry-agmt-appc-16apr01.htm
(similar wording is in the .biz, .info and .name agreements)

If an error is made during a renew operation, the operation can only be
reversed and the registrar provided with a credit for the renewal, by
deleting the domain name registration.

Given that mistakes can happen, it may be prudent to create a facility that
would allow for renewal commands to be reversed (within a specific time
period after the
initial transaction perhaps) that wouldn't require the deletion and
corrective re-registration of the domain name.

Lack of consistent practice in this area may, amongst other things,
cause a registrant to inadvertently lose their domain name registration.

- ----- End forwarded message -----
- --
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: Thu, 19 Sep 2002 12:25:09 +0200
From: "DNSO Secretariat" <[email-masked]>
Subject: [ga] Deletes Issue Paper for comment

[To: [email-masked]; [email-masked]]
[To: [email-masked]]

The attached issue paper has been prepared by a small team comprising:

Bruce Tonkin
Alexander Svensson
Ross Wm. Rader
Ram Mohan
Jordyn A. Buchanan
Liu, Hong

The intent of this paper is to stimulate discussion within the DNSO
constituencies, and will be used as a basis for the Names Council to
determine whether to initiate a policy development process for this issue.
The Names Council will discuss and vote on this issue during the
teleconference of 3 October 2002.   Please forward this paper to the
relevant constituency and GA mailing lists.

Regards,
Bruce Tonkin

DELETES ISSUE PAPER

Recent policy development activity in relation to studying transfers in
the transfers task force, providing advice on the Verisign Wait List
Service proposal, and in considering the redemption grace period
proposal has highlighted a range of issues associated with current
delete processes within the gtlds.

Issue 1: Uniform delete practice after domain name expiry by registrars
========================================================================

The ICANN Registrar Accreditation agreement
(http://www.icann.org/registrars/ra-agreement-17may01.htm) contains the
following clause:

"3.7.5 Registrar shall register Registered Names to Registered Name
Holders only for fixed periods. At the conclusion of the registration
period, failure by or on behalf of the Registered Name Holder to pay a
renewal fee within the time specified in a second notice or reminder
shall, in the absence of extenuating circumstances, result in
cancellation of the registration. In the event that ICANN adopts a
specification or policy concerning procedures for handling expiration of
registrations, Registrar shall abide by that specification or policy."

The above clause leaves open a deadline for deleting a name (and hence
making it available for registration by others) after a domain name is
not renewed.

For the com/net/org registry, the registry operator auto-renews domain
names at the expiry date of a domain.  There is then a 45 day grace
period following the expiry date, when a registrar may delete a name,
and be credited for the renewal fee.  Most registrars tend to explicitly
delete names before the end of the 45 day period, although some do not,
and often names are retained within the registry for an indeterminate
period of time for various reasons.  Sometimes names are withheld from
the market for periods beyond a few months.

Lack of consistent practice in this area may, amongst other things,
cause substantial potential confusion among registrants.

From
http://www.icann.org/tlds/agreements/verisign/registry-agmt-appc-16apr01.htm
#3

"2.3 Auto-Renew Grace Period

The Auto-Renew Grace Period is a specified number of calendar days
following an auto-renewal. An auto-renewal occurs if a domain name
registration is not renewed by the expiration date; in this circumstance
the registration will be automatically renewed by the system the first
day after the expiration date. The current value of the Auto-Renew Grace
Period is 45 calendar days."

The .biz and .info agreements have similar provisions.

In contrast the .name agreement
(http://www.icann.org/tlds/agreements/name/registry-agmt-appc-5-02jul01.htm)
states:

"The .name Registry Operator does not support an Auto-Renew Grace
Period. Upon the expiration of the term of a domain name registration or
SLD E-mail address registration, the registration is cancelled unless
its term has been explicitly extended by the sponsoring registrar."

Some registrars choose to undelegate a domain name (ie remove it from
the zonefile) so that a registrants email and web services may be
suspended. This often assists in contacting a registrant that has failed
to renew a domain name.  Other registrars may delete the name without
further warning if the name is not renewed.

Some registrars choose not to delete a name even if it has not been
renewed, if there is a dispute (for example UDRP) process underway.
There may be other circumstances where a registrar may not want to
delete the domain name after expiry, even though the renewal has not
been paid.

The end result of the above situation is consumers do not have a
consistent environment for the process of deleting a name.  This applies
to consumers that have a domain name that is expired (they have no idea
how long they have to attempt to renew the name before it is deleted),
and those consumers that desire an existing domain name that is no
longer in use (they have no idea when the name may become available).

Lack of consistent practice in these areas may, amongst other things,
cause substantial confusion among registrants.

A possible policy action is to consider a uniform delete process amongst
gtld registries and registrars.

Issue 2: Deletion following a complaint on WHOIS accuracy
=========================================================

The ICANN Registrars Accreditation agreement
(http://www.icann.org/registrars/ra-agreement-17may01.htm) requires
registrars to maintain the accuracy of WHOIS information, and to require
a registrant to update inaccurate information.  Note clause 3.7.7.2
states:

"3.7.7.2 A Registered Name Holder's willful provision of inaccurate or
unreliable information, its willful failure promptly to update
information provided to Registrar, or its failure to respond for over
fifteen calendar days to inquiries by Registrar concerning the accuracy
of contact details associated with the Registered Name Holder's
registration shall constitute a material breach of the Registered Name
Holder-registrar contract and be a basis for cancellation of the
Registered Name registration."

Recent pressure on registrars to comply with the clause above in
response to complaints about the accuracy of WHOIS data, may have the
unintended consequence that it could be exploited by those that want to
obtain a domain name from a current registrant.  The introduction of the
proposed Wait List Service may make this a more attractive option.

Given that registrars often have trouble contacting registrants at the
time of domain name renewal due to a registrant not maintaining
up-to-date contact information, the 15 day period may be inadequate and
out of proportion to typical 45 day grace periods available during the
renewal process following expiry.

A possible policy action is to review steps that should be taken by a
registrar to contact a registrant that has not maintained accurate
contact information, which may include a period where the name is first
undelegated before it is deleted, and may include a delete period that
corresponds to grace periods allowed in issue (1) above.

Issue 3 - Registry delete process
=================================

After a registrar issues a delete command to a registry, registry
operators have various methods for actually deleting a name.
Registrants have also developed various approaches for predicting when
the name will actually become available for registration - although this
isn't an exact science. Typically some registrants (or
registrars/resellers on their behalf) scan changes in the zonefile for
an early warning that a domain name is about to be deleted, they then
send repeated add commands to the registry when they believe that the
name may become available.  Over time this has led to performance issues
for both the registry operator and registrars, as many commands are
executed to try to obtain a deleted name.

Some registrars have suggested that they would like to see a uniform
process for the actual deletion of a domain name.  In this process they
would like to see the registry operator periodically publish a list of
names that are scheduled for deletion, and an exact time or time range when
the
deletion will occur. In addition, some registries would like to see a
standard method for the addition of names, such as a round-robin queue
system, to help alleviate problems from add storms, and to provide an
equitable manner of domain name reallocation.  This may result in a fairer
market for obtaining these names, and may ensure that the "add" storm is
confined to a small
segment of time.

A possible policy action is to determine a uniform process for a
registry to delete and reallocate names that ensures that the market is
equally
informed of the names about to be available, and schedule for when the
names are available.

Issue 4 - Reversal of renewal transactions
==========================================

With reference to the Renew/Extend grace period of the .com Registry
agreement:
http://www.icann.org/tlds/agreements/verisign/registry-agmt-appc-16apr01.htm
(similar wording is in the .biz, .info and .name agreements)

If an error is made during a renew operation, the operation can only be
reversed and the registrar provided with a credit for the renewal, by
deleting the domain name registration.

Given that mistakes can happen, it may be prudent to create a facility that
would allow for renewal commands to be reversed (within a specific time
period after the
initial transaction perhaps) that wouldn't require the deletion and
corrective re-registration of the domain name.

Lack of consistent practice in this area may, amongst other things,
cause a registrant to inadvertently lose their domain name registration.

- --
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: Thu, 19 Sep 2002 06:44:48 EDT
From: [email-masked]
Subject: Re: [ga] BC Telephone Conference

Philip,

It seems like every time a suggestion is made to improve the transparency of 
the BC, you act to reject the suggestion.  You don't want to provide 
transcripts of your meetings, and you don't want a public-archived discussion 
list.  One has to wonder what you are hiding.  Is it perhaps the fact that no 
one in your constituency actually joins these teleconferences other than the 
BC reps?  I understand that only 10 BC members bothered to show up at your 
last meeting in Bucharest, and of those, 3 were the Council members, 1 was 
the DNSO Secretariat, and another was Tony Holmes from the ISPCP.  

Perhaps it's time to start thinking about removing the BC from the GNSO as it 
no longer appears to be a viable constituency. The Blueprint contemplated the 
removal of constituencies that "cease to be active".  By all indications, 
that seems to describe the status of the BC.  When do you plan to formally 
dissolve your non-transparent and almost useless non-active organization?

- --
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: Thu, 19 Sep 2002 22:45:41 +1200
From: Joop Teernstra <[email-masked]>
Subject: Re: [ga] icannatlarge.com

At 03:27 p.m. 18/09/2002 -0400, John Berryhill Ph.D. J.D. wrote:

>Greetings Joanna,
>
>It is a very simple issue.
>
>Does ICANNatlarge have a license to use ICANN's trademarks?  Your answer, in
>about 500 or so words, is "no."

John,

I did not read  that in Joanna's recite of icannatlarge.com' s history. 
What she makes clear is that ICANN was aware and has condoned the use of 
its name.
I am surprised that you look at this issue in such a  myopic and legalistic 
way.

Icann is not a trading company.  The registration of its "trademark" has 
more to do with registrars who may claim to be "icann accredited" to sell 
Domain Name registrations, than with an organization of individuals, most 
of which still have a letter in their possession that declares them 
....icann members.

The icannatlarge.com website was finished in time to be brought to the 
attention of the Board in Accra. At that time the homepage carried  an 
explanation of the logo that said that the logo would be removed if 
ICANN  would object to it.

Instead, the Board issued a resolution encouraging the formation and 
self-organization of its At Large membership (even though it rejected the 
Board member election as proposed by its At Large Study committee).
After Accra, the website carried on, but added a computer-lib symbol to the 
ICANN logo that was later removed for lack of support among the membership.

<snip>

>ICANNatlarge.com is not authorized by or affiliated with ICANN, and its use
>of ICANN trademarks is misleading, deceptive and dilutive.  You either have a
>license or you don't, and it is clear that you don't.

That is not clear at all. Mr Touton and the ICANN Board and staff has been 
fully aware of the existence and (changing) looks of the site and it is 
ICANN's silence that  has sanctioned the use of the logo.

*One* letter from ICANN, telling us that it does not sanction the use of 
its name and logo by the icannatlarge.com website would have its webmaster 
take it down.
Instantly and with as much publicity as such an  event of dissociation 
would warrant.

The question is not if ICANN has sanctioned this use; the question, now 
being decided by the icannatlarge voting members, is whether *the members* 
still sanction it.

>But, keep up the good work, since if ICANN does not act to enforce its
>federally registered trademarks, then it will lose them.  In ten years, we'll
>all be ICANN.

This is the dilution you speak of. ICANN needs to be "diluted". In a 
political not  commercial context, it is called outreach. As long as either 
ICANN or our members do not say "stop that", we are still waving Icann's flag.

Misleading and deceptive?  That is an absurd accusation.

Any good read of our website makes it abundantly clear what we are about. 
We sign up and organize members for ICANN At Large in accordance with the 
Board's invitation.

  We want our elected representatives to be part of the ICANN 
decisionmaking structure.

If there is anything  misleading and deceptive, it has been the gradual 
abandoning of ICANN's founding principle to be a membership organization.

- --Joop Teernstra LL.M.--
   initial webmaster
www.icannatlarge.com
Sign up and spread the word.

- --
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: Thu, 19 Sep 2002 08:27:14 EDT
From: [email-masked]
Subject: [ga] Policies to govern the launch of new TLDs

Dear Bruce,

Like many in the community, I look forward to the introduction of new TLDs.  
When the general public thinks about ICANN reform, they also tend to focus on 
the topic of expanding the namespace.  The last five out of six public 
comments posted to the ERC's Forum (off-topic category) have requested the 
creation of new TLDs -- these particular contributors were asking for 
namespace for an adult domain (with an earlier post requesting the creation 
of a TLD for Scotland).   

The Final Report of the New TLD Evaluation Process Planning Task Force 
recommended that "The Board should consider to what extent it can initiate 
planning of and proposal solicitations for new rounds of gTLDs in parallel 
with the Evaluation and Monitoring projects recommended above."  In response 
to this report, the Board at its 23 August meeting decided to defer acting on 
the NTEPPTF recommendations until the Shanghai session, and resolved [02.97] 
that the President is directed to produce a plan for action for approval by 
the Board at its meeting in Shanghai, China, in October 2002.

I have to admit that I'm not comfortable with the idea of such an action-plan 
being left totally in the hands of ICANN Staff and Management, as the 
introduction of a new round of TLDs should ideally be governed by policies 
set by the DNSO.  I would ask you, as the current Council Chair, to place on 
the Council agenda the prospect of convening an open Working Group to 
formulate such policy recommendations.
- --
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: Thu, 19 Sep 2002 15:49:39 +0200
From: Thomas Keller <[email-masked]>
Subject: Re: [ga] Re: ICANN & Stability

- --tKy6e3LXpfmanBFM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 t=
he
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  =
=20
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 ccT=
LD
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=
=20
Internet dependent industries. All internet business, not only in Germany, =
is=20
built on a foundation of trust that all Internet services are reliable and =
dealt=20
with in a highly responsible manner. For the DNS as one of these services, =
if not=20
the most important one, not updating the root name servers is endangering t=
his=20
trust and might lead to cutbacks of Internet related business, impacting  g=
uiltless=20
companies and employees. This is a situation which cannot be tolerated by=
=20
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 gro=
und=20
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]    =
 =20

Am 16.09.2002 schrieb M. Stuart Lynn:
> You are assuming, Danny, that the assumptions that underlie=20
> Elisabeth's proposed resolution are correct. They are not. Perhaps=20
> you might be interested in the facts before forming your=20
> "impressions".
>=20
> There is no threat to Internet stability.  Soon after KPNQwest=20
> announced its suspension of operations, RIPE NCC agreed to assume=20
> operation of the ns.eu.net nameserver (which had formerly been=20
> operated by KPNQwest), and has committed to continue that operation=20
> for as long as necessary to migrate secondary nameservice to other=20
> nameservers. That nameserver has been operating for quite some time=20
> in a sound and stable manner.  The IANA has given priority to=20
> handling requests to migrate from the KPNQwest nameservers, and as it=20
> happens 38 of the 41 requests that have been received to migrate=20
> nameservice from ns.eu.net have been satisfactorily completed.=20
> (Incidentally, 37 of the 38 ccTLDs that have been migrated have no=20
> contractual relationship with ICANN.) There are several other ccTLDs=20
> that have not yet requested to migrate, and the IANA is in the=20
> process of suggesting that they move along to suitable substitute=20
> nameservice as well.  Three of the ccTLD requests for migration have=20
> not yet been completed because the ccTLD operators have (despite=20
> repeated requests) failed to cooperate in allowing the IANA to=20
> perform technical checks as provided by longstanding IANA policy.=20
> See the FAQs at <http://www.iana.org/faqs/tld-zone-access-faq.htm>=20
> for a description that we recently posted summarizing for ccTLD=20
> managers the policy, its longstanding basis (documented back to RFC=20
> 1591 in March 1994), and the means by which those seeking to change=20
> the policy should proceed.
>=20
> To reiterate, however, there no threat whatsoever to Internet=20
> stability, since the ns.eu.net nameserver continues to function=20
> perfectly.
>=20
> Stuart
>=20
>=20
> At 4:05 PM -0400 9/16/02, [email-masked] wrote:
> >Stuart,
> >
> >Having read the text of Elisabeth Porteneuve's proposed resolution on na=
me
> >server updates (reprinted below), I can't help but get the impression th=
at
> >either ICANN/IANA staff is thoroughly incompetent or that you are engage=
d=20
> >in
> >the process of blackmailing the ccTLD community.  It would seem to me th=
at
> >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 stabili=
ty=20
> >of
> >the Internet to be its highest priority, can you comment on why your sta=
ff
> >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-02=
sep02.
> >
> >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
>=20
>=20
> --=20
>=20
> __________________
> 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
>=20
=20
gruss

tom =20
       O /  =20
      /|    o  =20
      / \  \|/=20
    wenn ein kind eine blume pflueckt ist das schoen.=20
 wenn alle kinder eine blume pfluecken ist die wiese leer.

- --tKy6e3LXpfmanBFM
Content-Type: application/pgp-signature
Content-Disposition: inline

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9idXy2HigJRNIIhMRAskGAJ4pCVR+5LgAHXxVEydBrZo85jpTvgCdH3vr
4WUucsCduWivyaAUGy+uXNY=
=P1px
- -----END PGP SIGNATURE-----

- --tKy6e3LXpfmanBFM--
- --
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 #1426
*************************