August 2005 - council - lists.icann.org

GNSO Council proposed meeting schedule
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG Aug. 19, 2005

Aug. 19, 2005

[To: council[at]gnso.icann.org] Dear Council members, As agreed on during the GNSO Council call yesterday, please find a proposed schedule for additional GNSO Council meetings: 1. Thursday 25 August 2005 at 12:00 UTC (usual Council call time) GNSO Committee to meet with the Executive committees of the constituencies to discuss the GNSO Review Terms of Reference. 2. Thursday 1 September 2005 at 12:00 UTC GNSO Council to discuss New gTLDs - next steps. 3. Thursday 8 September 2005 at 12:00 UTC GNSO Council/ICANN Board to review the GNSO Council Review Terms of Reference. Thank you very much. Kind regards, Glen -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

Public input on current WHOIS recommendation from Marc Rotenberg, Director of the Electronic Privacy Information Center
by Bruce Tonkin Aug. 19, 2005

Aug. 19, 2005

Hello All, I pass this message on to the Council as part of the public comments regarding the current WHOIS recommendation before the Council. This comment was referenced during our recent GNSO Council teleconference. Regards, Bruce To the ICANN GNSO Council, I have been asked to provide an opinion regarding the proposal to adopt a WHOIS "privacy" policy that simply requires the registrars to provide information about the purpose of the WHOIS service, third-party bulk access, and the categories of information for the registered name holder that will be made available to the public. The current proposal does not advise registrants of any legal rights they may have. It does not provide a redress mechanism if their personal information is misused. It lacks transparency as to the disclosure of their data. And it fails to provide basic contact information for the person responsible for the data. >From the perspective of privacy protection, the current proposal is more likely to undermine Internet privacy than it is to protect it. In this context, notice operates as a disclaimer, i.e. it provides a "take it or leave it" proposition to the registrant. There are not even obligations established to safeguard the data that is collected. The only theoretical basis for a notice-based privacy regime is where there are market-based alternatives that would allow an individual to select from among competing policies But since the ICANN seeks to establish a policy that will cover all registrars, there is no market-based alternative. I would urge you to establish a privacy policy for WHOIS data based on Fair Information Practices. Simply stated, this approach would establish responsibilities for those entities that collect and use personal information and rights for those who are asked to provide personal information. This is the basis of privacy laws all around the world. Significantly, this is also the approach taken in policy frameworks that seek to facilitate the flow of personal information across national borders. This includes, for example, the OECD Privacy Guidelines of 1981 and the recently adopted APEC Privacy Framework. Thank you for your consideration of these views. Sincerely, Marc Rotenberg EPIC REFERENCES APEC Privacy Framework (2004) OECD Privacy Guidelines (1981) M. Rotenberg, "The Privacy Law Sourcebook: United States Law, International Law, and Recent Developments" (EPIC 2003) M. Rotenberg, "Fair Information Practices and the Architecture of Privacy (What Larry Doesn't Get)" 2001 Stanford Technology Law Review 1. D. Solove, M. Rotenberg, "Information Privacy Law" (Aspen 2003)

1 0

Letter from Paul Twomey regarding ICANN strategic planning process
by Bruce Tonkin Aug. 19, 2005

Aug. 19, 2005

Hello All, See attached letter from Paul Twomey. The text of the letter is copied below. Basically the ICANN staff will be publishing an issues paper and the GNSO community needs to respond by 8 October 2005. We will need to think about how best to get input from the constituencies so that we can provide a supporting organisation response, in addition to any individual responses from members of the GNSO community. Regards, Bruce Tonkin 18 August 2005 Dear Bruce, I write in connection with the ICANN strategic planning process for 2005. First of all, I would like to thank you for organising for members of the GNSO community to take part in the consultation process that we conducted in Luxembourg. Based on the feedback that we received from the first plan, we were very keen to gather the views of members of the community at the beginning of the process. Please pass on my thanks to those who participated. You will recall that the output of all the consultation will be an issues paper that will be released in early September. There is still time for the GNSO community to make further comments either through a formal response to the questions that we are using for the consultation (these can be found on the ICANN website tomorrow) or through the contribution of individuals on the public forum on the website. Could I ask you to encourage your members to contribute their views if they have not already done so? In this planning process, we are relying very heavily on the supporting organizations and advisory committees to make their members aware of issues that have relevance and to pull together responses so that the plan is based on a bottom up consultative process. When the issues paper is released, we will be looking for your response to those issues that are relevant to the GNSO community. The timetable for the planning process is very tight and if we are to keep to our schedule, we will need your response by the 8th of October. We will also be seeking your assistance in gathering feedback at other stages of the process. I look forward to your continued support over the coming months as we work together to complete our next strategic plan. Yours sincerely, Paul Twomey President & CEO

