[whois-sc] Draft 5 of Task force 2
Hello All, Attached is a new red-line draft of Task Force 2. I require comments on this draft within the next 24 hours. I believe I have taken into account the discussion on the mailing list. The main changes are: Description - removed the term "public register" as it seems to have different meanings to different people, I have kept the sense of the original wording that in other public databases there are some options to opt-out of data, and there are some items of data that must be displayed. Purpose (b) - I have made the wording of the purpose more open to reflect that a balance must be achieved between contactability and privacy. I note from a privacy point of view the question is often phrased as "what is the minimal amount of information necessary for the purpose". From a contactability point of view the question might be phrased as "what is the optimal amount of information for contactability, whilst providing mechanisms for protecting privacy". I have chosen somewhere in between these two wording approaches. Task (2) - has been extensively rewritten. I have extended the focus to look not only at the registrant data but also the domain name related data as suggested by Mark Jeftovic, I have added wording similar to the purpose (b), and I have explicitly added the option that the some elements may be made voluntary. I have removed the accuracy term as that is the subject of a separate task force (or working group of a task force :-)). Of course any new data elements that the task force recommends would also need to be subject to methods to achieve accuracy at reasonable cost. The task force could consider the likelihood of achieving accuracy with a particular data element without going into details on how to achieve accuracy. This would be part of the balance between contactability and privacy. I would assume that if you reduce the amount of information displayed, a trade off might be much better accuracy for the data elements that are displayed. The task force could conclude that accuracy of a particular data element would need to be improved. For example it may be easier to achieve an accurate email address, than it is to achieve an accurate postal address on a global basis. See below for a plain text markup. Changes marked [** Regards, Bruce Tonkin Title: Review of data collected and displayed 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: ========================== There are domain name holders that are concerned about their privacy, both in terms of data that is collected and held about them, and also in terms of what data is made available to other parties. In this regard it should be mentioned that there already is existing local law in several jurisdictions regulating this matter. At the same time, domain names, associated email addresses, and web sites located by domain names can be used in connection with fraud, criminal activity, and intellectual property infringement. This gives rise to a need for accurate identification of the registrant, and/or a need to reliably contact the individual or organization that is the registered name holder. Many users of Whois perceive that there is an unacceptable level of inaccuracy in Whois data that compromises its ability to facilitate identifying and contacting registrants. Similar trade-offs between privacy concerns and identification affect the technical functions of Whois. Extensive contact information can assist a registrar or network provider to contact a domain name holder in the event of a technical problem or in the event of domain name expiration. However, a domain name holder may be prepared to make a personal decision to accept a lower standard of service (e.g take their own steps to be reminded of when a domain expires) in return for greater privacy. A domain name holder may be prepared to provide extensive contact information to their domain name provider, but would prefer to control what information is available for public access. Identifiers in other media typically attempt to balance identification and privacy concerns. For example a telephone customer may provide detailed address information to a telephone service provider, but may elect not to have this information displayed in a public whitepages directory. Note however that national laws often permit access to the complete information to groups such as law enforcement and emergency services personnel. Similarly, the ability of persons [** DELETE whose data is listed in various public registers ] to opt out of public disclosure of [** REPLACE these items WITH some data ] may be limited. Although the GNSO has in the past adopted new policies (See http://www.icann.org/gnso/whois-tf/report-19feb03.htm) regarding the accuracy of data and bulk access, the prior Task Force chose to defer considerations of privacy to a future point. Another issue is that there is limited public understanding of the present contractual obligations, including the obligations to disclose to those who provide data the uses to which it will be put, and to obtain their consent. Most domain name holders are probably unaware that their information is being displayed publicly via the present port-43 and interactive web access methods, or is made available to third parties under the bulk WHOIS access agreement. The purpose of this task force is to determine: a) What is the best way to inform registrants of what information about themselves is made publicly available when they register a domain name and what options they have to restrict access to that data and receive notification of its use? b) What changes, if any, should be made in the data elements about registrants that must be collected at the time of registration to [** REPLACE maintain adequate contactability WITH achieve an acceptable balance between the interests of those seeking contact-ability, and those seeking privacy protection]? c) Should domain name holders be allowed to remove certain parts of the required contact information from anonymous (public) access, and if so, what data elements can be withdrawn from public access, by which registrants, and what contractual changes (if any) are required to enable this? Should registrars be required to notify domain name holders when the withheld data is released to third parties? If registrants have the ability to withhold data from public, anonymous access will this increase user incentives to keep the contact information they supply current and accurate. To ensure that the task force remains focussed and that its goal is achievable and within a reasonable time frame, it is necessary to be clear on what is out of scope for the task force. Out-of-scope ============ The task force should not examine the mechanisms available for anonymous public access of the data - this is the subject of a separate task force. The task force should not examine mechanisms for law enforcement access to the data collected. This is generally subject to varying local laws, and may be the subject of a future task force. The task force should not study new methods or policies for ensuring the accuracy of the required data, as this will be subject of a separate task force. The task force should not consider issues regarding registrars' ability to use Whois data for their own marketing purposes, or their claims of proprietary rights to customers' personal data. Tasks/Milestones ================ This Task Force would begin at the same time as the other one and execute its duties in the following order: 1. Examine the current methods by which registrars and their resellers inform registrants of the purpose for which contact data is collected, and how that data will be released to the public. Examine whether policy changes (or published guidelines) are necessary to improve how this information is provided to registrants. 2. Conduct an analysis of the existing uses of the registrant data elements currently captured as part of the domain name registration process. [** REPLACE Develop list of optimal required elements for contact-ability. WITH Develop a list of data elements about registrants and their domains that must be collected at the time of registration to achieve an acceptable balance between the interests of those seeking contact-ability, and those seeking privacy protection?] The intent is to determine whether all of the data elements now collected are necessary for current and foreseeable needs of the community, [** INSERT whether any of the current elements should be made voluntary,] whether any different elements should be added or substituted to improve [** REPLACE contact-ability WITH the balance between contact-ability and privacy], and how the data may be acquired [** DELETE with the greatest accuracy, least cost, and ] in compliance with applicable privacy, security, and stability considerations. 3. Document existing methods by which registrants can maintain anonymity and assess their adequacy. Document examples of existing local privacy laws in regard to display/transmittal of data. Decide what options if any will be given to registrants to remove data elements from public access and what contractual changes (if any) are required to enable this. 4. Taking into account the outcomes in 2 and 3, re-examine the methods by which registrars inform registrants of the use of their contact data by third parties and the options registrants might have to remove data elements from public view. Attachment:
Draft5taskforce2.doc |