October 2003 - council - lists.icann.org

WHOIS Area 3 terms of reference (accuracy)
by Bruce Tonkin 23 Oct '03

23 Oct '03

Title: Improving Accuracy of collected data Participants: - 1 representative from each constituency - ALAC liaison - GAC liaison - ccNSO liaison - SECSAC liaison - liaisons from other GNSO WHOIS task forces Description of Task Force: ========================== Data is collected from registrants at the time of registration to facilitate future contact of the registrant for a range of reasons including business issues (for example problems with payment), security and stability issues (for example relating to fraudulent use of a domain name, or failure of a nameserver associated with a domain name), intellectual property infringement, and other legal issues (e.g use of a domain name as part of a consumer fraud or a criminal activity). Many users of the data perceive that there is an unacceptable level of inaccuracy in the data that compromises its ability to facilitate identifying and contacting registrants. Data quality has been recognised as important by several groups. For example one of the OECD Privacy Guidelines (from: http://cs3-hq.oecd.org/scripts/pwv3/pwhome.htm) states that: "Personal data should be relevant to the purposes for which they are to be used, and, to the extent necessary for those purposes, should be accurate, complete and kept up-to-date"." The OECD Guidelines for Consumer Protection in the Context of Electronic Commerce (from: http://www.oecd.org/dataoecd/5/34/1824782.pdf ) states that: "Businesses engaged in electronic commerce with consumers should provide accurate, clear and easily accessible information about themselves" and "Businesses should not exploit the special characteristics of electronic commerce to hide their true identity or location, or to avoid compliance with consumer protection standards and/or enforcement mechanisms". The ICANN Security and Stability Committee (from: http://www.icann.org/committees/security/whois-recommendation-01dec02.ht m) stated that: "It is essential that Whois data used to provide contact information for the party responsible for an Internet resource is validated at the time of a registrant's initial registration and on a regular basis thereafter." The GNSO constituencies rated the issue of data quality with respect to procedures currently followed by registrars to promote accurate, complete and up-to-date data as one of the top 5 priority issues (see: http://www.gnso.icann.org/issues/whois-privacy/table-whois-privacy-issue .shtml, and issue 6 in the WHOIS Privacy Issues Report at: http://www.icann.org/gnso/issue-reports/whois-privacy-report-13may03.htm ). The main issues associated with data quality include: - verification of data at the time of registration - ongoing maintenance of data during the period of registration - protecting against deliberate submission of false information The types of contact data that may be verified for correctness include name (registrant, admin, technical and billing), domain name, postal address, email address, fax number, phone number, and other domain name related data. Verification software can attempt to verify that a particular data element is correctly formatted and exists. Note however it is often difficult to obtain such software that works on a global basis. Another issue is ensuring that the data is actually associated with the registrant (for example there have been incidents of identity fraud, where the data is completely verifiable but associated with another person). Domain names are provided purely electronically, and rarely involve delivery of a service to a physical address, or delivery to a physical person. This makes automated verification more difficult. The recent WHOIS policy development process created a new policy called the WHOIS data reminder policy (http://www.icann.org/registrars/wdrp.htm) that creates a process where a registrant is reminded on an annual basis to update the WHOIS data. There is also an established process whereby a user of the data may lodge a complaint with a registrar to get the contact data corrected. If the registrant does not correct the information, a registrar may cancel the domain name licence. (see clause 3.7.7.2 of the Registrar Accreditation Agreement http://www.icann.org/registrars/ra-agreement-17may01.htm). The recent WHOIS policy process also included a new policy to ensure that the redemption grace period could not be used as a mechanism to avoid these provisions (see Section 1B of http://www.icann.org/registrars/ra-agreement-17may01.htm). It is difficult to use verification or maintenance approaches for registrants that deliberately provide false information. The high-cost mechanisms to verify contact information with a high degree of uncertainty can be easily evaded by low-cost mechanisms at the disposal of some registrants. In such cases it may be necessary to collect additional information associated with an online registration to aid in contacting the registrant including credit card information, source IP addresses, website traffic logs, or use other approaches to identify registrations with suspected false information. It also may be necessary to create expedited procedures for responding to misuse of a domain name associated with deliberately false information. The purpose of this task force is to develop mechanisms to improve the quality of contact data collected at the time of registration. Out-of-scope ============ To ensure that the task force remains narrowly focussed to ensure that its goal is reasonably achievable and within a reasonable time frame, it is necessary to be clear on what is not in scope for the task force. Given that previous ICANN policy changes (http://www.icann.org/minutes/minutes-27mar03.htm) have addressed issues associated with maintaining accurate information (WHOIS data reminder policy, and mechanisms for handling complaints about inaccurate data), this will not be studied in this task force. The effectiveness of these mechanisms will need to be evaluated by the ICANN staff and reported to the GNSO (for example 12 months after implementation of the policies). Note not all the policy changes agreed by the ICANN Board in March 2003 are implemented as of October 2003. The task force should not consider issues associated with changing the data elements that are collected. This is the subject of a separate task force. The task force should not consider mechanisms for restricting the public display for some data elements, which may lead to a reduction in the provision of false information by those registrants seeking to protect their privacy. This is the subject of a separate task force. Tasks/Milestones ================ - collect information on the current techniques that registrars use to verify that the data collected is correct. For example techniques to detect typing errors by registrants intending to provide correct information. Survey approaches used by cctlds to verify that the contact data collected is correct. - collect information on techniques used by other online service providers (where there is no physical contact with the registrant and no physical delivery of goods or services) to verify that data collected is correct. - create a best practices document for improving data verification based on the information collected that can be applied on a global basis - determine whether any changes are required in the contracts to specify what data verification is necessary at time of collection to improve accuracy - determine what verification mechanisms can be used cost effectively to combat the deliberate provision of false information, and determine whether additional mechanisms are necessary to provide traceability of registrants, or provide for more timely responses for misuse of domain names associated with deliberately false information.

1 0

GNSO Council Carthage Agenda Wednesday, October 29, 2003
by GNSO SECRETARIAT 22 Oct '03

22 Oct '03

[To: council(a)gnso.icann.org; ga(a)gnso.icann.org] [To: announce@gnso.icann.org;liaison6c@gnso.icann.org] Proposed GNSO Council Agenda Wednesday, October 29, 2003 This agenda was established according to the Rules of Procedure for the GNSO Council Coordinated Universal Time UTC 13:00 - see below for local times Bruce Tonkin will be chairing the GNSO Council teleconference. Scheduled time for meeting - 180 mins. Dial-in number sent individually to each Council member who will not be present Item 1. Approval of Agenda Item 2. Summary of last meetings - approval of minutes for 25 Sept 2003 - approval of minutes for 16 October 2003 Item 3. Actions arising from last meeting [30 mins] - Request Discussion with the Board on extension of 3 representatives per constituency until annual meeting in 2004 Item 4. WHOIS terms of reference from GNSO WHOIS Steering Committee [1 hour] Divided into three areas: (1) Restricting access to WHOIS data for marketing purposes (2) Review of data collected and displayed (3) Improving accuracy of collected data Terms of Reference: http://gnso.icann.org/issues/whois-privacy/tor.shtml For discussion and approval by Council. Item 5. Decision regarding WHOIS task force structure [30 mins] Two options were discussed by the GNSO WHOIS Steering Committee, assuming all three areas being studied at the same time, and multiple representatives from each constituency to resource the workload (1) A single task force with 3 working groups (2) Three separate task forces For discussion and decision by Council. Item 6. Motion for an Issues Report on New TLDs [30 mins]: With reference to Section II.C.8 "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)." Motion proposed by Milton Mueller: In order to facilitate compliance with Section II.C.8 of the Memorandum of Understanding between the U.S. Department of Commerce and ICANN, the GNSO Council requests that the Staff Manager produce an Issues Report on the creation and implementation of a regularly scheduled procedure and objective selection criteria for new TLD registries. Item 7. Summary of top 5 UDRP issues [15 mins] Item 8. Budget update [15 mins] GNSO Secretariat to provide: - report on current balance of GNSO account - procedures in place by ICANN to manage the account on behalf of the GNSO). Item 9: Any other business (05:00 LA, 08:00 New York, 14:00 Paris, 22:00 Japan/Korea, Wednesday 29 October, 00:00 Melbourne Thursday 30 October 2003 ---------------------------------------------------------------------------- Local time between October and April , Winter in the NORTHERN hemisphere ---------------------------------------------------------------------------- Reference (Coordinated Universal Time) UTC 13:00 ---------------------------------------------------------------------------- California, USA UTC-8+0DST 05:00 Mexico City, Mexico UTC-6+0DST 07:00:00 Washington DC, USA (EST) UTC-5+0DST 08:00 Buenos Aires, Argentina UTC-3+0DST 10:00 Sao Paulo, Brazil UTC-2+1DST 11:00 London, United Kingdom UTC+0+0DST 13:00 Brussels, Belgium (CET) UTC+1+0DST 14:00 Barcelona, Spain (CET) UTC+1+0DST 14:00 Karlsruhe, Germany (CET) UTC+1+0DST 14:00 Stockholm, Sweden (CET) UTC+1+0DST 14:00 Paris, France (CET) UTC+1+0DST 14:00 Jerusalem, Israel UTC+2+0DST 15:00 Seoul, Korea UTC+9+0DST 22:00 Melbourne, Australia UTC+10+1DST 7:00 Thursday 30, 00:00 Auckland, Wellington, New Zealand UTC+12+1DST 02:00 Thursday 30 ---------------------------------------------------------------------------- The DST starts/ends on last Sunday of October 2003, 2:00 or 3:00 local time (with exceptions) ---------------------------------------------------------------------- For other places see http://www.timeanddate.com/worldclock/

1 0

ICANN President's correspondence to GNSO requesting pdp
by GNSO SECRETARIAT 22 Oct '03

22 Oct '03

[To:council@gnso.icann.org] Please find the ICANN President's correspondence to the GNSO Council Chair regarding the Request for initiation of policy Development Process at: http://www.icann.org/correspondence/twomey-to-tonkin-20oct03.pdf GNSO Secretariat

1 0

GNSO/GAC meeting in Carthage 7, Sunday 26 Oct,19:00
by GNSO SECRETARIAT 22 Oct '03

22 Oct '03

[To:council@gnso.icann.org] Confirming that the meeting between the GNSO and the GAC, planned for Sunday, 26 October 2003 at 19:00 (7pm), is in Carthage 7 on the first floor in the Carthage Palace Hotel. The purpose of the meeting is to brief the GAC on current issues before the GNSO, and to hear of any issues being discussed by the GAC - particularly in regard to WHOIS, UDRP, and Registry services. Refreshments will be served and the room will be open for use well before 19:00. GNSO Secretariat

1 0

GNSO WHOIS Steering Com./ccTLDs proposed meeting:Sunday 26 Oct
by GNSO SECRETARIAT 22 Oct '03

22 Oct '03

[To:council@gnso.icann.org] [To:whois-sc@gnso.icann.org] As requested, the proposed meeting of the GNSO WHOIS Steering Committee with ccTLDS on Sunday 26 October, has been moved to the last slot of the day. http://www.wwtld.org/meetings/cctld/20031026.Carthage-agenda.html Room: Carthage 3 Day 1: 26 October 2003 14:00 - 18:00 Plenary 2 Session Leader: Willie Black Last topic of the day, 16:00 Data Privacy gNSO Whois Steering Group Workshop 29 October, Bruce Tonkin and SG Members GNSO Secretariat

1 0

RE: [council] RE: [whois-sc] ISPCP View on Task Force Discussion
by Cade,Marilyn S - LGCRP 22 Oct '03

22 Oct '03

Milton, I think that reasonable people can have different perspectives. I would like us to discuss the options carefully and with full information and participation within the Council. I understand that you have a proposal on that table; there is a different proposal as well, and both deserve consideration. 202-255-7348c mcade(a)att.com -----Original Message----- From: Milton Mueller [mailto:Mueller@syr.edu] Sent: Tuesday, October 21, 2003 10:47 AM To: Bruce.Tonkin(a)melbourneit.com.au Cc: council(a)gnso.icann.org Subject: [council] RE: [whois-sc] ISPCP View on Task Force Discussion Bruce and Council: As to the options Bruce laid out, I think we already know that One Big Task Force won't work, we tried that with the Whois TF last time. I actually thought we had already solved this problem. We form TF 1 and TF2 separately but simultaneously. We expect TF1 (data mining) to go faster because the issues are narrower. TF2 starts with the (easier) notification issues, but those must be performed separately (and as Bruce notes, WILL be performed seperatley in any case, because the issues and investigations are different). By the time TF2 gets around to the hard issues TF1 may be finished or close to finished. When TF2 is finished, we start TF3. We cannot do TF2 and TF3 simultaneously, because accuracy issues depend too heavily on privacy protections. That is, we can't know how to improve or enforce accuracy until we know what (if any) opt out rights registrants have. Hope this is an acceptable plan to everyone. --MM

2 1

WHOIS area 1 terms of reference
by Bruce Tonkin 22 Oct '03

22 Oct '03

For consideration at the Council meeting on 29 Oct 2003. Note the text assumes that the area will be treated within a separate task force. The Council may decide to combine the three areas into a single task force. Regards, Bruce Title: Restricting access to WHOIS data for marketing purposes Participants: - 1 representative from each constituency - ALAC liaison - GAC liaison - ccNSO liaison - SECSAC liaison - liaisons from other GNSO WHOIS task forces Description of Task Force: ========================== In the recent policy recommendations relating to WHOIS: (see http://www.icann.org/gnso/whois-tf/report-19feb03.htm) it was decided that the use of bulk access WHOIS data for marketing should not be permitted. However, these recommendations did not directly address the issue of marketing uses of Whois data obtained through either of the other contractually required means of access: Port 43 and web-based. Bulk access under license may be only a minor contributor to the perceived problem of use of Whois data for marketing purposes. A subset of a registrar's Whois database that is sufficiently large for data mining purposes may be obtained through other means, such as a combination of using free zonefile access (via signing a registry zonefile access agreement - the number of these in existence approaches 1000 per major registry) to obtain a list of domains, and then using anonymous (public) access to either port-43 or interactive web pages to retrieve large volumes of contact information. Once the information is initially obtained it can be kept up-to-date by detecting changes in the zonefile, and only retrieving information related to the changed records. This process is often described as "data mining". The net effect is that large numbers of Whois records are easily available for marketing purposes, and generally on an anonymous basis (the holders of this information are unknown). The purpose of this task force is to determine what contractual changes (if any) are required to allow registrars to protect domain name holder data from data mining for the purposes of marketing The focus is on the technological means that may be applied to achieve these objectives and whether any contractual changes are needed to accommodate them. In-scope ======== The purpose of this section to clarify the issues should be considered in proposing any policy changes. The task force should consider the effects of any proposed policy changes on the ability of groups such as law enforcement, intellectual property, internet service providers, and consumers to continue to retrieve information necessary to perform their functions. The task force should consider the effects of any proposed policy changes on the competitive provision of domain name services including WHOIS access and transfers, and on the competitive provision of value-added services using WHOIS information. Out-of-scope ============ To ensure that the task force remains narrowly focussed to ensure that its goal is reasonably achievable and within a reasonable time frame, it is necessary to be clear on what is not in scope for the task force. The task force should not aim to specify a technical solution. This is the role of registries and registrars in a competitive market, and the role of technical standardisation bodies such as the IETF. Note the IETF presently has a working group called CRISP to develop an improved protocol that should be capable of implementing the policy outcomes of this task force. However, the task force should seek to achieve an understanding of the various technological means that could be applied to prevent or inhibit data mining with an eye toward evaluating their impact on other uses and their compatibility with the currently applicable contracts. The task force should not review the current bulk access agreement Provisions, except to the extent that these can be improved to enhance protection against marketing uses and to facilitate other uses. These were the subject of a recent update in policy in March 2003. The task force should not study the amount of data available for public (anonymous) access for single queries. Any changes to the data collected or made available will be the subject of a separate policy development process. Tasks/Milestones ================ - collect requirements (e.g., volume, frequency, format of query results) from non-marketing users of contact information (this could be extracted from the Montreal workshop and also by GNSO constituencies, and should also include accessibility requirements (e.g based on W3C standards) [milestone 1 date] - review general approaches to prevent automated electronic data mining and ensure that the requirements for access are met (including accessibility requirements for those that may for example be visually impaired) [milestone 2 date] - determine whether any changes are required in the contracts to allow the approaches to be used above (for example the contracts require the use of the port-43 WHOIS protocol and this may not support approaches to prevent data mining) [milestone 3 date] Each milestone should be subject to development internally by the task force, along with appropriate public comment processes (e.g seeking specific advice from the technical community, or from WHOIS service operators) to ensure that as much input as possible is taken into account.

1 0

RE: [council] Notice of Motion
by Bruce Tonkin 22 Oct '03

22 Oct '03

Hello All, Just a redminder that in the Council meeting in Montreal on 24 June 2003, http://www.dnso.org/dnso/notes/20030624.GNSOmontreal-minutes.html the Council accepted the following report on new gtlds: http://www.dnso.org/dnso/notes/20030612.gTLDs-committee-conclusions-v7.h tml The council decided that: 1. Expansion of the gTLD namespace should be a bottom-up approach with names proposed by the interested parties to ICANN. Expansion should be demand-driven. There is no support for a pre-determined list of new names that putative registries would bid for. 2. In line with ideas set-out in the Lynn paper March 1003[1] the committee endorsed the concept of a set of objective criteria that should be met in any future expansion. The development of this set of objective criteria should be the subject of a new Policy Development Process (PDP). Possible criteria for this PDP are listed below together with some strategies which point to practical, non-burdensome ways in which they can be met. I believe that Milton's motion below is consistent with the decision above. Regards, Bruce > -----Original Message----- > From: Milton Mueller [mailto:Mueller@syr.edu] > Sent: Wednesday, 22 October 2003 12:57 AM > To: council(a)gnso.icann.org > Cc: NCUC-DISCUSS(a)listserv.syr.edu > Subject: [council] Notice of Motion > > > > This motion is intended to be considered at the Carthage > Meeting: > > "In order to facilitate compliance with Section II.C.8 of the > Memorandum of Understanding between the U.S. Department of > Commerce and ICANN, the GNSO Council requests that the Staff > Manager produce an Issues Report on the creation and implementation > of a regularly scheduled procedure and objective selection > criteria for > new TLD registries." > > > >

1 0

Status of PDP process as it applies to WHOIS
by Bruce Tonkin 22 Oct '03

22 Oct '03

Hello All, Just a reminder of the PDP process: http://www.icann.org/general/bylaws.htm#AnnexA With respect to WHOIS, we have had the Staff Manager produce an issues report which contains around 20 issues. This was completed on 13 May 2003: http://www.icann.org/gnso/issue-reports/whois-privacy-report-13may03.htm The Council at its meeting on 22 May 2003: http://www.dnso.org/dnso/notes/20030522.GNSOteleconf-minutes.html "Decided to form a Steering Group - to take the Issues Report - to take the outcome of the Montreal ICANN workshop - to develop a set up terms of reference for one or more task forces on the critical issues - to make recommendations to the GNSO Council" The output of that Steering Group will be available for discussion at the GNSO Council meeting in Carthage. I believe that we are now decisions points 3 and 4 of the policy development process. 3. Initiation of PDP The Council shall initiate the PDP as follows: a. Issue Raised by the Board. If the Board directs the Council to initiate the PDP, then the Council shall meet and do so within fifteen (15) calendar days after receipt of the Issue Report, with no intermediate vote of the Council. b. Issue Raised by Other than by the Board. If a policy issue is presented to the Council for consideration via an Issue Report, then the Council shall meet within fifteen (15) calendar days after receipt of such Report to vote on whether to initiate the PDP. Such meeting may be convened in any manner deemed appropriate by the Council, including in person, via conference call or via electronic mail. c. Vote of the Council. A vote of more than 33% of the Council members present in favor of initiating the PDP will suffice to initiate the PDP; unless the Staff Recommendation stated that the issue is not properly within the scope of the ICANN policy process or the GNSO, in which case a Supermajority Vote of the Council members present in favor of initiating the PDP will be required to initiate the PDP. 4. Commencement of the PDP At the meeting of the Council initiating the PDP, the Council shall decide, by a majority vote of members present at the meeting, whether to appoint a task force to address the issue. If the Council votes: a. In favor of convening a task force, it shall do so in accordance with the provisions of Item 7 below. b. Against convening a task force, then it will collect information on the policy issue in accordance with the provisions of Item 8 below. Regards, Bruce Tonkin

1 0

Proposed agenda for Council meeting Wednesday 29 Oct in Carthage, Tunisia
by Bruce Tonkin 22 Oct '03

22 Oct '03

Scheduled time - 3 hours 1. Approval of Agenda 2. Summary of last meetings - approval of minutes for 25 Sept 2003 - approval of minutes for 16 October 2003 3. Actions arising from last meeting [30 mins] - Request Discussion with the Board on extension of 3 representatives per constituency until annual meeting in 2004 4. WHOIS terms of reference from GNSO WHOIS Steering Committee [1 hour] Divided into three areas: (1) Restricting access to WHOIS data for marketing purposes (2) Review of data collected and displayed (3) Improving accuracy of collected data The terms of reference for these 3 areas will be available in the next 24 hours. For discussion and approval by Council. 5. Decision regarding WHOIS task force structure [30 mins] Two options were discussed by the GNSO WHOIS Steering Committee, assuming all three areas being studied at the same time, and multiple representatives from each constituency to resource the workload (1) A single task force with 3 working groups (2) Three separate task forces For discussion and decision by Council. 6. Motion for an Issues Report on New TLDs [30 mins]: With reference to Section II.C.8 of http://www.icann.org/general/amend6-jpamou-17sep03.htm "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)." Motion proposed by Milton Mueller: In order to facilitate compliance with Section II.C.8 of the Memorandum of Understanding between the U.S. Department of Commerce and ICANN, the GNSO Council requests that the Staff Manager produce an Issues Report on the creation and implementation of a regularly scheduled procedure and objective selection criteria for new TLD registries. 6.Summary of top 5 UDRP issues [15 mins] (GNSO Secretariat to provide current table) 7. Budget update [15 mins] (GNSO Secretariat to provide report on current balance of GNSO account and procedures in place by ICANN to manage the account on behalf of the GNSO). 8. Any other business

1 0