1 0

proposed question to legal counsel on whois tf privacy waiver
by Robin Gross Aug. 18, 2005

Aug. 18, 2005

Follow-up to comment on WHOIS Task Force and waiver of privacy rights on GNSO policy call. Robin Gross Proposed question from GNSO Council to ICANN Legal Counsel: As the GNSO undertakes its further review of the WHOIS and what data should be collected and made public, is there a possibility that the language may be misconstrued as a waiver of privacy rights, and if so, how can we best adjust it to avoid this and preserve the original intent of the Task Force?

3 2

GNSO Council teleconference 18 August 2005 MP3 recording
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG Aug. 18, 2005

Aug. 18, 2005

[To: ga[at]gnso.icann.org; announce[at]gnso.icann.org] [To: liaison6c[at]gnso.icann.org; council[at]gnso.icann.org] Please find the MP3 recording of the GNSO Council teleconference, held on August 18, 2005 at: http://gnso-audio.icann.org/GNSO-Council-20050818.mp3 http://www.gnso.icann.org/calendar/#aug Happy listening! -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

[Fwd: Statement from Electronic Privacy Information Center]
by Robin Gross Aug. 18, 2005

Aug. 18, 2005

1 0

Re: [council] RE: request for ICANN action on single letter domain names (now reserved names)
by Marilyn Cade Aug. 18, 2005

Aug. 18, 2005

