Proposed GNSO Council Agenda Thursday, August 19, 2004

This agenda was established according to the Rules of Procedure for the GNSO Council

Coordinated Universal Time UTC 12:00

(5:00 LA, 8:00 Washington DC, 13:00 London, 14:00 Brussels, 21:00 Korea, 22:00 Melbourne

Bruce Tonkin will be chairing the GNSO Council teleconference.
Scheduled time for meeting - 120 mins.

Dial-in number sent individually to each Council member

Item 1: Approval of Agenda

Item 2: Approve the minutes of :
GNSO Council teleconference 20 July 2004
GNSO Council teleconference 05 August 2004

Item 3: Draft initial report on procedure for use by ICANN in considering requests for consent and related contractual amendments to allow changes in the architecture operation of a gTLD registry.

Item 4: Update on policy implementation from ICANN

3.1 Transfers:
(approved by ICANN Board 25 Apr 2003)

Status: Pending implementation on 12 Nov 2004
http://www.icann.org/transfers/policy-12jul04.htm

3.2 WHOIS:
(approved by ICANN Board 27 March 2003)


3.2.1 At least annually, a registrar must present to the Registrant the current WHOIS information, and remind the registrant that provision of false WHOIS information can be grounds for cancellation of their domain name registration. Registrants must review their WHOIS data, and make any corrections.
Status: Implemented
WHOIS data reminder policy:
(in effect 31 Oct 2003)

3.2.2
When registrations are deleted on the basis of submission of false contact data or non-response to registrar inquiries, the redemption grace period -- once implemented -- should be applied. However, the redeemed domain name should be placed in registrar hold status until the registrant has provided updated WHOIS information to the registrar-of-record.

The Task Force observes that the purpose of this policy is to make sure that the redemption process cannot be used as a tool to bypass registrar's contact correction process.

Status: Not yet implemented.

3.2.3

Use of bulk access WHOIS data for marketing should not be permitted. The Task Force therefore recommends that the obligations contained in the relevant provisions of the RAA be modified to eliminate the use of bulk access WHOIS data for marketing purposes. The obligation currently expressed in section 3.3.6.3 of the RAA could, for instance, be changed to read as follows):

"Registrar's access agreement shall require the third party to agree not to use the data to allow, enable, or otherwise support any marketing activities, regardless of the medium used. Such media include but are not limited to e-mail, telephone, facsimile, postal mail, SMS, and wireless alerts."

The bulk-access provision contained in 3.3.6.6 of the RAA would then become inapplicable.

Status: Not yet implemented

3.2.3

Section 3.3.6.5 of the Registrar Accreditation Agreement currently describes an optional clause of registrars' bulk access agreements, which disallows further resale or redistribution of bulk WHOIS data by data users. The use of this clause shall be made mandatory.

Status: not yet implemented.

3.3 Deletes (approved by ICANN Board 24 June 2003)

3.3.1 Uniform deletion practice after domain expiry by registrars

(a) At the conclusion of the registration period, failure by or on behalf of the Registered Name Holder to consent that the registration be renewed within the time specified in a second notice or reminder shall, in the absence of extenuating circumstances, result in cancellation of the registration by the end of the auto-renew grace period (although registrars may choose to cancel the name earlier). As a mechanism for enforcing this requirement, registries may elect to delete names for which an explicit renew command has not been received prior to the expiration of the grace period.

Extenuating circumstances are defined as:
- UDRP action
- valid court order
- failure of a registrars renewal process (which does not include failure of a registrant to respond)
- the domain name is used by a nameserver that provides DNS service to third parties (additional time may be required to migrate the records managed by the nameserver)
- the registrant is subject to bankruptcy proceedings
- payment dispute (where a registrant claims to have paid for a renewal, or a discrepancy in the amount paid)
- billing dispute (where a registrant disputes the amount on a bill)
- domain name subject to litigation in a court of competent jurisdiction
- other circumstance as approved specifically by ICANN

Where a registrar chooses, under extenuating circumstances, to renew a domain name without the explicit consent of the registrant, the registrar must maintain a record of the extenuating circumstances associated with renewing that specific domain name for inspection by ICANN consistent with clauses 3.4.2 and 3.4.3 of the registrar accreditation agreement.

