November 2003 - council - lists.icann.org

Constituency comments on Issues report: Registry Services
by GNSO SECRETARIAT Nov. 26, 2003

Nov. 26, 2003

[To: council(a)gnso.icann.org] Please find a text version of Constituency comments on the: Staff Manager's Issue Report on the Need for a Predictable Procedure for Changes in the Operation of TLD Registries http://www.icann.org/gnso/issue-reports/registry-svcs-report-19nov03.htm Message from ALAC to ICANN 7 November 2003 ---------------------------------------------------------------------------- ---- Date: Fri, 7 Nov 2003 21:15:36 +0100 From: Thomas Roessler To: Barbara Roseman Cc: Vittorio Bertola Subject: New registry services / constituency statements Individual Internet users can be affected by the introduction of new registry services in several roles: As registrants, they are affected by services that change the registration system, and by services that might affect their ability to reach an intended audience online. As "DNS consumers", they are affected by changes to DNS behavior. Individual Internet users are also affected by indirect effects that the introduction of new registry services (or, likewise, a failure to introduce such services) might have: A registry service not introduced might be a valuable offer that is not available to Internet users. A registry not able to operate in a commercially viable manner may damage its registrants. A TLD market that is commercially attractive for new operators will give Internet users more choice in the long term, and will enable competition. A registry service that moves choice from the network's edges to its center, though, means less choice for users, and will replace competition at the network's edges to its center, though, means less choice for users, and will replace competition at the network's edges by a monopoly at the center. A change to DNS behavior that specifically targets a single application-level protocol may improve user experience in the short term, but will harm innovation in the long term. These examples demonstrate that there is no simple and universal way to answer the question whether some specific new registry services should be introduced, by whom, and how. In very general terms, we would argue that the introduction of new registry services should be permitted unless publicly detrimental. As far as the implementation of this general principle is concerned, we limit our comments at this point to some preliminary and basic observations: Any decision about the introduction of new registry services should be based on well-defined, objective criteria that must be applied in an even-handed manner. This should not prevent ICANN (or whatever entity is chartered with evaluating proposed registry services) from taking possible market dominance of the party that proposes a registry service into account. When a new registry service is both deliverable at the network's edges and at its core, then preference should -- in general -- be given to delivering this service at the network's edges, in order to foster user choice and competition. (See issue 6.6 from the staff manager's draft report.) The introduction of a new registry service should not create a situation in which commercial gain at the center comes at cost that is incurred by parties at the network's edges, without giving those who incur the cost a choice about it. We appreciate the opportunity to comment, and look forward to further contributing to the development of a fair and objective process for assessing new registry services. Message from J. Scott Evans to Barbara Roseman 7 November 2003 ---------------------------------------------------------------------------- ---- From: "J. Scott Evans" To: <pdp-reports@xxxxxx> Subject: IPC comments for Staff Manager's Issues Report on the Development of a Date: Fri, 7 Nov 2003 17:41:39 -0500 Dear Ms. Roseman: [T]he IPC Leadership thanks the Staff Manager for the opportunity to provide its comments for the New Registry Services Issue Report. Given the monopolistic nature of registry-level services, the members of the IPC may be greatly affected by the introduction of such services. For this reason, the IPC welcomes the initiation of a PDP on new registry services and looks forward to working through the process with other stakeholders in the Internet community. Thank you for the opportunity to provide you with our comments. Kind regards. INTELLECTUAL PROPERTY CONSTITUENCY J. Scott Evans, President Message from Mark McFadden to Barbara Roseman 11 November 2003 ---------------------------------------------------------------------------- ---- From: "Mark McFadden" To: "'Barbara Roseman'" Cc: <ispcp@xxxxxx>, <iaison6c@xxxxxx> Subject: ISPCP Statement on Issues Report for Proposed Registry Services Date: Tue, 11 Nov 2003 12:21:21 -0600 Regarding the Proposed Issues Report on Registry Services Internet Service Providers and Connectivity Providers Constituency The ISPCP Constituency has a direct connection with a significant body of Internet stakeholders. Our customers - those people connected to the Internet - are the people and organizations most affected by unexpected changes in the Internet. This includes the introduction of new or modified registry services. Naturally, the ISPCP constituency needs to be a significant contributor to the Registry Services PDP process. ISPs are in a unique position to help guide policy development on new registry services. As those who have been largely responsible for the stability of the Internet, we believe that it is vitally important that the GNSO and its Council balance the need to move quickly on potential registry services while carefully thinking through operational and legal impacts of any recommendations. Our constituency actively supports the principle of maintaining the stability that the Internet has always enjoyed. Specifically, we believe that there is a requirement for technical, security and stability reviews for any newly proposed registry service. In addition, we believe that any significant change to registry services - that significantly changes or alters fundamental functions of DNS related services - should also be subject to an explicit, public, and extensive security, stability and technical review. No other group in the GNSO is as well positioned as the ISPCP to coordinate the technical evaluation of the protocol and operational impacts of a proposed change to registry services. Our constituency works daily with both the protocol standards that make the DNS work and is fully aware of the operational issues that are not part of the protocols, but which are embedded in the operational behavior of Internet protocols and services. Fundamentally, our constituency believes that: No new registry service should be introduced without an explicit, public evaluation of its technical, stability and security implications; No significant changes to registry services should take place that have the potential to significantly change the behaviour of underlying Internet services; The ISPCP constituency should be a central contributor to any discussion of the technical implications of the introduction of new registry services; All constituencies should be bound by the "principle of least astonishment" in the development of new services that affect the foundation protocols of the Internet; and, All participants in GNSO constituencies should be bound by principles of operational security and stability for the Internet's user community. The ISP community must be a central part of the PDP process and any process that evaluates any future registry service offerings. If the ISPCP is not an explicit participant in the process, they must be able to participate by identifying appropriate expert analysts who can represent the operational interests of ISPs. On behalf of the ISPCP Constituency, Mark McFadden ISPCP Secretariat Message from Ross Wm. Rader to Barbara Roseman 14 November 2003 ---------------------------------------------------------------------------- ---- Date: Fri, 14 Nov 2003 10:15:49 -0500 From: "Ross Wm. Rader" Barbara, I write to you on behalf of Tucows Inc. and those registrars that chose to provide me with the feedback I solicited in my message to the Registrar Constituency of November 4, 2003 (<http://www.gnso.icann.org/mailing-lists/archives/registrars/msg00820.html> ) concerning your draft report, "Excerpt from Draft Version of Staff Managers Issues Report for the Development of a Process for the Introduction of New or Modified Registry Services". This communication is not an official communication of the Registrar Constituency and should not be viewed as such. Thank you in advance for taking the time to review these (late) comments concerning your report excerpt. The excerpt is quite comprehensive and will likely serve as a useful basis for discussion and resolution of the issues you have identified. There are however three items of specific interest to registrars that you may wish to consider for inclusion in your document; Specifically determining the definition of a "registry service". This is very unclear to the registrars that I spoke to and will be the lynchpin in any discussions moving forward. There is a strongly held belief held by members of the constituency that there needs to be a distinction drawn between the evaluation of services that benefit from the registry having exclusive access to the TLD database and those that do not. Clarifying the intended nature of the registry contracts. This is not so much a matter for the policy development process, but rather, a statement that the ICANN Staff or Board can make to clarify whether the existing registry contracts are, as one member put it "...intended to be in the form of an outsourced arrangement where a registry operator provides a specified service (e.g domain name registration) for a specified price (e.g $6) for the ICANN community, OR is the registry agreement intended to be in the form of a licence right to operate a particular TLD and generate revenue based on the services possible from such a role (subject to some maximum price controls on core services)?" First examining the question of whether or not new registry services should be introduced prior to examining the question of how new registry services should be introduced. We would appreciate specific clarification on each of these questions. Given that a significant portion of the policy development process is analysis, we must ensure that we promote a complete and thorough analysis of the salient issues. The answers to each of these question will shape the nature of the policy development discussion on a very fundamental level and it is imperative that the community proceeds with the policy development process with the context that answers to these questions can provide. We therefore strongly urge that these matters are considered in some way by your report. I thank you again for your time and attention to this matter. Please do not hesitate to contact me if you require further clarification regarding the issues that I raise with this message. Warm regards, Ross Wm. Rader Tucows Inc. Message from Jeff Neuman to Barbara Roseman 7 November 2003 ---------------------------------------------------------------------------- ---- From: "Neuman, Jeff" To: Barbara Roseman, Paul Twomey, John Jeffrey, Kurt Pritz, pdp-reports@xxxxxx, Vint Cerf, Alejandro Pisanty Cc: GNSO Secretariat, GNSO Council, Tina Dam Subject: Unsponsored gTLD Registries Statement on Registry Services Date: Fri, 7 Nov 2003 15:54:55 -0500 UNSPONSORED REGISTRIES STATEMENT Regarding the Proposed Issues Report on Registry Services The gTLD Registries Constituency of the Generic Names Supporting Organization is currently comprised of the three Sponsored and six Unsponsored Registry Operators, including Afilias, Ltd. (.info), DotCooperation, LLC (.coop), Global Name Registry (.name), Musedoma (.museum), NeuLevel, Inc. (.biz), Public Interest Registry (.org), RegistryPro (.pro), SITA (.aero) and VeriSign (.com & .net). On behalf of the six Unsponsored gTLD Registry Operators, we submit the following statement set forth below: BACKGROUND Each of the gTLD Registry Operators has entered an agreement with the Internet Corporation for Assigned Names and Numbers which governs the relationship between ICANN and the individual registry operator. It should be noted that only the Unsponsored Registry Agreements have any provisions regarding "Registry Services." In addition, the Unsponsored Registry contracts only provide that ICANN consent to the price of a new "Registry Service" so long as the operation as such service does not truly threaten the technical stability of the domain name system. While this constituency recognizes the need for an ICANN procedure for prompt technical and security impact review of proposed "Registry Service", with a predictable, streamlined and appropriate market-based approach, the contracts themselves do not give ICANN or any third party, including any of the GNSO Constituencies, Supporting Organizations, Task Forces or Advisory Committees, the ability to consent to any other aspects of "Registry Services." The applicable contracts do not provide a role for ICANN with respect to prices or specifications for services or products provided by registries that are not "Registry Services" as defined in such agreements. To the extent that ICANN wishes to increase its scope and/or powers with respect to "Registry Services", it may only do so in accordance with its agreements or with the express written consent of those with which it has contracts (namely, the Registry Operators and Accredited Registrars). In addition, the meaning of such agreements will be governed according to applicable legal principles. It cannot be said that any interpretation by one party after having entered the agreement is binding on the other party or evidences ambiguity. In addition, interpretations offered by third parties have no particular relevance in determining the meaning intended by the parties to the relevant agreements. To the extent that there are any disputes over the meaning of any terms within ICANN's Agreements with the registries, there is a built in dispute resolution process in the contracts. Such dispute resolution does not involve any of the GNSO Constituencies, Supporting Organizations, Task Forces or even Advisory Committees. SPECIFIC COMMENTS ON ISSUES REPORT The gTLD Registries Constituency is extremely concerned about the issues raised in the "Excerpt from Draft Version of Staff Manager's Issues Report for the Development of a Process for the Introduction of New or Modified Registry Services." Not only are most of those issues irrelevant to the introduction of "Registry Services" as defined in the applicable contracts with gTLD Unsponsored Registries, but it also inappropriately suggests that parties other than ICANN and the gTLD Registry Operators might be entitled to prevent the introduction of otherwise lawful new "Registry Services." As stated above, many of these issues involve contractual interpretation that involve only the parties to those contracts, and not the ICANN community as a whole. ICANN may not unilaterally, or through the policy development process, promulgate rules or regulations interpreting these agreements without the consent of the registry operators. Any attempt to do so would be considered a violation of those agreements and subject to the dispute resolution process set forth in such agreements. It is the gTLD Registries Constituency's view that many of the topics identified in the "Issues Report" should not be addressed by the GNSO, Supporting Organizations or Advisory Committees, but by the ICANN staff/board and the gTLD Registry Operators. IMPACT OF PDP PROCESS ON GTLD REGISTRIES To state the obvious, if there is any one constituency of the GNSO that this PDP process potentially affects, it is the gTLD Registries, specifically the Unsponsored Registries. Not only does the introduction of "Registry Services" impact the competitive environment in which we operate, the investment which we are able to make in our businesses, but ultimately, it affects the very survival of our businesses. Without a procedure for prompt technical and security impact review of proposed "Registry Service" with a predictable, streamlined and appropriate market-based approach by which ICANN exercises its rights with respect to Registry Services, the future of domain name registries is in jeopardy. RESERVATION OF RIGHTS As the ICANN has posted only a portion of the Issues Report, the gTLD Registries reserve the right to comment on the complete Issues Reports, when such report is released. In addition, the comments contained herein do not address the substance of the issues raised in the report, but merely provide, as we were asked to do, an impact statement. Afilias, Ltd. Global Name Registry NeuLevel, Inc. Public Interest Registry RegistryPro, Inc. VeriSign, Inc. Jeffrey J. Neuman Chair, gTLD Registries Constituency e-mail: jeff.neuman(a)neustar.us GNSO Secretariat

1 0

Issues Report source material
by GNSO SECRETARIAT Nov. 26, 2003

Nov. 26, 2003

[To: council(a)gnso.icann.org] Message forwarded from Barbara Roseman regarding: http://www.icann.org/gnso/issue-reports/registry-svcs-report-19nov03.htm The statements received in the production of the current Issue Report will be posted Wednesday morning, Pacific Time. I apologize for the delay. Regards, Barbara Roseman

1 0

Timetable for production of source data
by Ross Wm. Rader Nov. 26, 2003

Nov. 26, 2003

I was hoping to have heard further word regarding the release of the source comments made to ICANN staff during the solicitation period leading up to the release of the recent staff manager's report on the registry services PDP recommendations. Is there are timetable for the release of these source submissions or any further word on even if they are forthcoming at all? Is this something that I should bring up with staff directly or is there protocol that can be followed? I view this data as being a critical to conducting an appropriate analysis of the staff manager's report. Thanks in advance, -- -rwr "Don't be too timid and squeamish about your actions. All life is an experiment. The more experiments you make the better." - Ralph Waldo Emerson Got Blog? http://www.blogware.com My Blogware: http://www.byte.org

1 0

DRAFT2 terms of reference on ICANN procedure for approving contractual approvals or amendments related to the operations of a gtld registry
by Bruce Tonkin Nov. 25, 2003

Nov. 25, 2003

Hello All, I have revised the attached draft to be specific about gTLDs (as the GNSO does not develop policy for cctlds). Thus I have replaced "TLD" with "gTLD" in all places. I would expect that any policy development completed by the GNSO would be a useful best practices document for the policy bodies of each cctld. Regards, Bruce Title: ====== Procedure for use by ICANN for contractual approvals or contractual amendments to allow changes in the architecture or operation of a gTLD registry Description of Task Force: ========================== ICANN has agreements with registry operators (for unsponsored gTLDs) and sponsors (for sponsored gTLDs). In the agreements, ICANN designates the operator (or sponsor) as the sole operator (or sponsoring organization) for the gTLD. In exchange, the operator or sponsor agrees that the gTLD registry will be operated according to various specifications, policies, and other requirements. These agreements constrain the freedom of a gTLD registry or sponsor to make changes in the architecture or operation of the registry that would not conform with those agreements, absent ICANN's prior consent. ICANN has agreed that it will not unreasonably withhold or delay this consent. Some examples of where ICANN is required to give consent include changes to the fees for registry services, changes to the list of domain names registered to the registry operator, and changes to the functional or performance specifications included in a registry agreement. Many changes approved by ICANN in recent history have been minor and should have been approved in under 30 days, and in other cases changes have been more substantial, but not so substantial as to justify decision making processes running for 6 months or longer. Where ICANN is required to give consent to a change, registry operators require ICANN to make decisions using a timely, transparent and predictable process. Under the unsponsored registry agreements, ICANN is also required to not unreasonably restrain competition and, to the extent feasible, promote and encourage robust competition; and not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and not single out a Registry Operator for disparate treatment unless justified by substantial and reasonable cause. The purpose of this policy development process is to create a policy concerning the essential characteristics of the process by which ICANN considers registry operator or sponsor requests for contractual approvals or contractual amendments to allow changes in the architecture or operation of a gTLD registry. Out-of-scope ============ Changes to the nature of the agreements between ICANN and registry operators (e.g removing the requirement to meet functional and performance specifications, and replacing with a more general requirement to ensure security and stability). This will be the subject of further policy development associated with the review of the current proof of concept for new TLDs, and the development of policies governing the introduction of new gTLDs. Additional obligations on gTLD registry operators or gTLD sponsors beyond what is already specified in their existing agreements. In-scope ======== The development of a "quick-look" procedure for quick approval of changes that do not harm the legitimate interests of third parties, threaten stability or security, nor contravene any existing ICANN policy. The development of a more comprehensive process for when the "quick-look" process used by ICANN staff results in concerns of ICANN staff that allows ICANN to obtain qualified outside expertise, including through consultation with competition and technical experts. Mechanisms to protect the confidentiality of requests for contractual approvals or contractual amendments to prevent unnecessary and premature disclosures of proprietary commercial information to competitors. Tasks/milestones ================ (1) Develop guidelines for when approval is required to make a change based on the existing registry agreements. (for action by ICANN staff in consultation with registry operators and sponsors) (2) Develop a check list of issues to consider when approving a change (3) Develop a process and timeline for responding to a request including "quick-check" phase, and where a quick-check indicates a need for further work - a timeline for obtaining expert advice and consultation with significantly affected entities. (4) Develop a process and timeline for an appeals procedure for use by registry operators.

1 0

Timeslot for GNSO council calls
by Bruce Tonkin Nov. 25, 2003

Nov. 25, 2003

Hello All, I have received a few requests to change the time of GNSO Council calls. Philip Sheppard provided me with a table showing the timezones for GNSO council participants. This is a very helpful table. I have added the General Counsel (John Jeffries) - but there may be additional ICANN staff based in Los Angeles required on the call (so the slot for John Jeffries may affect from 1-3 people at a time). I want to try to involve the ICANN staff in our calls as much as possible to ensure good cooperation. You will note from the attached that a time around UTC 19 or 20 is a reasonable compromise - but it does mean in the evening for most of Europe and very early for Jisuk Woo. For our next council meeting (probably around 18 Dec as currently scheduled) we can try UTC 1200. This will make a late night for Jisuk (9pm start) and a very early morning for ICANN staff (4am start), but does provide a nicer time for Europe. Thus we could potentially rotate the times between UTC 1200 and UTC 1900. Note the time for the next call is scheduled as UTC 1900. Any other ideas? Regards, Bruce

1 0

RE: [council] GNSO Council agenda Tuesday, December 2, 2003: Corrections
by Bruce Tonkin Nov. 24, 2003

Nov. 24, 2003

Hello Glen, For the avoidance of confusion - please update item 3 of the agenda to relate to a "gTLD registry" instead of a "TLD registry". The GNSO Council only deals with issues associated with gTLD registries, and not cctld registries. Regards, Bruce

1 0

GNSO Council agenda Tuesday, December 2, 2003: Corrections
by GNSO SECRETARIAT Nov. 22, 2003

Nov. 22, 2003

[To: council(a)gnso.icann.org; announce(a)gnso.icann.org] [To: ga(a)gnso.icann.org; liaison6c(a)gnso.icann.org] In the GNSO Council agenda for Tuesday, 2 December, 2003 http://gnso.icann.org/meetings/agenda-02dec03.shtml Please note following CORRECTIONS: Replace: Proposed GNSO Council Agenda Thursday , December 2, 2003 with Proposed GNSO Council Agenda Tuesday , December 2, 2003 Replace: (11:00 LA, 14:00 New York, 20:00 Paris, 04:00 Japan/Korea, Friday 21 November, 06:00 Melbourne Friday 21 November 2003 with (11:00 LA, 14:00 New York, 20:00 Paris, 04:00 Japan/Korea Wednesday 3 December, 06:00 Melbourne Wednesday 3 December 2003 Please forgive any inconvenience caused by these errors. GNSO Secretariat

1 0

REMINDER: Request for public comment on Descriptions of work for 3 WHOIS Task Forces
by GNSO SECRETARIAT Nov. 22, 2003

Nov. 22, 2003

[To: council(a)gnso.icann.org; announce(a)gnso.icann.org] [To: ga(a)gnso.icann.org; liaison6c(a)gnso.icann.org] REMINDER: Request for Public comment on: http://gnso.icann.org/comments-request/ The Descriptions of Work for the 3 task Forces: Title: Restricting access to WHOIS data for marketing purposes http://gnso.icann.org/issues/whois-privacy/tor.shtml Please send comments to: <dow1 at gnso.icann.org> * Title: Review of data collected and displayed http://gnso.icann.org/issues/whois-privacy/tor2.shtml Please send comments to: <dow2 at gnso.icann.org> * Title: Improving Accuracy of collected data http://gnso.icann.org/issues/whois-privacy/tor3.shtml Please send comments to: <dow3 at gnso.icann.org> * *Please replace the [at] in the address by [@] COMMENT PERIOD ENDS 28 NOVEMBER 2003, 23:00 GMT Thank you in anticipation for the time taken to comment. GNSO Secretariat ---------------------------------------------------------------------------- ---- ---------------------------------------------------------------------------- ----

1 0

MP3 recording of the GNSO Council teleconference Nov 20
by GNSO SECRETARIAT Nov. 21, 2003

Nov. 21, 2003

[To: ga(a)gnso.icann.org; announce(a)gnso.icann.org] [To: liaison6c(a)gnso.icann.org; council(a)gnso.icann.org] Please find the MP3 recording of the GNSO Council teleconference, held on November 20, 2003 at: http://gnso-audio.icann.org/GNSO-20030020.mp3 Happy listening! GNSO Secretariat gnso.secretariat(a)gnso.icann.org

1 0

Policy development process without a task force
by Bruce Tonkin Nov. 21, 2003

Nov. 21, 2003

Hello All, During the call today there were some questions raised about the policy development process should a task force not be appointed. The bylaws in this regard state: "a. If the Council decides not to convene a task force, the Council will request that, within ten (10) calendar days thereafter, each constituency appoint a representative to solicit the constituency's views on the issue. Each such representative shall be asked to submit a Constituency Statement to the Staff Manager within thirty-five (35) calendar days after initiation of the PDP. b. The Council may also pursue other options that it deems appropriate to assist in the PDP, including appointing a particular individual or organization to gather information on the issue or scheduling meetings for deliberation or briefing. All such information shall be submitted to the Staff Manager within thirty-five (35) calendar days after initiation of the PDP. c. The Staff Manager will take all Constituency Statements, Public Comment Statements, and other information and compile (and post on the Comment Site) an Initial Report within fifty (50) calendar days after initiation of the PDP. Thereafter, the PDP shall follow the provisions of Item 9 below in creating a Final Report." With respect to the process above, it covers the step of gathering constituency statements, but doesn't give the opportunity for discussion of the statements amongst the constituencies prior to completing the initial report. I recommend that under (b) above ("Council may also pursue other options that it deems appropriate to assist in the PDP"), that the Council augment the process described above by forming a committee of the whole council with the objective of working closely with the ICANN staff manager to develop an initial report that is close to a consensus position (e.g via fortnightly meetings). This may require the staff member to organise the constituency statements into a consistent report, and organise a teleconference amongst council members to discuss these positions and attempt to identify where areas of consensus emerge. It will also be an opportunity for a dialog between the council members and the ICANN staff to ensure that a proposed policy is implementable by ICANN staff. This avoids large gaps in time between when the council formally initiates the PDP and the Council receives an initial report to consider. I would separate the roles of "committee of the whole council" as a forum where views are shared with the objective of iteratively reaching a consensus position and a forum where guidance can be provided to the staff manager during the preparation of reports, and a formal meeting of the council to approve a particular policy. A separate public mailing list can be created for the purpose of discussion of a particular policy area independent from the main council mailing list. Regards, Bruce Tonkin

1 0