March 2004 - council - lists.icann.org

Registry changes PDP
by Marc Schneiders March 29, 2004

March 29, 2004

I have two fundamental problems with the flow charts/process: 1. (In http://gnso.icann.org/mailing-lists/archives/reg-com/png00004.png sub 3) Why does ICANN have to look at the business side of the proposal? I'd say this is irrelevant to the job of ICANN. Unless it involves monopoly issues, which is more related to the technical implementation (cf. e.g. WLS). Wheter the proposal is sound from a business perspective is none of ICANN's business. 2. Where does the GNSO (users, which I am supposed to represent) come in if staff decides a quick look is OK or no approval needed? I see it in the flow chart, but this is then the repeal process. We all know this is NOT in place. So it is of no use to refer people to that, is it? I may not understand. I do not think it is worthwhile to spend time to device a bureacratic procedure that has no safe guards for users except litigation. Users cannot afford that or are not organised enough to let it materialize. Users make no money from domain names. That explains it. ICANN does not do user protection. I understand that (though feel it is wrong since ICANN manages a restricted market). Those who are in the domain name industry do organise for obvious reasons. Feel free to say that domain name registrants should do the same. They have less incentive though. It is a great principle of law to protect the most weak, even if it is their own fault. So let's do that? Thank you. Marc Schneiders NCUC council rep

1 0

GNSO Council Rome meeting draft minutes 3 March 2004
by GNSO SECRETARIAT March 23, 2004

March 23, 2004

[To: council[at]gnso.icann.org] Dear All, Please find the minutes of the GNSO Council meeting held in Rome on 3 March 2004. If you would like any changes made, please let me know. Thank you. Glen de Saint Géry GNSO Secretariat

1 0

Draft Agenda for GNSO Council meeting 1 April 2004
by Bruce Tonkin March 21, 2004

March 21, 2004

The next GNSO Council meeting is scheduled for: Thursday 1 April UTC 19:00 (2pm Washington, DC, 7pm London, 6am Friday Melbourne, Australia) Item 1: Approval of minutes of last meeting - 3 March 2004 - Actions arising Item 2: Update on WHOIS task forces (30 mins) Receive an update from the WHOIS task force chairs - status of constituency statements - next steps - possible recommendations Item 3:Update on PDP for approval process for gtld registry changes (15 mins) Receive an update from the GNSO Committee chair (Bruce Tonkin) Item 4: Re-assignment of .net (30 minutes) - recommend establish a subcommittee of the Council - establish list of issues to consider and terms of reference (via ICANN staff manager) - review Namescouncil recommendations with respect to .org - collect constituency statements Item 5: new gtlds (30 minutes) - establish list of issues to consider and terms of reference (via ICANN staff manager) - collect constituency statements - consider establishing a task force >From the MOU with the US Dept of Commerce: 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)." Item 5: Any other business Regards, Bruce Tonkin

1 0

Leaving the council
by Jordyn A. Buchanan March 17, 2004

March 17, 2004

Fellow Council members: As many of you are probably aware, the operation of the .pro registry was transferred to a subsidiary of Hostway Corporation. Due to some geographical constraints (I live in New York and the new registry will be based in Chicago), I will no longer be part of the .pro team. The result of all of this is that I no longer work for a registry. As a result, I am resigning from the council, effective immediately. I understand that the gTLD Constituency has already selected Philip Colebrook from the Global Name Registry to replace me on the council. I am confident that Philip will serve admirably in my place. I have enjoyed working with all of you over the past year and a half, and hope that I will have the opportunity to meet with and work with many of you again in the future. Jordyn

2 1

GNSO Council Rome meeting captioning
by GNSO SECRETARIAT March 10, 2004

March 10, 2004

[To: council[at]gnso.icann.org] Please find a record of all the scribing that was done during the Rome meetings at: http://www.icann.org/meetings/rome/ as well as the GNSO Council Rome meeting real time captioning http://www.icann.org/meetings/rome/captioning-gnso-council-03mar04.htm at: http://gnso.icann.org/ http://gnso.icann.org/calendar/ GNSO Council meeting minutes will follow shortly. Thank you. Glen de Saint Géry GNSO Secretariat

1 0

GNSO Council pdp committee captioning
by GNSO SECRETARIAT March 10, 2004

March 10, 2004

[To: council[at]gnso.icann.org] [To: reg-com[at]gnso.icann.org] Please find the GNSO Council Workshop on the APPROVAL PROCESS FOR LOOKING AT CHANGES TO REGISTRY AGREEMENTS, held in Rome on Wednesday 3 March. http://www.icann.org/meetings/rome/captioning-whois-tf1-03mar04.htm Minutes of the meeting will follow shortly Thank you. Glen de Saint Géry GNSO Secretariat