Thanks, Bruce. These facts inform the discussion tomorrow[ -----Original Message----- From: "Bruce Tonkin" <Bruce.Tonkin(a)melbourneit.com.au> Date: Thu, 18 Aug 2005 09:31:38 To:<council(a)gnso.icann.org> Subject: [council] RE: request for ICANN action on single letter domain names (now reserved names) Hello All, Just to refresh my memory, I checked a couple of the IETF standards on this topic. >From the main DNS standard: RFC 1035 Domain Implementation and Specification November 1987 (http://www.ietf.org/rfc/rfc1035.txt ) "The DNS specifications attempt to be as general as possible in the rules for constructing domain names. The idea is that the name of any existing object can be expressed as a domain name with minimal changes. However, when assigning a domain name for an object, the prudent user will select a name which satisfies both the rules of the domain system and any existing rules for the object, whether these rules are published or implied by existing programs. For example, when naming a mail domain, the user should satisfy both the rules of this memo and those in RFC-822. When creating a new host name, the old rules for HOSTS.TXT should be followed. This avoids problems when old software is converted to use domain names. .... Note that while upper and lower case letters are allowed in domain names, no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical." So basically the DNS protocol itself can handle a range of labels, but the applications of the DNS may have restrictions. So the DNS protocol can handle single letter domain names. Prior to the DNS, most computers maintained host tables (ie tables of computer names and their IP addresses) - effectively like a local phone book as many of you might have in your mobile phone. Thr rules for computer names (Host names) are defined in RFC 952 DOD INTERNET HOST TABLE SPECIFICATION October 1985 http://www.ietf.org/rfc/rfc0952.txt "A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-), and period (.). Note that periods are only allowed when they serve to delimit components of "domain style names". (See RFC-921, "Domain Name System Implementation Schedule", for background). No blank or space characters are permitted as part of a name. No distinction is made between upper and lower case. The first character must be an alpha character. The last character must not be a minus sign or period. A host which serves as a GATEWAY should have "-GATEWAY" or "-GW" as part of its name. Hosts which do not serve as Internet gateways should not use "-GATEWAY" and "-GW" as part of their names. A host which is a TAC should have "-TAC" as the last part of its host name, if it is a DoD host. Single character names or nicknames are not allowed." Note the last sentence above. So the question really comes down to deciding what the impact on existing software would be to allow single letter domain names more broadly. On a related topic I have also heard requests for additional punctuation types such as the "&" sign, or "!" sign in domain names using the ASCII character set. Punctuation characters are used in company names (e.g AT&T, Yahoo!, , and it is now more common for domain names to relate to company names and brand names, than the type of names that were used to label computers in the past. Note these additional characters are excluded from the hostname definition above. As an aside, IDNs do meet the hostname standard, as they are converted from the hostname character set into different characters by end user software. One of the core debates when introducing internationalised domain names, was whether to simple allow UNICODE characters to be represented in the DNS labels directly. Regards, Bruce Tonkin Regards, Bruce Tonkin Regards, Marilyn Cade

1 0

ICANN comments to WGIG report
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG Aug. 18, 2005

Aug. 18, 2005

[To: ga[at]gnso.icann.org; announce[at]gnso.icann.org] [To: liaison6c[at]gnso.icann.org; council[at]gnso.icann.org] Please note: ICANN Comments to the Working Group on Internet Governance (WGIG) Report http://www.icann.org/announcements/ICANN-WGIG-report-comments-15aug05.pdf -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

RE: request for ICANN action on single letter domain names (now reserved names)
by Bruce Tonkin Aug. 18, 2005

Aug. 18, 2005

Some existing single letter domains: i.net INet Corporation q.com Qwest Communications q.net "Q Networks" x.com PayPal x.org The Open Group z.com Nissan

1 0

RE: request for ICANN action on single letter domain names (now reserved names)
by Bruce Tonkin Aug. 17, 2005

Aug. 17, 2005

Hello All, Just to refresh my memory, I checked a couple of the IETF standards on this topic. >From the main DNS standard: RFC 1035 Domain Implementation and Specification November 1987 (http://www.ietf.org/rfc/rfc1035.txt ) "The DNS specifications attempt to be as general as possible in the rules for constructing domain names. The idea is that the name of any existing object can be expressed as a domain name with minimal changes. However, when assigning a domain name for an object, the prudent user will select a name which satisfies both the rules of the domain system and any existing rules for the object, whether these rules are published or implied by existing programs. For example, when naming a mail domain, the user should satisfy both the rules of this memo and those in RFC-822. When creating a new host name, the old rules for HOSTS.TXT should be followed. This avoids problems when old software is converted to use domain names. .... Note that while upper and lower case letters are allowed in domain names, no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical." So basically the DNS protocol itself can handle a range of labels, but the applications of the DNS may have restrictions. So the DNS protocol can handle single letter domain names. Prior to the DNS, most computers maintained host tables (ie tables of computer names and their IP addresses) - effectively like a local phone book as many of you might have in your mobile phone. Thr rules for computer names (Host names) are defined in RFC 952 DOD INTERNET HOST TABLE SPECIFICATION October 1985 http://www.ietf.org/rfc/rfc0952.txt "A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-), and period (.). Note that periods are only allowed when they serve to delimit components of "domain style names". (See RFC-921, "Domain Name System Implementation Schedule", for background). No blank or space characters are permitted as part of a name. No distinction is made between upper and lower case. The first character must be an alpha character. The last character must not be a minus sign or period. A host which serves as a GATEWAY should have "-GATEWAY" or "-GW" as part of its name. Hosts which do not serve as Internet gateways should not use "-GATEWAY" and "-GW" as part of their names. A host which is a TAC should have "-TAC" as the last part of its host name, if it is a DoD host. Single character names or nicknames are not allowed." Note the last sentence above. So the question really comes down to deciding what the impact on existing software would be to allow single letter domain names more broadly. On a related topic I have also heard requests for additional punctuation types such as the "&" sign, or "!" sign in domain names using the ASCII character set. Punctuation characters are used in company names (e.g AT&T, Yahoo!, , and it is now more common for domain names to relate to company names and brand names, than the type of names that were used to label computers in the past. Note these additional characters are excluded from the hostname definition above. As an aside, IDNs do meet the hostname standard, as they are converted from the hostname character set into different characters by end user software. One of the core debates when introducing internationalised domain names, was whether to simple allow UNICODE characters to be represented in the DNS labels directly. Regards, Bruce Tonkin Regards, Bruce Tonkin

1 0