(b) In the absence of extenuating circumstances (as defined in Section 3.1.1), a domain name must be deleted within 45 days of either the registrar or the registrant terminating a registration agreement.

(c) These requirements retroactively apply to all existing domain name registrations beginning 180 days after the implementation of the policy.

(d) Registrars shall provide notice to each new registrant describing the details of their deletion and auto-renewal policy including the expected time at which a non-renewed domain name would be deleted relative to the domain's expiration date, or a date range not to exceed ten days in length. If a registrar makes any material changes to its deletion policy during the period of the registration agreement, it must make at least the same effort to inform the registrant of the changes as it would to inform the registrant of other material changes to the registration agreement (as defined in clause 3.7.7 of the registrars accreditation agreement)."

(e) If a registrar operates a website for domain name registration or renewal, details of its deletion and auto-renewal policies must be clearly displayed on the website.

(f) If a registrar operates a website for domain registration or renewal, it should state, both at the time of registration and in a clear place on its website, any fee charged for the recovery of a domain name during the Redemption Grace Period.

Status: not yet implemented.

3.3.2 Registrar deletion practice after domain name expiry for domain names subject to a pending UDRP dispute

In the event that a domain which is the subject of a UDRP dispute is deleted, a complainant in the UDRP dispute will have the option to renew or restore the name under the same commercial terms as the registrant. If the complainant renews or restores the name, the name will be placed in Registrar HOLD and Registrar LOCK status, the WHOIS contact information for the registrant will be removed, and the WHOIS entry will indicate that the name is subject to dispute. If the complaint is terminated, or the UDRP dispute finds against the complainant, the name will be deleted within 45 days. The registrant retains the right under the existing redemption grace period provisions to recover the name at any time during the Redemption Grace Period, and retains the right to renew the name before it is deleted.

Status: Not yet implemented

Item 5: Update on process for new gtlds

The MOU between ICANN and US Dept of Commerce requires:

Continue the process of implementing new top level domains (TLDs), which process shall include consideration and evaluation of:

a. The potential impact of new TLDs on the Internet root server system and Internet stability;

b. The creation and implementation of selection criteria for new and existing TLD registries, including public explanation of the process, selection criteria, and the rationale for selection decisions;

c. Potential consumer benefits/costs associated with establishing a competitive environment for TLD registries; and,

d. Recommendations from expert advisory panels, bodies, agencies, or organizations regarding economic, competition, trademark, and intellectual property issues.

Define and implement a predictable strategy for selecting new TLDs using straightforward, transparent, and objective procedures that preserve the stability of the Internet (strategy development to be completed by September 30, 2004 and implementation to commence by December 31, 2004).


(5:00 LA, 8:00 New York, 14:00 Paris, 21:00 Korea, 22:00 Melbourne)
----------------------------------------------------------------------------
Local time between April and October, Summer in the NORTHERN hemisphere
----------------------------------------------------------------------------
Reference (Coordinated Universal Time) UTC 12:00
----------------------------------------------------------------------------
Honolulu, Hawai, UTC-10 2:00
California, USA UTC-8+1DST 5:00
Monterrey, Mexico UTC-6+1DST 7:00
Irving, Texas (CST) UTC-6+1DST 7:00
Washington DC, USA (EST) UTC-5+1DST 8:00
Buenos Aires, Argentina UTC-3+0DST 9:00
Sao Paulo, Brazil UTC-3+0DST 9:00
London, United Kingdom UTC+0+1DST 13:00
Brussels, Belgium (CET) UTC+1+1DST 14:00
Barcelona, Spain (CET) UTC+1+1DST 14:00
Karlsruhe, Germany (CET) UTC+1+1DST 14:00
Zeist, Netherlands (CET) UTC +1+1DST 14:00
Stockholm, Sweden (CET) UTC+1+1DST 14:00
Paris, France (CET) UTC+1+1DST 14:00
Seoul, Korea UTC+9+0DST 21:00
Melbourne, Australia UTC+10+0DST 22:00
Auckland, New Zealand UTC+12+0DST 00:00
----------------------------------------------------------------------------
The DST starts/ends on last Sunday of March 2003, 2:00 or 3:00 local time (with exceptions)
----------------------------------------------------------------------------
For other places see: worldclock