1 0

Preparations for .net re-assignment
by Bruce Tonkin March 7, 2004

March 7, 2004

Hello All, The ICANN Board at its meeting in Rome, passed the following resolution (from http://www.icann.org/minutes/rome-resolutions-06mar04.htm ) "Resolved, [04.18] that in order to prepare for the designation of a transparent procedure by 30 June 2004, the Board authorizes the President to take steps to initiate the process as specified in Section 5.2 of the .net Registry Agreement for designating a successor operator for the .net registry, including referrals and requests for advice to the GNSO and other relevant committees and organizations as appropriate." This implies that the President will be seeking advice from the GNSO. >From the .net registry agreement ( http://www.icann.org/tlds/agreements/verisign/registry-agmt-net-25may01. htm ) "5.2.1 Not later than one year prior to the end of the term of this Agreement, ICANN shall, in accordance with Section 2.1, adopt an open, transparent procedure for designating a successor Registry Operator. The requirement that this procedure be opened one year prior to the end of the Agreement shall be waived in the event that the Agreement is terminated prior to its expiration." "5.2.4 ICANN shall select as the successor Registry Operator the eligible party that it reasonably determines is best qualified to perform the registry function under terms and conditions developed pursuant to Subsection 4.3 of this Agreement, taking into account all factors relevant to the stability of the Internet, promotion of competition, and maximization of consumer choice, including without limitation: functional capabilities and performance specifications proposed by the eligible party for its operation of the registry, the price at which registry services are proposed to be provided by the party, the relevant experience of the party, and the demonstrated ability of the party to manage domain name or similar databases at the required scale." Thus the terms and conditions need to be established via the processes for consensus policy. ie "4.3.1 "Consensus Policies" are those specifications or policies established based on a consensus among Internet stakeholders represented in the ICANN process, as demonstrated by (a) action of the ICANN Board of Directors establishing the specification or policy, (b) a recommendation, adopted by at least a two-thirds vote of the council of the ICANN Supporting Organization to which the matter is delegated, that the specification or policy should be established, and (c) a written report and supporting materials (which must include all substantive submissions to the Supporting Organization relating to the proposal) that (i) documents the extent of agreement and disagreement among impacted groups, (ii) documents the outreach process used to seek to achieve adequate representation of the views of groups that are likely to be impacted, and (iii) documents the nature and intensity of reasoned support and opposition to the proposed policy." Note also that if Verisign is not selected, Verisign has the right under the contract to challenge the "reasonableness" of the decision. Given that a final procedure must be established before 30 June 2004, we should start to think about the specifications/terms and conditions immediately. The Names Council went through a similar process for the re-assignment of .org. >From the DNSO archives see: http://www.dnso.org/dnso/notes/20020205.NCdotorg-to-ICANN.html dated 5 Feb 2002 And http://www.dnso.org/dnso/notes/20020117.NCdotorg-report.html dated 11 Jan 2002 Given the time available, I recommend that the Council form a subcommittee (e.g with 1 rep per constituency) of the Council to review the .org material, and draft a set of terms/conditions for .net consistent with the ICANN mission and core values for consideration by the Council. Please let me know your thoughts. Regards, Bruce Tonkin

1 0

TR : Can you please post this to the relevant list (probably Council)
by GNSO SECRETARIAT March 3, 2004

March 3, 2004

Please find the Comparison of Constituency Statements on New or Changed Services in gTLD Registries drafted by the Staff Manager Barbara Roseman. Thank you. Glen de Saint Géry GNSO SECRETARIAT

1 0

Registry constituency statement
by Bruce Tonkin March 3, 2004

March 3, 2004

Hello All, Attached is the registry constituency statement as a word document, and below is the text equivalent. Regards, Bruce REVISED DRAFT 2 March 04 Registry Constituency Statement This Registry Constituency statement relates to the GNSO Policy Development Process (PDP) on a procedure for use by ICANN in considering requests made by registry operators or sponsors for consents or related amendments to the agreements these entities have with ICANN. In accordance with Section 7(d) (1) of the GNSO Policy Development Process, ICANN initiated a PDP to develop a predictable procedure to handle such requests. The GNSO Council voted to initiate the PDP subject to additional Terms of Reference (TOR) (http://gnso.icann.org/issues/ registry-services/tor-revised.shtml). Both changes to the rights and obligations under the agreements between ICANN and the registries/sponsors under the agreements and non-contractual discussions between registries/sponsors and ICANN are explicitly "out-of scope" of the TOR. This statement does not address procedures relating to the adoption of consensus policies. Each constituency has appointed a rapporteur to solicit constituency views and submit the constituency position in writing to the Council. Introduction This document provides a joint Position Statement by the Registry Constituency, including the operators of the unsponsored gTLDs as well as the sponsors of the three Sponsored TLDs about the development of this Procedure. It is intended for submission by the Registry Constituency rapporteur as the definitive position of the entire Registry Constituency. Position Statement As a Constituency, we welcome the appropriate steps by ICANN and the GNSO Council towards the development of a fair, predictable and timely procedure for ICANN to handle requests for authorizations, approvals or consents required by our contracts or related contractual amendments in which we are interested. The implementation of a fair, predictable and timely procedure by ICANN to handle such requests is in the best interest of our Constituency. Such a procedure would reduce the uncertainty, substantially decrease the time and effort required for the review of proposed changes , and encourage both the unsponsored registries and the communities served by the sponsored registries to improve the gTLDs. Although we believe it is important to develop a predictable procedure for contractual approvals and amendments, specific contractual changes (or changes in the relationship between the registries and ICANN) should not be considered as part of this Policy Development Process. We present here certain concerns, which must be considered by the GNSO Council when developing the Procedure. 1. The procedure should be simple, transparent, and understandable by all stakeholders. We believe that the procedure should be a procedure for the ICANN staff to follow. Except in unusual circumstances, as determined by ICANN staff, the procedure should not involve other constituencies. We favor the use of "post-fact reporting" in cases where changes are of an administrative nature and their impact on the Internet community is limited. Any procedure should be in writing, published on ICANN's web site, and satisfy certain minimum requirements which will be detailed in a separate statement by this constituency. 2. The procedure should be cost-effective and timely. Both the Registry and ICANN will have to employ resources for a period of time to process a request. A procedure should be developed which minimizes the resources on both sides required to submit and review a request. The effort required for the procedure should be commensurate with the change requested. 3. The procedure should take into consideration the characteristics of the TLD in which the request is being made. One size does not fit all, and the same change in one TLD may have a completely different impact than the same change in another TLD. The procedure must take into account the nature and the size of a TLD when measuring the impact of the change. 4. The procedure should not impede development and innovation. If the previous concerns are addressed, then the procedure developed will be simple enough so that it will provide cost-efficient and timely confirmation of new processes for each TLD. Individual differences in the TLDs will be considered during early steps of the review process, and decisions will enable the Registries to develop and offer new services desired by the Internet community quickly and efficiently. 5. The procedure should recognize that the Sponsor represents the views of the sponsored community. It is important to differentiate between changes, which will affect users of a given TLD and changes which will affect the Internet community at large. One of the primary reasons to establish an sTLD is the desire of a specific community to manage its own domain according to its community-specific requirements. Sponsors obtained support of their respective communities and entered into agreements with ICANN to manage the TLD and to develop certain policies for and on behalf of their communities. Sponsored TLDs have developed mechanisms to consider views of the sponsored community when developing its policies. It would be redundant, costly, and inappropriate to try to replicate the process at the ICANN level in situations where the sponsored community has expressed its views already and impact on Internet users at large is limited. Also, as outlined in the FAQs prepared by ICANN staff, certain aspects of the procedure, while not applicable to Sponsored TLDs at the ICANN level, may serve the sTLD communities well as a recommended practice to employ by the Sponsor when dealing with requests from the Registry Operators of sTLDs. 6. The procedure must not diminish the ability of registry operators to operate reliable, secure and stable service to the Internet community. Operation of the DNS is essential to the stability and security of the Internet, and many individuals and businesses, regardless of their size, rely on this operation for their livelihood. In the event of an unexpected situation that threatens the very nature of the service, or may cause serious discomfort to Internet users, Registry Operators must be able to act quickly and at their discretion to ensure continuity of the service while making reasonably and timely effort at keeping ICANN informed. Conclusion The Registry Constituency favors development of a simple, transparent and timely procedure for ICANN staff to handle any requested changes in the registry agreements. We strongly believe that the implementation of such a procedure must take into account appropriate differences among TLDs, respect the role of the sponsored communities in sTLDs, appreciate the different levels of impact a change will have on different Internet constituencies, and favor development and innovation while maintaining the stability and security of the Domain Name System.

1 0

NeuLevel statement
by Thomas Roessler March 1, 2004

March 1, 2004

The NeuLevel statement that was just mentioned is at the following location: <http://gnso.icann.org/issues/registry-services/outreach-process.shtml> -- Thomas Roessler <roessler(a)does-not-exist.org> At-Large Advisory Committee: http://alac.info/

1 0